Add Native Support for BTHomev v2 Protocol in ESPHome ( bthome / bthome_advertiser / bthome_advertisements)

[asucrews]

Describe the component you'd like

Currently, ESPHome can create BLE clients or trackers, and passively receive BTHome advertisements (e.g. from Xiaomi, Govee, or other sensors) using esp32_ble_tracker. However, there is no built-in component for advertising data using the BTHome protocol.

This enhancement would add a first-class bthome: component that:

Encodes sensor values into BTHome format

Optionally supports encryption using a shared key

Sends BTHome-compliant BLE advertisements periodically

This would allow ESP32 devices running ESPHome to act as BLE-only sensors, ideal for low-power, room presence, or air quality monitors — all interoperable with Home Assistant's native BTHome support.

What are your use cases for this component?

• Create BLE-only battery-powered ESPHome sensors (using ESP32-C3 or ESP32-H2)
• Avoid Wi-Fi to reduce power draw
• Interoperate with Home Assistant or any app supporting BTHome v2
• Enable ESPHome devices to participate in Open Home Foundation-compatible BLE ecosystems

Is there a public datasheet, documentation and/or schematics?

Spec:

• https://bthome.io/
• https://bthome.io/format/
• https://bthome.io/encryption/

Anything else?

• BTHome is developed by the same Open Home Foundation that stewards ESPHome and Home Assistant
• Spec: https://bthome.io/
• BTHome Python encoder (reference): https://github.com/basnijholt/bthome-ble
• Working ESP-IDF example (C-based encoder): https://github.com/atc1441/BTHome_ESP32
• Reference discussion on community interest: https://community.home-assistant.io/t/bthome-ble-esp32-transmitter-esphome/518773
• Could build on existing esp32_ble_advertising API or add a bthome: sensor platform for seamless YAML configuration
• Example(s) https://github.com/afarago/esphome_component_bthome

[agittins]

I think that afarago's components (the last example listed in the OP) could serve as a great starting point. Personally I am particularly interested in the BThome-over-ESPNow support (Beethowen) that they created.

What I'd really like to see is the possibility of having an esp8266 on battery power, running esphome, encoding a BTHome packet that it sends over ESPNow as a broadcast. An esp32, on mains power and operating as a bluetooth proxy, could then receive the espnow broadcast, and send/forward/proxy/repeat it as if it were a bluetooth BTHome packet over the native HA API, so then HA would automatically set up and display that sensor as a device. This would allow multiple proxies to receive and forward bthome-over-espnow packets and forward them to HA, without having to re-invent the de-duplication inherent in having multiple receivers.

I think afarago was working in that direction, but now that we have native ESPNow support, and the packet transport component, perhaps we are at a point where this might have a clearer path forward for inclusion in core.

An important part for me is being able to avoid having to set up per-sensor data in every esphome device along the chain - I'd rather define it once at the source device (a battery-powered esp8266) and once at HA (the bthome device), with everything in between simply forwarding the data onward.

My particular pet project example is that I have a box full of lenovo PIR Wifi sensors, which have a Tuya MCU controller (in Low-power WiFi, power-down mode and an esp8266. The mcu keeps the esp8266 powered off until an event happens, then it powers up the esp8266 long enough for it to send data over wifi, receive confirmation, and power back down again. This is unsuitably slow (and thus, it's a rubbish product with bad reviews), but if I can put esphome on the 8266 and have it send espnow instead then power down, it will be a far superior product in performance and battery life. The cycle would look like:

• Tuya MCU in motion sensor wakes up the esp8226
• esp8266 sends motion event inside a BTHome packet, sent over ESPNow (using pre-saved channel number)
• esp8266 tells TuyaMCU it is done, and gets powered down
• Various esphome bluetooth proxies:
  • receive the BTHome packet over ESPNow
  • submit the report into the bluetooth_proxy stream as if it were a BLE Advertisement from that esp8266's MAC address
• HA receives the BTHome packets from one or more proxies, and does the normal discovery and device/entity creation/updates

This means that once you've deployed your proxies with some future esp32_espnow_bthome_relay: component, the only thing you need to do to deploy new sensors is to flash the esp8266's with their config, and they'll show up in HA's discovery automatically - pre-shared keys permitting.