You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Solar production and consumption forecasts are only fetched by BESS Manager twice per day: once at add-on startup, and once at 23:55 in the nightly prepare_next_day job (_fetch_predictions(), core/bess/battery_system_manager.py:965). There is no refresh on the regular 15-minute quarterly optimization job.
The underlying Home Assistant forecast sensors (e.g. Solcast, forecast.solar) do update intraday — typically every 30 minutes — as new weather/irradiance data comes in and same-day accuracy improves. BESS Manager never re-reads them until the next startup or the next 23:55 cycle, so every optimization run during the day is working off a forecast that's up to 24 hours stale, even when a materially better forecast (e.g. reflecting actual midday cloud cover) is already available from the sensor.
Evidence
_fetch_predictions() is called from exactly two places:
BatterySystemManager.start() (battery_system_manager.py:548) — once at startup.
_handle_special_cases(), only when prepare_next_day=True (battery_system_manager.py:1442) — once daily at 23:55 (backend/app.py:344-355, CronTrigger(hour=23, minute=55)).
The regular quarterly job (update_schedule_quarterly, backend/app.py:332-341, every :00/:15/:30/:45) calls update_battery_schedule() directly and never touches _fetch_predictions() or self._solar_predictions/self._consumption_predictions.
The DP optimizer's forecast inputs can silently lag actual conditions for most of the day. On a day where morning forecasts predicted overcast skies but it clears up by noon (or vice versa), the battery schedule computed at every quarterly tick through the afternoon still optimizes against the stale morning forecast instead of the improved same-day one, potentially charging/discharging at the wrong times.
Suggested fix direction
Refresh predictions on some intraday cadence (e.g. every quarterly job, or hourly) instead of only at startup/23:55 — to be scoped by whoever picks this up, weighing forecast-API rate limits (Solcast free tier has a daily call cap) against staleness.
Description
Solar production and consumption forecasts are only fetched by BESS Manager twice per day: once at add-on startup, and once at 23:55 in the nightly
prepare_next_dayjob (_fetch_predictions(),core/bess/battery_system_manager.py:965). There is no refresh on the regular 15-minute quarterly optimization job.The underlying Home Assistant forecast sensors (e.g. Solcast, forecast.solar) do update intraday — typically every 30 minutes — as new weather/irradiance data comes in and same-day accuracy improves. BESS Manager never re-reads them until the next startup or the next 23:55 cycle, so every optimization run during the day is working off a forecast that's up to 24 hours stale, even when a materially better forecast (e.g. reflecting actual midday cloud cover) is already available from the sensor.
Evidence
_fetch_predictions()is called from exactly two places:BatterySystemManager.start()(battery_system_manager.py:548) — once at startup._handle_special_cases(), only whenprepare_next_day=True(battery_system_manager.py:1442) — once daily at 23:55 (backend/app.py:344-355,CronTrigger(hour=23, minute=55)).update_schedule_quarterly,backend/app.py:332-341, every:00/:15/:30/:45) callsupdate_battery_schedule()directly and never touches_fetch_predictions()orself._solar_predictions/self._consumption_predictions.Impact
The DP optimizer's forecast inputs can silently lag actual conditions for most of the day. On a day where morning forecasts predicted overcast skies but it clears up by noon (or vice versa), the battery schedule computed at every quarterly tick through the afternoon still optimizes against the stale morning forecast instead of the improved same-day one, potentially charging/discharging at the wrong times.
Suggested fix direction
Refresh predictions on some intraday cadence (e.g. every quarterly job, or hourly) instead of only at startup/23:55 — to be scoped by whoever picks this up, weighing forecast-API rate limits (Solcast free tier has a daily call cap) against staleness.