Tesla BLE: recover missing SoC without requiring fresh telemetry to wake the car

[frahlg]

A reported v3 upgrade left a full Tesla scheduled for roughly 20 kWh of overnight charging because FTW did not obtain the current vehicle SoC. The Tesla BLE integration still exists and tesla_vehicle remains in the v3.5.1-beta.1 recovery bundle. The exact affected site has not been inspected.

Verified on FTW v3.5.1-beta.1 (e0d6e233) and device-drivers d44fda11, Tesla driver 0.2.2:

1. The driver deliberately does not force a BLE wake on its first poll. Its normal first wake is 30 minutes after startup. A Lua mock returning HTTP 200 with charge_state but no battery_level produces 30 polls with no wake and no vehicle reading; the first wake occurs at minute 30. Empty/partial successful responses do not arm the short recovery retry. This startup policy dates to Core commit 13aa7ad6 (2026-04-29), so it predates v3.
2. Core chooses the wake recipient through the fresh-SoC picker: main.go:2131-2141, telemetry/vehicle.go:112-124, then loadpoint/controller.go:1099-1105. Missing or stale SoC yields no vehicle recipient, so even a schedule refresh can silently skip the wake needed to recover that same missing SoC. Vehicle identity and permission to request telemetry must not depend on a fresh SoC value.
3. A second Lua probe repeats the same cached payload with an unchanged old charge_state.timestamp. The driver emits it as stale=false at +10 minutes and does not set soc_fresh=false. Only local error replays carry soc_fresh=false; cached successful proxy responses currently renew apparent freshness. Source timestamp semantics need verification against the proxy before implementing this fix.

Driver references: drivers/lua/tesla_vehicle.lua:252-310 (wake cadence), :352-410 (empty/partial responses), :412-436 (SoC freshness). Core planner input falls back to inferred SoC when no usable vehicle reading exists (main.go:1647-1657). The user report is consistent with these holes, but does not prove which path occurred on that site.

Required correction:

• Request a bounded telemetry-only wake/read when a configured local vehicle lacks fresh SoC at startup or an active charging-goal event. Keep rate limiting across repeated restarts; do not restore a wake storm.
• Find the authorized vehicle recipient from durable configuration/identity without accepting its stale SoC as planning truth. Handle multiple vehicles without waking or assigning the wrong car.
• Preserve source freshness; successful cached HTTP is not a new BMS observation. Show inferred/missing SoC explicitly and replan once a fresh reading arrives.
• Keep telemetry refresh distinct from charge_start and wallbox contactor cycling. A full car must not be forced to charge just to read its status.

Regression coverage must include cold boot with no cache, HTTP 200 without SoC, stale successful cache, normal HTTP errors, 408/503 throttling, repeated restarts, multiple vehicles, and a full car receiving fresh SoC after an incorrect inferred demand. Test the finished fix on a Tesla BLE installation before claiming the reported site works.

This remains unfixed in v3.5.1-beta.1. The beta is published; no production migration or Tesla wake command was run during this investigation.

[frahlg]

The owner removed release-blocker on 2026-10-07 so the first native stable can ship. The driver part is probably fixed (srcfl/device-drivers#167, in the bundled pin), but nobody has run it against a real Tesla over BLE yet. The stable release note says so. This issue stays open until someone confirms SoC recovery on real hardware.