Vpp unnecessary flash writes

[ridax67]

Beta 24 is much better at a oiding flash writes in Vpp mode. No writes every 15 minutes now.

But at startup allow ac grid charging and vpp_status are always set. In most cases these writes are not needed as they don't reset between runs, so if you test if they need to be set first, you will avoid a lot of flash writes for frequent restarters.

[johanzander]

Thanks for the report and for confirming beta24 fixed the periodic 15-minute writes.

Looking at the code (solax_modbus_growatt_controller.py / ha_api_controller.py): at startup we already do a read-first approach — read_and_initialize_from_hardware reads vpp_status/remote_control from the inverter (a plain read, no write) and skips writing vpp_status/allow_ac_grid_charging if the read confirms they're already in the desired state. So the guard you're asking for is supposed to already be in place for those two registers.

The likely explanation for what you're seeing: if the vpp_status HA entity returns unavailable/None right at startup (e.g. entity not yet populated after a reload), the code falls back to assuming "not confirmed" and rewrites it — which would happen more often for frequent restarters, matching your report.

To confirm before making a fix, could you attach a debug log bundle from a startup where this happens? Specifically we're looking for the line:

Growatt VPP: initialised from hardware — status=... remote_control=...

right after startup, to see what value was actually read. That'll tell us whether it's a read-timing issue (entity not ready yet) or something else.

[ridax67]

I have modified my solar modbus plugin a little so it logs all modbus writes (minus the VPP in RAM only) and those logs say you are in the write function.

2026-07-27 07:40:19.925 WARNING (MainThread) [custom_components.solax_modbus.plugin_growatt] growatt: Modbus register write — address=30100 value=1 unit=1
2026-07-27 07:40:20.979 WARNING (MainThread) [custom_components.solax_modbus.plugin_growatt] growatt: Modbus register write — address=30410 value=1 unit=1

Bess logg

2026-07-27 07:40:19 | INFO | core.bess.battery_system_manager:2461 - Schedule update required: Modbus intent count differs: 0 vs 96
2026-07-27 07:40:19 | INFO | core.bess.solax_modbus_growatt_controller:152 - Creating VPP schedule from strategic intents
.
.
2026-07-27 07:40:19 | INFO | core.bess.ha_api_controller:2019 - Growatt VPP: status -> Enabled
2026-07-27 07:40:19 | INFO | core.bess.ha_api_controller:2036 - Growatt VPP: allow AC charging -> Enabled
2026-07-27 07:40:21 | INFO | core.bess.ha_api_controller:2069 - Growatt VPP: remote control -> Enabled, power=0%
2026-07-27 07:40:23 | INFO | core.bess.battery_system_manager:2487 - Schedule applied successfully
.
.
2026-07-27 07:40:24 | INFO | core.bess.solax_modbus_growatt_controller:431 - Growatt VPP: initialised from hardware — status=Enabled remote_control=Enabled

bess-debug-2026-07-27-075654.md

[ridax67]

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

The read-first guard the reporter is asking for already exists and is correctly implemented — but on every fresh restart it runs after the very writes it's supposed to gate, because a shortcut added in #394 forces a full schedule-apply cycle (including VPP writes) from inside the startup health check, before the hardware-read step that seeds the guard has had a chance to run. This isn't the owner's "entity unavailable at startup" theory either — the debug bundle shows a clean health check with no sensor unavailability; the VPP registers read back Enabled/Enabled correctly, just too late to matter for that cycle.

Evidence

