fix: apply the intra-period discharge gate to LOAD_SUPPORT on VPP (#520)

[bess-agent]

Summary

• VPP half of Apply the intra-period discharge gate to LOAD_SUPPORT on both platforms (settles #384/#393) #520. fix: apply the intra-period discharge gate to LOAD_SUPPORT on TOU (#520) #524 landed TOU; VPP was still releasing control unconditionally, so the same house, same prices and same plan behaved differently depending on which inverter you own.
• The DP's authorization is now read once and handed to whichever path can spend it — TOU as a rate ceiling, VPP as a mode.
• Scope is the apply layer only, per the Option A decision recorded on Apply the intra-period discharge gate to LOAD_SUPPORT on both platforms (settles #384/#393) #520.

Root cause

The gate was scoped by and self._inverter_controller.discharge_rate_is_load_following, which is False in VPP mode (solax_modbus_growatt_controller.py:159 → _is_tou_control). VPP's discharge_rate is an immediate forced power command rather than a load-following ceiling (#324), so the rate path is correctly excluded — but the decision was never applied at all, and LOAD_SUPPORT released control unconditionally (#413).

Fix

DP decision	VPP command	Effect
gate open (or no decision)	vpp_power=0, remote disabled	load_first self-use — inverter covers the spike (#413, unchanged)
gate closed	vpp_power=+1, remote enabled	battery_first hold — spike imported, battery preserved

Closed maps to +1, not 0, and that is the whole subtlety. With remote control enabled the sign of vpp_power selects firmware priority, and <= 0 is grid_first — which per #118 still draws self-consumption from the battery. Only > 0 releases the house to grid/solar. Writing 0 would read as a hold and quietly keep discharging. #466 established the same mapping for IDLE for the same reason, so this is not a new claim about the hardware.

None ("no decision for this period") stays distinct from False ("the DP decided against it") — the three-state convention #526 established. The retry and discharge-inhibit paths carry no decision and keep #413's unconditional release rather than inventing one.

Scope assessment

Structural, not local. The gate value has to cross from _apply_period_schedule into the VPP command mapping, so apply_period / _apply_period_vpp / _intent_to_vpp each take one new argument. Chosen owner: the same route block_passive_charging and strategic_intent already travel, which exist for exactly this — VPP-only distinctions that grid_charge/discharge_rate cannot express (see apply_period's docstring).

Workaround check: passes. The new parameter carries a decision the VPP mapping genuinely needs and cannot derive; it is not routing around an ordering, timing, or dependency problem. The one structural change beyond plumbing — hoisting the authorization lookup so both platforms read one value — removes a re-derivation rather than adding one.

Test plan

• ./scripts/quality-check.sh — 0 errors
• 1693 fast + 458 slow passed
• RED test verified to fail against the pre-fix mapping, not pass vacuously
• Observed real commands from _apply_period_schedule, not just assertions:

VPP  gate OPEN   : vpp_power=+0%  remote_control=DISABLED
VPP  gate CLOSED : vpp_power=+1%  remote_control=ENABLED
TOU  both        : no VPP write (unchanged)

Verification gaps — stated, not glossed

1. No plan-faithfulness (R == P) test, which implement-issue normally requires for control-mapping changes. simulation/inverter_simulator.py is "Growatt MIN / cloud, execution-only" — it has no VPP mode, so an R == P scenario would exercise the load-following path and prove nothing about the branch changed here. This mirrors test_vpp_discharge_gate_capability.py, which exists for the same reason.
2. Full-stack E2E could not write VPP registers. The ci-growatt-vpp scenario boots with select.growatt_min_vpp_remote_control unavailable, so no VPP write occurs. The in-process observation above is the substitute. Root cause filed as E2E never exercises a Growatt VPP register write — control scenario has no VPP entities #538 — the control scenario carries no VPP entities at all, so no E2E has ever observed a Growatt VPP register write.
3. The gate-closed command is not real-hardware-validated. To be precise about scope: this is Growatt VPP (solax_modbus_growatt_min/_sph — Growatt GEN3/GEN4 via the solax_modbus integration), not the separate SolaX VPP platform. The control mode is marked experimental, but the hardware is not untested — Correction to Solax-Growatt integration: Growatt MIN-inverters now have functional VPP registers, and do not need TOU programming #118's LOAD_SUPPORT behaviour came from two real-hardware testers running Growatt MIN with control_mode=vpp. What is unvalidated is narrower: the two hold branches this builds on (battery_first Question: How is IDLE used? #466, grid_first Has it lost sense of battery wear cost? #355) ship pending confirmation, so the vpp_power=+1 gate-closed command specifically wants one of those testers confirming the battery actually holds.

Docs

INVERTER_PLATFORMS.md gains a "LOAD_SUPPORT is now gated" section with the mapping table and the +1 vs 0 reasoning. bess-knowledge.md's "VPP platforms are still excluded" paragraph was false after this change and is rewritten.

Does not close #520 — per repo policy an intermediate PR should not, and #520 auto-closed once already on #524's merge with the VPP half undone.

🤖 Generated with Claude Code

[bess-agent]

Blocked on #539 — do not merge yet.

Under the "no regression from beta for Growatt VPP" requirement, this PR changes behaviour on 172 of 603 LOAD_SUPPORT periods (28.5%, 26 of 36 fixtures) and we have no instrument to measure the effect. The trigger count is platform-independent — it comes from the DP's own intra_period_discharge_allowed — so it is how often the new branch fires. Whether firing is good or bad is unmeasurable today, because the simulator is Growatt MIN/cloud TOU only.

Worth recording an asymmetry between the two halves of #520 that I had not articulated when this was opened:

	gate closed does	regression risk
TOU (#524, merged)	max(plan_scaled, 0) = plan_scaled — identical to pre-#524	none, by construction
VPP (this PR)	writes vpp_power=+1, remote enabled — a new forced command	active change on 28.5% of periods

They are not "the same fix on two platforms". #524's gate-closed branch can only ever fail to raise something; this one actively commands something new — and it pushes against the field reports that produced #413, where forcing VPP commands instead of releasing control caused unnecessary grid imports/exports.

#539 adds VPP simulation pinned against v10.0.2, which turns this from "effect unknown" into a measured delta. That delta will be pessimistically biased against this change — at 15-minute point forecasts the simulator can model the gate's cost but never its benefit — so it answers "did behaviour change", not "is it worse". Still far better than the current position.

Nothing here says the change is wrong. It says the blast radius is broad and unmeasured, which is not something to ship into a platform with zero known bugs on beta.

Also corrected on this branch since opening: the "SolaX VPP / experimental / unvalidated" framing in the original PR body and in bess-knowledge.md. This is Growatt VPP on real production hardware; the ships experimental pending confirmation notes in the controller are stale comments from when those branches landed, not a current maturity statement.

[bess-agent]

Design defect — this must not merge as written. Found via @ridax67's comment on #520 ("it should cover load in all modes except IDLE").

The gate governs the discharge above the plan, not the planned discharge itself. TOU expresses that as a ceiling: gate closed leaves discharge_rate = plan_scaled, so the plan is still delivered, the ceiling just isn't raised to 100. VPP has no ceiling — this PR maps gate-closed to (1, True) battery_first hold, which delivers nothing.

Measured on the 36-fixture corpus:

LOAD_SUPPORT periods	603
gate closed	172 (28.5%)
...carrying a planned discharge	172 — every one
planned energy this PR abandons	118.11 kWh

Not a partial-overlap case: every gate-closed LOAD_SUPPORT period in the corpus has a real planned discharge. TOU delivers those; this PR would drop all of them and import instead.

The three states are not two. VPP can express "release" and "hold" but not "deliver exactly the plan" — which is precisely the state the gate needs. ridax's load-tracking proposal on #520 (adjust vpp_power against measured house load) is the mechanism that makes it expressible, and it is also the fix for #352. That is Phase 4 work.

Converting to draft pending redesign.