EV briefly resumes on Core startup before restored plan is rejected as stale #1718

Problem

On FTW v0.150.0-beta.1, an Easee charger briefly resumed during Core startup even though the site had been in a planned zero-power pause. Core sent a positive EV command before rejecting the restored MPC plan as stale. About five seconds later, after replanning, Core sent zero again.

This is a directly observed startup start/stop sequence. It is not yet evidence that the same mechanism caused the separate unexplained stop on 17 October at 23:32.

All times below are Europe/Stockholm, CEST (UTC+02:00).

Verified startup sequence — 18 October, 00:24

The restart was intentionally performed to install local diagnostic logging, while measured EV power and the current planned command were both zero. The user saw FTW temporarily lack contact with Easee before the brief charging pulse.

Selected original log evidence:

00:24:14.515 INFO  mpc: restored active plan from persisted diagnostic
00:24:14.520 WARN  mpc: no online battery capacity with SoC — keeping previous plan
00:24:19.784 INFO  Easee: auto-resumed after pause (offer=15 A)
00:24:19.784 WARN  mpc plan stale — falling back to self_consumption
00:24:20.993 INFO  mpc: replanned ... reason=missing_plan_retry

Additional driver-boundary tracing records the positive and zero calls above, including their return values. A successful driver call means API acceptance, not proof of physical delivery. The subsequent measured pulse supplies separate delivery evidence.

No Easee HTTP, authentication or poll error was found in this startup window. The temporary contact indication is consistent with waiting for the first observation after restart; an actual Easee cloud outage has not been established. The exact Core path choosing the first positive EV target still needs a deterministic regression test.

Separate unresolved stop — 17 October, 23:32

• At 23:32:49.348, Core detected EV power dropping from 4,712 W to 0 W and triggered replanning.
• No Core restart occurred then; the process had been running since 19:44.
• The retained household balance remained valid, approximately 2.6 kW. There was no invalid_balance at this transition.
• Easee's observed dynamic current remained 8 A through the stop, increasing to 9 A afterwards. The later 15 A offer was observed around 23:46:30, not at the stop.
• Highest retained phase samples in the inspected 23:31:50–23:33:10 window were 23.73 / 17.58 / 16.87 A, with configured 25 A fuses. These samples do not rule out unrecorded transients or thermal constraints.
• At 23:45:34, automatic vehicle wake failed because the VAG driver is read_only. A subsequent wallbox pause/resume returned success, without immediate measured charging.
• Charging was observed again at 23:56:19, with charger source state Charging at 23:56:11. The user confirmed no manual app action or cable change. Which automatic mechanism resumed charging is unknown.
• An Easee observation read at 23:58:55 still contained reason 78, but its source timestamp was 23:45:41, predating renewed charging. Code 78 alone is not proof of the original stop cause or a currently blocking fault.

An unlogged pause command, another charger/circuit constraint or a vehicle-side decision cannot yet be distinguished for this older incident. Do not classify it as solved by the startup evidence.

Environment and scope

• Native Core v0.150.0-beta.1, source tag commit 28f0623803e8b703cf9b821789fea570f5a6cce8.
• Three-phase Easee, configured 25 A site fuses; peak-import ceiling disabled.
• Personal Core build includes EV-cost/history changes from Add EV charging energy and costs for day, week and month #1547 and fix(history): retain estimated daily use across brief balance failures #1668, without changes to Core EV control.
• Local Easee driver includes fix(easee_cloud): report a load-balancer limit while the car charges device-drivers#172 and fix(easee_cloud): reject out-of-order power observations device-drivers#183, plus a separate local reason-timestamp comparison fix. The startup capture used local diagnostic version 1.3.10.
• Diagnostic instrumentation records existing command calls/results and source times. A scenario parity test produced identical vendor calls and emitted readings with/without tracing. This is not validation of a Core fix; no Core fix or deterministic reproduction has been implemented yet.
• Existing charging investigation: EV charging cycles to zero under import ceiling despite low phase currents #1674 / fix(ev): preserve confirmed power history and verify charging recovery #1675. History balance/estimation work and the reason-code comparison fix remain separate.

Expected behavior and next verification

1. Reproduce startup with a restored stale plan, delayed first telemetry, a valid saved charging goal and a previously paused schedule.
2. Establish plan validity and the applicable charging decision before dispatching a positive EV command. Avoid a transient start followed immediately by the planned pause, while preserving intentional immediate charging and all safety limits.
3. Trace the target-selection reason, requested power, final constrained command, API result and independently timestamped charger response. Use source and receipt times separately; do not treat old change-only observations as new physical measurements.
4. Test both Core restart and genuine driver reconnection, with and without an active charging window. Compare planned, constrained and measured delivery during the next scheduled charge.
5. Keep the older 23:32 stop unresolved until equivalent command/response evidence identifies who initiated it.

A bounded local capture is running for the next scheduled charging period. Diagnostic instrumentation should remain outside the production fix/merge.