Without further ado, I’ve 3 btproxy devices that scan some Airthings (10x), Nuki locks (2x) and an Oral-B toothbrush. About once a day, all my bluetooth devices go offline (all entities Unavailable).
Trying to debug that I have enabled bluetooth logging in HA:
logger:
logs:
homeassistant.components.bluetooth: debug
Which at some point starts giving me messages like:
2025-01-20 07:37:57.538 INFO (MainThread) [habluetooth.base_scanner] btproxy-c25b74 (E8:31:CD:C2:5B:74): Bluetooth scanner has gone quiet for 90s, check logs on the scanner device for more information
2025-01-20 07:37:58.648 INFO (MainThread) [habluetooth.base_scanner] btproxy-c257a8 (E8:31:CD:C2:57:A8): Bluetooth scanner has gone quiet for 90s, check logs on the scanner device for more information
2025-01-20 07:37:58.648 INFO (MainThread) [habluetooth.base_scanner] btproxy-c25bac (E8:31:CD:C2:5B:AC): Bluetooth scanner has gone quiet for 90s, check logs on the scanner device for more information
and eventually:
Error fetching airthings_ble data: Unable to fetch data: 80:6F:B0:D7:34:D1 - 80:6F:B0:D7:34:D1: Failed to connect after 9 attempt(s): No backend with an available connection slot that can reach address 80:6F:B0:D7:34:D1 was found: The proxy/adapter is out of connection slots or the device is no longer reachable; Add additional proxies (https://esphome.github.io/bluetooth-proxies/) near this device
…for all my Airthings devices - which given how proxies are distributed (some within 1-3 meters from Airthings device) can not be caused by bluetooth range.
There were no logs at the esphome device itself (beside my “uptime” sensor updates), but the error messages inspired me to add a couple sensors:
globals:
- id: ble_scans
type: int
restore_value: no
initial_value: '0'
esp32_ble_tracker:
# < skipping scan_params as irrelevant for this snippet about sensors >
# < see full config later in the post >
on_scan_end:
- then:
- sensor.template.publish:
id: ble_scans_finished
state: !lambda 'return ++id(ble_scans);'
sensor:
- platform: template
name: "btproxy connections free"
lambda: 'return id(btproxy).get_bluetooth_connections_free();'
update_interval: 60s
state_class: "measurement"
accuracy_decimals: 0
entity_category: diagnostic
icon: "mdi:bluetooth-settings"
- platform: template
name: "BLE scans finished"
id: ble_scans_finished
state_class: "total_increasing"
accuracy_decimals: 0
entity_category: diagnostic
icon: "mdi:bluetooth-settings"
Which gave me some picture - looks like at some point in time, connections are exhausted (theres 0 or 1 slot remaining) and at the same time, bluetooth scanning stops (until I restart esphomes):
My question is, for the lack of further debug information, where would I need to dig next to see what causes my blutooth proxies misbehave like that?
P.S. esphome config, manually expanded from !include’d packages - these are Olimex devices connected and powered over ethernet:
esp32:
board: esp32-poe
framework:
type: esp-idf
esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms
active: true
bluetooth_proxy:
id: btproxy
active: true
# The following is likely irrelevant but included for posterity:
api:
encryption:
key: !secret api_encryption_key
status_led:
pin: GPIO2
ethernet:
type: LAN8720
mdc_pin: GPIO23
mdio_pin: GPIO18
clk_mode: GPIO17_OUT
phy_addr: 0
power_pin: GPIO12
domain: ""
text_sensor:
- platform: ethernet_info
ip_address:
name: "Device IP (Ethernet)"
mac_address:
name: "Device MAC (Ethernet)"
logger:
sensor:
- platform: uptime
name: "Uptime"
button:
- platform: restart
name: "ESP chip restart"
entity_category: diagnostic
ota:
- platform: esphome
password: !secret ota_password