Cumulus Support

A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for that topic.
Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic. (As explained by: https://www.hivemq.com/blog/mqtt-essent ... -messages/)

Retained messages help newly-subscribed clients get a status update immediately after they subscribe to a topic. The retained message eliminates the wait for the publishing clients to send the next update.

I made a small pull request on GitHub that works well for me: (It solves some "problems" of developing an application based on MQTT subscription)

https://github.com/cumulusmx/CumulusMX/pull/86


Davide

I deliberately did not set the retained flag, I thought it better to have to wait a short while for an update, rather than possibly get data that is stale - possibly by a long time.

But MQTT is pretty new code and there is scope for change/improvement. One possibility is to add retained as an optional configuration item.

I agree. Surely it could be implemented with a checkbox.

It depends on the type of application in which MQTT is used. In my case, using MQTT in a * application turns out to be convenient to have last available data immediately showed to client and eventually check the time of the last data received throught a script.

This feature will be available in v3.9.0 of Cumulus MX.