Is manual re-subscription after reconnect required when using this library?
Is there a built-in mechanism for automatically restoring subscriptions after a broker restart?
I understand that paho.mqtt.c-ar is not an officially distributed Automation Studio library. However, since the repository is maintained within the B&R / ABB GitHub organization, I hope someone familiar with the implementation can clarify the intended behavior.
I don’t have experiences with this library, but from knowing a bit about TCP I at least assume that it’s a explainable / expected behavior.
Once the subscribe was done, after it the TCP client handling the subscriber is then just in “listening mode”. If the broker after restart does not longer has the information that topics were subscribed, it won’t send anything anymore to the subscriber … and / or depending on how it’s developed, the subscriber maybe even doesn’t know that the tcp channel for subscription is not longer valid / active.
So a new positive edge on the enable input, which means disabling and enabling like described, could be neccessary to reset the internal state machine of the subscriber and / or the tcp channel.
Unlike the subscriber, the publisher detects the connection loss because it’s a repetitive sender of data instead of just a receiver, and for the network stack it’s easier/possible to detect a broken connection when sending instead of just receiving.
Unfortunately I don’t know if there’s a built-in mechanism (or if a mechanism would even be possible, this depends not just on the implementation on the client side but also depends on the tcp server shutdown behavior of the broker). But as you can detect the connection loss at the publisher, I would just link the reconnect of the client (positive edge at “.Connected”).
I have checked the library and this is indeed the behavior.
If the broker is restarted you have to reconnect the subscriptions. What you can do is check the behavior of MQTT 5. The protocol update fixed some behavior.
