Bluetooth: Passive BTHome Devices get marked as unavailable too quickly

[jhbruhn]

The problem

My setup consists of multiple b-parasite sensors and multiple bluetooth_proxy ESPHome devices.
The b-parasite sensors are broadcasting their sensor values every 10 Minutes (default value), but the Bluetooth Integration (or BTHome) is marking the devices as unavailable after 5 Minutes already:

core/homeassistant/components/bluetooth/const.py

Line 30 in a28aeee

UNAVAILABLE_TRACK_SECONDS: Final = 60 * 5

What version of Home Assistant Core has the issue?

2022.9.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

bluetooth

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[probot-home-assistant]

bluetooth documentation
bluetooth source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (bluetooth) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[probot-home-assistant]

bthome documentation
bthome source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @Ernst79, mind taking a look at this issue as it has been labeled with an integration (bthome) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Ernst79]

It's a bit similar as this issue, see #78195, although in this case, we understand the cause of the issue (broadcasting interval of the b-parasite sensor). Will discuss this with the maker of b-parasite, either we change the scanning interval in HA, or we change the default for b-parasite.

[jhbruhn]

I'd vote for increasing the default interval to a higher value, or even making it configurable. In theory there could be sensors which broadcast once per hour to save on battery. As this is a format which is also meant for DIY sensors, I think it is a plausible use-case.

Increasing the interval of the hardware might work for this device, but not for different devices in the future. It also means a higher battery consumption without any gain in usability, as the measured values are changing very slowly.

Additionally, in my experience with a lot of bluetooth sensors, packets get lost due to multiple devices sending quasi-simultaneously or being just barely out of reach and thus only getting data every hour or so.

Is there a particular reason the unavailability was introduced here? With ble_monitor it was working nicely. I see the benefit of showing a sensor as unavailable, but IMO it could be after 24 hours since the last successful transmission.

[Ernst79]

The idea of sending multiple packets is that the changes are bigger that one gets picked up. Most Xiaomi sensors send 20 exactly the same advertisements per minute (although some other sends only one per 10 minutes).

The unavailability is a general Bluetooth integrations issue, I first want to see where that is going in #78195. If needed, we can make some changes in BTHome specifically, but I prefer to have a general solution.

[agners]

The unavailability is a general Bluetooth integrations issue, I first want to see where that is going in #78195.

It seems that the linked issue is related to the Bluetooth receiver device disappearing, and hence all devices which communicate through it will be marked unavailable. However, this case is a clear "mis"configuration between the firmware and what BTHome expects...

IMHO, a generic way to configure timeouts for all Bluetooth devices is not really sensible, as for other devices the sleep time is likely known. It's really BTHome which taps into the unknown territory, as the firmware is really custom.

[Ernst79]

I understand what you are saying, but even for BTHome devices there is already a difference between devices. E.g. ATC custom firmware on these Xiaomi temperature/humidity sensors is sending data every 2.5 seconds, while bparasite is sending data once per 10 minutes.

BTW. thanks for the sponsoring @agners

[bdraco]

I adjusted the timeout for the esphome proxies in 2022.10.x to be 15m. It was set to 5m

For the native stack we know when the device falls out of the stack so there is no timeout there as it just relies on the bluez logic

[balloob]

I've been thinking about this and I came up with home-assistant/bthome.io#11. Since it involves changing BTHome I would suggest taking our discussion there.

[agners]

I adjusted the timeout for the esphome proxies in 2022.10.x to be 15m. It was set to 5m

Cool, yeah with 2022.10.x the b-parasite device does not get unavailable anymore here 👍

[bdraco]

Since passive devices still fall out of the bluez stack too quickly, I'm attempting to build a new unavailable layer to better handle passive devices but it won't be ready until 2022.11.x at the earliest as gathering the requirements from all the issue reports, devs, and live testing has taken quite a bit of time. I'm just about ready to start writing code for it.