Optimizer over-credits solar export: planned charge power is not applied (charge_rate fixed at 100%)

[johanzander]

Summary

The optimizer's reported savings are inflated because it credits solar export that the applied inverter control cannot actually deliver. Root cause: the control layer encodes the optimizer's planned discharge power but not its planned charge power — charging periods always apply charge_rate = 100%, so the battery charges all available surplus solar instead of the planned partial amount. The surplus the optimizer planned to export is stored instead, and the export revenue it booked never materializes.

Surfaced by the closed-loop savings simulator (PR #144) on its first run: executing the optimizer's own plan via the control modes does not reproduce the planned economics (R ≠ P).

Evidence (real reproduction day, 2026-06-16)

Full-day: planned −45.50 SEK vs simulated-realized −40.11 SEK → 11.85% of the planned savings is not realized, concentrated in SOLAR_STORAGE periods.

Concrete period — P44 (11:00), solar 1.9, home 0.2, sell 0.96:

plan:  charge 0.10 kWh, EXPORT 1.60 kWh @ 0.96  → books ~1.5 SEK export revenue
real:  SOLAR_STORAGE → load_first, charge_rate 100% → charges ~1.7 kWh, EXPORT 0

Across the morning the battery climbs 2.4 → 20 kWh (full by ~13:00) instead of holding near the floor and exporting; then, full, it is forced to export the cheaper midday solar the plan wanted to store. Net: it stores expensive solar and exports cheap — the inversion of the optimal strategy.

Actual measured SoE in the log held at ~2.6–3.2 kWh through 06:00–09:00 because that window was applied as a solid EXPORT_ARBITRAGE/grid_first block (export works there). The bug bites in the later load_first window (10:30–18:00 in the applied schedule); the log ends at 09:01 so the midday actual SoC isn't captured.

Root cause

InverterController._map_intent_to_rates: EXPORT_ARBITRAGE scales discharge_rate from the planned battery power, so discharge is faithfully applied. But SOLAR_STORAGE/GRID_CHARGING apply a fixed charge_rate = 100% — the planned charge power is discarded. The optimizer's reward model (_compute_reward) then computes grid export from the energy balance assuming the planned (partial) charge, crediting export of the remainder — export that the 100%-charge execution never produces.

Modes are priority orders (home → battery → grid for load_first; home → grid → battery for grid_first), and load_first does export the excess once the battery is full or surplus exceeds the charge rate — so this is not about export being impossible in load_first. It is purely that applied charge ≠ planned charge.

Proposed fix

Make charge faithfully controllable: scale charge_rate from the planned charge power, mirroring the existing discharge_rate scaling for EXPORT_ARBITRAGE. Then applied charge == planned charge, and grid export (in any mode) falls out of the energy balance correctly — no export-by-mode gating and no edge-case special-casing needed.

Invariant to restore: applied battery power == planned battery power, every period.

Assumption to confirm: the Growatt MIN charge_rate % limits charge power the same way discharge_rate % limits discharge power (EXPORT_ARBITRAGE already relies on the discharge side).

Verification

This is an optimizer/control-contract economics change — covered by the slow suite, and now directly verifiable by the simulator (PR #144): after the fix, verify_plan_faithfulness should give R == P (realized == planned) on representative scenarios.

Relationship to #141

This is the root cause behind the morning behaviour #141 targeted. #141's hysteresis treats the cosmetic mode-dither; this issue is the underlying economic defect. Fixing charge faithfulness makes the dither economically harmless (it may still need a separate, lower-priority cosmetic fix). Recommend addressing this first and re-evaluating #141 afterward.

Refs: PR #144 (simulator), docs/investigations/simulator-plan-faithfulness-finding.md.

[johanzander]

Correction to the proposed fix (maintainer)

The diagnosis above stands, but the fix is not charge-rate scaling. Two reasons it doesn't work:

1. Solar is a forecast. Encoding a "planned charge power" into charge_rate chases noise — actual solar swings more than the fractional amounts involved, so the battery would fluctuate anyway.
2. charge_rate = 100% in store-mode is intentional. If the algorithm decides storing is best (plan: store 5 kW, no export) and actual solar is 6 kW, the best outcome is to store all 6 — bonus solar is upside. Scaling charge_rate down to the planned 5 would export the bonus 1 kW we wanted to keep.

Correct fix: binary store-vs-export per period

Model solar-surplus handling as a binary per-period choice, and credit export accordingly:

• Store period → load_first, charge_rate = 100%: store as much as physically possible (captures bonus solar); load_first exports only the genuine excess (above rate / when full). Optimizer credits no planned surplus-export.
• Export period → grid_first, charge_rate = 0: store nothing, export all surplus (+ battery discharge if arbitraging). Optimizer credits export.

This is forecast-robust (store-periods keep 100%, so actual solar — bonus included — is captured, and no phantom export is booked, so forecast error can't create a fake-revenue gap) and it removes the over-crediting bug (each period is honestly store-all or export-all, never a fractional split that no single mode can deliver).

Scope of the change

This lives in the optimizer's reward/action model for surplus solar (_compute_reward / the DP action space), not just the controller: the per-period decision becomes store-all-up-to-rate vs export-all, with export credited only in export-periods. Larger than a controller tweak.

Side effect

Dissolves the morning dither: morning resolves to export-periods (charge 0, hold at floor, export surplus), midday to store-periods — no fractional ±0.1 charges to flip-flop over. So this likely supersedes #141 entirely.

Verification unchanged: after the fix, the simulator's verify_plan_faithfulness should give R == P on representative scenarios.

[johanzander]

Implemented + verified (PR #146) — before/after on the reproduction day (2026-06-16)

Corrected mechanism (the earlier "can't split" framing was wrong)

Inverter modes are priority orders: load_first charges the battery from surplus up to the charge rate and exports the excess; grid_first exports (and discharges the battery for export). So the inverter can store-some/export-the-rest, and charge power is controllable.

The real bug: the optimizer's reward model planned a fractional charge + export in the same period and booked the export revenue — but a "store" period drives load_first at full charge power, soaking up all the surplus, so the planned export never happened. It over-reported savings and, in practice, stored the expensive morning solar instead of selling it.

The fix makes each period a clean store-all vs export-all disposition (not a fractional split). This is deliberate, for forecast robustness: solar is a forecast, so capping the charge to a planned fraction would dump the bonus whenever the sun over-delivers.

Morning behaviour (action / charge / export, kWh per 15-min period)

Period	OLD intent	OLD act/charge/export	NEW intent	NEW act/charge/export
09:00 (P36)	SOLAR_STORAGE	+0.10 / 0.10 / 1.30	EXPORT_ARBITRAGE	0 / 0 / 1.40
10:00 (P40)	EXPORT_ARBITRAGE	−0.10 / 0 / 1.70	EXPORT_ARBITRAGE	0 / 0 / 1.60
11:00 (P44)	SOLAR_STORAGE	+0.10 / 0.10 / 1.60	EXPORT_ARBITRAGE	0 / 0 / 1.70
12:00 (P48)	SOLAR_STORAGE	+0.10 / 0.10 / 1.50	EXPORT_ARBITRAGE	0 / 0 / 1.60

OLD morning (06:30–12:15) = 13 EXPORT_ARBITRAGE + 11 SOLAR_STORAGE (the flip-flop the user reported); the SOLAR_STORAGE periods book charge 0.10 + export ~1.3–1.6, which load_first cannot deliver (it stores all surplus). NEW morning = 24 clean EXPORT_ARBITRAGE — exports all morning solar at the high price, holds the battery at the floor, then fills from cheap midday solar (charging starts 12:30 at the price bottom).

Economics

	Reported (plan)	Realized (faithful simulator)
OLD	−45.50 SEK · savings 62.48	−40.11 SEK · savings 57.09
NEW	−44.71 SEK · savings 61.69	−44.78 SEK · savings 61.76

• OLD over-reports by 5.39 SEK (phantom export) and under-delivers.
• NEW reports honestly and delivers more: realized 57.09 → 61.76 SEK = +4.67 SEK (+8.2%) on this day.
• Plan ≈ realized to the öre (R−P = −0.075), confirmed by the closed-loop simulator (PR Closed-loop savings simulator (plan-faithfulness verification tool) #144).

Caveat: realized figures are from the verification simulator (validated to reproduce the plan to the öre), not a meter readout. The size of the win scales with a day's surplus solar.