[monitor] Reliable, Multi-User, Distributed Bluetooth Occupancy/Presence Detection

Is there any way to get monitor to output the MAC’s that aren’t in the known_devices list that it sees more than once? I seem to have a lot of random bluetooth devices triggering arrival scans and it seems to be throwing things off. I’m not sure if its just all of the random devices I have in my house or its picking up some neighbors phones/devices too.

1 Like

can the scan start/end topics be changed a bit? - I think having it be generic (location/scan {"status":"start"}) with a payload to indicate the status fits better into many use cases, particularly HA where you may want to easily setup a mqtt binary sensor to indicate the state of the scan(s)

1 Like

Try the environment reporting with the -e option.

Yes, harmonizing MQTT topics with standards is definitely on my list. But… it’s a pretty major breaking change for a lot of people, so I’ve been putting it off.

Does anyone know of a pi zero outlet mount? Meaning something like this: https://mountgenie.com/products/the-google-home-mini-back-pack

2 Likes

I used a command strip to attach each directly to the power brick. Probably adds wild interference, but whatever.

@andrewjfreyer Yup it looks like you understood exactly why I stop the service. I think your solution will be better since I wont have to wait for the monitor service to boot back up after the door opens. With your fix it should save me a few seconds on depart. If I am reading your solution correctly than this would essentially allow me to turn off my phone once it has arrived even if both devices are not home.

My only worry is if I leave, how long will it do the depart scan for? My elevator is relatively close to my front door. I would still want it to scan for a couple minutes just to make sure that I have truly left the house.

thanks for this BTW, I didnt want to ask because you are already doing a bunch of work on the project and I didnt know how many people actually let there phones die when they are at home.

@Odianosen25 I am not 100 percent worried about the security part of things, it was more of an annoyance. In my actual Door lock settings (August Lock) I have it set to lock immediately when the door closes (about 3 seconds). So my front door is essentially always locked. I am only stopping the service when all devices are home for 4 minutes. If my devices are both home and my door hasn’t opened there is no longer a need for monitor to worry about anything until my door actually opens again (since both devices are already home).
currently if I don’t stop the service my phone will turn on after recovering from off/dead and monitor would sense that I am home an open my door. (the august lock will auto re-lock if the door hasnt been open for 1 minute)

2 Likes

First i’m really sorry for insisting on something that people have answered so many times but my ignorant head stidd doesn’t get it:

So I, like some others, must have more then one instance of monitor running, but I know for a fact that If I haven’t connect to a specific one I’m not at home this is where -t option enters:

  monitor -t[adr] scan for known devices only on mqtt trigger messages:
        a \$mqtt_topicpath/scan/ARRIVE (defined in MQTT preferences file)
        d \$mqtt_topicpath/scan/DEPART (defined in MQTT preferences file)
        r send ARRIVE or DEPART messages to trigger other devices to scan 

This is perfect “stop everything” until I say i need your help.
Just for the sake of making this as clear as water (monitor+mqq for dummys (like ME) )
HA: 192.168.1.1
front door: 192.168.1.2 (topic: /door/00:00:00:00:00:00 )
bed room: HA: 192.168.1.3 (topic: /room/00:00:00:00:00:00 )

Now the problematic part for someone like me (maybe even just me)
I use HA so my mqtt server is on my HA server, which means I have credentials setup on my mqtt_preference file for my HA server (HA: 192.168.1.1)

Now for me to get this option to work I need to send/publish messages to the topics
/room/00:00:00:00:00:00 which on my exemple is on server 192.168.1.3

I have mosquitto running:
pi@monitor_quarto:~ $ mosquitto
1537520034: mosquitto version 1.5 starting
1537520034: Using default config.
1537520034: Opening ipv4 listen socket on port 1883.
1537520034: Error: Address already in use

This gives me nothing
pi@monitor_quarto:~ $ mosquitto_sub -t /#

This all seam correct since I publish to my HA server and noting is “local” to each monitor pie, so How can I publish in a way to get the -t option working?

can i publish on a “automation” frm the HA to the HA mqtt server? This means that both monitors are subscribed to the topic on my mqtt server (if so this is the missing link, that i wasn’t able to undesrtand).

So I ask again, based on the exemple I gave, how can I trigger an arrive/departure scan on any of the pie’s running the monitor since both publish to a remote mqtt server (my HA pie)

Thank you and once more sorry for the “insisting” on the “basic” topic for many of you but i can’t get this to work.

Honestly if you look at @andrewjfreyer commits he seems to be changing a lot of code in the last several hours.

Just my personal opinion. The -t option is good but BY DEFAULT you can already do manual triggers anyways. -t just makes it where it is required that you do a manual depart and a manual arrive trigger.

if you know your MQTT decently you need to get a broker on a different terminal windows or on a different computer and subscribe to your current MQTT server for “#”.

Now put the Pi’s in the default mode without any parameters. After you reboot the Pi’s you should see what type of messages are posted. Once you have the device detected turn on the bluetooth on your device/phone and see what depart message is sent on the computer that you have subscribed to # from the mqtt broker.

This will essentially give you the correct format for how to publish the triggers manually. By default if 1 Pi puts the confidence to 0 it will sent a depart trigger and vice versa when a Pi puts the device at 100 percent confidence.

short answer: Subscribe to your Mqtt server with # and read the messages that the Pi’s are ending in depart mode. This will tell you what arrive/ depart signal the Pi’s are listening to. Once you have these messages if you desire to ONLY scan for depart and arrive on trigger than you can put the pi’s back in -t mode and use the messages that you just saw when subscribed to #.

1 Like

Hopefully one of the last questions I’ll be asking here…(as things are working really well for me now).

If you’re using multiple Pi Zeros, and the idea is that if one Pi can’t “see” your bluetooth entity it then (and only then) triggers a scan on the other Zeros…can those Zeros also be used for arrival scans? Basically I have two possible routes of entry into my house and I’d like it possible that all of my Zeros are actively scanning for arrivals. Is this do-able? :slight_smile: :slight_smile:

1 Like

I think this is something that is still being implemented. In previous versions it would send the depart to the Other pi’s and they would ignore the arrival scans until the depart scan was completed. Essentially it would reject the arrive scan.

It looks like in version [0.1.629] he may have changed this behavior where it doesn’t actually reject the arrival scan it just queues it up. Don’t quote me but this either was just recently added or it is something he is still working on.

1 Like

ah - thanks - so at the moment only one Pi Zero can detect arrivals, but they can all detect departures?

1 Like

Well I have tried,

I have updated the monitor to the latest version [v. 0.1.635] created all new required properties:

preference: beacon rssi change required for reporting = 10
preference: bluetooth environmental report frequency = 300
preference: forced departure check interval = 240
preference: interval until beacon is considered expired = 145
preference: trigger a departure scan at other nodes below confidence = 25
preference: preferred HCI device = hci0
preference: minimum time between the same type of scan = 15

I got the topic:

0.1.635 02:54:24 pm [CMD-SCAN] (No. 1) 5C:1D:D9:19:AB:00 departure?
0.1.635 02:54:25 pm location/monitor/quarto/5C:1D:D9:19:AB:00
{
retain: false
version : 0.1.635
confidence : 100
name : JPM
timestamp : Fri Sep 21 2018 14:54:25 GMT+0100 (WEST)
manufacturer : Apple, Inc.
type : KNOWN_MAC
}

tried from another machine publishing to the topic:
location/monitor/quarto/00:CD:FE:C9:AB:00/scan/ARRIVE (no message)
and
location/monitor/quarto/00:CD:FE:C9:AB:00 message: /scan/ARRIVE

on the server that is running the monitor and nothing.

I give up, i’ve just added an sonoff pow with the trigger of my door sensor and voila, I keep getting my 2.4Ghz channels “underwater” but hey this is still by far the best location monitor for what i need.

Thank you @andrewjfreyer for all your personel time you have dedicated to us, and thank you @benjimatt for the help :slight_smile:

I found a bug and updated this morning. That may solve your issue. But, again, your MQTT topics are incorrect. Try subscribing to # and see exactly what is being received by a broker

@jpm I’ve also updated this morning to output the exact MQTT topic path you should subscribe to for all your known devices.

As far as the scan/arrive messages, your topics are not correct. The entire topic should be just:
location/monitor/scan/arrive

or

location/monitor/scan/depart

(NOTE: please verify in your mqtt_preferences file that your mqtt_topicpath is actually “location/monitor”, your logs above show a non-default topic path)

These scan messages indicate to all nodes connected to your broker that they should scan.

this are correct since I seperated the pies according to the topic:

PUBLISHER IDENTITY

mqtt_publisher_identity=‘division where i put the pie’

MQTT PUBLISH TOPIC ROOT

mqtt_topicpath=location/monitor

Thinking about it…if you ran two Pi Zeros, but didn’t have them operating master/slave…couldn’t you achieve the same aim? I think if you had a Pi Zero in the house tracking arrives/departs and one at the end of the garden watching out for arrivals only…that would work.
Basically in your HA automations you could simply not program any action for departure scans received from that particular Pi. Does that make sense?

EDIT: The more I think about this, the more I think this is the answer. Don’t “link” the Pis, just have BOTH setting arrival in HA, but only ONE of 'em setting depart.

So, if you’re running monitor with default settings, and you publish to the topic “location/monitor/scan/depart” your node should trigger a scan for your known devices.

What happens instead?

First i’m sorry but I’m assuming you are on USA or another GMT+xx hours so we have “opposite” schedules:

I have published to location/monitor/quarto/scan/depart and i think i saw something:
TIME
TIME
MQTTlocation/monitor/scan/depart (null)

Just as a side note, this version is causing a lot more “noise” on my wifi, as soon as i power up the device I immediately see package’s dropping on connection to a point I really need to get this “on trigger” to function or i can use it, but I recommend more feedback because i leave on a building and maybe some neighbor connected something and is causing this interference

Another note I think that time worked but any subsequent trials didn’t either depart or arrive, this last didn’t work ever.
Is this what I’m suppose to see?

1 Like

how many devices are you trying to monitor? Are you worried that one device will be leaving and a depart scan start while another device is returning home?

1 Like