Summary
On FTW v0.136.3-beta.1, the Overview/history graph stopped advancing even though live telemetry and raw time-series storage continued normally.
The stop happened immediately around a config hot-reload/API save.
Environment
- FTW: v0.136.3-beta.1
- Native systemd install
- State DB: /var/lib/ftw/state.db
- History DB: /var/lib/ftw/history.db
- Pixii Home battery
- SMA PV
- Easee cloud charger
- Sourceful Zap P1/HAN meter
Observed history failure
Both dashboard/site-history tables stop at exactly:
history_dashboard latest last_ms:
2026-09-25 11:31:19.505 local
history_site_energy latest last_ms:
2026-09-25 11:31:19.505 local
However raw history continues afterwards:
ts_latest latest:
2026-09-25 16:19:36.993 local
ts_series_hour latest:
2026-09-25 16:19:36.993 local
history_receipts also continued committing batches after the dashboard/site tables had stopped, e.g.:
sequence 11186
committed_at = 2026-09-25 14:20:48 UTC
So drivers/raw telemetry/history ingestion continued, but the layer producing history_dashboard and history_site_energy stopped.
Timing / likely trigger
The final dashboard/site history sample is at 11:31:19.505.
Only ~3 seconds later the log shows:
Sep 25 11:31:22 ... driver added name=sourceful-zap
Sep 25 11:31:22 ... HA bridge reloaded broker=192.168.1.65
Sep 25 11:31:22 ... config updated via API restart_required=false
After this hot-reload, history_dashboard and history_site_energy never advanced again.
Multiple later FTW restarts did not resume them.
There was no obvious SQLite/history write error in the journal at the moment the history stopped.
Related cursor state
history_site_cursor:
('from', 1790289863532) # 2026-09-25 00:44:23.532 local
('last', 0)
history_sqlite_progress is empty.
I have not modified this cursor manually.
The binary contains explicit code paths for both:
INSERT INTO history_site_cursor VALUES('last',0)
ON CONFLICT(key) DO UPDATE SET value=0
and:
INSERT INTO history_site_cursor VALUES('last',?)
ON CONFLICT(key) DO UPDATE SET value=excluded.value
so last=0 may be a symptom or reset state rather than the root cause.
Expected behavior
- Config hot-reload should not stop generation of
history_dashboard / history_site_energy.
- Dashboard/site-history should continue advancing while raw telemetry continues.
Actual behavior
- Raw telemetry continues.
ts_latest, ts_series_hour, and history_receipts continue.
history_dashboard and history_site_energy freeze at 11:31:19.
- Overview history graph freezes at the same time.
Reproduction clue
The failure appears tightly correlated with a Settings/API save that:
- tested/added the Sourceful Zap driver,
- hot-reloaded config,
- reloaded HA MQTT.
This may point to config hot-reload replacing or invalidating the site-history aggregation state.
Summary
On FTW v0.136.3-beta.1, the Overview/history graph stopped advancing even though live telemetry and raw time-series storage continued normally.
The stop happened immediately around a config hot-reload/API save.
Environment
Observed history failure
Both dashboard/site-history tables stop at exactly:
However raw history continues afterwards:
history_receiptsalso continued committing batches after the dashboard/site tables had stopped, e.g.:So drivers/raw telemetry/history ingestion continued, but the layer producing
history_dashboardandhistory_site_energystopped.Timing / likely trigger
The final dashboard/site history sample is at 11:31:19.505.
Only ~3 seconds later the log shows:
After this hot-reload,
history_dashboardandhistory_site_energynever advanced again.Multiple later FTW restarts did not resume them.
There was no obvious SQLite/history write error in the journal at the moment the history stopped.
Related cursor state
history_sqlite_progressis empty.I have not modified this cursor manually.
The binary contains explicit code paths for both:
and:
so
last=0may be a symptom or reset state rather than the root cause.Expected behavior
history_dashboard/history_site_energy.Actual behavior
ts_latest,ts_series_hour, andhistory_receiptscontinue.history_dashboardandhistory_site_energyfreeze at 11:31:19.Reproduction clue
The failure appears tightly correlated with a Settings/API save that:
This may point to config hot-reload replacing or invalidating the site-history aggregation state.