No, I use the script with default settings. I will run mosquitto_sub ‘#’ during HA restart, see if that will explain this behaviour
I’ve been seeing the same behavior with the default settings. I just cleared all my retained messages in MQTT, and did a restart of both HA and monitor while keeping an eye out on the MQTT topics.
I can see that only the messages in the <mqtt_topicpath>/owner/<mqtt_publisher> topic are being retained. The underlying devices get posted to the topic, but are not retained. I think that is why HA can’t read the values directly after startup.
After doing a pull of the latest version and changing my startup command to bash monitor.sh -u -x I thought it would work, but then it turned out that it wasn’t working yet.
Then, after manually checking the service definition in /etc/systemd/system/monitor.service I noticed that the -x flag wasn’t there. When I manually added it and restarted everything seems to be working now.
1 Like
Hi there,
Has something changed with the messages posted to the MQTT queues? I’m getting in node-red “Unexpected end of JSON input” from the format boxes, and seems that sometimes I’m getting empty strings in the payload, and the transformation to json is failing due to that…
I’m using monitor version=0.1.461 
Cheers
thanks, that did the trick. Thanks!
For some reason, with the implementation of the retain flag “-x”, the script is nulling the topic each time before publishing a new payload.
It’s this that is causing the issue in Node-Red when it sees the (NULL) 1 second before getting the payload.
#CLEAR PREVIOUS RETAINED MESSAGE
if [ "$PREF_SHOULD_RETAIN" == true ]; then
$mosquitto_pub_path -r -n -h "$mqtt_address" -p "$mqtt_port" -u "$mqtt_user" -P "$mqtt_password" -t "$mqtt_topicpath/$1"
should_retain="-r "
retain_flag="true"
sleep 1
fi
#POST TO MQTT
You can fix this for now by editing monitor>support>mqtt and commenting out lines #73 & #76
#CLEAR PREVIOUS RETAINED MESSAGE
# $mosquitto_pub_path -r -n -h "$mqtt_address" -p "$mqtt_port" -u "$mqtt_user" -P "$mqtt_password" -t "$mqtt_topicpath/$1"
# sleep 1
@andrewjfreyer is there a reason to be clearing the topic each time before publishing the payload?
1 Like
It’s a stopgap right now to make sure that retained messages are cleared. Some of the brokers I’ve tested do not overwrite retained messages correctly.
Reminder that this is beta!
Makes sense 
, just wanted to bring it to your attention in case it was an oversight.
@andrewjfreyer Did you see this post on Reddit? We can possibly use Google Home across the house for bluetooth data.
1 Like
It’s perfectly fine, I just report it in case nobody noticed it before 
Cheers!
I had not seen that. Interesting. From my own testing with Bluetooth over the years, though, I can say that the OP is getting very far ahead of him/herself by suggesting meter accuracy and reliable room-level triangulation. Far to much environmental variability.
There’s a good reason that Apple’s iBeacon spec and Google’s Eddystone spec are granular with distance predictions only to “near” “far” “very far” and the like. Distance measurements from RSSI are not consistent or reliable.
Having this access to GH’s hardware is very interesting though.
Indeed…the point is being able to use GH, which many of us have and may not mind investing in, as hardware to obtain the bluetooth information.
1 Like
Hi, Can anyone post their “behaviour_preferences” for ‘presence’ as at the moment this is killing my network?
Cheers to everyone contributing to this & that of course includes you @andrewjfreyer
Looking forward to trying out the motion’ script & was wondering in its present state would it be worth while moving over now from presence or waiting?
TIA
1 Like
Probably worth experimenting now.
Cheers will do. What’s the best settings for motion to run (I’ve been reading various methods -t 1 -t 2 etc.)?
The command line options are different. I’d recommend default settings for now.
Awesome work @andrewjfreyer! I added encryption support to the monitor mqtt file and sent a pull request. Seems to work fine on my end.
1 Like
After a device was identified, a line with topic / payload is printed in the log. On each subsequent lines I have
Error: Invalid port given: 0
Use ‘mosquitto_pub --help’ to see usage.
Only arrive / depart mqtt messages are received by my broker. To me it looks like there is something preventing mosquitto_pub getting called correctly. In publish_cooperative_scan_message() the port argument is not given, but this does not seem to be the cause.
Any ideas ?
Lars
Ok, got it: I did not specify a port number in the mqtt_preferences file. This should be caught at script startup.
The arrive/depart messages do not make use of an explicit port argument which seems also to be an issue (in case you use a port different from 1883).
Lars
1 Like
Added error detection. Thanks for pointing that out.
Incorporated the feature, but without a merge. Wanted to maintain consistency through other parts of the (stupidly massive, now) script. Please let me know if this is suitable for your purpose. Note that the variable name in the mqtt preferences file is different from the pull request.