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.

That is not just community folklore. Home Assistant's own Bluetooth documentation says that, in many cases, a Bluetooth proxy is a better approach than a directly connected adapter because Linux kernel updates and USB pass-through can create Bluetooth problems. The docs specifically call proxies out as especially interesting for virtualized Home Assistant installs. Also, despite the name, a Bluetooth proxy in this context is for BLE, not classic Bluetooth audio or keyboards.

Tara's Bluetooth rule: keep the main hub where it is operationally boring, then distribute cheap radios to the rooms that actually need Bluetooth reach.

Why This Question Keeps Coming Up

The demand signal is strong and current. Reddit threads over the last year asked which devices can act as Home Assistant Bluetooth proxies and whether there are retail or pre-flashed options that avoid a lot of DIY friction. Home Assistant Community threads in July 2025, November 2025, and May 2026 asked why proxies cap out around a few active devices, why an ESP32-C3 build can stop seeing broadcasts after customization, and why a proxy can show advertisements without giving you an obvious device to add.

Official product changes made the topic more relevant too. Home Assistant 2025.6 added a Bluetooth connection visualization to make proxy troubleshooting easier, and Home Assistant 2026.6 changed default Bluetooth scanning behavior to a new Auto mode that is much friendlier to battery devices. So the community is asking not only whether to use proxies, but how to set them up without wasting slots, batteries, or time.

Local smart home hub staying near the router while radios extend into the home
A Bluetooth proxy separates hub placement from radio placement. The server can stay near power, Ethernet, and backups while the Bluetooth coverage moves toward the actual devices.

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

For most people, an ESPHome-based ESP32 proxy is the default answer. Home Assistant and ESPHome both document and support that path directly.

Path Best for Watch-outs
Generic ESP32 over Wi-Fi Cheapest way to add BLE coverage to a room or floor The ESPHome ready-made projects page says the generic option is only for plain ESP32, not ESP32-C3 or other variants.
Ethernet or PoE ESP32 board Harder RF environments, steadier active connections, cleaner installs Some ready-made Ethernet paths disable Wi-Fi and expect wired network. You need the exact board match.
Olimex ESP32-POE-ISO-EA Officially favored development/test board for Home Assistant Bluetooth proxies More expensive than a bare ESP32, but the Home Assistant docs say the -EA variant has better RF performance than the standard model.
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.

If you want the fastest no-YAML starting point, the official ESPHome ready-made projects page is the current clean path. It explicitly supports Bluetooth proxy installs and says it works in a desktop browser with WebSerial support such as Chrome or Edge.

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 it joins Wi-Fi or Ethernet, Home Assistant should discover it through the ESPHome integration. If you adopt it into your own ESPHome dashboard, keep the recommended Bluetooth pieces intact: esp32_ble_tracker: and bluetooth_proxy:. Community threads from late 2025 show how easy it is to "take control" of a working proxy and accidentally lose the behavior that made the ready-made firmware work.

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

Home Assistant 2025.6 added a Bluetooth visualization that shows devices connected directly and through proxies. Community troubleshooting advice also points people to the Advertisement Monitor for each proxy so you can see what MAC addresses it is actually hearing. Home Assistant 2026.6 also added a Raw advertisement field in the Bluetooth device info dialog for deeper debugging.

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.

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.

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.

The June 3, 2026 Change Worth Knowing: Auto Scanning

Home Assistant 2026.6 changed the default scanning behavior for the Bluetooth integration and ESPHome Bluetooth proxies to a new Auto mode. According to the release notes, Auto switches to active scanning only when an integration actually needs it, and only on one scanner at a time. The release notes say this cuts Bluetooth scanning battery use by roughly 95-96% while preserving behavior.

This is important because people often mix up three separate ideas: passive advertisements, active scanning, and active connections. They are not the same. ESPHome's docs say passive scanning is enough for most BLE devices during normal operation, while active scanning is mainly needed when initially adding new devices. Active connection slots are the separate limit that matters for devices that need a live session.

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

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.

If this Bluetooth question is really a hardware, protocol, or hub-placement question in disguise, these guides help with the next step.

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.