Bluetooth Low Energy has a short range, and the server running Home Assistant often sits in a cupboard next to the router, far from the thermometers and plant sensors it is supposed to hear. The fix that the Home Assistant documentation itself recommends is not a better USB dongle. It is a cheap ESP32 running ESPHome, placed in the room where your Bluetooth devices actually are, forwarding what it hears to Home Assistant over the network.
This guide covers what a Bluetooth proxy can and cannot do, which boards to use, the configuration ESPHome recommends, and the placement and tuning mistakes that make proxies look worse than they are.
What a proxy actually does
A Bluetooth proxy (Home Assistant also calls it a remote adapter) is a networked device that receives Bluetooth signals near your devices and relays them to Home Assistant over Wi-Fi or Ethernet. The Bluetooth integration in Home Assistant pools every proxy together with any local adapter, so integrations such as BTHome, Xiaomi BLE or SwitchBot do not care which one heard a device. If several proxies are in range, integrations that follow the library guidelines connect through the one with the best signal and fail over to another if it disappears.
Two kinds of traffic go through a proxy:
- Advertisements. Small broadcast packets a device sends to announce itself, often with sensor readings inside. Many temperature sensors and all BTHome devices work this way. No connection is needed, any scanner in range picks them up, and there is no limit tied to connection slots.
- Active connections. A two-way GATT link that Home Assistant needs to read from a device or send it a command, for example some locks, thermostats or LED controllers. These use connection slots on the proxy.
Only BLE is supported. Despite the component name bluetooth_proxy, Bluetooth Classic devices will not work through it, and Home Assistant's Bluetooth integration does not support Classic at all.
Why not just plug in a USB dongle?
You can, and for a single room it may be enough. The Home Assistant docs are frank about the downsides: Linux kernel updates have broken Bluetooth before, Linux driver support for newer adapters lags behind other systems, and USB pass-through adds its own problems if you run Home Assistant in a virtual machine. They point to an ESP32 proxy as the better approach in many cases.
There is also a performance argument. Home Assistant ranks scanner types from best to worst, and an Ethernet-connected ESPHome proxy with passive scanning sits at the top, above a high-performance USB adapter. A Wi-Fi proxy with passive scanning comes third. The onboard Bluetooth chip in a typical mini PC or Raspberry Pi is near the bottom.
Pick the right board
The chip matters more than the brand of the board.
- Plain ESP32 (ESP32-WROOM-32 and similar). The safest choice. The browser installer on the ESPHome website offers a ready-made "Generic ESP32" proxy, and its description says it only works for the plain ESP32, not the ESP32-C3 or other variants.
- ESP32-S2. Skip it. It has Wi-Fi only and no Bluetooth radio.
- ESP32-C3 and other single-core chips. They can work, but ESPHome warns that Wi-Fi and the BLE tracker must share one core, which has caused Wi-Fi connection problems. The documented workaround is to scan only while Home Assistant is connected over the API.
- Ethernet boards. These give the best results because the radio no longer has to share air time with Wi-Fi traffic. The Home Assistant Bluetooth team develops and tests with the Olimex ESP32-POE-ISO-EA, and the "-EA" version with an external antenna has noticeably better RF performance than the standard one. The ESPHome projects page also lists the GL.iNet GL-S10, LilyGO T-ETH-POE, WT32-ETH01 and the Seeed Studio XIAO W5500 Ethernet adapter (only V1.2 boards, produced after 1 November 2025). Some of these need extra steps to flash, so read the notes on that page first.
Shelly Gen2+ devices and the SMLIGHT SLZB-U can also act as proxies, but only for advertisements. If you need active connections, use ESPHome on an ESP32.
The quick way: install from the browser
If you just want a working proxy on a generic ESP32, you do not need to write any YAML:
- Open the ready-made projects page on esphome.io in Chrome, Edge or Firefox (it needs WebSerial support) and choose Bluetooth proxy.
- Pick your board, plug it in over USB and start the installation.
- Enter your Wi-Fi details when asked.
- In Home Assistant, go to Settings > Devices & services. The new ESPHome device should appear as discovered. Add it.
That is the whole setup. The installed device can later be adopted in the ESPHome dashboard if you want to edit its configuration. Ethernet boards installed this way have Wi-Fi disabled and must be connected by cable.
Writing your own configuration
If you already run the ESPHome dashboard or want to add the proxy to a device you built yourself, this is close to the configuration ESPHome recommends for a Wi-Fi proxy:
substitutions:
name: my-bluetooth-proxy
esphome:
name: ${name}
name_add_mac_suffix: true
esp32:
variant: esp32
framework:
type: esp-idf
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
logger:
api:
encryption:
key: !secret encryption_key
ota:
platform: esphome
esp32_ble_tracker:
bluetooth_proxy:
active: true
A few lines deserve an explanation:
framework: type: esp-idfis there because ESP-IDF uses less memory than Arduino, and the BLE stack needs a lot of RAM.name_add_mac_suffix: trueadds part of the MAC address to the name, so you can flash the same file onto several boards without name clashes.esp32_ble_tracker:is required. The proxy depends on it.active: trueenables active GATT connections. It is already the default on ESP32, so writing it out just makes the intent clear. Set it tofalseif you want an advertisement-only proxy.- The
encryptionblock underapi:is optional, but if you add it, Home Assistant will ask for the same key when you add the device. ESPHome's own example uses it.
The first time you add esp32_ble_tracker to a board, flash it over USB. The code partition has to be resized, and after that OTA updates work again.
For an Ethernet board, replace the wifi: block with the matching ethernet: block. ESPHome's documentation has a full example for the Olimex ESP32-POE-ISO with a LAN8720 PHY, and it sets connection_slots: 4.
Connection slots, explained
Each slot is one simultaneous active connection. On ESP32 the default is 3 and the maximum is 9, but ESPHome recommends staying at 5 or below to avoid memory and stability problems, since each slot uses about 1 KB of RAM. Ethernet proxies can usually handle 4 reliably because they are not sharing the radio with Wi-Fi. The value cannot exceed max_connections in the esp32_ble component, which also defaults to 3, so if you raise one you need to raise the other.
You can still run more devices than you have slots. A device that stays connected, like some locks or thermostats, holds a slot the whole time. A sensor that connects briefly, exchanges data and disconnects frees its slot for the next device. Advertisement-only sensors do not use slots at all.
Placement first, tuning later
Before you touch the configuration, look at where the board sits.
- Put the proxy close to the Bluetooth devices it serves. If those devices are spread across rooms and floors, add a proxy in each area instead of trying to cover the whole house from one spot.
- Keep it at least 3 meters from routers, switches and other network gear, and do not mount it in a rack. Electromagnetic interference from that equipment degrades Bluetooth reception.
- If you add several proxies, keep them far enough apart that they do not interfere with each other.
- If an old, weak adapter is still active, consider disabling it. Home Assistant picks a path using signal strength and free slots, and the docs warn that a poor adapter with the best signal can limit performance.
Resist the urge to change the scan interval and window. ESPHome says the defaults suit most users and that aggressive values usually bring no benefit while increasing CPU load and network traffic. They can cause overheating on PoE proxies and Wi-Fi instability on Wi-Fi proxies.
Active, passive and auto scanning
Separate from active connections, there is active scanning: the proxy asks devices for extra scan response data. That speeds up discovery but drains battery-powered devices faster. In current Home Assistant versions you choose the mode per proxy in Settings > Devices & services, under Configure on the ESPHome device. The default, Auto, listens passively most of the time and switches to active scanning only when an integration needs more data. Home Assistant says this saves around 95 to 96 percent of the scan-related battery drain compared with continuous active scanning. Leave it on Auto unless an integration stops working.
Once Home Assistant has stored a mode, it takes ownership of it. Changing the scan mode in the device YAML no longer affects the running proxy, which can be confusing if you are editing YAML and wondering why nothing happens.
Checking that it works
Go to Settings > Connectivity > Bluetooth. The Adapters view lists every scanner, local and remote, with its state and capabilities, and the network map shows which scanner each device reaches Home Assistant through. The Advertisement Monitor shows what is being heard in range, and the Connection Monitor shows active connections.
If a device does not show up, check whether Home Assistant has an integration for it. ESPHome does not decode or keep a list of supported BLE devices; the proxy only forwards data, and the decoding happens in the Home Assistant integration.
Common problems
- Crashes or reboots after adding more features. The BLE stack takes a lot of RAM. Keep the proxy dedicated, avoid memory-heavy components such as voice assistant or audio, use
esp-idf, and consider disabling the web server component. - Memory issues on an older board. If the board was last flashed over serial before ESPHome 2022.12.0 on
esp-idf(or before 2026.4.0 on Arduino), update its partition table to get a larger NVS partition, either over USB once or with an OTA partition table update. - Wi-Fi drops on an ESP32-C3. Use the single-core workaround from the ESPHome docs that starts scanning only when the API client connects, or move to a dual-core ESP32.
- Battery sensors draining fast. Check that the proxy is not stuck in Active scanning mode.