• core/bess/battery_system_manager.py:521 — start() calls self._run_health_check() before line 526's self._initialize_tou_schedule_from_inverter() (which calls read_and_initialize_from_hardware, the method that seeds the guard).
• core/bess/battery_system_manager.py:2940-2952 (added in fix: retry startup schedule build when sensors recover but no schedule exists #394, commit de3ce77):

  if self._current_schedule is None:
      logger.info(
          "No schedule exists yet and all required sensors are "
          "healthy — retrying the initial schedule build"
      )
      now = time_utils.now()
      current_period = now.hour * 4 + now.minute // 15
      self.update_battery_schedule(current_period=current_period)

  self._current_schedule is None on every fresh process start (__init__), so this fires unconditionally inside _run_health_check() — i.e. before step 2 of start() runs.
• core/bess/solax_modbus_growatt_controller.py:96-104 — the guard's defaults: _vpp_status_confirmed = False, _last_written_vpp_remote_control = None. These are only corrected by read_and_initialize_from_hardware (lines 423-445), which hasn't run yet when the fix: retry startup schedule build when sensors recover but no schedule exists #394 shortcut fires.
• core/bess/solax_modbus_growatt_controller.py:308-320 (_ensure_vpp_status_enabled) and :322-359 (_apply_period_vpp) — with the guard state still at its __init__ defaults, command_changed is trivially True and _vpp_status_confirmed is False, so both set_growatt_vpp_status(True) / set_growatt_vpp_allow_ac_charging(True) and set_growatt_vpp_period(...) fire unconditionally, regardless of actual hardware state.
• This matches the reporter's own log excerpt exactly, and explains the surprising order (the "initialised from hardware" line trailing the writes, not preceding them):

  07:40:19 | Schedule update required: Modbus intent count differs: 0 vs 96   <- battery_system_manager.py:2461, fired from inside _run_health_check
  07:40:19 | Growatt VPP: status -> Enabled                                  <- ha_api_controller.py:2019, unconditional write
  07:40:19 | Growatt VPP: allow AC charging -> Enabled                       <- ha_api_controller.py:2036, unconditional write
  07:40:21 | Growatt VPP: remote control -> Enabled, power=0%                <- ha_api_controller.py:2069, unconditional write
  07:40:23 | Schedule applied successfully
  07:40:24 | Growatt VPP: initialised from hardware — status=Enabled remote_control=Enabled   <- solax_modbus_growatt_controller.py:431, runs AFTER the writes it was meant to gate
  

• Debug bundle (bess-debug-2026-07-27-075654.md): system_uptime_hours: 0.0 with 8 restart cycles that morning, health check Overall Status: OK with no sensor-unavailability warnings — rules out the "entity unavailable at read time" hypothesis for this event. control_mode: vpp, all three VPP entities already read Enabled at export time (i.e., these writes were re-asserting a state the hardware was already in).
• Secondary, narrower gap: read_and_initialize_from_hardware (solax_modbus_growatt_controller.py:423-445) never seeds _last_written_vpp_power from hardware — only _vpp_status_confirmed and _last_written_vpp_remote_control are seeded. So even once the ordering above is fixed, the first _apply_period_vpp call after a restart will still write set_growatt_vpp_period once (since power_pct != None is trivially true when remote control is enabled), even if the target power matches what's already on hardware.

Proposed fix

Move the hardware-read step (_initialize_tou_schedule_from_inverter, i.e. read_and_initialize_from_hardware) so it runs before _run_health_check() in start() — or, more narrowly, seed the VPP guard state ahead of the #394 retry-schedule-build shortcut so the very first update_battery_schedule() call of a process always sees hardware-confirmed guard state, not __init__ defaults. Separately, extend read_and_initialize_from_hardware to also seed _last_written_vpp_power (e.g. from get_growatt_vpp_power or equivalent, if the platform exposes a readback) so the first post-restart period write is skipped too when the target power already matches hardware.

Risks / open questions

• Need to confirm the platform actually exposes a readable "current VPP power" register/entity to seed _last_written_vpp_power from — if not, that part of the guard may be structurally unfixable at read-time and would need a different mechanism (e.g. defer only the power write, not the whole guard).
• Reordering start() needs to preserve why fix: retry startup schedule build when sensors recover but no schedule exists #394 put the retry-schedule shortcut inside the health check in the first place (recovering from sensors being transiently unavailable at startup) — the fix should not reintroduce that regression while fixing this one.
• The reporter's posted screenshot wasn't accessible during this analysis; it may show corroborating entity-history state but isn't needed for the diagnosis above.

---

Reply @claude-bot fix to implement and open a draft PR.

[ridax67]

The fix worked