fix(bthome_receiver): register listener via esp32_ble_tracker helper - #16
Open
magliaral wants to merge 1 commit into
Open
fix(bthome_receiver): register listener via esp32_ble_tracker helper#16magliaral wants to merge 1 commit into
magliaral wants to merge 1 commit into
Conversation
Manual parent.register_listener() bypassed the listener count used to size the ESPHOME_ESP32_BLE_TRACKER_LISTENER_COUNT StaticVector, which silently dropped the last-registered listener at runtime. Use the official register_ble_device() helper so the listener is counted.
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
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.
PR: Use
register_ble_device()helper so the Bluedroid listener is counted for StaticVector sizingSuggested title:
fix(bthome_receiver): register via esp32_ble_tracker.register_ble_device() so listener is counted for StaticVector sizingProblem
When
bthome_receiver(Bluedroid mode) is used together with other BLE listenercomponents (e.g.
victron_ble, Xiaomi/BTHome sensor platforms,ble_presence, …),one of the other components silently stops receiving advertisements. No warning,
no error — the affected device is simply deaf. Which component breaks depends on
registration order in the generated
main.cpp, so the symptom looks random and isvery hard to diagnose.
Observed in the field: ESPHome 2026.6.5, ESP32-S3, Arduino framework, config with
3×
victron_ble+ 1×bthome_receiver. The last-registeredvictron_bleinstancereceived no data while its advertisements were demonstrably arriving at the tracker
(verified with
esp32_ble_tracker: VERY_VERBOSE). Removingbthome_receiverfromthe config made the victron instance work again.
Root cause
Since the 2026.x releases,
esp32_ble_trackerstores its listeners in afixed-capacity
StaticVectorsized at compile time:StaticVector<ESPBTDeviceListener *, ESPHOME_ESP32_BLE_TRACKER_LISTENER_COUNT> listeners_;The
ESPHOME_ESP32_BLE_TRACKER_LISTENER_COUNTdefine is computed during codegen bycounting calls to the official Python helper
esp32_ble_tracker.register_ble_device()(it increments_get_registration_counts().listeners).bthome_receiverregisters its hub manually, bypassing the counter:The hub therefore performs a runtime
register_listener()call that was neveraccounted for at compile time. With N other listeners in the config, the vector has
capacity N, but N+1 registrations happen at startup — and
StaticVector::push_backon a full vector silently drops the excess element. Whichever listener registers
last (typically the last platform instance in the YAML) never receives
parse_device()callbacks.Reproduction / evidence
Config: 3×
victron_ble+bthome_receiver(bluedroid,esp32_ble_idset),esphome compile --only-generate:Fix
Register through the official helper, which both performs the registration and
increments the compile-time listener count:
After the fix, the same test config generates
ESPHOME_ESP32_BLE_TRACKER_LISTENER_COUNT 4with 4 registrations — all listenersget their slot. NimBLE mode is unaffected (the branch is only taken in Bluedroid
mode when a tracker ID is configured).
Testing
esphome configpasses on ESPHome 2026.6.5 (ESP32-S3, Arduino).esphome compile --only-generate: define now matches the actual number ofruntime registrations (verified with and without the patch, see above).
victron_ble(SmartShunt, SmartSolar,Orion DC-DC) and
bthome_receiver(3 Shelly BLU H&T) all receive dataconcurrently on an ESP32-S3.
Related note (separate issue?)
The registration currently only happens when
esp32_ble_idis set explicitly inYAML, because the schema declares the tracker reference as
cv.Optionalinstead ofcv.GenerateID. Without an explicitesp32_ble_id, the Bluedroid receiverinitializes but is never attached to the tracker (deaf, no warning). Happy to file
that separately / include it here if preferred — switching the schema entry to
cv.GenerateID(esp32_ble_tracker.CONF_ESP32_BLE_ID)and dropping theifwould fixboth ergonomics and this footgun in one go.
Suggested commit message: