EV charging cycles to zero under import ceiling despite low phase currents #1674

On v0.145.2-beta.1, an Easee Cloud charger repeatedly started and stopped on 16 October 2026 around 23:45–23:47 CEST. The UI reported “protect the main fuse”.

Observed evidence

• Main fuse configuration: 25 A, 230 V, three phases.
• Retained phase-current maxima over the incident: 10.01 / 11.19 / 10.02 A. These samples do not show a physical fuse overload.
• Configured peak-import ceiling: 7,500 W.
• Planned EV demand: 10,350 W; offered charge was repeatedly reduced to 6,210 W, then 0 W.
• Minimum supported charging step: 4,140 W.
• At 23:45:13 and 23:45:18, logs say loadpoint fuse-clamp: below minimum step ... fuse_cap_w=0 min_step_w=4140; analogous stop/start sequences recur at 23:45:43, 23:46:13, 23:46:48 and 23:47:18.
• Around each start, grid import rises to about 7.0–7.1 kW while the retained charger power sometimes still says zero; around a stop, the inverse disagreement occurs. The snapshot clocks are asynchronous.
• At 23:56, FTW again requested and offered 9 A / 6,210 W, but actual EV power remained zero. Easee was online, connected, ready (mode 6), with reason 78, “limited by dynamic charger current”. This does not establish which charger/vehicle state prevents recovery.

Investigation, not yet a proven cause

EVFuseBudget bounds a common balance by the latest site observation. When replacement credit for a managed EV cannot yet be confirmed, an approximately 7.1 kW site reading under the 7.5 kW import ceiling leaves only approximately 0.4 kW for a new offer, below the 4.14 kW minimum. This is a plausible start/stop mechanism, not a reconstruction of the internal budget verdict at each field tick: those intermediate values were not persisted.

A household load increase and an EV start with delayed charger telemetry can initially look identical. A fix must not simply credit requested EV power as measured power, reuse stale EV credit, or weaken phase/fuse or configured import limits.

Expected result

1. Reproduce the low-load, delayed-telemetry start/stop case with deterministic observations.
2. Expose which bound, raw/common observations, managed-EV replacement credit and pending battery power produced a stop.
3. Distinguish the configured import ceiling from a physical main-fuse overload in diagnosis.
4. Validate stable recovery without permitting a delayed EV start to overlap a new household load beyond the protected limits.

This is separate from the daily-history repair in #1667/#1668. No charging configuration or safety limit was changed during this investigation.

Follow-up: 17 October, 00:13–00:20 CEST

The two screenshots show Charge now requesting 15 A / 10,350 W, FTW offering 10 A / 6,900 W, and actual EV power 0 W. The second screenshot shows approximately 1 kW household consumption covered by the battery and near-zero grid exchange.

Rechecked logs from 00:10–00:21:30: 132 clamp records, 131 at 6,900 W and one at 7,590 W; no zero cap, pause or cooldown. At 00:13:13 and 00:19:53 the records both contain want_w=10350 fuse_cap_w=6900 snapped_w=6900. The 7,500 W configured import ceiling is consistent with the 10 A step. This positive cap explains the reduced offer, but does not explain zero delivery. Subsequent charger telemetry remained online/connected, ready (mode 6), reason 78, with a 10 A offer and no measured charging.

Two concrete core problems are addressed in #1675:

• A positive site clamp took precedence over sustained zero delivery, hiding the no-power response behind “main fuse” wording. After confirmation grace, fresh accepted positive offers with persistent zero power now report not-following/not-drawing; the lower allowed rate remains available as context. Wording identifies site fuse/import limits without asserting a physical overload.
• Recovery after FTW's own zero offer discarded its resume proof on HTTP acknowledgement. It now waits for measured delivery, retries at 30-second intervals up to three acknowledged attempts, and logs exhaustion. Existing session/device/generation and current safety/plan gates remain authoritative.

Regression tests reproduce the accepted 10 A / actual 0 W case and acknowledgement-without-delivery recovery, including intentional zero, freshness, grace, charging, session changes and safety/plan stops. Full make verify and all 729 web tests pass on e7b210d.

The initial 23:45 start/stop budget cause remains unproven; the bounded budget diagnostics are retained. Recovery is now tested in software, but requires validation on affected hardware. The running installation has not been updated by this PR.

Diagnostic build: 17 October 01:32–01:37 CEST

