Access to mqtt retained messages

I have a pi relay /sensor which successfully subscribes to an mqtt mosquitto broker.

I have node red flows which publish 'retained' mqqt data (e.g. astropi/heater/set/ON) .

'Set' triggers a relay on the pi and reports a 'state' back to the broker. (e.g. astropi/heater/state/OFF). At the time the relay is 'set', I can use an "mqtt out" to report the 'state'.

I want a flow which obtains the retained 'state' at a later time (i.e. not at the time of publication). I could store the 'state' on publication in context data but the rest of the system is complex (involving control via a web interface) and I would really rather obtain the data from the mqtt broker if I can.

Is this spossible ?

Thank you

If the messages are tagged to be retained then yes.

All you do is get a MQTT-IN node and set the topic.
Stick a debug node to (display entire message) and when you DEPLOY you should see the retained message for that topic.

Sorry I'm not exmplaing myself very well.

......... done all of that. Everything works as it should do.

Having done that and with everything up and running. How do I query the retained messages held in the mqtt broker and use that data in a flow ?

It's not possible. It's not how MQTT works I'm afraid. Context is the goto solution for this.

The retained data is in the broker.

You get it from the broker with the MQTT-IN node as I said.

Then you set the topic to get the data.
It only happens once at deployment. (Or if the data changes while/after deployed)
So you need to have the next part of the flow also built to process the message.

You want to get some_device/data (topic).
MQTT-IN set to some_deive/data/#. Connect a debug node to that shows the ENTIRE message.

DEPLOY and see if the debug node gives you what you want.
I hope it does as I believe it should.

Ok, all that is wrong.

Sorry, so am I wrong?

Use dynamic subscription, unsubscribe and resubscribe and the retained message will be delivered again

1 Like

While retained data sent via MQTT will be sent at the startup of node-red, it will only be sent once while NR is running. You can not 'request' the msg at a specified time.

The broker controls when data is sent to subscribers (i.e. node-red or some other subscriber) and that happens when a message is received by the broker.

When there is a new connection to the broker AND the broker has msgs retained for the topic just subscribed to, the broker will send those msgs to the subscriber.

If you want to save data that is received you can do as @jbudd suggests or, as @Steve-Mcl suggested, store the data in a flow or global context variable for use at a later time.

If you want to learn more about MQTT then see this tutorial MQTT Essentials - All Core Concepts explained

1 Like

Thanks for clarifying that for me.

I was confused but this does help.

I can confirm that simply re-injecting to a dynamic MQTT-in node will result in the retained messages being re-sent. This is actually a really useful side-effect when testing dashboards! :grin:

I guess the important part is that it is a DYNAMIC MQTT-IN node not the standard default settings on the MQTT-IN node..


MQTT retained messages + dynamic subscription as an alternative to global context variables.
As an alternative to persistent storage ...
Accessible from more than one Node-red instance too.

1 Like

Thanks for all of the info. I was having trouble with Owntracks staying updated and was wondering the same thing about getting access to retained messages. I was about to ask the same question as OP.

fair comment, thank you

I usually use Join nodes for that. Then you don't need the logic to trigger the fetch.

Sorry Colin, I don't understand using join nodes for this?

I only have a couple of global variables - for example API keys where I retrieve the data using an HTML node rather than a contrib node. It lets me manage these variables on a single editor tab instead of scattered among the flows as they are used. Then on a weather flow I use

msg.appid = global.get('openweathermapid');

I could have the weather flow on multiple Node-red hosts in different locations.
Using retained messages offers the possibility to ensure values are always consistent across the platforms.
Untitled 1
Just a thought, and probably not a good use case.

Something like this