Schedule shows "Storing solar" all day which is impossible

[johanzander]

bess-debug-2026-06-23-181847.md

What happened

(no description provided)

Debug bundle

Please drag-and-drop bess-debug-2026-06-23-181847.md from your Downloads folder into the editor below before submitting.
The file contains your version, settings, recent logs, and the raw HA discovery dump that the maintainers need to reproduce the issue.

[bess-manager-claude-bot]

The schedule is incorrectly showing "Storing solar" for the entire day, which shouldn't happen given the system's configuration. Debug log received. Reply @claude-bot analyze to start deep code-level analysis.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

When the battery starts the day below its configured minimum SoE (2.7 kWh vs min_soe_kwh = 3.0 kWh), a clamping artifact in the schedule reconstruction misclassifies every overnight IDLE period as SOLAR_STORAGE. This happens because the minimum-SoE floor causes the "idle" state transition to report a phantom SOE increase, which the intent classifier treats as passive solar charging. Since the battery remained near-empty all night, every hourly optimization run from midnight through ~09:30 triggered the same artifact, accumulating SOLAR_STORAGE as the persisted intent for every overnight period. The UI then displays all those periods as "Storing solar" even at 2 am.

Evidence

Step 1 — Phantom charging in the reconstruction (dp_battery_algorithm.py:229-234, dp_battery_algorithm.py:170-176):

# _state_transition, IDLE branch (power == 0)
else:  # Hold / IDLE
    next_soe = soe                          # 2.7 kWh (no solar at night)
# ... then immediately clamped:
next_soe = min(max_soe, max(min_soe_kwh, next_soe))  # → 3.0 kWh

# _idle_battery_flows receives (soe=2.7, next_soe=3.0)
passive_energy_stored = next_soe - soe      # 3.0 - 2.7 = 0.3 kWh ← clamping artefact
battery_charged = passive_energy_stored / efficiency_charge   # 0.309 kWh

Step 2 — Intent misclassified (decision_intelligence.py:439-440):

elif energy_data.battery_charged > 0.01:
    return "SOLAR_STORAGE"           # ← 0.309 > 0.01 → fires for every overnight IDLE period

Step 3 — Intent propagates to every run (schedule_store.py:143-164):
Each hourly run's first-period intent (SOLAR_STORAGE due to artefact) overwrites the previous run's value for that same period in the persisted JSON. With initial SOE staying at 2.7 kWh overnight, all 39 runs from midnight to 09:30 each wrote SOLAR_STORAGE for their opening period, so periods 0–38 all end up with SOLAR_STORAGE in the file.

Step 4 — UI shows only the planned intent (api_dataclasses.py:463, BatteryModeTimeline.tsx:47):

# api_dataclasses.py — only strategic_intent serialised, never observed_intent
strategicIntent=hourly.decision.strategic_intent,

// BatteryModeTimeline.tsx — same field used for both past and future periods
const intent = (hourlyData[i].strategicIntent as StrategicIntent) || 'IDLE';

The observed_intent field (which correctly shows IDLE for overnight) exists in the backend data model but is never exposed through the API.

Confirmed in the midnight log (system log at 00:00:47):

Intent transition at period 1: SOLAR_STORAGE → IDLE
Intent transition at period 33: EXPORT_ARBITRAGE → SOLAR_STORAGE

Period 0 = SOLAR_STORAGE, periods 1–31 = IDLE — exactly what the artefact predicts.

Proposed fix

Fix 1 (core — stop the misclassification): In _idle_battery_flows, treat the SOE increase as real passive charging only when soe >= min_soe_kwh. When soe < min_soe_kwh the next_soe increase is entirely due to the minimum-floor clamp, not solar production, so battery_charged should be 0 in that case.

Fix 2 (display — show what actually happened): Add observedIntent to the APIHourlyData dataclass and populate it from hourly.decision.observed_intent. In the BatteryModeTimeline component, use observedIntent (falling back to strategicIntent) for past periods (data_source === "actual"). This ensures that even if an IDLE period has a SOLAR_STORAGE plan attached, the UI correctly shows "Idle" instead of "Storing solar".

Risks / open questions

• The clamping guard in _idle_battery_flows may need to stay in sync with the clamping logic in _state_transition. If _state_transition ever changes how it handles the below-min case, the guard must follow.
• Adding observed_intent to the API is a non-breaking additive change, but frontend/src/types.ts must be updated to match.
• The misclassification only occurs when initial_soe < min_soe_kwh (below-minimum starting state). The normal above-minimum path is unaffected.

---

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

[johanzander]

@claude-bot fix

[bess-manager-claude-bot]

Draft PR opened: #168

Core fix (dp_battery_algorithm.py): _idle_battery_flows now returns (0.0, 0.0) when soe < min_soe_kwh. The minimum-floor clamp in _state_transition was producing a phantom SOE increase (2.7 → 3.0 kWh) that _idle_battery_flows counted as passive solar charging, sending battery_charged = 0.309 kWh to classify_strategic_intent, which then returned SOLAR_STORAGE for every overnight IDLE period.

Display fix (api_dataclasses.py + BatteryModeTimeline.tsx): observed_intent is now exposed through the API and used by the timeline for past (dataSource=actual) periods, so already-persisted records with bad strategic_intent also display correctly.

Quality gate: 791 tests passed, 0 errors.