DP holds charge for a known-worse tomorrow price instead of a known-better today price (real 2-day horizon branch)

[johanzander]

Summary

Once tomorrow's real day-ahead prices enter the optimization horizon, the DP can hold battery charge back from tonight's known, better sell price and export it instead at tomorrow's known, worse sell price. Confirmed with synthetic testing built from a real user's (Frank, #126) exact config, today's real prices, real Solcast tomorrow-solar forecast, and his real consumption pattern — varying only tomorrow's price array.

Belpex/ENTSO-e day-ahead prices are published values once available, not forecasts. Choosing a lower known price over a higher known price is a quantifiable revenue loss, not a legitimate risk/uncertainty tradeoff.

Background

This traces from the "74% SOC at midnight" thread in #126 (see this comment onward). Two earlier theories were raised there and both were checked against real debug bundles and ruled out:

1. Buy/sell price asymmetry ("DP holds charge because avoiding tomorrow's import beats tonight's export") — ruled out: Frank's actual 07:00 plan on 11 Jul already showed correct drain-to-floor behavior for tonight's peak, using the same asymmetric prices that would apply at any time of day. The asymmetry alone doesn't explain the later drift.
2. Terminal-value placeholder overestimating future value — already fixed by fix: cap DP terminal-value estimate at best in-horizon export price (replaces #245) #251 (merged 2026-07-09, present in Frank's v9.9.0b11) for the no-tomorrow-data branch of _calculate_terminal_value(). That fix caps the placeholder at the best in-horizon sell price. It does not touch the branch used once tomorrow's real prices are present, where terminal value is forced to 0.0 and the DP directly optimizes the real 2-day horizon (core/bess/battery_system_manager.py:1716-1788).

This issue documents synthetic testing that isolates a real defect in that second, previously-untested branch.

Reproduction

Built via mock-run.sh against a scenario generated from Frank's real debug bundle (attached to #126, exported 2026-07-12 06:07):

.venv/bin/python scripts/mock_ha/scenarios/from_debug_log.py bess-debug-2026-07-12-060741.md
# → scripts/mock_ha/scenarios/bess-debug-060741.json
#   (verbatim entity snapshot: real config, real today prices, real Solcast
#   tomorrow-solar forecast, real historical consumption)

Two edits to the generated scenario, applied per test:

1. sensors["sensor.belpex_h_average_electricity_price"].attributes.prices_tomorrow — populated with a synthetic 24-hour array (varied per test below; empty in the original export since Belpex hadn't published yet at 06:07).
2. bess_config.home.consumption_strategy → "fixed" with default_hourly set to Frank's real historical average (0.517 kWh/h, computed from the bundle's own historical_periods). Required because mock-HA doesn't implement the recorder/list_statistic_ids WS command Frank's real ha_statistics strategy depends on — without this the schedule build fails outright (Failed to update battery schedule: WS command recorder/list_statistic_ids failed).

mock_time set to @2026-07-12 06:10:00 (Europe/Brussels) so the very first optimization cycle already sees the injected tomorrow array. Then:

./mock-run.sh <scenario-name>
curl -s http://localhost:<BESS_DEV_PORT>/api/export-debug-data

...and read the ### Period Decisions table for periods 84–95 (21:00–23:45 tonight) and 180–191 (21:00–23:45 tomorrow).

Battery: 15 kWh capacity, 5 kW charge/discharge, min_soc=47% → min_soe_kwh=7.05. Today's real evening peak: sell ≈0.36–0.37 (buy-price column shown; export_spot_multiplier=1.018, no export markup) around 21:00–23:00.

Results

Scenario	Tomorrow's evening peak	SOE at 23:45 tonight (floor = 7.05/7.1)	Held charge's fate
Baseline — no tomorrow data (placeholder terminal-value branch, #251's fix)	n/a	7.1 kWh — drains to floor, correct	—
Tied — tomorrow cloned from today's real shape	same as tonight	13.3 kWh	Exported at tomorrow's identical peak (periods 180–191, drains to 7.1 there)
Worse — tomorrow's peak dulled ~21% (0.145 → 0.114)	known, worse	12.4 kWh	Exported at tomorrow's worse peak (periods 180–191, drains to 7.1 there)
Flat — tomorrow flat 0.02 EUR/kWh all day, no peak at all	no opportunity at all	9.6 kWh	Consumed locally overnight via LOAD_SUPPORT (avoids ~0.32 EUR/kWh grid import)

Analysis

The Worse scenario is the smoking gun. With tomorrow's price known (not forecast) to be ~21% below tonight's, a revenue-maximizing optimizer with full information should front-load the export onto tonight's better price — there's no uncertainty being hedged, both numbers are already fixed day-ahead auction results. Instead the DP holds ~5.3 kWh back from tonight (12.4 kWh vs. the 7.1 kWh floor-baseline) and sells it at tomorrow's confirmed-worse peak. That's a direct, quantifiable loss: roughly 5.3 kWh × (0.147 − 0.114) ≈ €0.17 in this dulled-by-21% test alone, and the gap scales with how much worse tomorrow's peak is — Belpex/day-ahead prices routinely vary by far more than 21% day to day, and Frank's original real-world observation (07:00 plan correctly draining to floor → midnight actual still ~74% SOC) is consistent with a much larger version of this same pattern.

The Flat scenario is not the same bug. There, the ~2.5 kWh held above the floor is spent overnight via LOAD_SUPPORT against Frank's real (tiny) consumption load, avoiding grid import at ~0.32 EUR/kWh — that's a legitimate self-consumption call (avoided-import cost beats a near-zero sell price) and plausibly reflects the extended 2-day horizon correctly provisioning for a second night's early-morning low-solar consumption that a 1-day horizon can't see at all. This part is not obviously wrong and is scoped separately from the export-to-worse-future-price defect above.

What's not yet known

• The exact code-level cause inside the DP's per-period reward/value computation (core/bess/dp_battery_algorithm.py, _compute_reward at line 233, battery_wear_cost = energy_stored * cycle_cost_per_kwh at lines 309/349/434) for why it doesn't correctly rank a higher known near price above a lower known far price once the horizon spans two peaks. cycle_cost_per_kwh (0.035) is in the right order of magnitude to be interacting with the price differential in the Worse scenario, but this hasn't been traced through the actual DP state transitions yet.
• Whether this is a discretization/state-space artifact (e.g. period granularity or battery-power-rate modeling) or a genuine bug in how marginal value is compared across non-adjacent periods.
• Whether the fix belongs in the DP's reward function, in how the extended real-forecast horizon is constructed, or in a discount applied to farther-horizon periods so nearer certain revenue is preferred when peaks are comparable.

Next steps

Trace _compute_reward / the backward-induction value comparison in dp_battery_algorithm.py for the Worse-scenario inputs to find why a period at 21:00 today (price 0.145) doesn't dominate a period at 21:00 tomorrow (price 0.114) net of cycle_cost_per_kwh, then propose a targeted fix.

The three synthetic scenario JSONs used here (frank-126-synthetic-tomorrow{,-worse,-flat}.json, all derived from Frank's original export-debug-data bundle) are available to attach/commit as regression fixtures if useful for a follow-up PR.

[johanzander]

Root cause found

Traced this using the same frank-126-synthetic-tomorrow-worse scenario from the issue description, re-running the DP's internals standalone with instrumentation against the exact buy_price/sell_price/solar_production/home_consumption arrays the optimizer actually used.

Not a cycle-cost tradeoff. Solar forecast for tomorrow (Solcast estimate=36.9 kWh) is more than 4× the battery's usable capacity, and the schedule itself shows the battery reaching full again by next noon regardless of how much is exported tonight — so "hold charge tonight to save a charge/discharge cycle" saves nothing in this scenario. Confirmed empirically, not just by inspection.

Not in _compute_reward or the backward-induction pass. _run_dynamic_programming (core/bess/dp_battery_algorithm.py:602-718) is exact, full-horizon backward induction with no windowing, and its own-period price indexing is correct. Forward-simulating the exact grid-consistent policy it computes reproduces its own value function exactly:

V[0, i0] (exact, from backward induction)                    = 1.22941 SEK
Grid-consistent forward reconstruction (round(), not interp) = 1.22941 SEK  — exact match

The bug is in Step 2's path reconstruction. optimize_battery_schedule's Step 2 (dp_battery_algorithm.py:1046-1064) calls _best_action_at_continuous_state / _interpolate_value (:721-821), which picks each period's action via a one-step lookahead using linear interpolation of V[t+1,:] at the true continuous SOE — not the nearest-grid lookup Step 1 used to build V. V has genuine kinks (slope jumps from POWER_STEP_KW/SOE_STEP_KWH discretization plus the BATTERY_EXPORT_THRESHOLD_KWH self-throttling cutoff, :344), so interpolation misjudges local marginal value near them. Because Step 2 lands on a fresh non-grid SOE every period, this error compounds period-over-period across the horizon:

Production optimizer's actual achieved reward = 0.85282 SEK
Exact value function's promised optimum       = 1.22941 SEK
→ production captured only 69% of the value its own value function says is achievable

That's a systematic ~30% shortfall on this horizon, not floating-point noise — and it manifests exactly as the reported symptom: hold at a good known price, dump later at a worse known price, because the interpolated continuation value near a kink is off by enough (~0.03–0.05 SEK/kWh in the shadow-price trace) to flip the decision across a price gap the size of this issue's ~0.03 EUR/kWh "Worse" test.

This is a known, previously-scoped mechanism — just underestimated

docs/superpowers/specs/2026-07-06-dp-bellman-guardrail-removal-design.md already identified this grid-snap-vs-continuous mismatch and applied the interpolated-recompute now in production as a partial fix, explicitly noting it "reduced the regression (0.27 → 0.16 SEK, ~40%) but did not eliminate it," with full elimination flagged as out of scope (needs finer discretization or a continuous-action reformulation). That acceptance was validated only against single-day (96-period) fixtures, where the residual stays small (~0.16 SEK, ~0.06% of daily cost).

The 2-day real-price horizon here exposes a much larger version of the same root cause (~30% vs ~0.06%) because: (1) more periods in the horizon means more compounding of the same per-period interpolation error, and (2) Frank's contract's sharp buy≫sell asymmetry produces sharper LOAD_SUPPORT/BATTERY_EXPORT kinks in V than the single-day fixtures likely exercised.

Fix direction (not yet implemented)

Make Step 2's action selection grid-consistent with Step 1 — use the same nearest-grid lookup (round()) to choose the argmax action, instead of interpolation. Interpolation could still be used to report the continuous SoE trajectory for display, just not to drive the decision. Alternative: finer SOE_STEP_KWH/POWER_STEP_KW discretization to shrink the kinks interpolation misrepresents, at the cost of more compute in the hot path.

References for the fix PR

• core/bess/dp_battery_algorithm.py:602-718 — _run_dynamic_programming (exact, confirmed correct)
• core/bess/dp_battery_algorithm.py:721-821 — _interpolate_value, _best_action_at_continuous_state (bug site)
• core/bess/dp_battery_algorithm.py:1046-1064 — Step 2 loop in optimize_battery_schedule
• docs/superpowers/specs/2026-07-06-dp-bellman-guardrail-removal-design.md — prior, partial fix of the same mechanism; the "out of scope" note there is what needs revisiting
• Reproduction: ./mock-run.sh frank-126-synthetic-tomorrow-worse 06:10, then curl http://localhost:<BESS_DEV_PORT>/api/export-debug-data

[johanzander]

Option A (grid-snap action selection) — ruled out by empirical validation

Implemented Option A exactly as scoped in the design doc
(docs/superpowers/specs/2026-07-12-dp-continuous-path-reconstruction-fix-design.md):
replaced _interpolate_value's linear interpolation with a nearest-grid
lookup (round(), matching Step 1's own internal read of V) as the
continuation value in _best_action_at_continuous_state, action selection
only — the continuous SoE trajectory reporting was untouched and stays exact
either way, so this doesn't affect R == P plan-faithfulness.

Ran the full pinned single-day fixture suite (test_scenarios.py, 29 tests /
27 fixture files) before and after, in an isolated worktree off main:

• Baseline (current production, interpolated): 29/29 pass.
• Option A (grid-snap): 17/29 fail. Of the 14 fixtures with a
  directly comparable pinned cost value, all 14 regressed, zero
  improved — 0.04 to 1.47 SEK (mean 0.48 SEK), larger and more
  unanimous than 2026-07-06's single-fixture 0.27 SEK worst case.

This is decisive: grid-snap resolves this issue's multi-day scenario exactly
(confirmed in the prior root-cause comment) but is a uniform, unambiguous
regression on the single-day case — not a mixed tradeoff with edge cases on
each side, every single comparable fixture got worse. Reverted the code
change after validation; nothing shipped.

Conclusion: Option A alone doesn't solve this. Need at least Option B
(finer SOE_STEP_KWH/POWER_STEP_KW discretization) to have a shot at
fixing both regimes without trading one off against the other. Option B is
effectively blocked on #236 (DP hot-loop vectorization) landing first —
current discretization already costs ~23s per 192-period optimization call
unvectorized, and halving the grid steps would roughly quadruple that.
Starting on #236 now as the prerequisite.

Option C (#276, continuous-action reformulation) remains the only option
that removes this tension at the root rather than picking a side, tracked as
a longer-term follow-up regardless of how B turns out.

Full validation numbers and methodology in the design doc, on branch
fix/275-dp-interpolation-error.

[ridax67]

Well, I think I were on the way to file a duplicate. Anyhow here is my debug package. So I guess it is confirmed , I have to sell the kWh myself this evening?

bess-debug-2026-07-12-142227.md

[johanzander]

If everything goes well, there will be a new release before then, otherwise yes. What electricity provider do you have?

[ridax67]

Göteborg Energi net provider and Eon electricity

[johanzander]

Fix merged: #279

Option B (finer DP state-grid resolution, SOE_STEP_KWH 0.1 → 0.05) is merged to main via #279, on top of #278's vectorization. Full validation history and final numbers in the design doc:
docs/superpowers/specs/2026-07-12-dp-continuous-path-reconstruction-fix-design.md.

What this does and doesn't fix: on this issue's "Worse" reproduction scenario, tonight's peak SOE now drains to 10.95 kWh instead of holding at 12.4 kWh (held-above-floor: 3.90 kWh vs. the original 5.32 kWh — a ~27% reduction). Confirmed via period-by-period tracing that a meaningful share of the previously-dominated BATTERY_EXPORT at a worse price is now correctly replaced by LOAD_SUPPORT self-consumption. It does not fully eliminate the defect — a residual export-at-worse-price pattern remains in some periods, consistent with what the design doc predicted going in (Option B alone can't fully close this; see Option C, #276).

Validated safely: full test suite (1457 tests) green, including zero R != P (plan-vs-realized) violations across the whole suite — two intermediate discretization levels tried during this work introduced real hardware-execution bugs (root-caused, documented in core/bess/dp_constants.py and the design doc, not just avoided by picking different numbers) before landing on the shipped configuration.

Live confirmation: Frank's 12 Jul ~15:00 debug bundle on the pre-fix build (v9.9.0b12) shows this exact mechanism live in production — SOE held at 12.3 kWh at midnight instead of draining toward his 7.05 kWh floor, tonight's export cancelled and moved to tomorrow's peak, magnitude matching this issue's synthetic reproduction almost exactly (see #126). Good real-world corroboration that the reproduction here reflects what's actually happening on his system.

Next: this fix will ship in the next beta. #276 (Option C, continuous-action/exact-piecewise-linear reformulation) is the tracked follow-up for full elimination — intentionally not started yet, per plan to let this partial fix bake in beta first.