Confusing presentation (inverter table)

[ridax67]

What happened

So far beta 27 has worked fine re the two Vpp fixes, but it is too early to make any conclusions on that maybe.

But I am really confused about the inverter schedule presentation. 6.00-6.15 it says solar storage and was in load first, so that presentation is correct, but I wonder why it runs as solar storage that period (not that it did any difference as there wasn't any pv input today at that time).

But now (7.15-ish) it is running in solar export, which is logical, but the table shows inverter mode load first. The inverter is running in grid first power 0 mode so it is running correct but shouldn't the table show grid first and export 0?

Debug bundle

Please drag-and-drop bess-debug-2026-07-29-072102.md from your Downloads folder into the editor below before submitting.
The file contains your version, settings, recent logs, and the raw HA discovery dump that the maintainers need to reproduce the issue.

[ridax67]

[johanzander]

Analysis

Root cause confirmed for the question in this thread ("shouldn't the table show grid first / export 0?"): yes, and it's a display bug, not an optimizer or hardware-control bug.

What's actually happening on your inverter: The optimizer picked SOLAR_EXPORT for this period. On control_mode=vpp, that intent is translated by _intent_to_vpp() (core/bess/solax_modbus_growatt_controller.py:300-340) into power=0%, remote_control=True — which per the Growatt VPP protocol is a grid-first hold. That matches exactly what you're seeing on the physical inverter.

Why the UI says "Load First" instead: The Schedule Overview / Current Mode labels come from a separate, static lookup table, INTENT_TO_MODE (core/bess/inverter_controller.py:60-67), where SOLAR_EXPORT -> "load_first". That table was written for register/TOU-based control, where SOLAR_EXPORT genuinely does mean load-first with discharge held at 0. The VPP controller (SolaxModbusGrowattController) never overrides this table or the methods that read it (get_period_settings() / get_all_tou_segments()), so it inherits the TOU-oriented label even though its own VPP write logic diverges for this one intent. LOAD_SUPPORT, BATTERY_EXPORT, and GRID_CHARGING happen to coincidentally display correctly under VPP; SOLAR_EXPORT is the one case where the static label and the actual VPP hardware outcome disagree.

Fix direction: get_period_settings() / get_all_tou_segments() need to derive the displayed mode from the actual control_mode-specific behavior (e.g. delegate to _intent_to_vpp() for VPP installs) instead of the static TOU-era table.

More broadly, this points at a design question worth addressing rather than patching in isolation: the "Mode" concept (load_first/battery_first/grid_first) is inherently a TOU-register concept, and doesn't map cleanly onto VPP's per-period power+remote_control model. We're going to think about how the UI should represent intent/behavior for non-TOU control modes rather than just relabeling to match, and will follow up here before opening a fix PR.

Unresolved: the earlier question in this thread (why 06:00–06:15 showed SOLAR_STORAGE with no PV) can't be diagnosed — no debug bundle was attached to the issue (the template placeholder is still in the issue body). If you can attach bess-debug-2026-07-29-072102.md, I can take a look at that separately.

[ridax67]

This debug file is downloaded a couple of hours later don’t know if it is still of any value?

bess-debug-2026-07-29-101820.md