(<class 'custom_components.bermuda.sensor.BermudaActiveProxyCount'>) took 1.280 seconds.

[fft1010]

Hi,
I found the following in the logfile today:

2025-01-13 12:58:48.804 WARNING (MainThread) [homeassistant.helpers.entity] Updating state for sensor.bermuda_global_active_proxy_count (<class 'custom_components.bermuda.sensor.BermudaActiveProxyCount'>) took 1.280 seconds. Please create a bug report at https://github.com/agittins/bermuda/issues

Configuration

Diagnostic Screen:

Options:

Select Device:

Describe the bug

Can't say more than in the log. It only occured once.

Diagnostics

In HA, Settings, Devices and Services, Bermuda, click the three-dots and choose "Download Diagnostics.
This will chug away for a bit then present you with a json file that you can upload here.

I tried this, but i gave a total crash. Machine did not answer any more, I had to restart the whole machine. Bermuda only ran about 1-2 days. After the forced restart: Here is the file: (took about 5-10 seconds)
config_entry-bermuda-01JHD28X2WF3PZEXZ3S00K6CSS.json

thank you
Juergen

[agittins]

Thanks for your report and the solid investigation! That's a great collection of proxies!

I'm seeing similar warnings on my system as well, but over multiple integrations and for those in Bermuda, over a few different entities:

I can't see any reason that the code in the relevant routines should take a long time, as it's only doing local variable processing (no disk or network requests etc). For my system, I suspect it's happening when my system is under a heavy load, and the homeassistant processes are being starved for cpu time while things like my database server, jellyfin and lord knows what other VMs and containers I'm running are hammering the system.

Are you seeing similar warnings from other integrations, or has this only shown up for Bermuda? I see you seem to be running this in a VM on a x86_64 machine, so might be in a similar situation to my server.

That said, of all the integrations out there, Bermuda is one of the more cpu-heavy ones, as it churns through all the bluetooth adverts it sees every second - but that's done separately from the routine that triggered that warning. The particular routine that you got a warning from does do more work than the routines that I got warnings for (the activeProxyCount check does a full (in-memory) tally over all known devices), so it is less efficient than it could be, but even so should only take a few milliseconds to complete if it has access to a cpu.

I think I can optimise that particular routine a bit, so I'll look into that. If you have any info on whether you see similar warnings from other integrations, or if the system might have been unusually busy at that time that might be helpful, but I'll be able to proceed either way.

Sorry about the system lockup on the diagnostics! 😦 There is a fix that will be in the next release that should prevent that in future.

[fft1010]

Hi,
As this behaviour until now only happened once, I suggest we have a look and close this issue in 1-2 month. My pulse was really going up, when the system locked. But as it came back after shutdown and reboot, and than the diagnostics came fast, I took it as a reminder for a newer backup :-)

I installed bermuda a while ago, but did not get it. But now we look for a lost key, so I tried a re-install. If I would have been more patient a while ago, I would not search keys now :-)

One question: As sensors flip in between rooms, is there a way that bermuda would use "floors" instead of rooms. I have a hierarchie in my house, like Floor_1: Kitchen, livingroom, entrance, floor_2: kid_1, kid_2, sleeping
As floors would be enough (and hopefully would not switch so much), would make my management here more "believing" that this works :-))

many thanks for bermuda,
and keep your fingers crossed for me key search
thank you
Juergen

[agittins]

I took it as a reminder for a newer backup :-)

😅

Agreed re seeing how this goes. And good luck finding your key!

Re floors, I do plan on Bermuda supporting floors as a concept, but up to now I only had it in mind for the future trilateration support. It makes sense though to have floor as a sensor entity for the current area detection method as well.

If you have issues with the area flipping between areas from different floors a new floor sensor would still do this (flip between the floors of the detected areas), but if you find it typically flips between adjacent areas on the same floor, it should be fairly sensible, and I could imagine quite useful, too.

I've raised a new feature request for a floor sensor :-) #431