Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.16.1 (build 3183) - 06 May 2022

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

If you are interested in supporting Cumulus then maybe you would like to contribute to the maintenance of the Wiki? This need not take hours of your time - just a half hour here and there can make a big difference, particularly if many people are doing this. Any contributions are very welcome, whether they involve new content or editing of existing content. It will be very helpful to current and future users of Cumulus software if the Wiki is kept well-maintained and current. If you are interested then please contact forum user saratogaWX and ask for a Wiki account.

[Implemented] MQTT retain message

A Forum to archive Cumulus MX development suggestions that have been rejected or solved by other means.
Post Reply
picca
Posts: 14
Joined: Mon 02 Jan 2012 4:35 pm
Weather Station: Davis VP2
Operating System: Raspbian 9
Location: Valdisotto - Italy
Contact:

[Implemented] MQTT retain message

Post by picca »

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
User avatar
mcrossley
Posts: 9980
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Buster Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: MQTT retain message

Post by mcrossley »

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.
picca
Posts: 14
Joined: Mon 02 Jan 2012 4:35 pm
Weather Station: Davis VP2
Operating System: Raspbian 9
Location: Valdisotto - Italy
Contact:

Re: MQTT retain message

Post by picca »

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.
User avatar
mcrossley
Posts: 9980
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Buster Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: MQTT retain message

Post by mcrossley »

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