Short Answer: Use a Proxy When the Radio Needs to Move, Not the Hub
If your Bluetooth devices already work reliably from the Home Assistant box, you may not need a proxy. If they are too far away, if Home Assistant is running in a VM or tucked into a rack, or if a direct USB adapter has become fussy, an ESP32 Bluetooth proxy is usually the better answer. It lets the Bluetooth radio live near the devices while the hub stays where Ethernet, storage, backups, and clean power make sense.
Bluetooth Low Energy, or BLE, is the low-power Bluetooth connection used by many sensors. Home Assistant recommends considering a proxy when a server's Bluetooth adapter is unreliable, particularly inside a virtual machine where passing a USB radio through to Home Assistant adds another possible failure. A proxy does not carry ordinary Bluetooth speaker audio or keyboard input.
Keep a working setup: If your existing adapter already reaches every device reliably, you do not need a proxy. Start with one only where coverage or USB reliability is causing a problem.
What a Bluetooth Proxy Actually Does
Home Assistant aggregates Bluetooth data from local adapters and networked proxies into one Bluetooth integration. That means a proxy does not create a second smart-home stack. It extends the same Home Assistant Bluetooth system over your network.
In practice, a proxy does three useful things:
- It puts a BLE radio physically closer to devices that are too far from the hub.
- It forwards passive advertisements from sensors and tags back to Home Assistant.
- It can also proxy active GATT connections for devices that need a real session rather than just broadcasting data.
That third point matters because not all "Bluetooth support" is equal. A temperature beacon that merely advertises data is lightweight. A thermostat, lock, or light controller that wants an active session is a different workload and will consume connection capacity differently.
When to Use a Proxy Instead of a Direct Adapter
The cleanest answer is to decide based on physical layout and device behavior, not ideology.
| Situation | Better starting point | Why |
|---|---|---|
| Small install with the hub already close to BLE devices | Direct adapter or no change | If coverage and stability are already fine, a proxy may add complexity without solving a real problem. |
| Home Assistant in a rack, closet, basement, mini-PC shelf, or VM host | ESPHome Bluetooth proxy | Home Assistant's docs explicitly favor proxies in many cases, especially for virtualized installs where USB pass-through can become annoying. |
| Battery BLE sensors spread across rooms or floors | One or more well-placed proxies | You get radios nearer the devices instead of trying to stretch one adapter through walls, cabinets, and networking gear. |
| Devices that need active Bluetooth control, not just advertisements | ESPHome ESP32 proxy | Active connections require real connection slots. Not every remote adapter class supports that. |
| You do not want a proxy | Home Assistant OS with a local adapter | The Bluetooth docs say Home Assistant OS includes Bluetooth patches for issues unsolved in other operating systems. |
Which Hardware Path to Pick
Start with a board listed in the official ESPHome installer. Match its model and revision before buying or flashing. These are documented setup options, not products benchmarked by Tara.
| Path | Best for | Watch-outs |
|---|---|---|
| Generic ESP32 over Wi-Fi | A simple Wi-Fi starting point if you already have a compatible board | The Generic ESP32 installer is for the original ESP32, not C3 or S3. Other variants need a matching project; this is not a claim that they all lack Bluetooth. |
| Seeed Studio XIAO W5500 Ethernet Adapter V1.2 | A documented wired option based on the XIAO ESP32-S3-Plus | The installer requires V1.2, not an earlier revision. Its ready-made firmware disables Wi-Fi, so connect Ethernet. |
| Olimex ESP32-POE-ISO-EA | A wired option with an external antenna; also used by Home Assistant's Bluetooth team | The ready-made Olimex project uses Ethernet, not Wi-Fi. Confirm the matching board, antenna, enclosure, and power supply. |
| Shelly Gen2+ remote adapter | Advertisement listening and bundling | Home Assistant docs say Shelly supports neither single nor multiple active Bluetooth connections, so it is not the right answer for devices that need active control. |
The browser installer needs a desktop browser with WebSerial support, such as Chrome or Edge. Use the project's own installation instructions and save any existing configuration before replacing firmware.
How to Add a Bluetooth Proxy in Home Assistant
This is the practical path that best fits the official docs and the recurring community questions.
1. Confirm the device is a supported BLE integration
ESPHome does not decode or maintain a list of BLE devices for you. Its docs explicitly say to search the Home Assistant integrations list to confirm your target is supported. A proxy hearing advertisements does not magically make an unsupported gadget useful.
2. Flash the right board the right way
For a plain ESP32, the easiest route is the official ready-made Bluetooth proxy project. Pick the exact board class shown there and do not assume the generic project fits a C3 or another variant. If you later want to customize the build, use the ESPHome recommended configuration as your baseline rather than inventing a proxy YAML from memory.
3. Add it to Home Assistant
Once the proxy joins your network, open Settings > Devices & services and configure the discovered ESPHome device. If discovery is missing, choose Add integration > ESPHome and enter the proxy's local IP address. Its native API uses TCP port 6053 by default. Use your configured port and encryption key if different; do not remove encryption to make pairing easier.
There are two connections to check: the proxy must reach the sensor by Bluetooth, and Home Assistant must reach the proxy over your home network. Guest-network isolation or a blocked API connection can break the second one. Keep the API private; do not port-forward it to the internet. For an already segmented network, see the Home Assistant VLAN checklist.
Adopting a working proxy into ESPHome Device Builder is optional for this setup. Before customizing an ESP32 build, retain its board settings, network/API configuration, esp32_ble_tracker:, and bluetooth_proxy:. Save the working configuration so you can return to it.
4. Place it like a radio, not a USB stick
ESPHome's Bluetooth proxy docs say not to place the node in racks or close to routers, switches, or other network gear, and recommend at least 3 meters of separation because EMI hurts Bluetooth reception. Put the proxy close to the Bluetooth devices you care about, not just close to the main hub.
5. Test it in Home Assistant's Bluetooth UI
In the current Home Assistant interface, open Settings > Connectivity > Bluetooth. Look under Adapters for the proxy and use the advertisement monitor to check whether it hears your sensor. An advertisement is a small broadcast from the device. Seeing it confirms radio reception; the sensor still needs a supported integration before Home Assistant can turn that broadcast into a useful reading. On older releases, follow the Bluetooth integration's device page to its diagnostics.
Start with a non-critical temperature sensor, not a lock or alarm. Wait for its normal reporting interval and confirm a new reading in Home Assistant. A proxy marked online is not enough. Record the sensor, final placement, and update times before deciding whether another proxy is needed.
6. Add more only where needed
If range is still spotty, move the proxy first. If specific actively connected devices keep dropping, then add another proxy closer to those devices. Home Assistant's docs say the number of remote scanners is limited only by host performance, but they also say to separate scanners enough to avoid interference with each other.
Example: one upstairs temperature sensor
Suppose Home Assistant runs in a basement mini PC and a supported BLE temperature sensor upstairs drops out. Keep the server in place, install one ESPHome proxy upstairs, and compare these observations before buying another board. This is a worked troubleshooting example; it is not a measurement from a Tara installation.
| What you observe | What to check next |
|---|---|
| The proxy is missing from Adapters. | Check power, its network connection, and the ESPHome integration first. |
| The proxy is online but receives nothing from the sensor. | Move it closer, check the sensor battery, and allow for the sensor's reporting interval. |
| The sensor's broadcasts appear, but there is no reading. | Check the exact model's integration and any required setup or encryption key. Extra range cannot supply missing device support. |
| The reading works close by but fails in the final location. | Adjust placement and interference, then retest there before adding another proxy. |
The Two Limits That Matter Most
1. Active connection slots
ESPHome's Bluetooth proxy docs say active GATT connections are enabled by default and are separate from active scanning. The default proxy has 3 connection slots. Ethernet-based proxies can generally handle 4 reliably, and the docs recommend not pushing connection slots too high because each slot costs RAM and can hurt stability.
Continuously connected devices such as some locks or thermostats can occupy a slot all the time. Passively broadcasting sensors do not. This is why a single proxy can hear a lot of BTHome-style sensors but still struggle with a smaller number of devices that need constant active sessions.
Three slots does not mean three sensors. Imagine a proxy with three slots and three devices that each stay connected. Another device needing a connection has no spare slot, even if its broadcasts are visible. If the first three connect only briefly, they can share those slots over time. Broadcast-only sensors use none of them. This is a capacity example, not a tested device count; check each integration's behavior before adding hardware.
2. Placement and interference
Bad placement wastes otherwise good hardware. ESPHome says Ethernet boards offload Wi-Fi traffic from the ESP32 radio and usually give better Bluetooth performance, especially with an external antenna. The same docs also say aggressive scan intervals are usually not worth it and can create overheating or Wi-Fi instability instead of better results.
Do not solve a radio-placement problem with YAML first. In Bluetooth, moving the proxy a few meters away from a rack or switch often matters more than tweaking scan numbers.
Choose Auto scanning in Home Assistant
Home Assistant introduced Auto scanning in 2026.6 and recommends it for most setups. It mainly listens and requests extra information when needed. The reported 95-96% reduction is in scan-related battery drain on nearby Bluetooth devices compared with continuous Active scanning, not their total battery consumption or the proxy's power use.
- Open Settings > Connectivity > Bluetooth > Adapters.
- Use the proxy's settings icon and choose Auto under Scanning mode. Some adapters do not expose this setting.
- For an already added ESPHome proxy, change the mode in Home Assistant. Its saved choice takes precedence over the device's YAML mode; repeatedly flashing the same YAML is not a fix.
- If a device's integration requires Active scanning for setup, follow that integration's instructions. Recheck normal updates afterward rather than changing every proxy's settings at once.
Active scanning and active connections are separate. One asks for extra broadcast details; the other opens a session with a device. Choosing Active scanning does not add connection slots or give an advertisement-only adapter control capabilities. The ESPHome integration documentation explains which scanning setting Home Assistant owns.
Common Troubleshooting Patterns
Community threads and issue reports show the same failure patterns repeating. The useful lesson is to debug the right layer first.
| Symptom | Likely cause | Check first |
|---|---|---|
| You can see MAC addresses in Advertisement Monitor, but no new device appears to add | The device may not have a supported Home Assistant BLE integration, may require active onboarding, or may not be BLE at all | Search the Home Assistant integrations list and confirm the device is supported through proxy-based BLE |
| Thermostats, locks, or Bluetooth lights keep dropping | Active slot exhaustion or a proxy too far from the device | Look at the Bluetooth visualization, count continuously connected devices, and consider a second nearby proxy |
| The proxy works on a desk but not in the network closet | EMI and bad placement | Move it away from the rack, switch, or router before touching scan parameters |
| A ready-made proxy worked, but the custom YAML build stopped hearing devices | Board mismatch or missing recommended BLE components | Compare against ESPHome's recommended proxy config and verify the board variant is correct |
| Editing the YAML scanning mode makes no difference | Home Assistant may own the saved mode for an already connected proxy | Check the adapter's Scanning mode in Home Assistant before reflashing |
GitHub issue reports from July 2025 reinforce the same point. One report described advertisements showing up while device onboarding did not; another described large numbers of Bluetooth thermostats disconnecting after the Home Assistant 2025.7 release family. Those issue tracker examples are not official setup instructions, but they are useful reminders that Bluetooth troubleshooting is usually about supported integration paths, slot pressure, placement, or version-specific regressions, not just "is the proxy online."
Tara's Take
A good Home Assistant install does not force the main hub to sit in the worst possible place just because a few BLE devices live somewhere else. The better architecture is to keep the hub near Ethernet, backups, and clean power, then push cheap Bluetooth radios out to the rooms that actually need them.
That is the real advantage of proxies: they let compute, storage, and radio placement become separate decisions. For Tara-style local installs, that is usually a healthier design than building the whole home around one heroic USB dongle.
Related Tara Reading
If this Bluetooth question is really a hardware, protocol, or hub-placement question in disguise, these guides help with the next step.
- Best Home Assistant Hardware in 2026
- Matter vs Thread vs Zigbee vs Z-Wave for Homeowners
- How to Add mmWave Presence Sensors to Home Assistant via Matter & Thread
- How to Move Home Assistant to New Hardware
- How to Run Your Smart Home Without the Cloud
- Home Assistant vs a Preconfigured Smart Home Kit
FAQ
Do I need a Bluetooth proxy if my Home Assistant box already has Bluetooth?
Not always. If the box is close to your BLE devices and the adapter is stable, you may not need one. Add a proxy when coverage is poor, the hub is virtualized or rack-mounted, or Bluetooth devices keep dropping off.
Can Shelly devices act as full Home Assistant Bluetooth proxies?
No. Home Assistant's Bluetooth documentation says Shelly Gen2+ devices support advertisement listening and bundling, but not active Bluetooth connections. Use an ESPHome ESP32 proxy if you need actual device control over Bluetooth.
How many Bluetooth proxies can Home Assistant handle?
Home Assistant's docs say the number of remote scanners is limited only by host performance. The practical limits are interference, network quality, and how many actively connected devices are competing for slots on each proxy.
Why can I see advertisements but still cannot add the device?
Because radio visibility is only step one. The device still needs a supported Home Assistant BLE integration, may need active onboarding instead of passive listening, and may fail entirely if it is not really a supported BLE device.
Do I need one Bluetooth proxy in every room?
Usually no. Start with the rooms or floors where BLE devices actually live or where active slot pressure exists. Expand only when coverage or device behavior proves you need another proxy.