[segran2]

When an EV draws less than requested and the charger reports no limiting reason, FTW currently directs the owner to the charger app even if its own site measurements show that the requested increase would exceed the main-fuse budget. This adds a conditional site-headroom explanation without changing dispatch, priorities, settings or the existing control verdict.

For the reported household, EV charging was approximately 4.2 kW against 10.35 kW requested, while Pixii charged at 9.4 kW and site phases carried about 20 A. With other loads unchanged, the requested EV increase would take the busiest phase to approximately 29 A against a 25 A fuse. The UI explains this projection and explicitly distinguishes it from a limiting cause reported by the charger.

Dependency and scope

Stacked on #1537, base branch easee-load-balancer-limited at b6d93cdf. That PR has right of way for device-reported load-balancer reasons. This PR adds only the fallback calculation for a settled power_below_target with no stronger explanation. Merge/rebase and retarget to master after #1537 lands; do not merge this stack independently.

The local test package was backported to official v0.154.1-beta.1 separately. Installation and real-hardware validation of that package have not yet been confirmed. This draft is for review and testing.

Implementation

• Add optional site_headroom evidence to Core feedback, keeping the underlying status/reason unchanged.
• Require signed positive power on all three site phases before projecting the missing EV load. Current magnitudes alone cannot establish import. Missing, zero, nonfinite, exporting or mixed-flow phase power leaves the cause unknown. Require an exceedance of more than 0.5 A above the effective fuse budget.
• Initially support explicitly configured three-phase EV charging with all three site phase currents available. Single-phase/automatic switching and export/mixed-flow cases remain unexplained rather than assuming a phase mapping.
• Require healthy meter telemetry no more than 15 seconds old and within 10 seconds of the fresh EV observation. Battery charging is contextual information only, included from healthy measurements within the same time bounds.
• Preserve explicit charger reasons, faults, failed commands and existing constraints. The calculation never asserts that a particular load balancer caused the lower draw or that battery charging alone explains it.
• Add a patch changeset. The installable app that vendors web/control-feedback.js will need the updated file after merge.

Validation

• This stacked PR passes make verify and all 701 web tests. Docker-context validation is skipped because the Docker daemon is unavailable.

• API tests cover the reported numbers, asymmetric phases, sufficient headroom, freshness/skew, future readings, missing/nonfinite phases, single-phase mapping, export, safety margin, stronger reasons and healthy battery/meter context.

• Web tests cover conditional wording, explicit inferred evidence, stale UI and fallback behavior.

• Browser-rendered preview of the same new wording using recorded household measurements was inspected by the agent. Human UI inspection and real-hardware validation remain pending.

• The separate v0.154.1-beta.1 backport passed make verify and 865 web tests; its installer was tested for install/rollback, unknown binary refusal and recovery from a simulated startup failure. Docker-context validation was skipped because no Docker daemon was available.

Closes #1761.

Phase-direction correction — 20 October 2026

Commit fbdca47 requires l1_w/l2_w/l3_w to confirm import on every phase. Two regressions reproduced the false 28.98 A explanation before the fix: a fully exporting meter with positive current magnitudes, and mixed phase directions with net import. Both pass after the fix. Tests also cover absent, null, zero and nonfinite phase power; the importing-household projection still passes.

The corrected branch passes the full API suite, focused API race tests and make verify locally, including Docker-context validation. GitHub workflows target master, so the stacked PR does not receive those checks while its base is #1537. Refresh CI after the stack lands and is retargeted.

The updated #1537 now includes master e3da286 and the compatibility change: a named load-balancer limit can explain zero delivery, while a positive offer without a named cause still warns. This PR merges that updated base. Both use the updated driver172 tree aa0ee46, which retains all newer main driver fixes. The separate local integration with #1763 passes the full make verify, web suite and targeted API/control/telemetry race tests.

This PR remains draft and stacked on #1537. Its dependency on device-drivers#172, human UI inspection and real-hardware acceptance still need resolution before merge.

Updated dependency chain

The current heads are driver #172 at aa0ee46, Core #1537 at b6d93cd, then this PR. Conflicts are resolved without rewriting author commits. Keep the merge order driver #172 → Core #1537 → #1762; #1763 remains an independent control fix. Human UI and affected-hardware acceptance remain pending. No release, installation or driver-channel publication follows from these source checks.

Validation on updated head dbf47b5: full make verify passes. The first run failed in the unchanged TestUnsupportedBootTriggerLeavesIdentityUnknown; ten focused repeats and a full retry passed on the same code. The initial failure remains recorded with its cause unqualified. No OCPP code or test was changed to obtain the pass.

[segran2]

Real-hardware follow-up — 2026-10-20 (Europe/Stockholm)

Tested Charge now → Return to plan with Easee Cloud, Audi e-tron 55 (2022), and Pixii Home charging concurrently.

Step	Pixii charging	EV charging	Observation
Scheduled battery charging	~6.5 kW	0 kW	Normal plan
Charge now (15 A requested)	Decreasing	0 kW	At 12 s FTW displayed: Site power limits cap this charge at 0 W right now (15 A requested). (12 s)
After allocation settled	~1.8 kW	~5.5 kW	EV started automatically without Easee-app intervention
Return to plan	Increasing gradually	0 kW	Pixii ramped back up, reportedly subject to FTW safety limits

The observed reduction in Pixii charging (~4.7 kW) coincided with EV delivery rising to ~5.5 kW. This confirms that FTW can redistribute charging power between battery and EV and recover on Return to plan in this test.

Interpretation / limits: The initial 0 W here was explicitly attributed by FTW to site power limits; it should not be conflated with an unresponsive charger. A separate earlier Charge now attempt showed Easee Waiting for over two minutes before charging began automatically, but its root cause is still unverified. This follow-up is field-test evidence, not proof that all under-delivery cases are fixed, and does not establish the cause of the earlier delay. It supports making the site-limitation explanation clearly distinguishable from device-reported limitations and no-power-response states. No code change is requested based solely on this observation.

Next planned check: scheduled EV charging on 2026-10-21 at 02:30 local time.