In a Daq project ,I use mqtt to sending some data to broker. If sent failed, the data was to be stored locally. The question is how to detect the data was sent to mqtt is failed?(individual)I must make sure that every data is sent to mqtt broker. I have to get individual sending data status.
If you set the QoS to 1 or more and clear the Clean Session checkbox in the mqtt out node then the mqtt node will queue up messages until it can send them provided you don't restart node red.
Edit It appears I was wrong about this, that is what should happen but there is an issue with MQTT nodes so messages can be lost. The issue should be fixed in node-red v1.3 for which the beta is due within days. See MQTT-Node: Messages are lost on connection problems, despite QOS-Level 1 · Issue #2864 · node-red/node-red · GitHub
If you cannot wait for this then come back as I do know how to solve the problem, but I will have to build a flow to implement it, which is not worth it if you can wait for 1.3
The issue you link to is not planned for the 1.3 release. It is too big a change to get done and we don't want to delay 1.3 even further. Given the behaviour is not a regression - its how it has always worked, then we'll have to consider it for the following release.
Yes, so I see, I saw the earler post there which had suggested it could get included in 1.3 and then misinterpreted the later one saying that it had been added to the todo list as meaning the todo list for 1.3, which isn't what it says.
I had better sort out a flow to work around the problem in the short term then.
@Colin, please change your 3.1 in your posts to 1.3 to avoid any trouble.
Or - leave it as 3.1 maybe the correct timeframe 
3 Likes
Oops, fixed. I must have been thinking of Windows.
That dates me doesn't it.
I spent a couple of hours building a complex flow to guarantee delivery and then realised that there is a much simpler solution:
- Install mosquitto on the node red machine and publish to that rather than the remote one, with QoS 1 or more.
- Configure the local mosquitto to bridge the relevant topics across to the remote MQTT broker, again with a QoS 1 or more.
- There is no step three. Job done.
Now mosquitto will handle everything for you and will buffer messages in the local broker if connection to the remote broker fails. If necessary configure max_queued_messages and/or max_queued_bytes in the local mosquitto conf file. The former sets the maximum number of messages that will be queued and defaults to 1000, the latter sets the max number of bytes that will be queued and defaults to no limit. Once either of those limits is hit, subsequent messages are silently dropped. Provided mosquitto has persistence enabled (which is generally the default I think, but not sure) then if mosquitto (or the system) is shutdown then it will save queued messages to disc and will send them after a restart.
For details of how to configure bridging see Mosquitto MQTT Bridge-Usage and Configuration
1 Like
thanks very much.I found a solution yesterday that I could use the node '' check mqtt conn" to store data if the node found the link was down or mqtt broker cound reach.
This is my solution .
Have you implemented the queuing logic in node red? Depending on how important it is that you never miss one that might be good enough. It is very difficult to make sure you have caught all the edge cases as the network goes down.
I found another solution that I establish a mqtt sub. And subscribe the topic .use the sub to Gurantee the message.But this could cause Network delay .
That is the route I took but it is very difficult to avoid race conditions. For example, suppose the network is ok at the moment you decide whether to post a message to the mqtt node but the network fails before the message is sent? The only way around this, I think, is to add a unique id to each message and track it out and back, which lets you know that message got through. That gets complex to implement and there are many traps for the unwary. This is exactly what the mqtt protocol does internally when you use QoS 1 or 2.
Why bother re-implementing that yourself? The solution I posted using MQTT Bridging takes 10 minutes to setup and you can be sure that it will work.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
