Elegant way in a flow to determine if the MQTT broker is still disconnected, connecting or finally connected? I have a rather busy NR instance, and on NR start up, or full deploy, the MQTT nodes are taking a few seconds to connect, update status. Unfortunately other flows maybe set to start automatically, and thus get tripped up because the MQTT nodes are still awaking up, if you, will. Would like to design into the flow its-self, some type of logic where the flows that get 'ahead' of MQTT nodes, wait until the MQTT nodes are 100% ready? This is not just a case of lost messages, but that the MQTT nodes are just not ready to process any messages.
Why not have the flows wait on the "birth" messages from the relevant brokers? They can monitor the "close" message for normal disconnects and the "will" message for unexpected disconnects.
Or you could use a Status node linked to an MQTT node to tell you what the current status is.
Alternatively this post shows a flow for guaranteed delivery via MQTT. It will queue mqtt messages until they get sent successfully. If necessary you can use persistent context to even queue them over a node-red restart. It only guarantees delivery to the MQTT broker though, it does not guarantee that a client successfully receives them from the broker.
1 Like
Yeah for now I am using the status node method. However, you have provided some interesting ideas.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
