A practical guide to where Bluetooth fits in a smart home, written for people deciding what to build. It builds on my earlier beacon listener thread. I have relied on the documentation linked below. Check device support on your own gear.
1. Classic vs Low Energy
Bluetooth Classic is what you use for audio streaming. Bluetooth Low Energy (BLE) is the one that matters for sensors, beacons and most smart devices. Home Assistant's Bluetooth integration supports BLE devices only, and says Classic devices are not supported. ESPHome's Bluetooth proxy is also BLE only.
2. Advertisements vs connections
- Advertisements: a device just broadcasts. Any listener nearby can read it. Sensors, beacons and BTHome devices work like this, and the ESPHome docs say passively broadcast data isn't limited by connection slots.
- Connections (GATT): a listener connects, then reads or writes. Locks, plugs and some thermostats work like this. A proxy has a limited number of connection slots (the ESPHome docs say 3 by default on ESP32), and a device that stays connected permanently uses a slot the whole time.
- iBeacon broadcasts a UUID, a major and a minor number. HA's iBeacon Tracker uses these to track devices and estimate distance. The docs suggest a numbering scheme, for example the same UUID for the whole house, major per floor and minor per room. They also note that "away" detection can take several minutes and that distance is only a rough guide, needing calibration at 1 metre.
- Eddystone is Google's open beacon format, with several frame types including an encrypted-ID one. The specification is on GitHub. I haven't checked how well current phones and apps support it.
- BTHome is an open format for broadcasting sensor data, supported by HA's BTHome integration, with optional encryption using a 32 character hex bindkey.
HA's docs say that an ESP32 Bluetooth proxy is often a better approach than a USB adapter, particularly if you virtualise HA. The ESPHome docs recommend keeping the node at least 3 metres from routers and switches, using Ethernet where possible, and the esp-idf framework for lower memory use. See the companion project thread for a working config.
5. Bluetooth Mesh
According to the Bluetooth SIG's mesh page, Mesh is designed for control and automation with hundreds or thousands of devices. It has no central controller, uses publish/subscribe messaging, offers managed flood and directed forwarding for relaying, and makes security mandatory. It is mostly pitched at commercial lighting. I'm not aware of a core HA integration for Bluetooth Mesh, so check before you buy mesh hardware for a home setup.
6. Matter and Thread
Matter devices that use Thread often use Bluetooth LE only for commissioning (discovery, pairing and handing over network credentials). After that they run on Thread (IPv6), not Bluetooth. In HA this involves a Thread border router and the phone doing the commissioning. See HA's Matter and Thread pages.
7. Security and privacy
- "Just Works" pairing gives no protection against a man-in-the-middle at pairing time. Prefer authenticated pairing (LE Secure Connections with numeric comparison or passkey) where the device offers it.
- BLE proximity alone is not safe for unlocking. NCC Group has shown relay attacks against BLE proximity authentication. Don't use "phone is near" as the only condition for opening a door or garage.
- Phones randomise their Bluetooth addresses. HA's Private BLE Device resolves them using an IRK. Treat an IRK as a secret: it lets anyone who has it recognise your device. Only do this for devices you own.
- Further reading: the NIST Guide to Bluetooth Security and the Bluetooth SIG's security and privacy best practices.