search

Bluetooth-Devices / bthome-ble

Parser for BTHome BLE devices
https://bthome.io/
MIT License
64 stars 11 forks source link

[Question/possible enhancement suggestion] - How much radio silence before a device is considered to be unavailable? #121

Closed kquinsland closed 2 months ago

kquinsland commented 2 months ago

I am working on adding BTHome support to a device and in testing ran into a question that - initially - I couldn't find a clear answer for. While trying to answer the question, it sorta morphed into an idea that might make the protocol a bit more power efficient and/or more responsive for some use-cases.

For a device that has the BTHome Device Information byte set to 0x40 (not encrypted, not trigger based, version 2), How long from last transmission until the device is considered unavailable?

Since the BTHome protocol definition doesn't explicitly define the timing for bit 2, i'm assuming that the policy for unavailable is up to each implementation.

In testing with ESPHome/BT-Proxy -> Home Assistant, this appears to be 5 min/300 seconds. This 300 second cutoff appears to be defined here.

This leads me to my (revised) question / suggestion:

Is there value in adding a "consider me unavailable If you don't hear another advertisement from me by $secondsFromNow" field to the advertisement payload?

The use case I had in mind: being able to tune the sensitivity of presence detection instead of the binary "it will check in 12 times an hour or ... whenever" choice.

In my current use-case, it would be nice to trigger actions no more than 60 seconds after a device stops phoning home. Example: a beacon device attached to a pet collar. An escaped animal could make it quite far from the receiver before the 300s window elapses!

But the inverse is also true: devices that have a regular check-in interval measured in tens of min/hours are either forced to check in every 300 seconds to avoid going offline or set the "check in ... whenever" bit which means they'll (almost) never appear as offline... even if they are offline.

E.G.: a heating fuel tank level sensor. During the summer, phoning home every few hours is more than enough to confirm that the sensor is still alive as the fuel level will be incredibly stable. During the winter the fuel level might drop measurably every hour or so.

If the fuel measure device sets the "irregular interval" bit then there's nothing to notify the user that the device failed a scheduled liveliness check.

If the fuel measure device sets the "regular interval" bit than it needs to wake up at least 288 times per day just to report that ... there's still no measurable change in fuel level. Any less often and the user risks getting a false "device offline" notification from HA.

If the fuel measure device sets a "consider me offline if no update by 43200 seconds from now" byte in it's advertisement then HA will still expect a check-in 2x/day or more often.

During the winter, the sensor might be reporting fuel level changes hourly so this liveliness interval is being met. During the summer, waking up 2x a day for liveliness is adequate. If the sensor fails for some reason, the missed liveliness check will result in an appropriate "device offline" status in a timely manner.

Ernst79 commented 2 months ago

The unavailable timeout in Home Assistant is indeed set by the Bluetooth integration, not by the BTHome integration in HA, and also can’t be set in the BTHome protocol itself. It might not be needed to set it in the protocol, as you can also decide to implement a device specific configuration option that sets the time out (if you want to use something else than the default HA Bluetooth timeout).

kquinsland commented 2 months ago

as you can also decide to implement a device specific configuration option that sets the time out (if you want to use something else than the default HA Bluetooth timeout).

Where/How is this done?

Ernst79 commented 2 months ago

That would require adding a config option in the Home Assistant BTHome integration, which is part of the home assistant core repository. It might also require some changes to the Bluetooth integration. It's not something I have time for unfortunately

kquinsland commented 2 months ago

It might also require some changes to the Bluetooth integration.

I misunderstood. Presently it's not possible.

I assumed this might be the case; the whole HA component would likely need a re-factor to keep track of the per-entity (or would you implement it per PHY MAC?!) timeouts.

Adding manual user/configurable timeouts per entity would be the first (and probably biggest?) step. Then adding a new ID and a few bytes for the timeout would be a relatively simple addition to the actual BT-Home protocol.