question

Can anybody answer this? I'm also interested.

It is an old topic but if you have exactly the same question then.... do not trust MQTT-Explorer. It always shows QoS-0. It seems that MQTT explorer is not maintained anymore so don't expect this to be fixed.

Your client should "ask" for a QoS level. The broker can/should honor this request unless the max_qos_level is set. If you have a really crappy network connection you might consider a higher QoS level but in 99% of the cases level 0 should be fine. QoS-1 or 2 do have some advantages but there are also plenty of disadvantages.

If you really, really want a reliable connection then you could add a real queueing mechanism like RabbitMQ. It will need some platform to run on though.

Be aware of adding complexity is not always the best answer to the problem. Since you have not told us I do not know what wat problem you want to to solve.

Thanks @Gerard van Seventer . It wasn't until now that I have noticed your response here, so excuse me for not replying earlier.

I want to achieve that I collect some of the VenusOS MQTT data into my own time series database. that's hosted in the cloud So, I want to subscribe to topics I'm interested in and process the data in my own environment. When the connection breaks I want to seamlessly reconnect and get all the messages that occurred in the meantime.

It's not related to MQTT Explorer that I only see QoS 0 messages, it also happens with other tools I tried. Only the sender can set the QoS level, not the receiver.

What I see is this: even if I use a different tool (e.g. MQTT.fx) and set my QoS level to 1, the receiver gets the message with QoS set to 0. I'm not sure if this is intended behavior of VenusOS and if I can change it, or if it's something I missed.

When a connection breaks for how long is it broken? Seconds, minutes or even hours? Setting the QoS level will not solve this issue. A MQTT broker can, when enabled, queue some messages but not for a long time.

I also have a timeseries db (InfluxDB) on a (private)cloud instance with Grafana on top of it. As an interface between the MQTT broker on the GX I use node-red to subscribe to some topics of interest and write them to Influx. I have a stable internet connection but if you do not, it is not too difficult to add a queue to node-red either by using a queue node or creating one yourself.

So, If I understand your problem well, I would not go for the QoS route for your problem.

@Gerard van Seventer

Thanks for your assessment. I have a very similar plan which I described here in detail: https://community.victronenergy.com/questions/258370/ask-for-review-seamless-ess-time-series-data-colle.html

If I understand you correctly, you directly connect to InfluxDB from Node-RED, probably with a REST call?

The connection between the GX and the internet (= MQTT broker) could break for several days (or worst case weeks). The connection between the cloud and the MQTT broker can break for hours, or a few days.