Programmatically disconnect from MQTT

Hey,

I want to retrieve info from zgibee2mqtt that I can only seem to retrieve on the initial MQTT connection, namely the stored state of each device.

Each time I want this data I could just restart all my flows, however I was hoping there might be a "magic" topic to send to disconnect to MQTT, so I can then send another "topic" right after to re-subscribe and then receive all the data I need/want.

I have done some searching, but can seem to find a solution. Hoping someone can help out.

PS: One option would be to send a command to the MQTT server to stop and then restart it, but that would affect all MQTT subscriptions other than zigbee2MQTT.

I am under the impression, that you are misunderstanding the way mqtt messaging works.
The topics published to the broker cannot be accessed in the same way as a database (retrieved) but are getting pushed to any subscriber....but only when the topics updates AFTER the client has subscribed to it.

What you describe looks like you are trying to "fetch" the topics that have been published (by your zigbee2mqtt device(s)) with the retain flag active. This way, a client will receive these topics even when subscription happens after the topic has been published and this is what happens when you force the client to reconnect to the broker with a new ID (by restarting your flow).

If these topics are rather static and do not update after the device is active, you must find a way to persist these inside your flow after receiving them when your client connects first.

Hi @alex88 - we added the ability to dynamically connect/disconnect the MQTT nodes in 2.1.0 - Version 2.1 released : Node-RED

1 Like

Brilliant!

I was already using dynamic subscription. I just didn't know about the additional actions available.

Took me a minute to realise that I needed to send msg.action (from here: Dynamic MQTT connections by knolleary · Pull Request #3189 · node-red/node-red · GitHub) along with the original msg.topic, but after that it worked like a charm!

I can now unsubscribe and then re-subscribe and get all those wholesome stored state messages to update my device state global json in NR.

Thank you!

If you are storing them in global context then they should get picked up automatically when node-red starts (assuming they are Retained topics, which they must be, or they would not get refreshed when you reconnect). Why is that not happening?

Are you dynamically subscribing to the topic in question? If so, then do you mean that when you subscribe to a Retained topic, it does not send you the initial value?

Right you are @Colin, however I was looking for a solution to a niche edge case.

I need to populate a global variable that gets intermittently wiped.

The link @knolleary sent solved it prefectly.

I could just restart all the flows, but now I have a wee little button that I can press amd my global gets populated... Woo hoo!

It's part of a bigger picture of multiple sources populating the same global.

Rather than re-connecting you could unsubscribe and resubscribe to that topic.

An alternative solution might be to use a Join node (in key value mode) to join all the candidates into one message, then route the appropriate one to the global.

Though I think personally I might put the whole set in the global, then pick the relevant one out when needed (using another global to define which one to use currently).

That's what I'm doing now - unsubscribing then re-subscribing to get the dump from zigbee2mqtt with the last held state, which I then use to re-populate my global JSON.

I only do this when I'm changing the structure of the global JSON i.e. adding new key/value pairs or new objects. Otherwise there's no point in grabbing a view of the state of all the devices, as they are provided as incremental messages during normal operation.