Troubleshooting

Settings revert after an update

Almost always the missing ./data:/app/data volume — see the Docker section. Add the mount, then reconfigure once.

A sensor reads nothing

Use the Test button next to the field. It fetches the entity and shows the current value, which distinguishes a wrong entity name from a connection or token problem. The log also names any sensor that fell back to a built-in default.

The battery stops updating after a sensor drops out

Symptom: SOC, battery temperature and the dynamic charge power all freeze at their last values and never move again, while the rest of EOS Connect keeps running. A restart fixes it until the next time.

Cause: an entity that goes unavailable reports an empty state. Reading it crashed the background thread that refreshes the battery, and nothing restarts that thread.

Fix: update EOS Connect. An unreadable reading is now treated like any other failed fetch — the last known value is kept and the log says which sensor it was:

[BATTERY-IF] HOMEASSISTANT - Error fetching battery SOC:
  sensor returned an empty state. Failure count: 1/5. Using last known SOC = 42%.

After five failures in a row the SOC falls back to 5 % so the optimizer works from a safe assumption rather than a stale one. If the message repeats, the entity itself is the problem — check it in Home Assistant or OpenHAB.

Home Assistant history times out on startup

On a large recorder database — MariaDB with years of history is the usual case — building the load profile could flood Home Assistant with requests until they timed out:

[LOAD-IF] Request failed after 5 attempts for
  http://homeassistant:8123/api/history/period/2026-09-12T00:00:00
[LOAD-IF] DATA ERROR household load smaller than controllables
[BATTERY-IF] HOMEASSISTANT - Error fetching battery SOC: Request timed out.

The load profile is built from four fixed days of history — the same weekday one and two weeks back, plus the following day — so it only changes at midnight. It is now built once per day and held, instead of being rebuilt on every optimizer run, and each sensor's history is fetched once for the whole day instead of once per hourly slot. In the log you should see [LOAD-IF] creating load profile for weekdays … once a day, not every few minutes.

Nothing to configure. If you still see the messages above, the recorder itself is the bottleneck — check its purge settings.

Older days come back empty

Home Assistant's recorder purges detailed state history after purge_keep_days (10 by default), while the load profile looks back 14 days. For days whose history is gone, EOS Connect falls back to recorder statistics, which are kept indefinitely.

That fallback calls the recorder.get_statistics action, so the long-lived access token needs permission to call services. On a Home Assistant too old to offer it, the log says so once and the profile simply uses the days it can still read.

Reading the log

Set log_level: debug (or EOS_LOG_LEVEL=debug) and watch the startup sequence: it reports the selected optimizer backend, the solver binary, every interface it constructed, and every configured sensor it could not read. The web UI exposes the same log, with alerts filtered separately.