I'm using the Node-Red Add-On on Home Assistant to poll and send via mqtt (to a remote mqtt broker) various sensor data. Now, if the internet goes down for whatever reason, the connection between the remote mqtt broker and node red will break. Once they're connected again (ie. internet is up), the mqtt out node will continue sending live data and I would have missed out on data that it tried sending when the internet was down. Is there any way to avoid this sort of data loss? Can the mqtt out node save the data someplace when mqtt disconnects and then resend the same once connection is established? Is there any in-built setting that allows this?
Thanks - I'm actually struggling with that. I imported the MQTT example and tried following instructions, it's repeatedly sending the same payload over and over again - not sure what I might be doing wrong.
In your mqtt node remove flow1/temperature from the Topic field.
You might want to give this node a meaningful Name because without the Topic filled in it will just be labelled mqtt out.
Connect a Debug node to the output of the function, set to display the complete message object.
This will let you check that msg.topic is right, and if Home Assistant and the function are repeatedly sending the same data.
Thanks and big thank you to you @Colin for creating this.
I went through the node's description page really carefully this time and figured out a much simpler alternative for my particular use case, where I don't have to specify the topic in the message:
The "MQTT Complete Check" (linked to "Send to MQTT") simply passes the JSON to the "Send OK if Send Complete" change node (if the delivery was successful) which in turn passes an "OK" to the Guaranteed Delivery node. If it doesn't pass an OK within fail timeout, the Guaranteed Delivery node assumes the MQTT payload failed to send and queues it. This node is super handy.
The context store I'm using is "default", which in Home Assistant, I believe, won't persist after a restart, unfortunately. Once "offline" data is sent, will it auto delete from memory? Or will it stay?
Your simplified approach does not account for the fact that the MQTT node can queue messages itself. In particular it may queue repeated requested attempts of the same message while the connection is down. Other times it will discard messages when the connection is down. This means that when Complete is triggered you have no way of knowing which message has been sent, so messages will, under some circumstances, get lost. Believe me, if you want to guarantee that every message is sent at least once, and in the correct order, then you need the full example flow.
You can configure a file based context store in node red, then they will persist over a restart.
I thought this applies only if the MQTT node is doing qos1 or qos2 - not on qos0. I tested the flow on qos0 by randomly simulating disconnections and it worked alright. In fact, I'm not sure if there's even any need to use qos1 or 2 when guaranteed delivery is involved.
One would have to examine the code of the node to work that out. I doubt whether that distiction is made. QOS 0 implies that it may only send it to the broker once and then forget it. It does not mean that if the broker is not available then it should not hold on to it and try when the broker is available again.
I did many automated tests over many hours with variable message rates and varying disconnection periods and to make it 100% reliable I had to use the technique shown. If it really matters to you that every message is sent to the broker then why are you worried about a few extra nodes? What are you gaining by using a simplified flow?
