Odd Bluetooth Device Tracker Behavior

ranunculales · March 23, 2019, 12:36am

Wondering if anyone else has experienced this; looking at Bluetooth device tracker, both my phone and my wife’s.

When I leave the house my status changes to ‘away’ and at the same time it changes her Bluetooth status to ‘away’ as well, but she is still home. In reverse, if I am home and she leaves; the status of her’s remains as ‘home’ as does mine.

I’m reluctantly leaning towards my conversion to the Intel NUC; as this all worked fine on RPI3b+ in 0.89.2. But, the Bluetooth driver appears to be working because it does see my phone come and go just not my wife’s. I’ve checked the known_devices.yaml, the BT_MACs are different, they show up in States header as separate devices…

HASSIO 90.2 (I have also rolled back to 0.89.2 with the same results)
Intel NUC (updated bios, Bluetooth enabled)
Ubuntu Server 18.04 LTS (updated kernel and Bluetooth drivers)
Docker CE with Portainer

rendili · March 23, 2019, 8:54am

I have this exact issue!
I also have moved from a rpi where it was working perfectly to a nuc a which has this issue
For me I have exactly as you describe along with no new devices being discovered.

Using the hcitool shows that the nuc is detecting the correct devices at the correct time, but for some reason this does not make it as far as HA

My nuc is also on Ubuntu 18 lts, but I am running a munaul HA install rather the hass.io

How do you update the kernel and Bluetooth drivers?

I have almost given up trying to get this fixed and was trying to find time to mqtt the Bluetooth states from my rpi which is still working perfectly with Bluetooth to my nuc HA, but it is heartening to know someone else has the exact same issue.

rendili · March 23, 2019, 9:07am

oh and to add, I have found that whichever Bluetooth device is first in the knowndevices file is the one which has the accurate tracking and the others go home and away with it.

Plus only the first 4 or 5 BT devices in knowndevices will be tracked in any way at all, every device after that is completely ignored.

ranunculales · March 23, 2019, 5:09pm

I’m back to square one, marked my previous two updates for deletion, as this morning I’m not certain I fixed it (as I said) nor it subsequently then braking after updating HASSIO to 0.90.1. I’d rather not feed inaccurate information if I’m not certain. As for your question about how I updated the Kernel and Drivers, see below.

I just tried (re)implementing andrewjfreyer’s Monitor project for MQTT/Bluetooth presence detection (for the third time) on a seperate RPI. I really want that to work for me, and I can get it working, but it’s a bit complicated to reliably integrate into my current presence configuration (my problem, not his). So I’ve rolled back to the traditional bluetooth device_tracker hoping I can get it working again on the NUC. It was so simple and reliable for me, I really want to see if I can get it working.

That is an interesting observation about the first device in appears to take the lead for the others… I’ll see if that rings true for me too.

Update the Kernel:

Install UKUU:
sudo add-apt-repository ppa:teejee2008/ppa
sudo apt-get install ukuu

Check Current Version and for Updates:
ukuu --check

Install Latest:
ukuu --install-latest

Check Version to Verify:
ukuu --check

Install/Update the Driver:

Install the Driver:
sudo apt install bluez

Check version:
dpkg --status bluez | grep '^Version:'

Add the Repo and Update:
sudo add-apt-repository ppa:bluetooth/bluez
sudo apt-get update
sudo apt upgrade

Check version:
dpkg --status bluez | grep '^Version:'

ranunculales · March 23, 2019, 5:43pm

Sure enough, I just flipped the order of my phone and my wife’s in the known_devices.yaml and her’s seems to be (for lack of a better term) the master device for Bluetooth tracking now. My phone is reporting ‘away’ because she isn’t home right now, but both were ‘home’ when my phone was listed first. How frustratingly weird.

Edit: I just set her known_device ‘track: false’ and my Bluetooth switched to ‘Home’. Putting her’s back to ‘track: true’ marked us both ‘Away’ again. Fantastic… /s

rendili · April 3, 2019, 7:20pm

hi @ranunculales

thanks for the info regarding updating the firmware, I will have try and find some time to give it a go, I have been a bit too busy to look in to HA stuff recently.

