Skip to content

fix(ev): explain vehicle completion without a no-power alarm - #1980

Open
segran2 wants to merge 1 commit into
srcfl:masterfrom
segran2:fix/1976-vehicle-completed
Open

segran2 wants to merge 1 commit into
srcfl:masterfrom
segran2:fix/1976-vehicle-completed

Conversation

@segran2

@segran2 segran2 commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

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.

Signed-off-by: Segran <goran@andersson-stehag.se>
@segran2
segran2 marked this pull request as ready for review November 6, 2026 22:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

EV feedback reports no power response after Easee Completed at the vehicle's 80% charge limit

1 participant