BLE tracker is fast to detect home but takes a long time to detect away

As per the title the BLE tracker is able to detect devices within seconds but takes around 15 minutes to detect as away. The interval_seconds & consider_home parameters don’t seem to make any difference - Though consider_home set to 10 seconds makes the device flip between home & away until its really detected as away (15 mins or so)

I’m using an RPi4 and do also have Shelly devices that can act as Bluetooth proxies but to help with troubleshooting I’ve scaled everything back to just the RPi Bluetooth enabled with just 2 device entries within the known_devices.yaml

Rebooting HA will result in the device being shown as away until I bring it back into range so I’m confident the test I’m doing is fair.

I’ve also just tried using an automation to set the device as away once its been home for 20 seconds, something still sets it back to home after what looks like 7 seconds - The process of home & away continues on and on so its like the home status is cached.

I’ve tried so many things and searched home assistant docs high and low but out of ideas (Possibly missing something obvious). If anyone has any ideas to try I’d be most grateful as it feels like I’m so close to having the perfect setup where BLE devices can be detected within seconds anywhere in the house or garage withing seconds (when Shelly devices are enabled for bluetooth).

Below is my latest config, I’ve also tried it without the standard bluetooth tracker but that doesn’t seem to make any difference.

device_tracker:
  - platform: bluetooth_le_tracker
    consider_home: 15
    interval_seconds: 10
    track_new_devices: false
  - platform: bluetooth_tracker

It sounds like the issue may be related to the Bluetooth Low Energy (BLE) devices themselves, rather than the Home Assistant configuration. BLE devices are designed to be low power and consume very little energy, which means that they often have long periods of inactivity or sleep. This can result in delays in detection or reporting of the device’s status.

One possible solution is to increase the transmit power of the BLE devices, if possible. This can help to increase the range and reliability of the signal, which may reduce the delay in detection or reporting. Another option is to use multiple BLE devices or Bluetooth proxies, as you mentioned, to provide better coverage and reduce the likelihood of devices being out of range.

You could also try experimenting with the consider_home parameter, which defines the amount of time that a device should be considered “home” before being marked as away. Increasing this value may help to reduce the frequency of flipping between home and away status.

It’s also worth noting that the interval_seconds parameter controls how often the BLE tracker scans for devices, rather than how often it updates their status. The status update is controlled by the BLE devices themselves, which may have their own built-in delay or reporting interval.

Thanks for replying appreciated.

HA can detect the devices coming home really quickly e.g. quick enough that an automation can open the garage door whilst I’m driving down drive in time so HA is definately detecting the devices ok so I don’t see the problem is related to the device being inactive - If it were I’d expect it not to see me come home. The problem is that it takes for ever to detect the device as away.

I’ve tried so many different combinations on consider_home and interval_seconds but nothing seems to help improve the time it takes to detect the device as away.

Did you ever come up with a solution to this issue? I am also having a difficult time controlling the “Away” timeout. My beacons also are instantly detected upon arrival, so I know the signal is strong and reliable… The beacons simply take ages to become detected as away.

My guess is there is a flaw in the integration code somewhere. Probably when the BLE device totally disappears suddenly, i.e. without a couple of weak signals showing the BLE device has moved further away. To cover this type of situation, the code should have some sort of “missing in action” backup timer that marks the item as “away” if no signal is seen for x seconds or more. Or maybe the code does have this feature but the timeout is set to 2 minutes or some other super long period.

On my garage door automation project, this is also a potential problem since my automation is searching for a weak signal from the car beacon to confirm the car has left the garage. I had to tweak the signal smoothing until I found the right balance of fast reaction and reliable/correct reaction. Technically it can probably still happen if I back out of the garage at 50mph. :smile: