It doesn’t return anything.
Then that’s why you’re not seeing anything for saving it as a known device. The device simply does not respond. Looks like it works just fine as a general beacon, though!
Breaking Changes to monitor 0.1.575
Y’all, in preparation for further distancing monitor from presence, I had to push some breaking changes - specifically, the path part ‘owner’ is removed from here on out for all mqtt topics.
This means endpoints and sensors need to be updated. Apologies, but this is one of the last holdovers from presence
Again, apologies for the inconvenience this will cause many of you.
1 Like
is it possible to account for beacons listed in the known_devices file? If they aren’t found using hcitool name can they be checked using the beacon method for a more accurate response/confidence?
If you are using monitor, yes. Presence does not have reliable beacon detection, and I’m likely to remove it.
Problem is that it only ever reports as confidence 100 if I don’t include it in known_static_addresses.
I’ve just removed its address from the file and rebooted, an MQTT message was sent with confidence 100, I then took it out to the car where it’s been sitting way out of range for 30 mins and home assistant still thinks its home because the last message said confidence 100.
Make sure you are updated to the most recent version.
I'm sorry y'all...
I know it's a pain that I push out updates so quickly and in rapid succession, sorry. It's far easier to debug and update my personal setup in this way since I had set my nodes to monitor for github changes...It’s stupid and lazy and it causes y’all to update far more often than you’d prefer. We’re getting close on monitor, and I appreciate the community’s patience.
5 Likes
After upgrading to monitor would I use something like the following to remove presence startup at boot?
systemctl stop presence.service
systemctl disable presence.service
rm /etc/systemd/system/presence.service
rm /etc/systemd/system/presence.service symlinks that might be related
systemctl daemon-reload
systemctl reset-failedYes, you should stop presence from running. The two will constantly fight over the bluetooth hardware and likely neither will perform ideally.
1 Like
Updated to latest and seems much better with respect to the Mi Band, confidence is updating every few seconds and is fluctuating between 60 and 100, can’t really take it out of range at the moment to test properly.
Great to hear! Beacons are a challenge since there are so many different types and since some of the cheaper manufacturers (read: aliexpress) don’t conform to protocols all that well.
For your information, the confidence value is based on the duration since the beacon was last seen. By default, after 1m 25s without any advertisement, a beacon is considered “gone”. So, if you are seeing a confidence of 60% (and you haven’t changed default settings), we know that monitor hasn’t received an advertisement from your device for at least 58s. For beacons, we expect the confidence to fluctuate a bit beacons do not advertise at fixed intervals.
Note also that I have a built-in ‘biasing’ that should learn to prevent false positives and false negatives. Essentially, if a device is marked “gone” and then rapidly shows up again, we will add a bit of time to the interval after which the beacon is considered gone the next time around.
For example, if a beacon expires after 125 seconds, but is seen again at 127 seconds, we will add 15 seconds of bias. Then, next time, the beacon will have 125+15= 140 seconds before it is considered “gone”.
Does that make sense?
1 Like
Makes sense 
I’ve just placed it in an antistatic bag and it disappeared within about 3 minutes so seems to be working well.
1 Like
Phew! That timing lines up well with default settings!
Hi Andrew, thanks for all the hard work
I’ve downloaded the latest monitor and have been putting it thru’ it’s paces
As far as my phone (a Sumsung S9) goes it detects it very well , however my Nut mini is pretty much not detected at all - it very occasionally sees it and reports confidence 0 if it’s in the known address file, if not in the known address file it never seems to see it.
My BT LED bulbs are detected as are my MiFlora Plant sensors.
Would it be possible to have a mechanism to not report certain mac addresses (i.e. my bulbs and plant monitors)?
Yes, I can add a reporting filter, but that will take a bit of time. I’ve been working on a solution for my own, since each of the TVs in my house show up too!
As far as the NUT Mini, how are you trying to detect it? As a generic beacon? As a known device?
“Yes, I can add a reporting filter, but that will take a bit of time. I’ve been working on a solution for my own, since each of the TVs in my house show up too!” - sounds good
I tried both with the -g and as a known device, it pretty much never shows up with the -g but it will sometimes show up when in the known devices file but always with a conf of 0.
My bulbs and plants show up every min or so as generic beacons.
Hi,
Not sure if this is on the roadmap or even possible. It would be good if could somehow report beacon battery status on some sort of interval. Not sure how to retrieve without an attempted pairing though?
Do you know its mac address? If so, what is the result of the command hcitool name [MAC ADDRESS]?
Not on the road map. Far too many of these devices implement different data structures (as best I can tell) for reporting battery status and whatnot. I’ll look into it, but that’s likely to be variable by manufacturer and protocol.