I didn’t realise the other two issues are with people also using Pi.
Have you tried the non LE Bluetooth component to see if that is any better?
Wont it track the Tiles but in non LE mode?
I didn’t get time to try an install of the latest HA on my Pi, next opportunity will be Wednesday.
I was playing around with a couple of commands to see what the OS / hardware was doing, and the following command:
dmesg | egrep -i 'blue|firm'
shows pages and pages of the same error:
[296988.055841] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297017.055840] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297047.054753] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297076.059708] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297105.055861] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297134.053757] Bluetooth: hci0: last event is not cmd complete (0x0f)
[297163.053832] Bluetooth: hci0: last event is not cmd complete (0x0f)
no idea what it means, but I am sure this is outside of HA, maybe HA initiated, but this is coming from the OS
My system works flawlessly for the most part with the regular bt tracker for presence detection and i have the same logs and have had every since i installed it. I figured it was normal. I can tell you this much though. If that log stops outputting entries that means my bt scanner is no longer scanning and a restart of ha is all that fixes it. Also , if you look closely at the number at the beginning the first few digits before the decimal, if compared to the line before it, will add up to very close and sometimes exactly, the sum of interval_scan subtracted from concider_home in the config. so i assume that every other line is a bluetooth scan for devices.
I tried the normal BT tracker and it definitely doesn’t seem to recognize BLE devices, it only saw my (regular BT) TV, whereas the BLE tracker sees a whole bunch of other devices, like the Google Home Minis, my watch, etc.
I refined the reboot automation a bit, in the sense that it doesn’t restart the entire VM now, it just restarts HA, which leads to a lot less downtime.
I also tried the custom BLE component someone here made, which should not crap out after a while, but it didn’t detect my Tiles, it only saw some of the BLE devices in the house, less than half of what I actually have. It might be somehow optimized for the Pi’s Bluetooth, thus maybe not using my USB BT device properly.
Using a Google Home Mini as a BLE scanner did identify the Tiles, but I think giving it the task of constantly scanning for them was too much for it, it couldn’t see one of them stably at Home, it was frequently seeing it Away (the other one seemed fine).
Thus, the official BLE component really seems like the way to go for now, at least in my situation. It recognizes the Tiles impeccably when it hasn’t crapped out and the restarts take care of that situation.
lol, looks like the “refinement” of the reboot option was not a good idea - at one point it sent HA into a reboot loop because I had an I/O error with the BLE component which both kept it from starting and provided an error in the log, which triggered the automation constantly…luckily, it had a 30ish-second window in which I could turn it off and make the modification.
whoops
I still have not got anywhere with mine and have not found the time to try the latest HA version on a spare SD card on my pi.
Tomorrow however I will (probably) rename me knowndevices file and get a new one created and have HA populate entries again. Some devices however will need some manual intervention to get back in there.
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.
good to know.
I started looking at something involving a 2nd instance of HA and linking via MQTT, but I failed to get anywhere with MQTT as my knowledge on this is pretty much zero.
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.
great stuff
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:
Is there any particular reason the Bluetooth implementation doesn’t use the Bluez D-Bus interface?
Running external commands such as hcitool and parsing the output seems a bit flaky.
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.
whoops
