bug: DP picks GRID_CHARGING with explicitly negative net_strategy_value, self-corrects 15 min later

[johanzander]

bug: DP picks GRID_CHARGING with explicitly negative net_strategy_value, self-corrects 15 min later

Summary

The optimizer selected a GRID_CHARGING action for a period whose own debug output
already showed the move as a net loss (net_strategy_value: -0.28 EUR,
future_value: 0.0), i.e. the DP's own accounting knew the action was uneconomic and
chose it anyway. The very next re-optimization (15 minutes later, same price regime)
reverted that slot to SOLAR_STORAGE. This looks like the same class of DP
search-precision defect as the (now-fixed) #336, but with a different trigger —
worth its own investigation since #336's fix apparently didn't cover it.

Reported by @Frank-Leysen on #126, 18 Jul 2026, v9.9.0b20, live Growatt MOD.

Evidence

15:30 optimization — bad plan

Debug: bess-debug-2026-07-18-154328.md
(gist)

Slot	Intent	Mode	Grid Charge	BattAct	Buy	Notes
15:30–15:59	IDLE	Load First	No	0	~0.21	Target 49% (below current SOC)
16:00–16:14	GRID_CHARGING	Battery First	Yes	+1.25 kWh	~0.21	Target 57%; period savings −0.275 EUR
16:15–19:59	SOLAR_STORAGE	Load First	No	small solar charge	~0.21–0.33	Target toward ~66%

Sell price at 16:00 was still negative (~−0.013 EUR/kWh). Debug for the 16:00 period (period 64) shows:

• economic_chain: "Store 1.1kWh grid energy (−0.28 EUR) → Future discharge opportunity
  (+0.00 EUR) → Net strategy: −0.28 EUR"
• future_value: 0.0
• net_strategy_value: -0.28
• future_target_hours: [18,19,20,21] — valued at zero despite being the stated
  justification for storing the energy

Under Belgian Dynamic pricing (buy ~0.21 vs sell ≤0), imported kWh needs roughly 3×
export later just to break even — the chosen action does not look like rational
arbitrage.

15:45 optimization — self-corrects

Debug: bess-debug-2026-07-18-155251.md (same gist)

Per	Time	Intent (15:45 plan)
63	15:45	IDLE
64	16:00	SOLAR_STORAGE (was GRID_CHARGING in the 15:30 plan)
65+	afternoon	SOLAR_STORAGE

No input changed between 15:30 and 15:45 that would explain flipping from a −0.28 EUR
grid-charge to solar-only storage — same price regime, same approximate SOC/PV forecast
window.

Ask

Investigate why the DP would ever select an action whose own net_strategy_value is
negative and future_value is zero, and why a re-optimization 15 minutes later (same
price regime) reaches a different, better answer for the same slot. If this is a search
resolution/pruning issue, it's likely the same family as #336 (also self-corrected on
a later re-optimization) but not covered by that fix.

[johanzander]

Analysis (Stage 2): fully explained by two already-known, already-fixed causes — not a new DP defect.

