[frahlg]

Problem

A tester on v0.140.0-beta.1 (Easee Cloud, Pixii, 25 A three-phase fuse) saw "Not following. Asked for 11.0 kW charge, delivering 8.3 kW. The charger has not said why." Requested current, charger offer and charger limit all read 16 A. The charger's load balancer had cut the car to about 12 A per phase.

#1536 stops FTW's own battery charge from causing that cut. A load balancer set tighter than FTW's fuse, or a fast house load, can still cut the car. FTW should then name the cause.

Two things hid it:

• The Easee driver dropped ReasonForNoCurrent while the car charged, if the reason was older than the last power change. Fixed in fix(easee_cloud): report a load-balancer limit while the car charges device-drivers#172.
• Core never used a charger's reason for a shortfall. power_below_target always ends with "The charger has not said why."

Change

• feedbackReading reads the driver's vendor-neutral current_limited_by. When an EV driver sets it to load_balancer and the car draws less than asked for the usual grace, classifyControlFeedback reports load_balancer_limit. setControlStatus maps it to limited / info, like fuse_limit: a load balancer protecting the fuse is expected and clears on its own. More power than asked still warns.
• web/control-feedback.js: title "Limited by the charger's load balancer"; "Asked for 11.0 kW charge, delivering 8.3 kW. The charger's load balancer is limiting the car." At zero: "…but the charger's load balancer gives the car no current." Next step: "The load balancer raises the current again when the house uses less. If this happens often, check that FTW's main fuse setting matches the load balancer's."
• Advance the current 5cc7 driver snapshot to aa0ee46, the updated fix(easee_cloud): report a load-balancer limit while the car charges device-drivers#172 tree (easee_cloud 1.3.7). All other driver Lua bytes from current main remain unchanged.
• Changeset: patch.

The reason name is not in contract/registry.yaml; no control-feedback reason is. srcfl/ftw-webapp vendors web/control-feedback.js and needs a fresh copy after this merges. Until then the app shows "Limited" with "The box reports “load_balancer_limit”, which this version cannot describe."

Paired PR

srcfl/device-drivers#172 must merge first. Then move drivers/BUNDLED_SOURCE.json to its merge commit on main before this merges.

This branch now includes master e3da286 and the updated driver dependency without dropping newer driver fixes. Keep #1762 stacked on this branch until the dependency chain lands.

Evidence

• TestLoadBalancedChargerReadsAsLimited replays a 6-minute Easee-like trace: named load balancer at 8.3 kW and at 0 W reads limited/load_balancer_limit/info; without the name it stays not_following/power_below_target/warning; 13 kW against 11 kW stays power_above_target. With the new branch disabled, the named cases fail as not_following.
• TestControlStatusAnswersEveryReason covers the new reason; web/control-feedback.test.mjs checks the words, and the existing test checks every reason in setControlStatus has words.
• make verify and npm test (700 tests) pass locally.
• Browser review: the PR's web/ served against the home box's live /api/status, with the EV row replaced by Core's output for the tester's case. Desktop and 375 px phone width read correctly; Numbers show 16 A requested, offered and limit. Not yet seen with a real load-balanced Easee.

🤖 Generated with Claude Code

Current-master compatibility

A named load-balancer limit may explain zero EV power. A positive offer without a named cause still produces no_power_response after the normal response window. This resolves the interaction with master's newer zero-power warning without changing dispatch or safety limits. The six-minute scenario covers both cases.

The driver dependency is updated and tested on #172, with green checks. This pin refers to that exact PR head; the existing dependency merge order still applies. No driver channel or Core release has been published by this work.

Validation on b6d93cd: full make verify and the web suite pass locally. The first full run failed in the unchanged TestAQUICSessionThatEndsBeforeHelloOKDemotesQUIC; ten focused repeats and a second full run passed on the same code. That first failure remains in the evidence and its exact cause is unknown. All 44 generated Core Lua files match the pinned driver source byte for byte. Human UI and affected-hardware acceptance remain pending; no box was changed.