[segran2]

When Easee reads back a 15 A dynamic current setting but signals a 13 A pilot, FTW must distinguish the setting from the current actually offered to the car. This extension to #1537 adds fresh pilot evidence and displays the values separately for #1874.

Change

• Export actual pilot current, its source timestamp and confirmation time separately from the dynamic setting. Keep legacy offered_a compatible but stop labelling it as an actual charger offer.
• A pilot-aware driver needs finite, nonnegative and freshly confirmed evidence (at most 90 seconds old, no future confirmation/source). Invalid or zero pilot cannot explain an ongoing charging shortfall. Globally stale rows clear the new fields.
• When fresh positive pilot evidence explains the measured delivery, retain informational load-balancing limits; without a proven internal cause use charger_pilot_limit/info. A matching known static charger limit is also informational.
• Preserve failed/pending/unconfirmed command precedence and warnings for no delivery or genuine delivery below the pilot. Legacy driver behavior remains compatible.
• Add API and rendered-text regressions plus a patch changeset.

Dependencies and scope

Stacked on #1537 at 84a3aada1c46a38b8a067c50a6577a64d4a57a73, targeting its existing easee-load-balancer-limited branch. Paired driver extension: srcfl/device-drivers#200 (itself stacked on srcfl/device-drivers#194).

Do not merge this stack directly past those dependencies. The generated driver snapshot is untouched; after driver integration a separate pin/snapshot update is required. The app that vendors web/control-feedback.js needs the matching module. No battery diagnostics, native updater overlay or EV charge-cost changes are included.

Related to #1874. Keep the issue open until the dependency stack and release integration are complete.

Validation

Exact stacked PR tree:

• make verify: passed (Go tests, vet, build and repository checks). Docker-context and live Avahi checks skipped because Docker was unavailable.
• npm test: 887 passed, 0 failed.
• Added API regressions cover known/unknown/static pilot limits, stale/future/missing evidence, zero pilot, no delivery, genuine underperformance and command-state precedence.
• Git whitespace and tree checks passed.

The same pilot extension integrated with official v0.157.2-beta.1 and prior local patches passed a separate full verification and 895 web tests before deployment. That deployed combination is not this older stacked base.

Live paired evidence, 27 October 2026, local v0.157.2-beta.1+local.2, Easee cloud charger and Audi e-tron:

• 15 A requested / 15 A pilot / approximately 10.46 kW: Following FTW.
• 15 A request and dynamic setting / 13 A pilot and circuit allocation / approximately 8.93 kW: six consecutive settled samples over approximately 54 seconds classified limited/load_balancer_limit/info. The real EV sheet rendered “Limited by the charger’s load balancing” with separate 15 A setting and 13 A pilot, without a red warning.
• Releasing the temporary hold restored plan, 0 A pilot and 0 W. Durable goals/protection settings were unchanged.
• An earlier test with the car already at its own limit delivered 0 W and retained no_power_response after the response wait. Initial transient following/power_observed while 0 W was still present is a separate observed transition issue, not fixed or treated as charging proof here.

One-site hardware evidence does not establish other makes/firmware, precise load-balancer causality or all failure/recovery transitions. Charger model/firmware identifiers were not captured. Rendered browser checks and live screenshots were inspected locally; no raw household logs, private addresses or device identifiers are added to the repository. Keep draft pending dependency integration and CI/review.