The local e7b210d-derived build still cycles. At 01:32:37 the common balance reserves 9,009.628 W of battery increase with 6.832 W grid import, while latest-site reservation is 0.628 W. At 01:34:42 common EV credit is 286 W versus latest credit 7,527 W, common cap 607.745 W versus latest cap 7,813.744 W. These are direct decision records, not later status reconstructions.

Code probes reproduce two mechanisms: a missing after-bracket makes the common battery baseline fall back to the configured -10 kW discharge bound even where the latest-site calculation can use a preceding fresh battery reading; and a later EV low sample retroactively reduces credit for an older bracketed site observation. This establishes the arithmetic mechanisms, not every underlying physical sample's accuracy.

Follow-up in #1675: align the fallback reservation with the latest site bound and keep historical EV brackets historical in the common balance, while retaining the independent latest-site and phase bounds and conservative later-stop handling there. Add regressions for observed stop/restart, true household increases, pending battery orders, and unknown/stale readings. Hardware validation remains required.

Budget fix available: 815e305 / PR #1675

The common EV balance now evaluates its historical brackets without a later stop/restart retroactively removing that site's credit. Independent latest-site and phase bounds remain authoritative and retain later-stop handling. The no-common-bracket battery path uses a fresh preceding measurement instead of inventing a full configured discharge loss; a first battery sample after the site read retains its conservative unknown-history fallback. Pending loss-of-discharge orders remain reserved.

Regression tests fail on the prior revision and pass with this fix. Entire control suite and full make verify pass on both PR and cumulative v0.145.2-beta.1 personal trees; web tests pass (729 / 731, TZ=UTC). Linux ARM64 personal patch revision 2 is built. Hardware validation and human review of earlier UI changes remain pending; no installation or charging command was performed for this budget revision.

Revision 2 field result and latest-site fallback correction

Revision 2 (815e305-derived ARM64 build) was installed and its executable checksum verified. FTW restarted at 01:52:54 CEST. Stable charging is not validated: it still emitted zero offers. At 01:55:36 the common path used grid 6,587 W with EV credit 0 W, yielding 913 W, while latest-site EV credit was 6,820 W and cap 7,733 W. At 01:58:16 an older 6,640 W grid sample with zero EV credit constrained the offer to 821.932 W while latest grid was -99.39 W.

New regressions reproduce both paths. When no common bracket is found, the fallback now retains EV credit already qualified by the existing latest-site guard; it previously left that field zero. When no positive eligible EV measurement exists, obsolete older site candidates are skipped rather than retaining grid demand from before an EV stop. Freshness, missing-data, latest-site, phase and pending-battery limits remain authoritative. Tests include a real household increase, a later EV reading that cannot fund an earlier site reading, unavailable EV data, and the worst-phase bound. Hardware validation of this follow-up remains pending.

Revision 3 source fix is pushed as 1fe1195 in #1675. Full local verification passes on both source trees, and all executed GitHub CI checks pass. Personal revision 3 ARM64 package is built, copied/extracted on the RPi and checksum-verified. It is not installed; stable charging is still unverified.

Further investigation after revision 3 field failure

The 02:19 incident contains a real household increase: history changes from approximately 0.9 kW household demand / 7.1 kW grid with 6.183 kW EV to approximately 2.0 kW household / 8.15 kW grid. Reducing the EV offer under the 7.5 kW import ceiling was justified. Offers then fell from 9 A to 8 A at 02:19:41 and 7 A at 02:19:46, before the zero-cap verdict at 02:19:51. This is not evidence of physical 25 A fuse overload. History aggregates cannot reconstruct every decision's raw source sample.

Two additional code defects are reproduced locally by focused probes, without changing the running installation or PR production source:

1. recordControlObservation clears the observation ring when source At is over 10 seconds old, even when ControlPowerObservation returns known=true with fresh ConfirmedAt. The probe uses 6183 W source age one minute, confirmation age one second: current reading is valid but the ring is empty. Repeated same-source confirmations are also discarded rather than updating the anchor, and copyControlPoints filters on source time alone. A steady change-only source can therefore lose its pre-transition evidence. Retaining one confirmed anchor must not manufacture multiple physical samples or a usable response window; unavailable/unconfirmed data and observed stops must still invalidate/bound proof.
2. resumeAfterZeroOffer deletes recovery evidence after any sample >= DeliveringW (100 W). A 130 W startup pulse clears it despite a 4140 W minimum charge step. The history includes ~130 W startup pulses. A focused probe reproduces proof deletion. Recovery should require sustained meaningful delivery rather than one low transient; do not globally change the shared delivery threshold without assessing its other consumers.

