One BT Proxy randomly stops? Debugging?

ESPHome
1

Not sure where to go with this, I’m having problems with a ESP32 Bluetooth Proxy - the one in my garage randomly just stops relaying beacons.

I have 2 others with the same ESP32 board in other rooms that seem to work fine monitoring for beacons and thermometer reports. All running the same YAML other than the name.

Even more confusing, its alive enough I can command it to reboot via Home Assistant restart-switch on the device and it will respond rebooting and start working for a bit.

Help?

substitutions:
  devicename: bt_proxy_garage
  friendly_devicename: BT Proxy Garage

esphome:
  name: $devicename
  platform: ESP32
  board:  esp32dev

wifi:
  networks:
    - ssid: !secret ssid
      password: !secret password
      bssid: !secret bssid_garage-EWS377AP-local
      priority: 2
    - ssid: !secret ssid
      password: !secret password
      priority: 1
  domain: !secret dns_suffix

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${devicename} setup"

captive_portal:

# Enable logging
logger:
  baud_rate: 0
  level: INFO
  # To debug BT Proxy, use VERBOSE
  #level: VERBOSE

# Enable Home Assistant API
api:

ota:


esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true


switch:
  # Allow forced-reboot from HomeAssistant
  - platform: restart
    name: "${friendly_devicename} Restart"


status_led:
  pin:
    number: GPIO2
    inverted: true
2

Help? Not likely without logs.

3

I don’t know where to start with that? Nothing I see looks useful?

ESPHome output (I was told to set this for “info” if it will be running more than a couple minutes, but the glitch only happens intermittently days later):

INFO Reading configuration /config/esphome/esp32_bt_proxy_garage.yaml...
WARNING 'bt_proxy_garage': Using the '_' (underscore) character in the hostname is discouraged as it can cause problems with some DHCP and local name services. For more information, see https://esphome.io/guides/faq.html#why-shouldn-t-i-use-underscores-in-my-device-name
WARNING GPIO2 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from bt_proxy_garage.apt using esphome API
INFO Successfully connected to bt_proxy_garage.apt
[21:18:49][I][app:102]: ESPHome version 2022.12.8 compiled on Feb 11 2023, 19:41:24

And all I have for days in my home-assistant log:

2023-02-11 21:18:14.622 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:20.603 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:26.704 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:40.200 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:46.678 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:52.604 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:18:58.619 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:19:13.060 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:19:19.625 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}
2023-02-11 21:19:26.095 WARNING (MainThread) [iotawattpy.iotawatt] Nothing to query, update() called too soon, must wait {timespan}

I’m not sure how to debug this or what other I should be looking for?

4

I have the same problem with my (only) BT proxy (based on esphome 2022.12.8). It has been working fairly fine until recently. It did stop working a few times before without reason, but ran at least a few days uninterrupted. It appears to me that the spontaneous stops started to happen much more frequently (randomly every few hours) after upgrade to the latest HA version 2023.2.3, or, also possible, after upgrading the custom integration dbuezas_eq3btsmart to 5.0.3? I haven’t collected any logs yet nor have I tried to isolate the conditions, but looked for reports by others first which brought me to this topic.

5

I don’t think I have any custom integration installed (unless it was done automatically by ESPHome somehow) but I am on HA 2023.2.3 now so maybe I’m just noticing it more now.

In my case I have 3 of them (so far) in different parts of the house and only 1 of them stops picking stuff up…but I have no idea how to figure out what’s going on.

That is interesting though that you have the same sort of issue.

6

I’m having the same thing on 5 proxies. It started weeks ago, but I didn’t have time to investigate. I’ve been slowly disabeling all kinds of other things I had running, until it is only the proxy itself. It is still happening, and it is getting worse. I have to reboot them every day now. If I had to guess, I’d say it is a memory leak or something like that.

7

That’s an interesting idea, no idea how I’d test it but the one I have which drops off probably “hears” the most BLE beacon traffic out of the 3 I run.

8

So last time it happened I changed logging to verbose on the ESP. Its stuck again, though I can’t tell if it crashed because logging filled up memory or if it crashed because of a bug in ESPHome.

Maybe someone else can tell something useful…there should be a LOT of stuff in range of it.

