Direct follow-up to beta.4's perf pass.
Symptom
The Helios dashboard panel (the dive-in view opened by clicking the home) showed today's charged / discharged kWh totals that did not match what the HA Energy dashboard reported for the same battery. Order of magnitude correct, but the value was systematically lower.
Cause
The dashboard panel's today totals are computed by computeBatteryToday, which integrates the signed power curve from _batteryPowerHistory between local midnight and now, splitting positive watts into chargedKwh and negative into dischargedKwh.
beta.4 capped every history fetch at the last 6 hours to keep the recorder responsive on 1 Hz installs. That cap applied to BOTH arms of fetchBatteryHistory:
- The LTS arm (
recorder/statistics_during_period, 5-minute period). Near-free on the recorder regardless of source frequency. - The raw
history/history_during_periodfallback. The heavy one.
Capping the LTS arm served no perf purpose, what it cost was the morning portion of today's battery curve when the user opened the card after 6 a.m. Integration over a 6-hour window starting at, say, 9 a.m. only covers 9-to-15h instead of 0-to-15h, and computeBatteryToday reported a fraction of the day's true energy as a result.
Fix
fetchBatteryHistory now takes TWO start anchors:
ltsStart: the full visible timeline range (typically midnight or earlier). The LTS arm queries the recorder over this broader window so today's totals integrate across the full current day.rawStart: the last 6 hours. The raw fallback (only fires when the entity has nostate_class) keeps its cap so a 1 Hz BMS without LTS tracking does not drag the recorder.
Scope
- PV chart: not affected, the chart's blend already falls through to the 5-day hourly LTS slot for past beyond 6 h.
- Grid: not affected, the two-tier 24 h LTS + 6 h raw backfill landed in beta.3.
- W/m²: not surfaced on the dashboard panel.
- Recorder load: identical to beta.4, the LTS arm was always cheap and the raw fallback is still capped.