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 ?
If the messages are tagged to be
retained then yes.
All you do is get a
MQTT-IN node and set the topic.
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
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
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.
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
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!
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.
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.
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.
Just a thought, and probably not a good use case.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.