thanks, i updated and now have -V available, still nothing from /echo though
I also just recently installed this, and can get no responses when posting to monitor.
It has to be something with the versions we are running I bet.
#enter monitor directory
cd monitor/
#(optional) switch to beta branch for latest updates and features (may be unstable)
git checkout beta
And your point is?
Are you suggesting people switch to beta?
Are you suggesting beta wont help them?
I donât know. I am just curious. You seem to think it will. An explanation would assist my understanding, and others too no doubt.
The only difference between master (ie 0.2.197) and beta does indeed relate to echo. https://github.com/andrewjfreyer/monitor/commit/36a05b38656279dfdfdbb8ca7efd381bbca2fd26
Whether it solves the problem that is described above I do not know.
Didnât seem to make a difference.
It is like monitor.sh is not listening to the topic.
It is sending updates correctly at least.
The easiest test I keep trying is the "monitor/setup/00:11:22:33:44:55 test with no success
It definitely is, check -h for help and youâll see it there. More likely something went wrong with your syntax.
@trevor1 are you able to post other messages? Restart, arrive, etc. Nothing works for me. And since adding a second monitor node, Iâm experiencing a lot more offline statuses
Nope I have tried all variations, and Monitor.sh doesnât seem to be listening. I am using MQTT Explorer just to check if my posts are being picked up by the broker. Which they are. But no response from monitor.sh of any kind. Not sure what the issue is. I think I am moving on to a different solution.
Yea, I installed it on my RP Z W and mosquitto 1.67 failed but found some things about rolling it back to 1.64 and mqtt works. I have the server connected but I am not getting any responses. I am not sure what the deal is. I will have to keep playing with it.
What other solutions are you considering?
Sorry for the multiple messages here guys. I have spent a good 6 hours on this. So far, I have sudo bash monitor.sh -b -V showing arrival scans and showing the 2 devices that are known. It has confirmed my phone with 100% which is good. I have my server setup on my hassio and it works fine. I tested sending messages from 2 phones and it works to receiving them. I downloaded mqtt explorer and saw messages from $SYS thinking that was monitor, turns out I donât think is after manually sending messages from my phones. This leads me to believe monitor is not sending messages. I checked the mqtt preferences file and I changed passwords etc., but when I run monitor.sh it doesnât connect. So I do believe it is connecting properly when I enter the right mqtt information. So I am left to thinking monitor is not sending the messages. Any other things I can do to debug this?
Thanks!
Joshua
Paragraphs, and formatting, are good 
It should be quite clear if itâs connecting to your broker. Is it? If it is itâll both say so in the log, and itâll be publishing messages to topics under monitor/$mqtt_publisher_identity - replacing $mqtt_publisher_identity with whatever you defined in mqtt_preferences.
Check that before going any further. You can test by subscribing to monitor/# in your MQTT client and restarting monitor
I figured it out. I had a username with a password that had !@ and it wasnât accepting that. I tried manually sending a message thru mosquitto_pub and it was erroring on that password.
It is working well now! super excited. I may have to get a second pi zero though, it may not reach the length of the house. Any ideas about a long-range BT dongle maybe?
I would definitely consider letting people know that passwords with !@ like stuff wonât work. Can save some headaches! Lol
I would say that earlier when watching the script run from ssh it looked like it was running the departure scans. Now it doesnât look to be running them. Does it only run them when it thinks someone left based on the arrival scan change?
Would it be possible to use monitor-watcher.sh on a docker/monitor container? Im only getting about 4-6 hours before the container seems to freeze.
You just drop this in configuration.yaml?