Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.8.4 (build 3094) - 14 September 2020 (please see announcement regarding releases since 3.5.0)
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 the NOAA report and Snow Index drop-down menus to 2030)

Use this Wiki link to Download the Software (Cumulus MX / Cumulus 1 and other related items).

MQTT retain message

Please DO NOT use this to publish your entire wish. This Forum is for specific suggestions to enhance the usability of Cumulus MX for all users, NOT your personal requirements. Please check this forum and the rejected forum to make sure you are NOT posting a DUPLICATE suggestion. It will be heavily monitored by Admin and Mark Crossley to determine the feasibility and the difficulty of the suggestion. Those Topics that are deemed inadmissible will moved to the rejected Forum. The remaining Topics will be the Accepted list of future developments, and when our voluntary development group adds it to a build, the build number will be added to the Topic title.
Post Reply
picca
Posts: 5
Joined: Mon 02 Jan 2012 4:35 pm
Weather Station: WMR 180 | Oregon
Operating System: Windows 7
Location: Valdisotto

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: 6936
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2
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: 5
Joined: Mon 02 Jan 2012 4:35 pm
Weather Station: WMR 180 | Oregon
Operating System: Windows 7
Location: Valdisotto

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.

Post Reply