Updated to 0.7.1rc4 and I’m getting thousands of these:
2024-11-18 02:48:12.053 ERROR (MainThread) [custom_components.bermuda] Failed to find config for scanner 00:1A:7D:DA:71:13, this is probably a bug. (241 previous messages suppressed)
The Bluetooth adapter has disappeared from the scanner list.
Any reason you didn’t install v0.7.2? It doesn’t have that bug 
I wanted scanner offsets. 
Hello,
I am running version 0.7.2 and absolutely love it when all my scanners are reporting. For most of my scanners I use the esp32 wroom boards. I find that they regularly die, once a day or so, showing the skull and crossbones icon on the Bermuda configuration page seen in the attached screenshot. My EP1 sensor never dies and my wyze outdoor plug scanners rarely die. A simple unplug and plug usually fixes this. Is there anything I can do to help prevent these from have no longer scanning? I’ve included my esphome yaml below as well for the scanners. I’ve tried searching and looking at the wiki but have had trouble finding any solutions. My esp32 wroom boards have soldered power on the 5v pin.
Any suggestions?
esphome:
name: bermuda-kitchen-1
friendly_name: Bermuda_Kitchen_1
esp32:
board: esp32dev
framework:
type: esp-idf
logger:
baud_rate: 0 # disable serial uart logging
#level: VERBOSE
# Enable Home Assistant API
api:
encryption:
key: ""
ota:
- platform: esphome
password: ""
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Bermuda-Kitchen-1"
password: !secret ap_password
captive_portal:
bluetooth_proxy:
active: true
esp32_ble_tracker:
scan_parameters:
active: True # Whether to send scan-request packets to devices to gather more info (like devicename)
interval: 320ms # suggested 211ms # default 320ms
window: 300ms # suggested 120ms # default 30ms
Yeah, I agree, was just seeing if I could avoid an additional purchase 
no biggie though! Thank you for the detailed response, hugely appreciated! I’ll raise a request over on the hass.Agent GitHub.
Ahh. I don’t (currently) run any parallel branches, and definitely not at a point of removing any features, so any later version will always include all the features of earlier versions. ie, 0.7.2 is later than 0.7.1rcAnything and will include anything it has (except, hopefully, as many bugs!)
There’s a few things you can check and/or do. I also use classic esp32’s (D1mini32 clones) and I haven’t had to power cycle any of them regularly, so it might be environmental (power) or config related…
captive_portal: improves things - I think it uses a fair amount of memory (but maybe it’s pulled in by the ap section anyway, not sure).window: setting, to see if opening that up gives more processing time - maybe 275ms (although I am becoming less convinced of this necessity with recent versions)button:
- platform: restart
name: "${name} restart"
You could also try the startup automation used in the C3 config, as it will help during reconnection attempts:
api:
# Only enable BLE tracking when wifi is up and api is connected
# Gives single-core ESP32-C3 devices time to manage wifi and authenticate with api
on_client_connected:
- esp32_ble_tracker.start_scan:
continuous: true
# Disable BLE tracking when there are no api connections live
on_client_disconnected:
if:
condition:
not:
api.connected:
then:
- esp32_ble_tracker.stop_scan:
If you use that, ensure you have
esp32_ble_tracker:
scan_parameters:
# Don't auto start BLE scanning, we control it in the `api` block's automation.
continuous: False
to make sure it doesn’t start until after the api has connected.
Other than that, not a lot of ideas, sorry. Maybe check that the units haven’t rebooted and failed to connect to wifi, and then came up with their fallback AP activated (you can just check with your phone before rebooting them). If that’s the case you could remove the ap: block inside wifi and I think they should keep rebooting until they can get wifi back. Might be applicable if your router flips out and is the root cause of the issue, perhaps.
Howdy folks - can anyone confirm if they have a working esp32-S3 based bluetooth scanner, using the esp-idf framework? Just wanting to confirm that they do indeed work OK on esp-idf, and how the performance is for a given config.
Quite interested to see the full yaml and some hist_interval examples from a diagnostic, if available (edit: Please do a “reload” on Bermuda before doing the download diagnostics, otherwise if Bermuda’s been running for a few days it might crash HA (sorry sparkydave! 
) ).
I’ve got 3 Sonoff NS Panels with the BLE working, running esp-idf. They seem to work well from what I’ve noticed.
The code is from here.
I just tried to download the diagnostics from within the Bermuda Integration but it wouldn’t download…maybe because I’m at work something is blocking it. EDIT: actually it would appear that trying to download the file has crashed my HA completely.
Great, thanks!
Oh crap, sorry 
I keep forgetting that the diagnostics has performance issues after Bermuda’s been running for a long time. Hopefully the supervisor (if applicable) will restart it automatically, but it might churn for a bit beforehand If Bermuda is recently “reloaded” it works fine, but if Bermuda’s been up for several days it can bog down hard enough to get oom-killed or grinds the cpu for ages. There’s a PR in progress to resolve that, which doesn’t help you right now, sorry.
Ah, from what I can see the NS Panel uses a classic esp32 (ESP32-DOWD-V3) rather than the S3, is that right? I’m particularly looking for examples of the esp32-S3 + esp-idf combo working with bluetooth proxy.
I really wish espressif had more sensible names!
Unfortunately it didn’t come back to life. I remotely power cycled my HA server (because I’m at work) but it still didn’t come back to life. I’m guessing it’s stuck at the boot screen where you have to press Ctrl+D or whatever it is on a keyboard connected to the machine. I’ll sort it out when I get home.
Crap, sorry mate. I owe you a beer.
Nah, it’s all good mate. You’ve done great work creating this Integration, I’m just trying to provide my limited skills to help out.
Limited skills?! I see you helping out more people on these fora than most! 
Sorry for the delayed response Ashley! It seems no matter what I configure the proxies to (lots of trial and error) they continue jumping around eachother. In the end, I bit the bullet and just reduce them from being in each room (9 in total) down to just two. One in the upstairs bathroom and one in the TV room downstairs. It is annoying because the integration does exactly what it is supposed to, and when I put my phone right next to one, it won’t move, which is great, but unfortunately until there is some way to really hone in on a parameter for each proxie to broadcast its signal or something like that, this seems like the best option in the interim. I am sure that will come in good time! If you’re ever up this way, give me a shout and we can have a beer! 
I did similar. I have 6 and the accuracy was just never good enough when each was assigned to a room. It was bad data; no fault of this integration. Instead, I changed each proxy’s area to the floor that each was on so I have 2 each in basement, on 1st floor, and on 2nd floor. That is enough granularity for my dynamic dashboard and it’s working great. I originally went from 6 each assigned to a room down to 3 (1 per floor) but going with 2 per floor definitely helped.
Hi All, After the recent update, I am noticing that the Area does not gets updated (using ESP32 Proxies) when the phone (HA Companion App) moves out of range. Meaning the Area is updated if the phone moves between proxies in various room, but if the phone goes out side of any proxy range (say leave the house) , the last Area stays and is not updated to AWAY .
Is this something you are also experiencing ?
Thank you in advance
Yes, there was a bug in an earlier release, but it was fixed about 2 weeks ago - can you test with v0.7.2 and check if it’s fixed for you?