These are verified code behaviors and plausible contributors. Raw Easee source/confirmation times from the exact stop ticks were not retained, so they are not claimed as a complete field replay. Reason 78 remains observed during refusal to resume, but does not identify the underlying vehicle/contactor condition. The user's cable disconnect/reconnect, rather than demonstrated FTW recovery, started the successful charge.

The new probes are retained outside the source checkout as investigation artifacts; no intentionally failing tests were committed. Revision 3 is still not a validated charging fix. No fourth package or further control mutation was installed during this investigation.

Two further fixes implemented: revision 4 / 8a02c0a

The confirmed-power buffer now keeps one sample at its original source time and advances only its confirmation time. Freshness of that confirmation prevents an unchanged change-only sample from being discarded solely for an old source timestamp. Missing/unconfirmed data and contradictory values at one source time invalidate proof; stops remain in the bounded ring. A separate confirmed-window view serves time-aligned power bounds; independent response verification still uses physical source samples, so repeated confirmations cannot manufacture measurement windows.

Recovery after FTW's own zero offer now requires ten seconds of fresh, advancing meaningful delivery (90% of the lower of configured minimum and actual offer). 130/800 W pulses, one high sample and cached/unavailable observations do not clear it. The shared DeliveringW constant, existing session/safety gates and three-acknowledgement/30-second retry bound remain unchanged.

New before/after and integration tests pass, including a steady confirmed EV followed by a rate decrease, real household increases, missing data, observed stops, one-phase offers and sustained delivery. Full make verify passes on PR and cumulative personal source. Linux ARM64 revision 4 is built; installation and hardware validation remain pending. No automatic reboot or new authorization commands are introduced.

Revision 4 validation update: all executed GitHub checks on 8a02c0a pass, including core (Go) and go test + vet in 38988812967. Final focused regressions pass 20 repeats. The ARM64 revision 4 package is copied to the RPi, extracted and checksum-verified. It has since been installed and checksum-verified; see the revision 4 field-test update below for the current result.

Revision 4 installed: controlled stop/recovery test — 17 October 2026 (CEST)

The personal cumulative v0.145.2-beta.1 ARM64 revision 4, derived from 8a02c0a, is now installed. The running executable SHA-256 matches the revision 4 manifest. FTW restarted at 03:08:08.

Observed on the affected Easee/Pixii installation:

• Before the test, with the import cap disabled: 10.315 kW measured charging, 15 A offered, at 03:09:54.
• With 7,500 W import cap: at 03:13:20, measured EV 6.209 kW, offer 9 A / 6,210 W, grid 7.058 kW, phase currents 9.85 / 11.16 / 9.88 A. Initial offers varied between 6–10 A, then held 9 A for approximately the last minute. No zero offer was recorded in that cap-on interval.
• With 3,000 W cap: at 03:14:02, FTW offered 0 A, actual EV 0 W, grid 851 W. Easee reason 52, max dynamic charger current too low, was consistent with the intentional zero offer. The below-minimum diagnostic reported approximately 2.16 kW available against the 4.14 kW charging minimum.
• After the user disabled the cap, without disconnecting the cable or manually sending Start/Resume: at 03:15:19, offer 15 A / 10,350 W, actual 10.328 kW, charging mode 3. Reason 78 was no longer reported. At 03:16:49, charging remained 10.328 kW, status Following, with no new stop logged in that follow-up interval.

This controlled cap-reduction / below-minimum stop / automatic-recovery scenario passed. It does not establish long-term stability, recovery from every charger state, or correct response to a separate real household load step. The observations do not isolate which individual revision 4 change caused the improved result or establish whether the bounded resume retry path was needed. Human review of the earlier UI changes also remains pending.

Leave the issue open and PR draft. The user has no current peak-tariff requirement, so the import ceiling is disabled for normal charging; configured 25 A per-phase protection remains active. Next validation is a longer charging period and inspection of history around these transitions. History coverage/invalid_balance work remains separately tracked in #1667/#1668; this charging test does not verify that fix.