ESPHome Configurations

Compatibility of ESP32 Chips

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!

General configuration

• Use the esp-idf framework, as the arduino 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?)

BLE Tracker settings

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 and 1000, say).

ESP32-C3 Modules

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 to interval 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.