[nuttytree]

An ESPHome sensor keeps serving its last value indefinitely once its source stops responding, and nothing downstream can tell the difference between that and a real measurement. On two consecutive mornings the PZEM stopped returning valid Modbus frames for exactly the hour both pumps ran, 04:00–05:00, and because its readings froze rather than disappearing, every consumer believed them.

Pump No Current turned on at 04:00:01 and stayed on for the full hour while the pump was actually drawing ~1500 W. Runtime stopped accumulating for a pump that was running. When frames returned at 05:00:02 the current sensor stepped from a frozen value to a live one in a single sample, which spiked the spread estimate past the variance threshold and set Pump Anomaly Status chattering — 285 transitions, reason VARIANCE_SPIKE. The energy sensors appearing to dump a whole hour of consumption at once had the same cause: the meter had been counting internally the entire time, only the reads were dead.

binary_sensor.pool_status never left on and the recorder was healthy throughout, so this was neither an API drop nor a database problem. The only signal that could have distinguished a live reading from a frozen one was when it last arrived, and nothing was tracking that.

This does not fix the underlying dropout, which is still unexplained and most likely electrical — it recovers the instant the cleaner stops, so the cleaner's booster pump is the prime suspect. What this does is stop the controller drawing false conclusions from dead data, and make the outage visible as itself in history.

Changes:

• Track the arrival time of every current_sensor publish and declare the reading stale after current_timeout (new, default 30s). Add current_stale_binary_sensor so a dead sensor is reported as a dead sensor rather than as a pump fault.
• While stale: hold motor_running_ instead of recomputing it from a frozen value, suppress no_current (a sensor that stopped publishing supports no claim about the pump), and stop sampling for anomalies.
• On recovery, clear the debounce streak and the spread estimate so the step change back to live data cannot trip the variance detector, and discard the inrush peak of any run whose startup window contained a gap.
• Measure runtime from flow_sensor whenever one is configured, falling back to current_sensor and then to the output command. Moving water is what the schedule is actually buying, and flow stays valid through a current-sensor outage — in this incident the flow inputs are on the PCF8574 and were live all hour.
• Split "a new run started" from "runtime is accumulating", which were tangled in track_runtime(). The anomaly startup window has to stay anchored to electrical turn-on, because flow lags the motor by long enough to miss the inrush peak the startup check exists to measure. turned_on_ms_ is now 0 until a sensor confirms the motor, which also prevents a stale recovery from restarting the startup window mid-run and recording steady-state current as if it were inrush.
• Document the local ESP-IDF toolchain setup and its pitfalls in CLAUDE.md, and stop the commit_pr command delegating to the pr-workflow skill, which belongs to the upstream esphome/esphome checkout and would target the wrong repository.

No behaviour changes on upgrade beyond the above; nothing persisted is discarded. Both new options are optional with defaults, so existing configs need no edits.

Verified with esphome compile on an ESP32-S3 build of pool.yaml — clean, exit 0, no warnings from any touched file.