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.
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?
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.
