[Monitor] Reliable, Multi-User, Distributed BT Occupancy/Presence Detection

Tags: #<Tag:0x00007f47fdecd7d0> #<Tag:0x00007f47fdecd5a0>


Cool. Good to know. Will start getting the stuff I need.

p.s. What range do you get out of these things?


to be honest - no idea - didn’t measure it.
Keys are usually ~7m from the bt dongle used for scans. max i used is 10m with 1 wall.


Can you actually program them somehow that they only trigger if they’re really close to the Pi zero?
I mean kind of want to use it for a door unlock within the house.
Range of maybe just 0.5-1m?


In Monitor, Is there a way I can get rssi/distance of iPhones as well in order to use only in very close proximity?


No, iPhones do not broadcast RSSI without connecting to them, which slows down detection for multi-device homes and single-device homes alike.


Agreed the room-assistant might be better for @forums2012, but note that it does not have the ability to detect phones. That’s one of the main reasons I wrote this project in the first place.


@andrewjfreyer Does the beta version work better on pi zeros? I’m having the high load issue, but weird enough only on one of my pis.


Thanks a lot for the info.
Loving it so far.
However kind of trying to figure out what all cool things I can do with it?


@andrewjfreyer, do you see any reason why a combination of Monitor (for phones) and Room Assistant (for ibeacons/BLE beacons) wouldn’t fly ? Even though I’m very happy with Monitor (thanks!) in regards of phones, it’s still giving me quite some headache on beacons.


I can confirm the high load issue in a raspberry pi3 using the beta branch. After 4-5 hours running monitor.sh goes to 100% CPU load consistently:

top - 09:09:15 up 19 days, 17:30,  4 users,  load average: 1.02, 1.14, 1.31
Tasks: 180 total,   2 running, 175 sleeping,   0 stopped,   3 zombie
%Cpu(s): 25.5 us,  0.2 sy,  0.0 ni, 74.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   947732 total,    97336 free,   446472 used,   403924 buff/cache
KiB Swap:   102396 total,        0 free,   102396 used.   412056 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                             
4306 root      20   0    5304   2736   1948 R 100.0  0.3 365:22.43 bash                                                
13871 pi        20   0    8248   3224   2660 R   1.0  0.3   0:00.22 top    

monitor pids:

[email protected]:~ $ ps aux | grep monitor
root      4220  0.0  0.3   7164  3276 pts/3    S+   Nov19   0:00 sudo bash monitor.sh -td -R
root      4224  0.0  0.3   5396  3216 pts/3    S+   Nov19   0:35 bash monitor.sh -td -R
root      4304  0.0  0.2   5032  2176 pts/3    S+   Nov19   0:01 bash monitor.sh -td -R
root      4305  0.0  0.2   5032  2188 pts/3    S+   Nov19   0:07 bash monitor.sh -td -R
root      4306 35.0  0.2   5304  2736 pts/3    R+   Nov19 372:41 bash monitor.sh -td -R
root      4308  0.0  0.2   5032  2252 pts/3    S+   Nov19   0:00 bash monitor.sh -td -R
root      4309  0.0  0.2   5032  2252 pts/3    S+   Nov19   0:01 bash monitor.sh -td -R
root      4317  0.0  0.2   5032  1936 pts/3    S+   Nov19   0:00 bash monitor.sh -td -R
root     14116  0.0  0.1   5032  1688 pts/3    S+   09:16   0:00 bash monitor.sh -td -R

I can’t seem to find anything in the logs that hint to a problem. For instance, started monitor late evening and this morning was 100% again but the logs did’t show anything unusual:

0.1.732 09:45:19 PM [CMD-INFO]  **** Completed departure scan. **** 
0.1.732 11:18:49 PM [CHECK-DEL] PUBL/BEAC  [REDACTED]:67 expired after 109 seconds
0.1.732 11:54:24 PM [CHECK-DEL] PUBL/BEAC  [REDACTED]:4D expired after 108 seconds
0.1.732 03:05:46 AM [CHECK-DEL] PUBL/BEAC  [REDACTED]:46 expired after 96 seconds
0.1.732 08:33:53 AM [INSTRUCT] mqtt trigger arrive

Let me know if I can do anything to help test this further.


So my hack is just to restart it. Not ideal but hopefully it keeps it operational until a fix is available.

$ sudo crontab - e

Add this at the bottom. Restarting every hour might be overkill but I see no harm

55  *   *   *   * systemctl restart monitor.service


Thanks @ryanrdetzel, I will do something similar to my crontab. I was reluctant as I didn’t know what would happen if a restart was done in the middle of an arrival or departure scan…

If you don’t experience much problems I would prefer to add it to crontab rather than having my pi at 100% all the time.


You could have it restart when you think nobody is home or at night. I think worst case though it runs when it boots so it would still detect just a little delayed, if at all.


That sounds awesome. Would this also affect Known iPhones as well?

That way we could essentially decrease the range of a pi zero?


Wow. That has been my intention for using Monitor.
Any tips on making it more secure? As in when using nmap on iphones my phone goes not_home in the middle of night and that’s the reason I am not using that to auto-unlock door.
Secondly, I kind of want to restrict the range of my pi zero, so that it triggers auto unlock only if I am in a very close range to the door, any workaround for this?

Thanks for being so active on this thread!
Love your recommendations!


Hello (again)

Right playing with virtual iBeacons on my phone so it advertises and it actually works very well… how do I do this please? I I get randomly generated MACs using the virtual iBeacon, so cannot add them to known devices. My phone BT address is added

By subscribing to location/first floor/00000000-0000-0000-0000-000000000000-4-12003, presence of the iBeacon can be determined.

where do I do this please? I put in the UUID/major/minor into known beacon addresses and it was ignored.



Yes, but it’s in testing and bugs exist


Run Monitor from the console to find your Beacon addresses if you don’t know them


thanks… I did that using -b-g but it just shows the random mac.


I think the simplest way would be to remove the i personally would change my automation structure. Are you basing these unlock/lock automations off a Not_Home/Home trigger and/or the confidence level of Bt sensors?