Hmm. That seems like very unusual behavior, especially considering that vendor names are cached - that’s about two requests per minute per pi. I’ll investigate.
Perhaps your cache is corrupted? cat .manufacturer_cache should return only lines with partial mac addresses and manufacturer names.
@benjimatt is right - there’s no express need for the manufacturer data.
Dont think so hard. You do not NEED to use the arrival trigger if you do not want to. If you lived in a very Bluetooth congested neighborhood it would be helpful because it would only do an arrival scan when a certain event it triggered. Right now you will go by random advertisement when works just fine.
I use this setting
Monitor.sh -trd -x
I have 3 Pi’s in a one bedroom location (OVERKILL) but once one of the Pi’s sees me it triggers an arrive scan just in case the other pi’s haven’t started the arrive scan. Either way all 3 pi’s are doing arrive scans on random device advertisements.
My front door triggers the depart scan which is a script that send a depart scan topic about 5 times throughout 5 min. (just in case im held up at the elevator)
if you want to use TD that should honestly work just fine. Also how do you have these sensors in HASS. Are the sensors triggering automation’s per sensor? or do you have them combined in a min_max or bayeson sensor?
First of all how many devices are you tracking? This is going to absolutely matter. if you have more than 3-4 you may notice a delay IMHO.
Also how fast are you needing this to be realistically? is this just for home detection or are you trying to do something per room?
if you have your heart set on using periodic mode (presence) then yes that is the value that you will need to change but you will also need to use
monitor -r
And I dont think @andrewjfreyer has it set up in the way you are wanting. But it does sounds interesting. I think the real issue would only come if a device is Home but another device isnt home. It would do these very aggressive scans and mess with the 2.4 ghz band.
Just tracking one at the moment. Living by myself. It’s for home detection and then turn on my lights when I get home. So sometimes when I get home my apt is already lit up but other times it takes 10-15 seconds to turn my light scene on. So it isn’t slow but just wonder why it sometimes already is lit up and sometimes not. My pi is placed 2 meters from the entrance door. Would placing it next to the door on the wall make it detect faster? Than maybe it would sense me through the door earlier, already in the stairs up to my apt?
That’s true. Didn’t think of that, would be hard to make a perfect rule that sometimes every known_devices should be home and others just one. Not everyones lives alone I guess, haha.
@all - I’ve added a new feature to the beta branch that you might be interested in. I’ve been testing it with great success.
Essentially, monitor will reject all advertisements that are received lower than a specified RSSI. Default is -70dBm, although I might change it. This has reduced a lot of reporting/scanning noise in my house and, as a resulted in faster arrival times.
I think I may actually increase the default, but -70 has been working pretty well so far.
Essentially, this reduces the universe of bluetooth device advertisements that monitor will use to trigger a name scan to those only very close to the bluetooth hardware.
Is the Docker file available?
How did you managed to avoid “service not installed” check at startup? AFAIK there’s no flag for that. I have done my container too, but had to make a small change to monitor.sh script in order to skip service check when running in a container:
I wanted to make PR for that, but now I’m unsure if it makes sense.
Second change I made to the original script is the new switch to specify external config directory. This way you can keep whole script within the container and only config directory is mounted from host.
I have just got mine working in a way that works for me, so won’t mess around with the beta branch for now, but will be interested in seeing how it pan’s out and works, as I have a very congested bluetooth area around me.
No, it wouldn’t. You have to use different base images for arm and x86 architectures. Moreover, it may not work with Raspberry Pi Zero (armv6) if the base image was compiled for Pi3 (armv7) and vice versa.
I just update. So far so good. Im hoping you can take a look at al of the extra scanning when both devices are home. Im also going to compare my bandwidth on this device vs the last update with the manufacturer setting.
my logs AFTER both devices have completed name scanning. it just keep going and going
Oct 23 01:38:22 blue0 bash[12507]: 0.1.680 01:38:22 am [CMD-RAND] 6F:B5:D8:13:FC:2F ADV_NONCONN_IND -68 dBm
Oct 23 01:38:22 blue0 bash[12507]: 0.1.680 01:38:22 am [CMD-INFO] **** Completed arrival scan. ****
Oct 23 01:38:23 blue0 bash[12507]: 0.1.680 01:38:23 am [CMD-RSSI] 4A:B7:89:D3:61:F3 Undiscoverable Device Name RAND RSSI: -68 dBm (Fast Motion Departing, changed -68)
Oct 23 01:38:23 blue0 bash[12507]: 0.1.680 01:38:23 am [CMD-RAND] 4A:B7:89:D3:61:F3 ADV_NONCONN_IND -68 dBm
Oct 23 01:38:24 blue0 bash[12507]: 0.1.680 01:38:24 am [INSTRUCT] mqtt trigger arrive {"identity":"livingroom"}
Oct 23 01:38:25 blue0 bash[12507]: 0.1.680 01:38:25 am [CMD-RSSI] 79:26:05:24:26:04 Undiscoverable Device Name BEAC RSSI: -86 dBm (Fast Motion Departing, changed -86)
Oct 23 01:38:25 blue0 bash[12507]: 0.1.680 01:38:25 am [CMD-RSSI] 60:65:67:9D:BB:6A Undiscoverable Device Name RAND RSSI: -63 dBm (Fast Motion Departing, changed -63)
Oct 23 01:38:26 blue0 bash[12507]: 0.1.680 01:38:26 am [CMD-RAND] 60:65:67:9D:BB:6A ADV_NONCONN_IND -63 dBm
Oct 23 01:38:35 blue0 bash[12507]: 0.1.680 01:38:35 am [CMD-RSSI] 5C:17:16:17:34:7E Undiscoverable Device Name BEAC RSSI: -95 dBm (Fast Motion Departing, changed -95)
Oct 23 01:38:52 blue0 bash[12507]: 0.1.680 01:38:52 am [CMD-RSSI] 74:DA:E4:C6:75:24 Undiscoverable Device Name RAND RSSI: -74 dBm (Fast Motion Departing, changed -74)
Oct 23 01:38:52 blue0 bash[12507]: 0.1.680 01:38:52 am [CMD-RAND] 74:DA:E4:C6:75:24 ADV_IND -74 dBm
Oct 23 01:38:53 blue0 bash[12507]: 0.1.680 01:38:53 am [CMD-RSSI] 51:E8:1D:5E:CB:AF Undiscoverable Device Name RAND RSSI: -72 dBm (Fast Motion Departing, changed -72)
Oct 23 01:38:54 blue0 bash[12507]: 0.1.680 01:38:54 am [CMD-RAND] 51:E8:1D:5E:CB:AF SCAN_RSP -72 dBm
Oct 23 01:39:25 blue0 bash[12507]: 0.1.680 01:39:25 am [CMD-RSSI] 18:E3:06:04:1C:29 Undiscoverable Device Name RAND RSSI: -73 dBm (Fast Motion Departing, changed -73)
Oct 23 01:39:25 blue0 bash[12507]: 0.1.680 01:39:25 am [CMD-RAND] 18:E3:06:04:1C:29 ADV_NONCONN_IND -73 dBm
Oct 23 01:39:30 blue0 bash[12507]: 0.1.680 01:39:30 am [CMD-RSSI] 43:4A:71:CB:8D:A6 Undiscovera
According to the Dockerfile (FROM clause) it will work with Raspberry Pi 2 (armv7) and will not work with Raspberry Pi Zero and older Pies (which also utilize armv6). Not sure whether it is compatible with Raspberry Pi3 (armv8) as I don’t have it.
For x86 another base image is required and, probably, another set of software packages depending on the OS version.
Thank you for getting back to me, it looks like the cache is just fine on both of my Pis. Do you know what line that macvendors code is at? I couldn’t find it to comment it out.
I think I managed to make it working with Nut Mini BLE tracker. My config: known_beacon_address is empty known_static_address does not contain Nut Mini address, but may contain other BT devices, e.g. phone
I run the script with the single key: monitor.sh -g
This is from log file:
0.1.675 12:15:19 AM monitor/dietpi/D0:87:D4:F2:5E:E7
{
retain: false
version : 0.1.675
address : D0:87:D4:F2:5E:E7
confidence : 100
name : Unresponsive Device
timestamp : Wed Oct 24 2018 00:15:18 GMT+0300 (MSK)
manufacturer : Unknown
type : GENERIC_BEACON
rssi : -71
adv_data : 04 3E 0C 02 01 02 01 E7 5E F1 D4 87 D0 00 B9
}```
When I put Nut Mini mac address into known_beacons file or into known_static_address, the confidence is always 0. If I have it empty (see the post above) it works. If any additional actions may help to investigate the problem please let me know.