Add Bluetooth connection binary sensor for Teslemetry BLE vehicles - #989
Draft
Bre77 wants to merge 4 commits into
Draft
Add Bluetooth connection binary sensor for Teslemetry BLE vehicles#989Bre77 wants to merge 4 commits into
Bre77 wants to merge 4 commits into
Conversation
Shared by teslemetry, tesla_fleet and tessie, so all three manifests move together. 1.11.0 adds the ObservationFunnel the closure covers adopt in the following commit.
Route the Bluetooth charge-port and front-trunk covers through a per-vehicle tesla_fleet_api ObservationFunnel with BleBroadcastPublisher and VehicleDataResultPublisher attached, so each renders a value from either the BLE broadcast or vehicle_data and survives the loss of one source. Demand signalling drives both sources: the BLE publisher subscribes only while a field is listened to, and a demand observer gates the vehicle_data feed. The lock and rear trunk stay on the existing single-source BLE path.
The funnel keeps its structure and BLE broadcast publisher, but the VehicleDataResultPublisher and the coordinator-fed path that existed only to feed it are removed: streaming signals, not vehicle_data, are the intended second source and no stream publisher exists yet. While the funnel is single-source BLE, the funnelled charge-port-door and front-trunk entities re-impose the BLE connection-generation tie so a dropped link clears the value, matching ble.py; this is removed once a second source is attached.
Bre77
force-pushed
the
fm/ble-d9-6-funnel
branch
from
August 28, 2026 01:59
09b1cb6 to
8a87adb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Breaking change
Proposed change
Add a per-vehicle Bluetooth connection binary sensor for BLE-paired Teslemetry
vehicles. It reports whether the vehicle is currently reachable over its local
Bluetooth link, reading
TeslemetryBLEDataManager.connectedand re-evaluatingon the manager's
async_on_connection_changesubscription. The device alreadycarries several connectivity sensors (cellular, Wi-Fi, GPS, and the awake state
mapped from VCSEC sleep), so the entity is named "Bluetooth connection" and
keyed
bluetooth_connectionto be unambiguous among them; it is diagnostic andobserve-only.
Unlike every other BLE-driven entity, this one deliberately does not go
unavailable when the link drops — a connectivity sensor that went unavailable on
disconnect could never report the one thing it exists to report. It stays
available and reads off, and is only absent when a vehicle is not BLE-paired at
all (no manager, so no entity). A regression test asserts exactly that: on
disconnect the sensor is available and off, not unavailable.
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: