fix(output): show History state under a warning, and don't read warnings as charge/export states

[chalfontchubby]

Posted by Claude on behalf of @chalfontchubby.

Summary

The History view can show the wrong state for a whole day when a warning recurs every cycle. On one install, a car integration logged out, so car_charging_soc read unavailable and every cycle raised Warn: Return bad float value unavailable from car_charging_soc. The battery force-exported from 16:00 to 19:00 exactly as planned, but History showed HoldChrg from 07:30 to 19:30.

After this change, History shows the state Predbat actually carried out, and marks any slot that ran alongside a warning or error with 🚩. Hovering over the 🚩 names the problem.

Cause

• record_status(..., had_errors=True) makes the warning the state of predbat.status for the rest of the run. When had_errors is set, record_final_run_status() only logs the run's real state. So a warning that recurs every cycle removes that state from the sensor, and from its history, for as long as the warning lasts.
• calculate_yesterday() rebuilds past slots from that history by substring. "car_charging_soc" contains "charging", so every slot became a charge window, with its target set to the SoC actually reached. That renders as HoldChrg.

Changes

1. Warnings are not states. In the History view, a Warn:/Error: status with no state recorded maps to an empty state. The Error: Complete run status X with component errors summary is unwrapped to X.
2. The state is recorded after the warning. A run that raised a warning ends with predbat.status set to <warning> [<state>], for example Warn: ... [Exporting].
   • The status still starts with the warning. The web dashboard's red row, the gateway (and predbat.com behind it) and user templates checking startswith('Warn') or startswith('Error') behave exactly as before.
   • It is a state change, not an attribute change, on purpose. HA's /api/history/period (queried without significant_changes_only=0) drops attribute-only changes, so a run_status attribute would be lost from history.
   • The run's detail (its target SoC) is shown with its state as on a clean run. The warning's own debug is kept, error_count is not incremented again, and no notification is sent.
   • The midnight tariff comparison runs after this and can record a warning of its own. When it does, the run's state is added after that warning too.
   • A run that stops early without carrying anything out still shows the bare error, so History shows no state for it rather than a stale one.
3. History splits state from warning.
   • The state is taken from the trailing bracket. The brackets are matched from the end, because a state can carry brackets of its own (Demand [Freeze exporting], Charging [Alert]).
   • The bracket only counts as a state when it starts with a known run state (RUN_STATE_NAMES in const.py), because warning text can end in brackets that are not a state, such as an interpolated list.
   • The state is then rebuilt as before, so force and freeze exports stay distinct. The warning becomes a 🚩 on the state cell and a status_warning reason after the slot's own reason.
4. The state survives the 255-character clamp. Home Assistant rejects longer states. The warning is shortened instead of the whole string, so the [state] suffix is never cut off.
5. Flags match the rebuilt state. A slot's first and last few minutes can still carry the previous or next slot's status, and History ignores those minutes when rebuilding the state. A warning from those minutes is ignored too, so the 🚩 only names problems from the minutes the shown state was rebuilt from. record_final_run_status() and the History parser share the component-error summary's wording through const.py.
6. Less flip-flopping. A mid-run warning whose text repeats the one already shown keeps the [<state>] suffix. Without this, a single recurring warning would change the sensor's state twice every cycle (bare warning, then with its state).
   • Two different recurring warnings, or one whose text changes each cycle, still change state within a cycle, as they already did on main.
   • A state trigger with no to: still fires every cycle on the attribute updates, also as on main.
   • Predheat's Warn - ... is recognised as a warning too.
7. The plain state as an attribute. predbat.status also carries the state the last completed run carried out as its run_state attribute (Exporting, Demand, Hold for car), with no warning text, for automations and the gateway.
   • It is kept while a warning is shown part way through a run, and when a run stops before executing, as the inverter is still following it. It is empty after a restart until the first run finishes.
   • The History view still decodes the state from the sensor's text, because some recorder databases don't keep attribute history.
8. Docs. output-data.md and the status list in what-does-predbat-do.md describe the Warn: ... [<state>] form; output-data.md also lists the run_state attribute.

Behaviour changes to be aware of

