I’m trying to understand bluetooth_proxy and esp_ble_tracker capability and behavior.
From my reading it seems like tracking devices is one use of BLE. But BLE can also control devices, but at lower speeds and power usage. The YAML tag “esp32_ble_tracker” implies it can enable tracking, but does it also enable proxy control?
I have Switchbot blind controllers which have this on their spec page:
BLE: ≥5.0 (Long Range) Bluetooth Technology: Proprietary power-saving BLE with mesh support
I originally compiled my ESP32 device with only bluetooth_proxy, and they worked. So I assume the can use non-BLE BT connections as well.
In order to try and save battery usage on the devices, I then added esp_ble_tracker to the YAML config, and updated the ESP32. The devices still seem to work, but I’m unsure what connection they are now using… is there any way to tell? Do devices and the ESP32 automatically negotiate the best protocol to use?
I’m trying to figure out if there’s any further configuration I need to do or it’s auto-magic once devices are discovered… I’ve also read there’s a ble_gatt tag, but unsure how that would play in to this scenario…
I was confused about this as well, in fact I think the naming is a bit unfortunate (and this should perhaps be clarified somewhere in the docs).
The bluetooth_proxy Integration is really using BLE (to my understanding). This is what you want for all your BLE thermostats, sensors, (your blind controller), etc.
My instinct says perhaps not, but I would welcome a definitive answer as well. I have also heard this referred to as “Classic Bluetooth” (to differentiate those things like phone and audio headsets, speakers, etc.).
Obviously the esp32_ble_tracker is more about tracking, specifically. My understanding is that it just forwards the BLE advertisements to HA without any processing whatsoever. So I would also assume no 2-way control. Not even sure it can forward sensor packets?
You could do an experiment, if you want…
You could do the opposite and see if the sensors (or blind controller) still work or not. But I would bet not.
Ah ok, so this is really a YAML tag naming issue. Although “ble” is specifically included in the other tags (such as for tracker) , that doesn’t imply it’s not also part of bluetooth_proxy.
I do agree it’s not entirely apparent, especially as the ESPHome Bluetooth Proxy configuration page includes in its “Recommended Configuration” including both, with no indication that in reality the ble_tracker directive is not really needed for a proxy.
Yeah, given I may have actually been connecting via BLE all along, I bet you are right.
With this context that seems right as well. It’s not a separate BLE stack but rather the tracking component implemented as part of BLE, and not available to “classic” Bluetooth. (Which kind of makes the naming more sensible)
I actually did that shortly after I posted and sure enough control went away… so that tracking component doesn’t imply it enables Bluetooth BLE proxying as well. However, the YAML parser didn’t complain about the proxy not being also enabled, and the log files did report no clients registering, so it does feel like it activated the Bluetooth stack for the tracker to use, just without any proxying ability.
Incidentally to answer my own question as to how to know if a device is using BLE vs classic BT, I found that in the ESPHome add-in in HA, you can access the log files for a client device in the project… opening them I now have more questions, as I removed the esp_ble_tracker component from the YAML, reinstalled and have entries such as:
[18:48:52][C][esp32_ble_tracker:677]: BLE Tracker:
[18:48:52][C][esp32_ble_tracker:678]: Scan Duration: 300 s
[18:48:52][C][esp32_ble_tracker:679]: Scan Interval: 320.0 ms
[18:48:52][C][esp32_ble_tracker:680]: Scan Window: 30.0 ms
[18:48:52][C][esp32_ble_tracker:681]: Scan Type: ACTIVE
[18:48:52][C][esp32_ble_tracker:682]: Continuous Scanning: YES
[18:48:52][C][esp32_ble_tracker:683]: Scanner Idle: NO
[18:48:52][C][esp32_ble_tracker:684]: Scan End: NO
[18:48:52][C][esp32_ble_tracker:685]: Connecting: 0, discovered: 0, searching: 0, disconnecting: 0
