Bluetooth Vehicle Control

Every command Teslemetry sends to your vehicle today takes the same path: up to Teslemetry's servers, out to Tesla's servers, down to the car. That works well, but it means every lock, unlock, or climate command depends on your internet connection, Tesla's API, and the car having connectivity. The Home Assistant integration now has a new option that skips all of that entirely: Bluetooth.

Straight to the car

The latest beta of the Home Assistant integration adds local Bluetooth control for your vehicle. Once paired, supported commands like locks, climate, and charging are sent directly to the car over BLE first, falling back to the cloud automatically, per command, whenever a local connection isn't available. No API call, no command credits, no internet hop, no dependency on Teslemetry's or Tesla's servers being up.

This matters most in the situations where cloud control is at its weakest: a flaky home internet connection, a Tesla API outage, or a vehicle sitting in a garage with poor cellular reception. If the car is within Bluetooth range of your Home Assistant server, or a Bluetooth proxy, your commands still get through. The other major benefit is for high-volume use cases like charge on solar, which can bypass command credits entirely, allowing you to make frequent fine adjustments.

What you'll need

• Home Assistant, on a stable core from 2026.7.0 or newer.
• The hass-teslemetry custom integration installed via HACS, since Bluetooth control isn't in the core integration yet.
• A Bluetooth adapter in range of your vehicle. If your Home Assistant server doesn't have Bluetooth built in, or your car usually parks out of range of it, Home Assistant's existing Bluetooth proxy support has you covered: a cheap ESP32 running ESPHome's Bluetooth proxy firmware, placed in your garage or driveway, extends coverage to wherever you need it.
• One-time pairing per vehicle. Reconfigure the vehicle in the integration to add its virtual key over Bluetooth, then approve it once on the car's touchscreen. After that, no further pairing is needed.

Getting started

Bluetooth control ships through the beta channel of the Home Assistant integration, installed via HACS as described in the docs. As with any beta, expect things to keep moving quickly, so keep an eye on the release notes as it stabilizes.

How we got it reliable

Bluetooth is a much less forgiving transport than a REST API, and Tesla only provides limited documentation on how Bluetooth communication works. There's no server to retry a bad request for you, and a car doesn't respond like a web service does, so getting this from "it connects in the lab" to "it works every time" took a lot of iteration against a real, parked vehicle. We leaned on Firstmate, Claude Code and an automated test harness to do most of that iterating.

The first challenge was getting the agent, running on a headless server nowhere near the Tesla vehicle, access to it over Bluetooth. We already mentioned above how ESPHome Bluetooth proxies can help bridge this, but we needed this to work outside Home Assistant, so using bleak-esphome the agent could connect to my existing Bluetooth proxy. However, we soon realised Home Assistant didn't like sharing, so I built a dedicated ESPHome Bluetooth Proxy for the agent to own.

With a reliable connection in hand, the harness worked through the full command surface against the car - locks, climate, charging, media, navigation - catching a few real bugs along the way, like a mis-mapped seat heater setting.

The most useful thing it found wasn't a bug, but a rule: a Bluetooth timeout on a command that changes the vehicle's state doesn't mean the command failed. We proved this directly - a lock command timed out over Bluetooth, and the door had locked anyway. Reads get an acknowledgement plus the requested data back, which is self-checking; actuations like locking a door only get a bare acknowledgement, and if that one packet goes missing, you see a timeout even though the car already acted. So the integration never treats a timeout as a failure and never blindly retries a command that changes state - it always double-checks with a follow-up read instead. The same testing cut the typical time to confirm a lock or unlock from around six seconds down to about one, by fixing how the library waited for that acknowledgement.

By the time we sat down next to the actual car and tested every physical command by hand - doors, frunk, trunk, charge port, horn - it worked exactly as expected. That's the bar we hold a beta release to.

More local control on the way

Bluetooth control is the first piece of a broader push towards local control that doesn't stop at your vehicle. Local data access will be coming soon, and local command routing for Powerwall over the local network is being worked on in parallel. The goal across both is the same: give you access to your Tesla products' data as easily as possible.