Skip to content

Cap a car at its request maximum only where the car sets it - #759

Open
MikeBishop wants to merge 1 commit into
ngardiner:mainfrom
MikeBishop:fix/car-max-amps
Open

MikeBishop wants to merge 1 commit into
ngardiner:mainfrom
MikeBishop:fix/car-max-amps

Conversation

@MikeBishop

Copy link
Copy Markdown
Collaborator

A Tesla reports charge_current_request_max capped at the charger's pilot, so it's the car's own AC maximum only when the car, not the charger, is the limit. vehicleMaxAmps took any reading as the car's own, which caps the car's power share (VehicleEndpoint.maxPower) and the range a car provider commands amps over.

What went wrong:

  • A Gen2 TWC briefly offers 6 A as a car goes idle. A read then recorded a request maximum of 6, and it stayed until the next read while charging.
  • The next scheduled charge started with the car's target at 6 A. On some nights the reconciler sent 6 A before the reading caught up, and then 48 A seconds later.
  • On our own TWC the pilot is our last offer, so a car read under a low offer could hold its charging point at that offer.

The change:

  • A request maximum counts as the car's own only when one source's reading has it below that source's pilot, and is no older than the pilot. Otherwise the wiring limit (wiringMaxAmpsPerTWC) stands, and the car clamps a higher rate itself.
  • A car-limited value doesn't change with the charger, so it holds under later low pilots.
  • Lifts are unchanged: a car the TWC carries is raised once per session to the TWC's maximum, never to the offer or the car's own maximum. A new test pins that.

Evidence:

  • Full unit suite (pytest tests --ignore=tests/API --ignore=tests/integration --ignore=tests/scenarios): 2669 passed, on main f094c7c.
  • Found on a live install (one car, one Gen2 TWC, the car on a TWC run by a second instance). Diagnostic logging on 2026-11-09 showed the car's target set to 6 A at the 00:00 schedule start with the car's last request maximum 6, then 48 A once a read while charging came in. The same 6 A then 48 A command pair appeared on 10-31, 11-06 and 11-08.
  • Not exercised on hardware: a car whose own maximum is below its charger's, or the lock-in on our own TWC. Unit tests only.

Released in 1.4.0 in an earlier form: TeslaAPIEVSE.maxPower was the car's last-read pilot (charger_pilot_current). It applied to cars at home that no TWC serves, so a car on a third-party EVSE read while the pilot was low stayed capped there. The 1.4.1 changelog's existing entry already claims "never the pilot it last saw"; this corrects it to say the car's own maximum is known only where a reading shows it below the pilot.

🤖 Generated with Claude Code

A car reports its request maximum capped at the charger's pilot. Read
as a Gen2 TWC briefly offered 6 A going idle, it stayed at 6 until the
next read while charging, so the next night's scheduled charge was rated
at 6 A and sometimes commanded there before the reading caught up. On
our own TWC the pilot is our last offer, so a car read under a low offer
could hold its charging point there.

A request maximum is now the car's own only when one source's reading
has it below the pilot; otherwise the wiring limit stands. Lifts still
go to the TWC's maximum.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.

1 participant