[segran2]

Problem and behavior

Fixes #1976. A car that has stopped at its own charge limit can draw 0 W while Core still asks for charging because vehicle SoC is missing or stale. The driver already reports request_active=false, but feedback could still say not_following/no_power_response and optional recovery could restart the vehicle.

This change uses that existing, explicit driver signal to explain “The charger reports that the car has finished or paused charging”, with a prompt to check the car's charge limit and schedule. It never infers a full battery, rewrites SoC or marks the charging goal complete.

• Fresh vehicle-stop evidence, an accepted positive order and measured near-zero power produce vehicle_not_requesting/waiting/info. ControlStates uses the same result, so control.not_following does not fire solely on this explained zero draw.
• Missing/stale request evidence, failed/unconfirmed commands, safety stops, a lower order held by the charger and unexpected draw keep their own diagnoses.
• RequestKnown distinguishes explicit vehicle refusal from legacy telemetry without the field. Optional resume and vehicle-wake retries are avoided while the current vehicle explicitly declines power. Normal recovery returns when the vehicle requests charging again.
• No driver changes, settings changes, public diagnostic endpoints or local-only instrumentation are included. vehicle_request_active is an additive optional feedback field. A patch changeset is included.

Validation

On this standalone branch based on ec8ce36192cfe9947b63f7ed9e388c28ecc375a5:

• make verify: passed. Docker-daemon-dependent checks skipped in this environment.
• npm test: 902 passed, no failures.
• Targeted go test -race for API, loadpoint and cmd/ftw: passed.
• Regressions cover a sustained vehicle stop, notification verdict, missing/active request evidence, stale readings, failed/unconfirmed commands, a lower held current offer, unexpected power, suppressed optional retries and recovery after a new active vehicle request.

Hardware evidence and limits

Real Audi e-tron + Easee Cloud + Pixii, 6 November 2026, CET (Europe/Stockholm). The owner reported 72% before charging, an 80% vehicle limit, and confirmed 80% after the test.

The field run used v0.159.0-beta.1+local.3 (1c385a353b91cb8596c99494843031b82811424b), which carried this correction alongside unrelated local diagnostics/pilot patches. This PR excludes those patches; the standalone upstream build has automated validation, not a separate field deployment. Charger/vehicle firmware versions were not recorded.

• Observed charging at approximately 10.3 kW.
• 17:54:20: charger Completed, request_active=false, measured 0 W, while the accepted order remained 10,350 W. Core correctly reported vehicle_not_requesting/waiting/info in 18 five-second monitor samples; no false no-power alarm.
• No accepted optional ev_resume after the vehicle's stop in the retained command trace; no later auto-resume in the retained Easee log.
• 17:55:54: manual charging was inactive and the loadpoint returned to the plan at 0 W. The observer did not change or renew any owner hold.
• No control-loop stall in the test journal window, no trace drops/write errors. Maximum sampled absolute site phase current 24.1 A against a configured 25 A fuse; shorter transients are not excluded.

Completed alone does not prove 80%: the final level is owner-confirmed, not independently timestamped BMS telemetry. No physical fault injection or safety-limit test was performed. Detailed private diagnostic bundles remain local and are not attached publicly.

Review and overlap

Draft pending human review of the rendered EV view. An AI browser preview exercised the actual before/after formatter with simulated status rows; this is not a human UI acceptance check.

#1537 and #1905 also touch feedback. This is a separate vehicle-request/completion path and adds no pilot-current or load-balancer inference; the regression fixture is independent of their evTrace extensions. Their changes/reviews are not superseded. No automatic reviewers are requested.

[frahlg]

Maintainer commits on top (6957b2c, after merging current master):

• vehicle_not_requesting is back in the following list: it is Core's own 0 W stop after its debounce, and Core is in control there. The new case — the driver says the car stopped while Core still offers more than 100 W — has its own reason, vehicle_declined (waiting/info, title "Car stopped charging"), so one reason does not mean two things.
• The decline needs 90 s (SessionCompletionTimeout), reusing the manager's notRequestingSince timer. A brief request_active=false during the session handshake keeps waiting_response/no_power_response.
• chargerIdleForWake is back to master's form; the request check moved into vehicleDeclinesOffer, which checks freshness. This also restores the contactor kick and ev_resume after Core's own pause.

Tests for the blip, the lasting decline, Core's own stop and the controller side; each fails without its fix. The iOS app needs words for vehicle_declined in a paired ftw-app change.