What an active connection actually means
Home Assistant opens an active GATT connection whenever it needs to read a value or write a command to a BLE device, and a Bluetooth proxy passes that connection through to the radio on the ESP board. ESPHome's bluetooth_proxy component controls this with the active option, which the Bluetooth Proxy documentation describes as proxying active GATT connections. On ESP32, RP2040 and RP2350 boards it defaults to on. That switch decides whether a proxy can carry connections at all, not how many it can carry at once.
Every connection is a session with a beginning and an end. ESPHome loads an internal bluetooth_connection component automatically, with no configuration of its own, and its log lines use the bluetooth_connection tag, which makes it the practical way to watch connections open and close.
Three slots do not mean three devices
connection_slots sets the maximum number of simultaneous BLE connections. On ESP32 the default is 3. Devices that stay connected continuously, such as some locks and thermostats, hold a slot the entire time. Devices that connect briefly, exchange data and disconnect, such as many sensors, release the slot again. The documentation's own conclusion is that you can use more devices than you have slots.
A hypothetical example shows where an extra request goes. Suppose a front-door lock holds a connection all day (slot one) and a wall thermostat holds another (slot two). A bathroom scale connects for a few seconds each morning, sends its reading and disconnects, borrowing slot three while it is connected. While all three slots are occupied, the next request waits: a second lock that wants a permanent connection queues behind them until one frees. Nothing in that queue says the proxy lacks long-lived capacity; it says three connections are open at the same moment. A plant sensor that only broadcasts advertisements never asks for a slot at all. That arithmetic is illustrative, not a measurement of anyone's network.
Advertised sensor data is received separately and is not limited by connection slots. Many BTHome sensors work this way, which is why one proxy can report temperature from a dozen devices while holding three connections.
Active scanning is a separate setting
Active scanning is not an active connection. Scanning is the radio listening for advertisements; active scanning additionally asks devices for scan response data. It is configured on the platform's BLE tracker through scan_parameters: active, and the ESPHome ESP32 tracker enables it by default. The documentation notes that active scanning is typically only needed while adding new devices, and that it increases battery drain on battery-powered devices.
Scan settings do not change the number of connection slots. Turning active scanning off can cut battery drain and airtime, but a device that needs a GATT connection still needs a slot when Home Assistant connects to it.
Checking what actually holds a slot
Watch the proxy log for the bluetooth_connection tag and see which connections are open at the moment a device misbehaves. A connection that opens and never closes is the pattern behind a slot that seems stuck. Home Assistant also reports connection state alongside its Bluetooth adapters, so the two views can be compared: a device listed as connected is holding a slot somewhere, while a device that only ever appears as advertising is not competing for one.
Symptoms are not diagnoses, so treat the table as a list of possibilities to check rather than a key.
What you see | Plausible explanations | What to check |
|---|---|---|
Lock commands fail while a thermostat is connected | Occupied slots are one possibility; a failed command can also come from range, interference or the lock's integration | Watch |
A BTHome sensor misses updates | Advertisement loss from range or interference is common, but a missed update does not prove slots are irrelevant to every interaction that device performs | Compare reception at a second scanner, check distance and 2.4 GHz interference, and confirm how the device is integrated |
A new device cannot be added or interviewed | Setup can fail for range, scan mode or pairing reasons without any slot shortage | Move the proxy closer, enable active scanning for the setup, then retry |
The proxy becomes unstable after raising slots | Memory pressure is possible, and so is a board or framework that does not support the setting | Lower |
When raising the slot count helps
Raise connection_slots when one proxy genuinely holds several connections at the same moment and the log shows them open: two or three locks, or a thermostat and a lock whose integrations keep a connection rather than polling advertisements. On ESP32 the documented maximum is 9, and the documentation recommends not exceeding 5 because of stability and memory use. Do not make 9 the target.
A minimal change, showing only the options involved rather than a complete board configuration, looks like this:
bluetooth_proxy:
active: true
connection_slots: 4Four is an example above the default, not a recommended ceiling for every board; the useful value is the number of connections you actually see open. If the log shows brief connections coming and going, the three defaults already serve far more devices than the number suggests, and a higher count buys nothing.
If a proxy really is holding its slots with supported, long-lived connections, a second proxy can spread those connections across radios and put a radio closer to the devices. That is a fix for a measured slot shortage, not a default answer to every missed command, and it depends on the device's integration working through a proxy in the first place.
Which proxies can hold a connection
ESPHome separates platforms by what the controller can do beyond scanning. ESP32 boards run the full proxy, with advertisements plus active connections, and require the ESP32 BLE tracker component. RP2040 and RP2350 boards such as the Pico W family also run the full proxy, with up to 3 concurrent GATT connections, which is both the default and the maximum. BK72xx and LN882x controllers are advertisement-only: active: true fails validation there, and so do the connection-oriented options.
A Bluetooth proxy extends BLE coverage only. Zigbee and Thread devices run their own radios and mesh, and a BLE proxy does nothing for them; if the rest of a home already uses one of those protocols, that choice matters more than the number of BLE slots. The site's Zigbee vs Thread comparison covers how the two mesh options differ.
Device support is a separate question from slot capacity. ESPHome does not decode BLE devices or keep a list of supported models, and the documentation points you to the Home Assistant integrations list to check whether a specific device works. A device that an integration does not support will not start working because a proxy has free slots.
