WhatIf Annual Prediction run restarts the Predbat add-on before completing

[mitulgovind]

Running the WhatIf Annual Prediction tool (Configure → Run simulations) causes the Predbat add-on to restart partway through the run, aborting it before it finishes. This happens consistently — reproduced multiple times, including after reducing samples_per_month from the default.

File /config/annual_work/apps.yaml was modified
Stopping Predbat due to file changes....
2026-07-30 23:23:14.261361: Stopping Predbat
2026-07-30 23:23:15.096032: Info: Web socket stopping
2026-07-30 23:23:15.096324: Info: Web Socket stopped
2026-07-30 23:23:15.097004: Info: HA interface stopped
2026-07-30 23:23:15.333634: Info: Components stopped
Web interface stopped
Shutdown, sleeping 20 seconds before restarting
[23:23:42] INFO: Predbat init script running
Running Predbat inside Add-on
Bootstrap Predbat
Startup
Predbat files are installed correctly for version v8.47.1
**** Starting Standalone Predbat ****

Steps to reproduce

1. Go to WhatIf → Configure, fill in the form.
2. Click Run simulations.
3. Run progresses partway (varies each time — seen anywhere from ~8% to ~25%).
4. Add-on restarts, run is aborted, progress is lost.

Expected behavior

The run should complete without the add-on restarting.

Environment

Predbat version: v8.47.1
Running as: Home Assistant Add-on
Home Assistant: Home Assistant Green

[mitulgovind]

Update: This is more serious than just the run failing to complete — triggering the restart also reset my live Predbat config back to defaults, not just interrupting the annual job.

After one of the restarts, Predbat came back up in Monitor mode instead of my normal charge/discharge mode, and several tuned settings had reverted to stock defaults rather than what I'd configured. The log from the restart itself shows why:

New install detected
Set reset inverter true due to reset_inverter on item set_reserve_min
Set reset inverter true due to reset_inverter on item set_charge_low_power
Set reset inverter true due to reset_inverter on item set_export_low_power
Set reset inverter true due to reset_inverter on item set_export_freeze
Set reset inverter true due to reset_inverter_force on item set_read_only
Set reset inverter true due to reset_inverter_force on item mode
It looks like the restart caused Predbat to treat the instance as a fresh install, which triggered the reset_inverter/reset_inverter_force logic on several config items — including mode — rather than restoring the tuning I already had in place. I had a saved profile from earlier that morning, so I was able to revert to it, but it's worth flagging that anyone hitting this restart bug without a recent saved profile could lose their live tuning silently.

Given this, I'd suggest bumping the severity/priority here — it's not just "the annual tool doesn't finish," it's "running the annual tool can reset a live production instance."

[chalfontchubby]

Just hit me - correlates with multiple reports on facebookof trashed settings.

[chalfontchubby]

Claude has found something

[chalfontchubby]

(Posting as Claude, an AI assistant helping investigate this)

Traced this down to two separate bugs that chain together - only the first is caused by the new Annual tool, the second is pre-existing.

Bug A - the trigger (new, caused by the Annual tool): Predbat's file watcher (hass.py's check_modified()/main()) walks its working directory tree recursively and restarts the add-on whenever it sees a file bump whose basename is exactly apps.yaml - it never checks that against the actually-configured apps.yaml path. Each WhatIf Annual run writes a fresh, real apps.yaml-named scratch file into annual_work/ (inside config_root, i.e. /config in production) so the headless simulation instance has its own isolated config - a reasonable design in isolation, but it lands squarely inside the same directory tree the live watcher walks, so the watcher can't tell it apart from your real config and force-restarts the live add-on mid-run.

Bug B - the actual data loss (pre-existing, not introduced by the Annual tool): load_user_config() decides whether this is a "new install" purely by reading predbat.status back from HA at that exact instant (userinterface.py) - no persistent marker, just "did this one state read succeed right now." Immediately after any restart, before HA's websocket/history layer has fully warmed back up, that read can legitimately come back empty even on a long-running production instance. When it does, config items (including mode) get silently treated as unset and fall back to their code defaults, and expose_config() then fires the reset_inverter/reset_inverter_force logic for each one, live-overwriting your actual HA entities with those defaults - which is what wiped your settings.

Confirmed via git log that the commit which added the Annual tool (#4315) never touched the file watcher or the new-install detection - Bug B could in principle have been triggered by any abrupt restart (crash, OOM, manual restart at the wrong moment) before now, it just went from "rare and easy to miss" to "trivially reproducible" once Bug A started forcing unplanned restarts on demand.

Starting on a fix for Bug A now (scoping the watcher so it can't be fooled by files elsewhere in the tree) - that removes the trigger for this specific report. Bug B is a real, separate hardening issue worth its own fix (don't treat a single failed state read as authoritative for "new install"), which I'll follow up on separately given it's a different risk profile and deserves more care than a quick patch.

[chalfontchubby]

Fix is up: #4401 - scopes the watcher to the actual configured apps.yaml path so it can't be fooled by the Annual tool's scratch file anymore. Note it fixes the trigger (the unwanted restart) but not the separate new-install/reset_inverter race mentioned above, which is a pre-existing issue I'll follow up on separately.

[chalfontchubby]

⚠️ Heads up for anyone on v8.47.0/v8.47.1: until #4401 is merged, running the WhatIf Annual prediction tool can restart your live Predbat instance and reset real settings (mode, reserve, read-only, etc.) back to defaults - not just interrupt the annual run itself. If you've already run it and things look off (e.g. mode showing Monitor unexpectedly), check your config against a recent save/backup rather than assuming it's still what you set. Recommend holding off running the Annual tool on a live production instance until the fix lands.

[gcoan]

Bug B - the actual data loss (pre-existing, not introduced by the Annual tool):

Sounds like you have found this bug as well. It's been reported in the past that predbat would randomly reset config and swap to monitor mode, but it never got tracked down.
Hypothesis at the time was it was some form of race condition on HA startup which matches what you found

[chalfontchubby]

Ok, I'll have a scan for related issues. Thanks.