-
-
Notifications
You must be signed in to change notification settings - Fork 10
ESPHome Configurations
Chip | Compat | Notes |
---|---|---|
ESP32 | Good | Original esp32 chip, such as the ESP-WROOM-32 etc. BT4.2 |
ESP32-S2 | NO | Has no Bluetooth, single core. |
ESP32-S3 | Good? | BT5, Dual-core. No integrated Ethernet MAC |
ESP32-C2 | ?? | Single-core RISC-V |
ESP32-C3 | Good? | Single core RISC-V, BT5 |
ESP32-C6 | ?? | Dual-core RISC-V, BT5.3, Thread, Zigbee |
ESP32-H2 | ?? | Single-core RISC-V, BT5.3, NO WIFI |
ESP32-C5 | ?? | Single-core RISC-V, BT5, WIFI6 (2.4GHz + 5GHz) |
ESP32-P4 | NO | Triple-core RISC-V, NO WIFI OR BT |
- Please let me know if you have first-hand experience of bluetooth-proxy working on any of the above where I don't have "Good" noted. The "??" entries don't mean "it doesn't work well" it literally means that I, personally, aren't sure - probably because I've been too lazy to check properly. Corrections welcomed!
- Use the
esp-idf
framework, as thearduino
framework is less memory-efficient and doesn't seem to perform as well.
esp32:
board: wemos_d1_mini32 # Make sure you choose *your* board here!
framework:
type: esp-idf
- I turn off serial logging because I think it uses more memory and cpu time. I don't know if that's entirely true or not. With this setting you still get debug logging via wireless connection.
logger:
baud_rate: 0 # disable serial uart logging
#level: VERBOSE
- Try flashing your proxy via USB or Serial just once. This is because esphome changed the flash format/layout not too long ago in order to improve the Bluetooth performance and stability, but esphome will only apply that change when the board is flashed via USB or Serial - it won't do it when flashing OTA. (todo: find version where flash partition layout changed - early 2024?)
The default ESPHome setup works "ok" but it is fairly conservative with the advert listening, which works for most use-cases but we want the esp32 to be hearing every possible advert.
The default setup listens for advertisements for 30ms every 320ms. This means that for 90% of the time, it isn't receiving adverts!
The BLE advert protocol is designed to handle this by adding random delays in various places, so that users can usually "find" the devices they want to connect to, but for our purposes we want to see every advert we can.
This is worth experimenting with, but my current suggestion is to use the following:
esp32_ble_tracker:
scan_parameters:
active: True # Whether to send scan-request packets to devices to gather more info (like devicename)
interval: 320ms # suggested 211ms # default 320ms
window: 300ms # suggested 120ms # default 30ms
Other interval/window timings to try are 1000/900
. You can experiment with these, but bear in mind:
- the difference between invterval and window is where esphome gets to do everything else it needs to do, including managing the wifi connection and actually sending data back to Home Assistant.
- If the interval and window values are too close together, your esp will crash, the wifi will drop, timeouts with HA etc.
- A BLE device will typically send an advertisement on each of the three advertising channels, in rapid succession, wait for its own interval time, then repeat.
- setting
active: False
might give better performance, I am not sure. The downside with active mode is that the esp will be spending some of its time sending requests to devices to discover their names. This might impact receive performance, I am not sure. The up-side of active mode is that you are more likely to get the name of devices showing up in Bermuda when configuring things, but this isn't hugely useful since you can simply name your entities however you like anyway. - If, and ONLY IF you have an esp32 connected via Ethernet, you could use interval/window timings of 1:1 (so,
1000
and1000
, say).
The C3 variant of the ESP32 has a single cpu, rather than two cores per the other variants. This seems to result in there being more cases where the sharing of bluetooth and wifi between the one radio causes more difficulties with the software.
- Any time the firmware is doing "bluetooth stuff" it can't do any "wifi stuff". So if the
interval
is too long wifi things will time out. - If
window
is too close tointerval
then it won't have enough time to perform the wifi (or other) things it needs to do.
One workaround that seems to help a lot (I don't have any of these modules so haven't tested it myself) is to configure the unit to not perform any bluetooth stuff until after it has the wifi up and running, and if the wifi drops then stop doing bluetooth until it gets going again:
esp32_ble_tracker:
scan_parameters:
continuous: false
api:
on_client_connected:
- esp32_ble_tracker.start_scan:
continuous: true
on_client_disconnected:
- esp32_ble_tracker.stop_scan:
digiblurDIY has suggested settings for esp32-c3 boards that set some SDK options that might be helpful - again I haven't tried this and I don't know how old that advice is, but digiblur tends to know what they're talking about...
esp32:
variant: ESP32C3
board: esp32-c3-devkitm-1
framework:
type: esp-idf
sdkconfig_options:
CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"
From what I understand, the CONFIG_ESP_TASK_WDT_TIMEOUT_S
is going to allow the device to spend up to 10 seconds "doing stuff" before the watchdog timer reboots the module. This sort of thing usually indicates a bug elsewhere in the code, so presumably at some point this workaround would not be needed, but it may be worth trying if you're having trouble with the esp32 rebooting a lot or never quite connecting to the wifi. I'd do the earlier change first though.