Idea: BLE-based local data collection via smartphone as a supplementary/fallback data source

Background

TeslaMate currently depends entirely on Tesla's cloud APIs to receive vehicle data. Given the uncertainty around the Owner API and a potentially restricted or paid Fleet API in the future, it seems worth discussing whether parts of the data collection could work independently of Tesla's cloud.

This idea was brought to me by @ptar (thanks, Peter!) via the German TFF forum, and I'm opening this issue to put it up for discussion with the community. To be clear up front: this is an idea for discussion, not a committed feature — I currently don't have the capacity to work on this myself. (But I applied for Claude for OSS)

The idea

Most Tesla drivers already carry their smartphone as their vehicle key, which means the phone is connected to the car via BLE during virtually every drive. A companion smartphone app could:

• Communicate with the vehicle over BLE while driving (and possibly while charging with the phone nearby)
• Collect and buffer vehicle data locally on the phone
• Sync the buffered data to the TeslaMate instance later, once connectivity is available

This would make TeslaMate more resilient in several scenarios:

• API unavailability: Drive data could still be recorded even if Tesla's APIs become restricted, rate-limited, or unavailable
• Cellular dead zones: Gaps in drives caused by the car losing connectivity could be bridged, since the data is collected locally
• Parking spots without coverage: e.g. underground garages — drives could be recorded completely from start to finish
• TeslaMate server offline: A real-world example from Peter: his fiber line was cut and his TeslaMate instance had no internet for 1.5 days. With locally buffered data on the phone, those drives could have been imported afterwards instead of being lost

Why a smartphone and not a dedicated BLE dongle?

A permanently installed in-car BLE dongle was considered but has a significant downside: to work without maintenance, it would have to be paired as a key and permanently live inside the car — effectively leaving a full vehicle key in the vehicle at all times. The chance of someone exploiting this may be small, but it's real.

A smartphone avoids this: it's always with the driver, always charged, always online — and not in the car when the car isn't being used. Support for multiple phones (all drivers of the vehicle) would be the natural extension.

Scope: supplement, not replacement

To set expectations: this approach could not fully replace the Tesla APIs. Some states are simply not observable via BLE, in particular:

• The vehicle while parked without a phone nearby
• Remote/cloud-side information
• Charging sessions without a phone in range

So the API would remain the primary data source, with BLE data acting as a fallback and gap-filler. Missing data would either come from the API as it does today, or simply be absent.

Prior art

The esphome-tesla-ble project demonstrates that BLE communication with Tesla vehicles is feasible and documents parts of the protocol. Tesla's own vehicle-command SDK also covers the BLE transport.

Open questions

• Which data points are actually obtainable via BLE, and how well do they map onto TeslaMate's existing data model (drives, charges, positions, etc.)?
• How would deduplication/merging work when both API and BLE data cover the same time range?
• Mobile platform constraints: background BLE and background execution are restricted on both iOS and Android — how reliably can a companion app collect data without the user actively opening it?
• What would the ingestion path into TeslaMate look like (e.g. a dedicated API endpoint for delayed/batched data)?
• Authentication/pairing: the phone app would need to be enrolled as a key or piggyback on existing key material — what are the security implications?

Call for contributors

As mentioned, I won't be able to drive the implementation myself. If someone from the community is interested in prototyping this (e.g. starting with a proof of concept that reads basic vehicle data via BLE and pushes it to a TeslaMate instance), this issue is the place to coordinate. Peter (@ptar) has offered to help with testing.

Looking forward to your thoughts — both on technical feasibility and on whether this is something the community would want in TeslaMate.