No, you can resend a subscription at any time and get the retained messages.
Yes, Just re-subscribe, there is no un-subscribe as far as I know
Why not just store it locally in context the first time ?
Yes that's possible too, but not a logical way to do it. Read above posts
Given the constraints of the existing nodes itās a perfectly logical way to do it. In fact given that MQTT is a push based protocol Iād say itās the best way to do it. Holding the state locally allows you to query it as many times as you like without incurring any extra bandwidth usage.
1 Like
The issue with holding locally (apart from the extra nodes needed to do it) is that there is no guarantee that you are actually holding the true messages being held on the broker
Extra nodes. One change node to move payload to context. Not excessive imho.
If you subscribed QoS 1 or 2 then you will have what is on server. Unless connection fails in which case you wouldnāt know anyway. On (auto) reconnect you would then get latest retained.
1 Like
Maybe I'm not explaining my original "need" for this facility or maybe there is an easy workaround that I can't see
I have an MQTT in mode feeding other nodes
I do editing work on the flow and re-deploy the changed nodes - the MQTT doesn't auto re-connected so I edit it to a non-exisitant broker - redeploy - edit it back to my real broker - redeploy
At that point I get the latest message(s) from the broker
AFACS retaining the previous old message(s) will not help me get the current message(s) from the broker without having to effectively re-subscribe
Any reason not to change the deploy to modified flow rather than nodes ? So changing anything downstream of the mqtt node will cause it to restart on deploy and resubscribe
TBH I've never been sure what that option means so I've always avoided using it 
(Given that "flow" is used to mean different things at different times)
If it just applies to other nodes connected to the node I'm editing (and not all nodes in the tab) then that could work for me
I'll try it out
I know the workaround, but it would be easier and more intuitive if you just could trigger the mqtt node....
1 Like
[Edit] the below does actually work, but see later message for what doesn't. Leaving this in so future messages make sense.
Actually this does not work as far as I can see. I configured an MQTT IN node subscribed to a retained topic, feeding a function node that just passes the message on to a debug node. When I initially deploy the debug node shows the retained topics. If I edit a comment in the function node and deploy using Flow mode then the debug node does not show the retained value again.
Node-RED version: v0.18.7
Node.js version: v8.11.3
Linux 4.15.0-29-generic x64 LE
Ubuntu 18.04
Which connects first ? The mqtt or the web socket to the debug ?
Sorry, don't understand the question, however I have to retract my previous comment, it does work if the function node is edited, but if just the wiring out of the mqtt node that is changed then it does not. So if the mqtt node is wired to a debug and deployed, then wired to a second debug node and deployed (Flow mode) again then nothing appears in the debug window.
Whatās Iām saying is that the mqtt may connect, subscribe and receive the retained message before the browser reconnects to the debug web socket so the debug may miss the message.
The debug Webocket doesn't drop when you hit the deploy button.