INFO Reading configuration /config/esphome/esp32_bt_proxy_garage.yaml...
WARNING 'bt_proxy_garage': Using the '_' (underscore) character in the hostname is discouraged as it can cause problems with some DHCP and local name services. For more information, see https://esphome.io/guides/faq.html#why-shouldn-t-i-use-underscores-in-my-device-name
WARNING GPIO2 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from bt_proxy_garage.apt using esphome API
INFO Successfully connected to bt_proxy_garage.apt
[21:47:47][I][app:102]: ESPHome version 2022.12.8 compiled on Feb 11 2023, 19:41:24
[21:47:47][C][status_led:019]: Status LED:
[21:47:47][C][status_led:020]:   Pin: GPIO2
[21:47:47][C][wifi:504]: WiFi:
[21:47:47][C][wifi:362]:   Local MAC: 78:21:84:E2:1E:80
[21:47:47][C][wifi:363]:   SSID: [redacted]
[21:47:47][C][wifi:364]:   IP Address: 192.168.3.155
[21:47:47][C][wifi:366]:   BSSID: [redacted]
[21:47:47][C][wifi:367]:   Hostname: 'bt_proxy_garage'
[21:47:47][C][wifi:369]:   Signal strength: -54 dB ▂▄▆█
[21:47:47][V][wifi:371]:   Priority: 2.0
[21:47:47][C][wifi:373]:   Channel: 11
[21:47:47][C][wifi:374]:   Subnet: 255.255.255.0
[21:47:47][C][wifi:375]:   Gateway: 192.168.3.1
[21:47:47][C][wifi:376]:   DNS1: 192.168.3.1
[21:47:47][C][wifi:377]:   DNS2: 0.0.0.0
[21:47:47][C][logger:293]: Logger:
[21:47:47][C][logger:294]:   Level: VERBOSE
[21:47:47][C][logger:295]:   Log Baud Rate: 0
[21:47:47][C][logger:296]:   Hardware UART: UART0
[21:47:47][C][bluetooth_proxy:065]: Bluetooth Proxy:
[21:47:47][C][bluetooth_proxy:066]:   Active: YES
[21:47:47][C][restart:076]: Restart Switch 'BT Proxy Garage Restart'
[21:47:47][C][restart:078]:   Icon: 'mdi:restart'
[21:47:47][C][restart:099]:   Restore Mode: restore defaults to OFF
[21:47:47][C][esp32_ble_tracker:870]: BLE Tracker:
[21:47:47][C][esp32_ble_tracker:871]:   Scan Duration: 300 s
[21:47:47][C][esp32_ble_tracker:872]:   Scan Interval: 1100.0 ms
[21:47:47][C][esp32_ble_tracker:873]:   Scan Window: 1100.0 ms
[21:47:47][C][esp32_ble_tracker:874]:   Scan Type: ACTIVE
[21:47:47][C][esp32_ble_tracker:875]:   Continuous Scanning: True
[21:47:47][C][captive_portal:088]: Captive Portal:
[21:47:47][C][mdns:103]: mDNS:
[21:47:47][C][mdns:104]:   Hostname: bt_proxy_garage
[21:47:47][V][mdns:105]:   Services:
[21:47:47][V][mdns:107]:   - _esphomelib, _tcp, 6053
[21:47:47][V][mdns:109]:     TXT: version = 2022.12.8
[21:47:47][V][mdns:109]:     TXT: mac = 782184e21e80
[21:47:47][V][mdns:109]:     TXT: platform = ESP32
[21:47:47][V][mdns:109]:     TXT: board = esp32dev
[21:47:47][V][mdns:109]:     TXT: network = wifi
[21:47:47][C][ota:093]: Over-The-Air Updates:
[21:47:47][C][ota:094]:   Address: bt_proxy_garage.apt:3232
[21:47:47][C][api:138]: API Server:
[21:47:47][C][api:139]:   Address: bt_proxy_garage.apt:6053
[21:47:47][C][api:143]:   Using noise encryption: NO
[21:47:54][D][esp32_ble_tracker:327]: Starting scan...

And it just sits there. Forever.

Maybe I’ll look at adding a daily reboot to help it limp along…

9

Still no ideas I take it? Just noticed its acting up again.

10

I’m not sure if this is the same issue that others are experiencing, but I observed my BT proxy getting “stuck” connecting to active devices: it would pause the scan to attempt a connection, and never unpause it. (I didn’t think to save my logs, so I can’t remember the exact messaging.)

I believe that I have now addressed my problem by removing active: true from my bluetooth_proxy: configuration. For my current use cases, at least, this is acceptable.

2 Likes
11

I’m ending up here as well. My switchbots stop reporting and become available every now and then. The only way to solve that is to restart an esphome device with bluetooth proxy on in it. Then it’s back in seconds.