a) all sensor.* entities render unavailable once the device is not_home. That’s a minor thing and probably correct.
b) It takes 15 to 20 minutes (did several tests over the last hours: most state changes happen between 16 and 18 minutes) for the device_tracker entity to switch to not_home once leaving the house (or completely turning off bluetooth on the iDevice)
Unfortunately there’s also no consider_home config option for this integration following this:
I’d like to know
what can be done to improve this way too long “away detection timeframe”
how other users of this basically great integration handle this situation
Because all of my use-cases are impossible because of this, rendering the actual practical benefit of this integration to pretty much 0 % (“useless”).
@Jc2k hopefully we can discuss this here as the corresponding GitHub issue has been closed.
To repeat the discussions elsewhere, I can’t control how fast things go unavailable. I can’t add a setting because there’s nothing in the underlying frameworks an integration can do. It’s part of the design of the underlying HA Bluetooth framework. I report as unavailable as soon as it does.
The core code the integration is built on is quite clever about how quickly it marks things as unavailable. It monitors the times between transmissions and after a bunch of them it has an expected transmission rate for the device. That is the minimum time before it gets marked as unavailable. From what I remember it’s somewhat dynamic, in case that rate is variable. There is some headroom baked in because Bluetooth reliability.
The kicker is that (for performance reasons) there is a reaper that runs in the background that actually notifies integrations when those timeouts are reached and things are really unavailable, and that is longer than some people would like. I think it defaults to a certain number of minutes. A more naive implementation caused a lot of cpu churn. It’s chosen to balance more than just your use case, and it’s not something I maintain or control. But I do agree with the design and the trade offs it makes, which is why I’ve not tried to change it.
I will say that for me it’s faster than you to detect that both my phone and my Apple Watch have gone unavailable. What hardware are you using? USB dongle? Esphome? I have esphome only. Not sure it’s the case here, but we did have some people swear it wasn’t working at all and it turned out turning off a device didn’t stop Bluetooth enough in some cases. There should be a sensor that has the current broadcast interval. It should be less than 16s. Normally it’s less than 3s for me.
In my experience it’s about as fast as various “find my” services for marking me not home. I would say the house alarm arms itself before Apple notices I left my headphones behind for example. And it’s instantaneous for arriving home.
The other factor for the devs is that a slower notification is actually a hedge against poor Bluetooth reliability and false unavailability. Even at the current rate I get false alerts more often than I’d like. The answer for that is more proxies but I’m already on 5. If it was faster, I’d likely experience these more often. So adding a setting just invites a different kind of forum post I get tagged in, this time because of too many false positives.
If you have a use case that really really needs faster updates you can probably create a template sensor that updates on a time interval and gets the last changed timestamp for the signal strength, and subtract it from now(). If that’s over X seconds, boom.
Meanwhile - and I‘m still testing/monitoring things - it seems to have improved. No idea if it needs some „training“ (the kind of monitoring you mentioned in the beginning) but the long times of 15 to 20 minutes I saw directly after setting up the integration (in a specific fixed location of my home) are a thing from the past - hopefully.
Meanwhile I‘m somewhere in the round about 5 minutes scale after (physically) leaving home (instead of switching off Bluetooth - and yes, completely off, not the Apple default „don’t connect to devices until tomorrow“ state with grayed out Bluetooth icon which does not stop tracking) for testing purposes like in the beginning).
Sometimes that‘s even faster than my WiFi based device tracker (with a timeout set to 180 seconds).
I have basically 3 Bluetooth collectors:
on-board Bluetooth chip of the HA server (Pi 4)
ESPHome Bluetooth proxy
Shelly based Bluetooth proxy
When doing the initial tests I was close to 3 and 2. When actually leaving home I‘m likely next to 1 or 2 or 3 at last (guessed in that order).
So for now I will monitor the away timeouts a few more days, but things have improved.
