Skip to content

history_dashboard/history_site_energy stop after config hot-reload #1441

Description

@segran2

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:

  1. tested/added the Sourceful Zap driver,
  2. hot-reloaded config,
  3. reloaded HA MQTT.

This may point to config hot-reload replacing or invalidating the site-history aggregation state.

Activity

  1. changed the title [-]history_dashboard/history_site_energy stop after config hot-reload; stale Pixii capacity also restored[/-] [+]history_dashboard/history_site_energy stop after config hot-reload[/+] on Sep 25, 2026
  2. added a commit that references this issue on Oct 1, 2026
    76643ea
  3. frahlg commented on Oct 1, 2026

    @frahlg
    Member

    Thanks for the detailed report. The cursor rows made this quick to find.

    Cause. The Sourceful Zap driver can report PV, but only reads it when its config has read_pv: true. Settings can save the Zap with no read_pv key at all. Core then expects a PV reading from the Zap that never comes. Since #1089, history uses the same check as forecast learning, so every history point was skipped from the moment the Zap was added. last=0 in history_site_cursor is a result of that, not stuck state. The cause sits in the saved config, which is why restarts did not help.

    Fix. #1480 lets history ignore PV flows the config does not declare. A separate PR will make Settings save an explicit read_pv: false.

    Until you upgrade. Set read_pv: false on the Zap driver in config.yaml and save or restart. History resumes at the next valid point. No manual repair of the database is needed. The gap since 25 September stays empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions