Yes, I can add an option for topic aliases. This would probably help a number of users. Good idea!
This is already an option! I suggest that you use the -t flag with your ‘remote’ pi nodes. This means that these notes will only scan when they are triggered via mqtt to scan. For example, in my house I have three nodes. A “main” node on the first floor, and two “triggered” nodes on the second and third. There is no scanning on the second/third floor unless and until the “main” node determines that one of our phones/beacons has left.
These are important errors, and I’d be very surprised monitor worked after logging these errors. First, make sure to update the script. Second, make sure that the /support directory created during the git pull operation is actually present.
I have a NOOB question:
how do really trigger the scan for the -t option?
I have three pies and like you @andrewjfreyer One covers all the doors and each have sensors that already communicates with my mqtt server on HA.
Now i have to send the mqtt [topic_path]/scan/depart to the pie running the monitor, to trigger the scan, however i only have HA mqtt, and this should be done on the pie running the monitor, so i’m not sure how to do this part
Can anyone advise if this is a normal scan pattern for an iPhone vs an iTag? I’m worried that my MQTT server (on HASS) might be getting spammed. If it’s normal, that’s fine…
Yes, this is normal since the presence of phones is affirmatively determined by scanning but the presence of beacons is inferred based on the last time that a beacon advertised its presence. I’m working on a few techniques to smooth out the beacon confidence reporting, but in the interim you can try changing preference is to include longer delays.
So Far I have no node on the -t option since i didn’t knew how to make them work.
So my “main” pi that report to [topic_path]/sala/mac will report in something that my other pies ([topic_path]/quarto/mac and [topic_path]/garagem/mac) will understand that shell start monitoring?
The -t flag causes the monitor script to only respond to trigger messages. The script, by default, will respond to mqtt messages posted to that topic.
Note, that the “[topic path]” string in the example and documentation is merely a placeholder reference for the mqtt_topicpath variable you have defined in your mqtt_preferences file. So, if you are using default settings and you want to trigger a scan at your notes, the topic path would be: monitor/scan/arrive or monitor/scan/depart
By default, all of your nodes will respond to either of those messages. If you do not want a node to respond to a particular message, include that node’s mqtt_publisher_identity in the message. So, with default settings, omitting the “first floor” node from the scan, the topic path would be: monitor/scan/arrive or monitor/scan/depart and the message would be {"data" : "first floor"}. Sending this message will cause only the “second floor” and the “third floor” to scan; the first floor will ignore the message.
Note the more detailed description of monitor here.
Does anyone know what setting to use for the iTags? Are they beacons or ibeacons? At one point (before I did the Git Pull to add the missing support directory, bizarrely!) Monitor was really responsive to the iTags but now (I’m using -g and the latest version of monitor, with the MAC addresses in the known_beacons file) it’s taking sort of 3-8 minutes for any changes to be noticed and the granular tracking every minute seems to have gone. Monitor still super quick for our iPhones. Thanks
EDIT: Should point out that doing an depart/arrive MQTT publish dramatically helps…
OK, I’ll try removing them from the known_beacons file - I’m hoping doing so will speed up their recognition - my iPhone is detected within what seems like milliseconds but the iTag seems to take about five minutes before its recognised. Thanks, Andrew, for your patience with this noob!
@andrewjfreyer Just a question on your node flow - probably a dumb one most of this is new to me.
" On the other hand, if the input boolean is false, I set the input boolean to false only if an exterior door on the main floor (including the garage lift) has been opened or closed in the last 10 minutes. This is a final check against false exit events."
How are you updating the boolean for last ten minutes - i can set it based on the state change of door sensor but I couldn’t figure out the best way to update it so it isn’t always on.
monitor -e report bluetooth environment periodically via mqtt at topic:
[topic path]/environment
If so it would be really helpful if you could share that part of your config if you have a mo so I can wrap my head around how it would help. I’m restarting my instance of HASS pretty often at the moment and I’m finding that obviously when HASS restarts it doesn’t know the presence status of my tracked devices and it takes a state change to correct itself. Rebooting the Pi Zero W is a bit of a blunt tool and doesn’t provide a speedy update, either. Thinking this might help. Thanks!
I suggest that you use the 
to the link.