1. future_value: 0.0 was a display bug (#357/#353), fixed in 8cd31fce (2026-07-20), not present in your b18/b20 builds. _build_period_data computed the reported reward from only import/export/wear cost, so future_value = reward - immediate_value was mathematically forced to 0 regardless of period — but _best_action_at_continuous_state (the code that actually picks the action) already included the real continuation value (_interpolate_value(V_next, next_soe, ...)) when scoring GRID_CHARGING against the alternatives. This is provable from your own bundle: period 64 shows future_value: 0.0 and shadow_price: 0.27821 in the same block — a genuinely-zero continuation value is incompatible with a nonzero shadow price. The "net loss with zero future value" you saw was a reporting artifact, not the DP's real internal accounting.

2. Applying the actual (non-displayed) valuation, GRID_CHARGING was economically defensible. Marginal cost to store that 1.25 kWh via grid (import + wear) was ≈0.221 EUR/kWh; shadow_price was 0.278 EUR/kWh — above cost, per the governing marginal-value law.

3. The 15:45 flip to SOLAR_STORAGE is explained by real SOE drift, not search instability. The 15:30 plan predicted battery_soe_start: 7.35 kWh for the 15:45 slot; the 15:45 run's actual measured initial_soe was 7.95 kWh — 0.6 kWh more free solar charging happened than the 15:30 forecast expected, in an unchanged price regime (buy/sell identical between runs, shadow_price moved only 0.278→0.252). That extra headroom removed the case for grid-charging that slot. This is ordinary re-optimization on updated inputs, not the #336 search-precision defect.

4. Not #336. #336's fix (below-min_soe_kwh value-function clamp, #341) doesn't apply here — your SOE (7.35–7.95 kWh) was well above min_soe_kwh=4.05 kWh the whole time; the clamp only fires below the floor.

Recommendation: please re-test on a build including 8cd31fce (v9.9.0b22+ or beta once released) — the debug display will then show real future_value numbers, which should make this kind of read much clearer. Closing as explained by already-shipped fixes unless you see this pattern again on a build that has them.

[johanzander]

Confirmed fixed in v9.9.0b22 (released 2026-07-21), which includes 8cd31fc. Closing per the analysis above — please reopen if the pattern recurs on b22+.

[Frank-Leysen]

Recurrence on 10.1.0b8 — GRID_CHARGING with negative net_strategy_value (15 Aug 2026 afternoon)

Johan previously closed this as explained / fixed for b22+. Seeing the same surface pattern again on 10.1.0b8 (Growatt MOD 5000TL3-XH, 15 kWh, Luminus Dynamic / Belpex H).

What happened (CEST)

Two quarter-hours of intentional grid→battery while PV was weak:

Slot	Strategic / observed	SOE (kWh)	Grid→batt	net_strategy_value
14:15	GRID_CHARGING / GRID_CHARGING	2.6→3.5	0.80 kWh	−0.2177
14:30	IDLE / SOLAR_STORAGE	3.5→4.1	0	−0.0177
14:45	GRID_CHARGING / GRID_CHARGING	4.1→5.1	0.80 kWh	−0.2177
15:00	SOLAR_STORAGE / SOLAR_STORAGE	5.1→5.5	0	−0.0223

Live inverter matched: Time 1 Battery First + Enabled, charge ~3.8–5 kW; brief Load First at 14:30; back to Battery First 14:45–15:00; then Load First again.

Measured impact

• Daily grid import 1.4 → 3.0 kWh in that window (+~1.6 kWh)
• SOC ~16% → ~35% over the hour (later ~49% with solar storage)
• Solar barely moved early in the window (~5.6→5.7 kWh daily)
• Period energy shows grid_to_battery: 0.8 kWh each GRID_CHARGING slot; buy ≈ 0.224 €/kWh, sell ≈ 0

Each GRID_CHARGING slot’s own period economics show hourly_savings ≈ −0.218 € (import + cycle cost). Debug still reports future_value: 0.0 / shadow_price: 0.0 on those actual rows — happy to treat that as display vs internal if that’s still expected, but the executed Battery First / grid charge is real.

Evening context (same day)

Latest optimization (~16:30) has no Battery Export tonight — only LOAD_SUPPORT from ~19:00 through the night. Battery was never going to be full on this weak-PV day, so the afternoon grid charge also didn’t unlock a sell window.

Debug

Full export (bess-debug-2026-08-15-164330.md, 10.1.0b8):
https://gist.github.com/Frank-Leysen/0a0f3f8cc0e15365c86b82fc0b4d6cde

Please reopen if this is still in-scope, or point us at the right issue if the mechanism changed since the July analysis.

[Frank-Leysen]

Reopening: same GRID_CHARGING + negative net_strategy_value pattern observed again on 10.1.0b8 (15 Aug afternoon). Details in the new comment + gist.