fix(ev): recover stalled charging without interrupting measured delivery

[frahlg]

Problem and result

Refs #1674. On v0.150.0-beta.1, delayed vehicle status could interrupt measured charging. Recovery could end on an API acknowledgement or a startup pulse, while repeated current adjustments could keep a stopped charger labelled Adjusting.

Supersedes #1675. Carry its useful recovery and feedback work onto current master. Keep the meter-based hard limit and battery coordination from #1695, #1699, #1701, #1706 and #1713 unchanged. The branch preserves #1675 in its history and removes its superseded EV-credit work.

Behaviour

• Apply and acknowledge the safe current before optional resume. Require ten seconds of fresh, advancing power near the supported minimum before ending recovery. A 130/299/800 W pulse is insufficient.
• Recover after FTW's own zero offer. Also allow recovery for a known device/session that still requests charge after two minutes of accepted positive offers without delivery. Send no pause in this path. Allow at most three acknowledged resumes, at least 30 seconds apart; failed calls retain the existing bounded backoff.
• Check Stop, device/session identity and connection generation after a slow current write, optional resume or refused vehicle start. Newly measured charging or unknown power blocks an automatic wake/cycle. Driver health and site limits remain required.
• Read-only and observe-only car drivers supply telemetry without automatic wake, force-start or wake-kick state. The force-start error names the missing charge-control capability.
• Preserve the accepted current receipt across optional resume. Retuning positive current keeps the observed zero-power interval. EV mismatch duration uses advancing observations, so UI polling of one cached zero cannot establish a two-minute failure.
• Log the current offer, reason, command result/time and power time at an EV-stop replan, plus resume acknowledgements. Retain no credentials or raw vendor payloads.

Follow-up review and simplification

Rechecked #1536, #1644/#1663, #1648, #1651, #1657, #1672, #1675, #1695, #1699, #1701, #1703, #1706 and #1713, plus srcfl/device-drivers#172/#183. Core's control and control-observation files match master.

The new review reproduced four failures before fixing them: the cached-zero finding, vehicle wake after Stop/session change during a current write, a charger cycle after those changes during a refused vehicle start, and unknown power becoming a measured zero in the loadpoint adapter. Regression coverage also preserves detection across current retuning and startup pulses.

One shared session check covers the slow calls. Dispatch owns one recovery record per affected loadpoint; ordinary measured charging creates none. Remove repeated state copies, map writes, error checks and manual-limit assignments. Reuse the already checked power value in the adapter. Most of the follow-up diff is regression coverage.

Validation

• Full make verify passed on e89f27a: Go suites, protocol checks, vet and build.
• Web: 772 tests passed.
• Integration: fix(ev): recover stalled charging without interrupting measured delivery #1719 at e89f27a2 plus fix(telemetry): derive Home use from energy and preserve history gaps #1720 at 78674490 (including fix(history): retain estimated daily use across brief balance failures #1668 at 5d1af9b) merges without conflicts on master 2dde2463. Full make verify and all 775 web tests passed in an isolated combined tree. This is local integration evidence; neither PR was merged on GitHub.
• Race: full loadpoint, telemetry, API and driver suites passed; the loadpoint suite passed again after the last state simplification.
• Telemetry read guard: 144 occurrences, none added, checked on committed code.
• Browser: synthetic responses from the real Core API rendered by the production component. Cached zero waits, advancing zero warns, and measured charging follows. Desktop checked again; the earlier 489 px check had no overflow. Human visual review remains pending.
• All applicable GitHub CI checks passed on e89f27a, including the full Go race detector, full stack and Linux ARM64/AMD64 builds.

Field validation and open work

The archive does not establish the physical cause of the 23:32 stop. Reason 78 was older than renewed charging and does not establish that cause. No customer box access is available here; no deployment, configuration change or real charger command was made. Keep #1674 open until the affected charger has been tested.

The separate startup pulse in #1718 remains open. A current EV-only goal reserve can exist while the battery plan is stale; the later stale-plan log alone does not establish which path selected the earlier EV offer. This PR does not change startup scheduling.

Operator check once an approved candidate or beta contains this fix:

1. Record exact Core and driver versions, local time, car and charger. Keep existing site limits and the charging goal.
2. Confirm normal charging stays stable with delayed vehicle status.
3. Stop, verify measured zero, then Start. Require sustained delivery near the supported minimum for ten seconds, rather than an acknowledgement or startup pulse.
4. If positive current again produces no delivery while the car requests charge, record the times. Check the two-minute wait, resume without pause, three acknowledged-attempt limit and non-delivery warning. Do not create an overload or bypass a limit.
5. Include a restart during a planned pause (EV briefly resumes on Core startup before restored plan is rejected as stale #1718). Export the support bundle with times of Stop, Start, unexpected stops and sustained recovery.

#1537 owns named load-balancer diagnosis; this PR does not infer it from code 78. Home use remains in #1668 → #1720: merge #1668 first, then rebase #1720. The latest #1720 uses timed charger session-energy differences and other flows integrated over the same period, with period and age in the UI. Those estimates never enter this recovery or the meter-based safety guard. #1547/costs remain separate. Other open main.go work keeps its scope; changes here only wire vehicle write authority and extend the existing stop log.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-18T04:34:22.451292Z	6da74c6	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6da74c6a02

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".