Off-topic but
There's no absolutes in life 
but I'd wager a whole Ā£5 that any proper mqtt client/broker would only push a non-retained QOS0 message out once.
That isn't the issue here, as I understand it. The issue is that if the connection is broken for a short time (but not long enough for the mqtt to disconnect) then the mqtt node buffers messages sent to it (or at least may do, I haven't tested it with QoS 0) and sends the data when the network reconnects. So that the message arrives late.
...........
@Siothrun I have just re-read the thread, I had missed the bit about hivemq timing out immediately, but mosquitto not timing out for 20 minutes. That is very strange. Can you explain a bit more about how the device is connected to the internet, and how it is connected to the machine running mosquitto?
You may well be onto something there. What happens if (on the device) you run a ping to the mosquitto server and leave it running while you take the sim card out. Also does the device have a network connected display of some sort? If so then how does it behave?
The Node-RED device is the MTX-GTW II-S AUS, which has a Debian GNU/Linux OS. It is connected to the internet via a SIM card.
The Mosquitto broker is running on a VM in Azure.
Are you particular about where the ping is originating from? Node-RED? OS?
I have had a ping running to Google's DNS server (8.8.8.8) from both Node-RED and the OS while removing the SIM card whilst conducting these tests.
I haven't tested this while pinging the Mosquitto broker, but given I can't reach Google's DNS server I wouldn't expect different results. Unless you suspect a mechanism that escapes me?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
