On my primary HA installation on the NUC renaming the knowndevices did not do anything to help, new wifi devices get populated in to the file, but no new Bluetooth devices, and it will track only the first Bluetooth device to anything close to accurate, and the 2nd BT device appears to only be tracked if the 1st BT device is home.
on my old installation on my RPi I upgraded HA in the end, from 0.80.4 to 0.88.1, this appears to have had no impact on Bluetooth, with Bluetooth still working pretty flawlessly and very accurately on the RPi.
So only conclusion out of that, HA version does not appear to be the cause, so I guess it would have to be hardware related.
I broke down and bought a Pi, will try to use this: https://github.com/andrewjfreyer/monitor - it will add a whole bunch of complexity, since I also have to install MQTT, but at least I don’t have to maintain another HA instance.
I am still not quite sure what kind of voodoo is involved with it, buuut, I got it to work last night!
So far I’ve tested the fact that is sees me at home all night without marking me Away and that I am marked Away when leaving the apartment (or, rather, my gf was marked when she left for work this morning)…now the only remaining unknown is how quickly it marks us Home when arriving, will test that tonight and if all is well will post a mini-guide.
a mini-guide would be very much appreciated. would the mqtt bit work with HA? I have HA running on my Pi with Bluetooth perfectly and I don’t really want to disturb that. but if I can get the HA BT devices and states in to my main NUC HA that would be ideal.
I was testing more on my NUC and found that using the command line and bluetoothctl this will monitor as it should, so it appears to be HA working with the Bluetooth system on the NUC does not.
the behaviour in HA appears to be:
First BT device in KnownDevices is tracked perfectly
the next 4 or 5 devices are tracked as long as the 1st devices in the list is home
If the 1st device is turned off / goes away from home, then all BT devices show as away
The all BT devices after the 5th or 6th BT device in knowndevices are never tracked.
The NUC wont discover new BT devices either (**edit)
To me this now sounds like a bug in something related to what HA uses but closely tied in to the hardware. Maybe 64bit implementation of Bluetooth on Linux. Maybe its Ubuntu (my NUC) vs Debian (Pi)?
OK, so I’m cautiously optimistic that this is my long-term solution
Here’s what I did:
On a Raspberry Pi (3B+ in my case), I followed the steps described here: https://github.com/andrewjfreyer/monitor - specifically, the sections “Installation Instructions for Raspberry Pi Zero W” and " Configuration and Setup", right up until point 10 “Edit mqtt_preferences file:”, which I did not follow
Installed the MQTT integration in HASS.IO, using the Discovery option
Went back to the Pi and did Step 10 from the guide (“Edit mqtt_preferences file:”) with the user and pass I created in HASS.IO for this purpose
DID NOT FOLLOW STEP 11 TO ADD ANY KNOWN MAC ADDRESSES (because when I did, it would just see my Tile twice when scanning, once home and once not_home, thus rendering the whole thing useless)
Edited the behavior_preferences file on the Pi to add the line “PREF_DEVICE_TRACKER_REPORT =true” (thus the system will work as a device tracker, not just with the percentages initially described by the author, saves you from creating template sensors if all you want is home/not_home)
Edited configuration.yaml to add a new device tracker:
Nope, if the app is installed and Bluetooth on the phone is activated, it will always connect to my phone and not be available to the Monitor script. Thus, I don’t keep the app installed (I have BT always active on the phone because of my smartwatch).
Thanks, that’s what i figured was the case. Did you have it paired originaly? if so will uninstalling the app prevent the tile from connecting to the phone? I got mine yesterday and wanted to test it out and then started messing around with monitor.
sudo bash monitor.sh -b is a foreground command and thus closing your ssh client terminates all tasks attached to that login session. You’d have to install the command as a service and enable it so it runs in background. Once the service is enabled it will automatically start at bootup. After installing/enabling the service, systemctl start [service_name], or reboot…