Vehicle API charger: trigger wakeup when vehicle is asleep

[andig]

Closes #28652

Summary

The vehicle-api charger propagated api.ErrAsleep from Status(), causing loadpoint Update() to early-return at core/loadpoint.go:1962 before reaching setLimit/Enable. The existing wake-up plumbing in setLimit (loadpoint.go:951 — calls vv.WakeUp() on ErrAsleep) was therefore never triggered, so a Tesla using the Vehicle-API charger could fall asleep and never wake up again, even with an active plan or mode: now.

Fix

Treat ErrAsleep in VehicleApi.Status() as connected, not charging (StatusB) instead of propagating the error. This lets the rest of Update() run; the existing wake-up path then handles the sleeping vehicle:

setLimit() → charger.Enable(true) → vehicle.ChargeEnable(true)
           → returns ErrAsleep
           → setLimit() catches and calls vv.WakeUp()  (loadpoint.go:951)

For Tesla Fleet API, StartCharging() is one of the calls that wakes the vehicle implicitly, so in many cases the implicit wake is enough; the explicit WakeUp() only fires as the rate-limited retry on the next cycle if needed.

Why this approach over patching Update()

The issue body suggests handling ErrAsleep directly in Update(). That works but:

• bypasses the existing rate-limited wake-up timer (wakeupAttempts = 6, wakeupTimeout = 30s from core/timer.go),
• only covers planActive() — would still skip mode == now, welcome-charge, SOC-driven charging,
• duplicates wake-up logic that already exists in setLimit.

Re-using the existing path keeps semantics consistent across charger types.

Edge cases

• mode == off, no plan, vehicle asleep: Status() reports StatusB, strategy switch runs setLimit(0) → Enable(false) → Tesla controller's StopCharging() swallows ErrAsleep (vehicle/tesla/controller.go:48). No spurious wake-up.
• Geofence enabled, vehicle away and asleep: isVehicleAtHome would normally fail because Position() requires the vehicle to be awake. With the patch, that path also returns StatusB. The next Enable(true) call goes to Tesla, the implicit wake fires, and the next Status() call gets a real position — if it's outside the geofence, Status() correctly returns StatusA. Worst case: one unnecessary wake before the geofence kicks back in.
• Geofence disabled, Tesla asleep: wakes on first Update, treated as connected. Matches user expectation since they have no other connection signal.

Test plan

• Tesla asleep + plan active → wakes within one Update cycle, plan executes
• Tesla asleep + mode = now → wakes within one Update cycle
• Tesla asleep + mode = off, no plan → no wake-up calls, no log spam
• Tesla awake but disconnected (geofence enabled, away) → still StatusA, no behaviour change
• Geofence disabled + Tesla asleep → wakes on first Update (treated as connected)

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've left some high level feedback:

• The ErrAsleep handling in both the isVehicleAtHome branch and the v.Status() branch is nearly identical; consider extracting this into a small helper or at least centralizing the logic so future changes to the asleep behavior aren’t duplicated in two places.
• When treating ErrAsleep as StatusB you currently do so silently; adding a debug-level log in these branches would make it much easier to understand why a vehicle is considered connected when it is actually asleep during troubleshooting.
• The comment "assume previously known location is still valid" in the isVehicleAtHome error path is a bit ambiguous since the code doesn’t reference any stored location here; consider clarifying how/where that state is maintained or rephrasing to avoid implying behavior that isn’t explicitly visible in this function.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `ErrAsleep` handling in both the `isVehicleAtHome` branch and the `v.Status()` branch is nearly identical; consider extracting this into a small helper or at least centralizing the logic so future changes to the asleep behavior aren’t duplicated in two places.
- When treating `ErrAsleep` as `StatusB` you currently do so silently; adding a debug-level log in these branches would make it much easier to understand why a vehicle is considered connected when it is actually asleep during troubleshooting.
- The comment "assume previously known location is still valid" in the `isVehicleAtHome` error path is a bit ambiguous since the code doesn’t reference any stored location here; consider clarifying how/where that state is maintained or rephrasing to avoid implying behavior that isn’t explicitly visible in this function.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}