inverter and dashboard states grid export...

[johanzander]

What happened

... while savings view shows load support, NOT grid_export.

running 9b beta.

Debug bundle

bess-debug-2026-07-07-215802.md

[bess-manager-claude-bot]

Report: inverter and dashboard show different supported capabilities — inverter shows load_support, dashboard shows grid_export. Debug log received. Reply @claude-bot analyze to start deep code-level analysis.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

The battery correctly discharged with a tiny grid-export slice (battery_to_grid = 0.0403 kWh, mostly load support with 0.84 kWh total discharge). The backend's strategic-intent classifier uses a 0.01 kWh noise floor, so it correctly labels the period BATTERY_EXPORT — this is what drives the Growatt TOU mode and the dashboard's "Selling to Grid" card. The Savings page, however, only renders a grid-export flow badge when the same batteryToGrid value exceeds 0.05 kWh — 5x less sensitive. Since 0.0403 falls between the two thresholds, the Savings table shows only the dominant load-support badge for that row, making the period look like pure LOAD_SUPPORT even though the backend correctly classified and executed it as BATTERY_EXPORT. Both views are individually "correct" against their own threshold — they just disagree because the thresholds don't match.

Notably, the backend's 0.01 kWh threshold was deliberately tuned as recently as 2026-07-06 (docs/superpowers/specs/2026-07-06-dp-bellman-guardrail-removal-design.md, one day before this issue was filed) to fix a related R == P plan-faithfulness problem — the frontend's 0.05 kWh display threshold was not updated to match at the same time, which is almost certainly how the two fell out of sync.

Evidence

• core/bess/decision_intelligence.py:438 — intent classification uses the tight threshold:

  if energy_data.battery_to_grid > 0.01:
      return "BATTERY_EXPORT"
  return "LOAD_SUPPORT"

• frontend/src/components/SavingsOverview.tsx:339 (and duplicated at 398, 738, 797) — badge rendering uses the loose threshold:

  {(hour.batteryToGrid?.value ?? 0) > 0.05 && (

• backend/api_dataclasses.py:330,446-447 — confirms both surfaces read the same underlying number (hourly.energy.battery_to_grid → batteryToGrid API field), so this is a display-threshold mismatch, not a data-pipeline bug.
• Debug bundle (bess-debug-2026-07-07-215802.md, v9.9.0b9) evidence extractor for the period matching the screenshots ("now" = 21:45):

  intent=BATTERY_EXPORT  battery_action=-0.800  SOE=8.1→7.3
  battery_to_grid=0.0403  SOE=8.1→7.258
  

  0.0403 clears the backend's 0.01 floor (→ BATTERY_EXPORT everywhere else) but misses the frontend's 0.05 floor (→ no export badge on the Savings page).
• System health at export time was OK (0 critical, 0 warnings) — this is not a sensor/connectivity issue, confirming it's a pure UI/threshold inconsistency.

Proposed fix

Align the Savings page's flow-badge display threshold with the backend's intent-classification threshold (0.01 kWh) in SavingsOverview.tsx, or better, have the frontend derive "is this an export period" from the backend's already-computed strategic intent rather than re-deriving it from a second, independently-tuned numeric threshold. The latter avoids this class of drift recurring the next time either threshold is tuned.

Risks / open questions

• Lowering the display threshold to 0.01 kWh may surface more sub-kWh badges across the Savings table as visual noise — worth a quick look at whether that's desirable UX or whether deriving from backend intent (avoiding a second threshold entirely) is preferable.
• Separately (not part of this bug, noted for awareness only): the debug bundle's own "Historical Sensor Data" table (core/bess/debug_report_formatter.py:400) labels its Time column with the raw collection timestamp rather than format_period()'s period-start convention used elsewhere in the bundle. This caused an initial mis-read during investigation (a "period 86 = 21:45" row is actually the prior period) but is a debug-bundle-only artifact, not related to the live-app bug reported here.
• I could not visually re-confirm the exact cropped Savings-page screenshot pixel-for-pixel (only a description was available), so the "grid-export badge is absent" conclusion follows necessarily from the code threshold (0.0403 < 0.05) rather than a direct re-inspection of that specific image region.

---

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