Better support for BLE devices with less frequent advertisements.

[prestomation]

I wanted to say thank you so much for the amazing integration. The model you have created that automatically uses BT devices, BT proxies, areas, Private BLE Integration/etc is such great software and was soo easy to setup. I had been avoiding room presence for so long as I was fearing the exponential increase in maintenance but bermuda plus ESPHome bt proxies made this so great.

Is your feature request related to a problem? Please describe.
I have some BLE devices that aren't 'seen' as often as others.
I have a Fi dog collar. It is bluetooth/wifi/LTE. It pairs with a base station or an owners phone most of the time for least power consumption. I have this tracked in bermuda.
My goal is room tracking for my dog, so I know where she is in HA.

I did some experimenting. If I powered down the base station and disabled BT on the phones, it works great!
but the area would go 'unknown' after turning on any of these. Not sure of the details but whatever advertisements this thing sends out seem to stop/slow down.
I thought they stopped altogether, but I noticed later that I see rare pings, see image

in this one evening sample the collar went as long as 90 minutes without an advertisement.

Describe the solution you'd like
I'm not 100% sure what I want but wanted to start this issue to try to identify this general problem and what broad solutions maybe could be implemented to improve usability of tracking these devices.
In my case the last known area is better than nothing. maybe ' last area seen' and 'last time seen' sensors? Maybe a per device 'area timeout' I can set to 90 minutes? I also use this integration for the collar so I have a web-powered device tracker for the same device. Maybe something that helps these integrations work together so the area doesn't timeout for longer if the associate device tracker is 'home'?

Describe alternatives you've considered
I have a similar problem with my HA beacon on an android phone. with the default settings I saw similar behavior(but with shorter 'dead periods'. Fortunately HA let's me fiddle with the settings, but this could be useful for this case too.

Additional context
Add any other context or screenshots about the feature request here.

[agittins]

Thanks for your well-presented and thought through feature request!

The model you have created that automatically uses BT devices, BT proxies, areas, Private BLE Integration/etc is such great software and was soo easy to setup. I had been avoiding room presence for so long as I was fearing the exponential increase in maintenance but bermuda plus ESPHome bt proxies made this so great.

Cheers! I've tried hard to avoid having too many levers people need to pull for a working setup (which lowers support!) and to have Bermuda do as much as possible "automagically", so it's rewarding when folk notice and call it out 😁

I have a Fi dog collar. It is bluetooth/wifi/LTE. It pairs with a base station or an owners phone most of the time for least power consumption. I have this tracked in bermuda.

There is a good chance that the long intervals in Bermuda are caused by the collar being actively connected to a device (like a phone, perhaps the base station). Most BLE devices will only advertise when they have no active BLE connections, and will go quiet once they have connected. The result is that Bermuda will only see the device "between" connections, such as when the phone is out of range of the collar etc. My smartwatch does this, so I now leave my watch disconnected from the phone app except when I want to perform some action. This might not be a practical solution if the BLE connection being active gives you benefits (such as much-reduced battery draw, or monitoring benefits etc).

If you can't alter the frequency of BLE adverts (by choosing to not keep it connected, or through some config options), then the next best bet is probably, as you suggest, to persist the last known area value in the absence of updates.

Another possibility is that the collar doesn't advertise when there is no movement. I think AirTags do this, and another tag (chipotolo or something?) actually changes what it advertises depending on movement.

The short term work-around for your instance is probably to create a helper template sensor, that updates only when the bermuda sensor's value updates, and copies its value (but not 'unknown' or 'unavailable' states). This gives (as you suggested) a last_known state as you described.

There is an issue open #202 to add a "last seen area" sensor to Bermuda, and despite initial reservations I am pretty sure I plan to implement this, as a disabled-by-default sensor. Adding new sensors is a bit scary (for me) since a lot of folk have small rpi setups that start to struggle as the number of sensors increase, but AFAIK disabled sensors shouldn't cause an issue in those cases.

Soo..... in summary(!🙂):

• Consider if having the phone app (or basestation, if applicable) maintaining a BLE connection is a suitable trade-off if it prevents more regular advertisements
• See if there's any config option for the device to still advertise in some form even when it is connected (this is probably unlikely)
• Enable a last_seen_area sensor either by making a template yourself or holding tight for Add "last seen" sensor for tracked devices with timestamp #202 to be done.

[prestomation]

Thanks for your input.
I've opened #440 which implements #202

For my specific problem I've put the dog collar base station on a smart plug and force a reset every 10 minutes. This disconnects Bluetooth and forces a beacon signal. Not great but it works!