Very interesting test results you have there with setting the first device track to false, surely this must be an HA issue then with how it interprets the data from Bluetooth on the NUC?

Have you managed to get any further with troubleshooting the Bluetooth issues on the NUC?

I still need to try and find time to work out how to setup MQTT on my Pi to send its Bluetooth tracked devices states to from HA on the Pi to HA on the NUC.

Which version of Bluez does your NUC run?
Mine report the following when I run your check version cmd:

Version: 5.48-0ubuntu3.1

ranunculales · April 3, 2019, 9:04pm

Quite honestly, I gave up. I removed it from my config to give the IOS app another run for it’s money with the Nabu Casa trial, since it now provides remote connectivity I will say, adding the iOS app and Nabu Casa, my presence detection has never worked better.

rendili · April 6, 2019, 9:10pm

ok
personally I have more than just ios devices, so I will, when time permits, persevere.

joelprine · June 26, 2019, 3:10am

Any update on this one? I have the EXACT same issue, same setup at OP, except latest version of Home Assistant (0.94.0)

First BT_ device listed in known_devices is the master and controls home/away state for all other BT_ devices in the file. I think the RSSI signal strength info is correctly tracked separately for each device; appears to only be home/away state that is affected, testing further to confirm.

EDIT: I don’t have a clear understanding, but it appears to be working now. My issue seemed to be two fold.

You need to have a blank space between each device in the known_devices.yaml file. Without the blank space, even the sorting in the Lovelace UI was out of order. Not sure all the issues (if any) this was causing.
I enabled “request_rssi: true” in the bluetooth tracker - This seems to be the primary fix.

I also notice that my consider_home appears to be roughy half the time I have specified. The device appears away about twice as fast as I would expect. I am not sure if this is related or not.

device_tracker:
  - platform: bluetooth_tracker
    interval_seconds: 30
    consider_home: 300
    request_rssi: true
    new_device_defaults: 
      track_new_devices: false

I will monitor for next few days and if I discover anything else I will update the thread.

rendili · June 26, 2019, 8:05am

Thanks @joelprine for this info

I have just updated my config to include the line request_rssi: true and restarted (I already had line between each device).
I will also monitor for the next few days and see how is goes

rendili · June 26, 2019, 11:37am

Little update:

The 1st BT_ in the known_devices.yaml file went out, and as expected its state changed from Home to Away, then changed back to Home when it came home.
Unfortunately at the some time exactly the 4th BT_ device in the file also changed its states to Home then Away then back to Home at exactly the same time.
The 5th BT_ in the list however remained in the Home state the entire time.

No idea what this means, but before it was everything after device 4 in the list changed state inline with device 1.

joelprine · June 27, 2019, 12:59am

So far so good for me, I have three BT_ devices and now that I have the RSSI parameter added they have all changed home/away as expected. Continuing to watch, but seemed to resolve thus far.

thowi · July 3, 2019, 8:19pm

My Bluetooth tracking is also very flaky on Intel NUC/Ubuntu.

Strangely for me, it also shortly marks devices as “away” at every “consider_home” interval.
I use consider_home = 10 for testing (normally I use 180) and every 10 seconds my device(s) are marked away for a blink of an eye and then marked home again. Very strange.

request_rssi didn’t fix anything for me.
I’m considering to buy a separate bluetooth dongle to see if that would work better.

thowi · July 3, 2019, 8:31pm

BTW, this used to work.
Not sure what changed. Maybe I upgraded Ubuntu, maybe HA, maybe I made a config change…
It’s quite annoying though.

rendili · July 3, 2019, 8:48pm

mine was flawless on an pi up to version 0.88.1, I then migrated to a new NUC and it has not worked much since.
after adding request_rssi for the first time on the NUC it now detects new devices automatically and it does work a lot better, but still some devices still follow home and away at the same time as the first BT_ device, but some work as they should.
its all very confusing.

rendili · July 3, 2019, 8:50pm

if I had the time I would try and write my own HA component and library to replace this, but unfortunately I am too busy at the moment