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.
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.
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.
EXAMPLE: 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.
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.
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!
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.
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.
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.
Just a thought, and probably not a good use case.
