If you are running via command line, restarting the service will stop stdout and stderr for a manually started session.
i have this for my HA automation:
- id: āpi11ā
alias: Update MQTT sensors on startup
initial_state: āonā
trigger:- platform: homeassistant
event: start
action: - service: mqtt.publish
data:
topic: monitor/scan/restart
- platform: homeassistant
1 Like
whenever i reboot ha - my sensors say unknown
also when running -tad i am noticing that i dont see an initial scan when viewing the ssh lines - it seems to just pause and not do anything. Just started recently
Just says begin logging and nothing after when I run - tad again this is recent on both my PIās I am up to date using master
If you dont want it to say unknown you need to retain your Mqtt topics and possibly turn off availability topics (if you have them on), also are you meaning to use -tad ? I hope you realize that you will only scan arrival AND departs on triggers. was this your intention??
I use sudo bash monitor.sh -u -d -tdr -x
which means update the monitor service config, use reset to default values, depart on trigger only and each node with report when its doing an arrive or depart scan, and retain topics to the Mqtt server.
I use - tad and have it triggering on my front door with logic built in to check or conf level. So if it sees I am at 100 it will call the depart script. I will try - x for retain and see if that does anything. But this used to be ok until I updatedā¦ Now if I run - tad the script does not move or run an initial scan when viewing in console. Itās as if itās hung. I rebooted 100 times and same thing on both pies.
I have 2 pies with different identity topics. Main pi and secondpi and both have the same topic of monitor. How should the mqtt file look like with multiple pis?
just sits here now:
pi@raspberrypi:~/monitor $ sudo bash monitor.sh -tad
====================== DEBUG ======================
starting monitor.sh (v. 0.2.016)ā¦
removing public name cache
trigger mode: scan only (both on arrive and depart) on trigger
preference: using default mqtt protocol version
preference: minimum time between the same type of scan = 15
preference: regex filter for flags to accept = .*
preference: regex filter for flags to reject = NONE
preference: regex filter for manufacturers to accept = .*
preference: regex filter for manufacturers to reject = NONE
preference: maximum sequential arrive scan attempts = 1
preference: maximum sequential depart scan attempts = 2
preference: selected HCI device = hci0
mqtt trigger: monitor/scan/ARRIVE
mqtt trigger: monitor/scan/DEPART
90:97:F3:B1:F7:A7 publishes to: monitor/pimain/90:97:F3:B1:F7:A7 (has not previously connected to hci0)
98:CA:33:83:AC:43 publishes to: monitor/pimain/98:CA:33:83:AC:43 (has not previously connected to hci0)
================== BEGIN LOGGING ==================
Main issue seems to be on HA reboot - sensor values go to unknoiwn. I trued -x as well and did not work and i also tried the automation:
- id: āpi11ā
alias: Update MQTT sensors on startup
initial_state: āonā
trigger:- platform: homeassistant
event: start
action: - service: mqtt.publish
data:
topic: monitor/scan/restart
- platform: homeassistant
which does not work as well
Update the service file from where monitor is executed with the correct parameters:
sudo bash monitor.sh -u -tad -x
Restart the service:
sudo systemctl restart monitor
Check the logs to see if itās running with the correct parameters:
sudo journalctl -fu monitor
Or alternative you can check the status of the services which also provides the current parameters
sudo systemctl status monitor
You should see something like
āā336 /bin/bash /home/pi/monitor/monitor.sh -tad -x &
Hope this helps
4 Likes
if you are using -tdr what do you run on your other piās? Since the r is telling the other piās to run checks as well.
would this make sense?
pi1 = -tdr
pi2 = -tad
1 Like
Yes, thatās what I use. one āarrivalā detector node, and other āverificationā nodes
Thanks! If you donāt mind may I see your node red triggers and how you call the script?
Also, how instant is your arrival when you get home? Right now I am doing tad on both PIās. And when the front door closes it checks our conf level and if it sees 0 it will call arrival for instant arrival.
If I do TDR on main pi. Will it keep scanning for arrival on known macs until they get home and then stop?
Iām worried that when I leave the house it calls trigger based on my door and departs me. But letās say Iām on my driveway for a bit like 5 mins and the arrival gets me back in. How will it depart me again of we donāt use the door trigger?
What if it departs you and your just within range and arrival grabs you again while you are waiting. And at the same time the depart times have run out. What would happen in that case? You would still be checked in as home but really not. What would you suggest?
Is donāt think there is currently any option to set PREF_BEACON_EXPIRATION either on a per beacon basis, or group beacons into groups to have different expirations?
Would this be something you could consider?
As a real life example, there are beacons on both cars which as they are outsider even when they are stationary they lose their confidence a lot more than the same beacon used to track things inside
Ideally Iād be able to set the beacons outside to have a longer expiry time, so that I donāt get false results, but without effecting the expiry time of the devices I track inside
I donāt fully understand the technology either, but I assume a different use for this method would be if people owned different brands of beacons they could send advertisements at different frequencies to each other, so being able to group the same type beacons together and set an expiry time in a group basis, could help.
Just a thought.
Youād need to configure it to your needs. In this case he has observed that he doesnāt stay more than 360 seconds outside of his door. If you would, then set a depart scan at a time it suits your habits.
1 Like
Yes, Iāve considered this structure. Thinking on the best architecture.
1 Like
Personally both of mine are -tdr. My goal is to be detected as soon as possible. So whichever device sees me first end up telling the other to scan.
Hi @andrewjfreyer , my topics are
first pi
monitor/name_of_first_pi/mac_alias
second pi
monitor/name_of_second_pi/mac_alias
third pi
monitor/name_of_third_pi/mac_alias
they all connect to a mqtt server on another host
When I want to trigger ARRIVE or DEPART scan, which is the mqtt message that I have to publish?
1 Like
Is anyone using monitor as room detection? How would you do if you have three+ sensors, in order say in which floor is John, it should be calculated which of the 3+ sensor has the highest rssi number
sensor:
- platform: mqtt
state_topic: 'monitor/first_floor/john_phone/rssi'
name: 'John first floor RSSI raw'
- platform: mqtt
state_topic: 'monitor/second_floor/john_phone/rssi'
name: 'John second floor RSSI raw'
- platform: mqtt
state_topic: 'monitor/third_floor/john_phone/rssi'
name: 'John third floor RSSI raw'
The below gives always Error
- platform: template
sensors:
lowest_rssi:
friendly_name: Lowest Rssi
value_template: >
{% set sensors = [ 'sensor.john_first_floor_rssi_raw', 'sensor.john_second_floor_rssi_raw', 'sensor.john_third_floor_rssi_raw' ] %}
{% set min = states('sensor.min') %}
{% set selection = states.sensor | selectattr('entity_id', 'in', sensors) | selectattr('state', 'eq', min) | map(attribute='name') | list %}
{% if selection | length > 0 %}
{{ selection[0] }}
{% else %}
Error
{% endif %}
1 Like
monitor/scan/arrive will trigger a scan everywhere.
monitor/scan/depart will trigger a scan everywhere.
If you want to exclude nodes from scanning, include their name in a message:
Topic: monitor/scan/arrive
Message: name_of_second_pi
Will scan everywhere except for at name_of_second_pi
1 Like
Whatās the error?