• While a warning is active, predbat.status reads Warn: ... [Exporting] instead of just Warn: ....
  • Anything that checks how the status starts, or whether it contains Warn/Error, is unaffected.
  • A template comparing one exact warning (== 'Warn: ...') will no longer match.
• History shows the state Predbat commanded, even when the warning says the command failed (for example Warn: ... No entity_id for charge_start_time [Charging]). The 🚩 and its reason make this visible.
• Automations that follow the state (the LuxPower freeze automations, Victron route C) see the warning first, exactly as on main, so their docs are unchanged.
• The charge-curve learner in inverter.py splits predbat.status on the first comma. It still skips cycles that raised a warning, as on main.
• On the first update, History recorded before this change has no state for warning slots, which show blank with 🚩. That clears within the two-day window.
• predbat.status gains a run_state attribute. Automations should prefer state_attr('predbat.status', 'run_state') to matching the status text.
• execute.py now takes its run state names from const.py (RUN_STATE_*), the same constants RUN_STATE_NAMES is built from, so the History parser can't drift from what is written. The strings themselves are unchanged.

Left as-is (for discussion)

record_status() and record_status_under_warning() share a lock, because component threads such as GE Cloud call them alongside the main loop. update_pred() clears the run's warning state under it too.

• The lock does not cover record_final_run_status()'s choice between the two, which reads had_errors outside it. A component warning that lands between that read and the write is overwritten until the next run, as on main.
• The status-change notification is sent after the lock is released, because over the websocket it can wait up to two minutes on another thread.

A component thread can set had_errors via non_fatal_error_occurred() without recording a warning. In that case predbat.status keeps the last clean state, as on main. The comments in component_base.py and solis.py rely on this. Changing it would put an error on the status for every cycle with a transient cloud-API failure, so I've left it alone.

Across a gap in the recorder, a warning is held along with the state it arrived with, because both come from the same forward-filled series. The 🚩 therefore always describes the status the cell was rebuilt from.

Tests

• Splitting status strings into state and warning: the bracket suffix, including states with brackets of their own ([Demand [Freeze exporting]], [Charging [Alert]]). Warnings ending in their own brackets, with and without a state after them. Unbalanced brackets. The component-error summary. The Predheat form, bare and with a state.
• History rebuild: from a warning that stays all day, a transient warning, the bracketed form, freeze under a warning, and a bare warning. Also the exact plan minutes a one-hour warning flags, and a warning lagging into the next slot's edge flagging only its own slot.
• record_status_under_warning: the state recorded after the warning, kept debug, no double-counted error_count, and the run's detail shown with its state. A repeated mid-run warning keeps its suffix and detail. A different error is shown bare. A component-only had_errors leaves the sensor alone.
• Run state names: every RUN_STATE_* constant, and the qualified forms execute.py builds (Demand (Holiday), Demand [Freeze exporting], Charging, Hold for iBoost...), reads back from behind a warning. The test fails if one is missing from RUN_STATE_NAMES, which I checked by dropping Calibration from the list.
• record_status_run_state: the attribute before the first run, after a warned run, through a repeated mid-run warning, after a run that stopped early, after a clean run and after a component error.
• The clamp: a long warning is shortened so its [state] suffix stays within 255 characters, both at the end of the run and when the warning repeats mid-run.
• History row: the 🚩 and its reason.
• record_status_concurrent: 40 warnings from 4 threads are all counted, and the notification is sent with the lock released. The component health test also puts the real component-error summary through the History parser.
• record_status_reset_locked: the start-of-run reset waits for the status lock.
• record_status_after_comparison: a warning the tariff comparison records ends up with the run's state and detail after it.
• ./run_all --quick passes, and pre-commit passes on the changed files.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[springfall2008]

Reviewed at d09f8b3: no issues found.

• History reads the run's state back from Warn: ... [<state>]. It only accepts a balanced trailing bracket that starts with a known run state, and the 255-character clamp keeps that suffix.
• execute.py takes its run state names from const.py, the same constants the History parser checks against. A test fails if the two drift apart.
• predbat.status gains a run_state attribute for live readers. History still decodes the state from the text, as some recorder databases don't keep attribute history.
• CI passes, and the branch merges cleanly with main.