# Paho.mqtt.c-ar library - resubscription after broker restart

**URL:** <https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504>\
**Category:** Programming\
**Tags:** library\
**Created:** [September 3, 2026, 8:21am UTC](https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504 "2026-09-03T08:21:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![siedlak](https://avatars.discourse-cdn.com/v4/letter/s/FF8800/32.png) [@siedlak](https://community.br-automation.com/u/siedlak)\
**Post date:** [September 3, 2026, 8:21am UTC](https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504/1 "2026-09-03T08:21:53Z")

</div>

Hi Community,

I have a question regarding MQTT subscriptions after a broker restart.

**Initial behavior is correct.**

After PLC startup:

1. `IotMqttClient` connects successfully to the Mosquitto broker.
2. `IotMqttSubscribe` subscribes to the configured topic.
3. Messages are received correctly.

The issue only appears after a broker restart:

1. Mosquitto broker is stopped.
2. `IotMqttClient` detects the connection loss.
3. Mosquitto broker is started again.
4. `IotMqttClient` reconnects successfully (`Connected = TRUE`).
5. The publisher can publish messages to the broker.
6. The subscriber no longer receives messages.

After analyzing a Wireshark capture, it appears that after reconnect the client does not automatically send a new `SUBSCRIBE` request.

As a workaround, I currently detect reconnect and perform:

IotMqttSubscribe.Enable = **FALSE**

IotMqttSubscribe.Enable = **TRUE**

which results in:

**UNSUBSCRIBE**

**UNSUBACK**

**SUBSCRIBE**

**SUBACK**

After that, message reception works again.

Current MQTT configuration is shown in the attached screenshot. Relevant settings are:

 ![image](https://europe1.discourse-cdn.com/brcommunity/original/2X/e/e44eb3273b15d67d335f96a5415e2a2fe7a463a5.png)

Environment:

Automation Studio 6.5.2.12

Automation Runtime 6.6.3

X20CP0483

Questions:

- Is this expected behavior of `IotMqttSubscribe`?
- 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.

Kind Regards

---

<div class="post-metadata">

**Author:** ![alexander.hefner](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/alexander.hefner/32/111_2.png) [@alexander.hefner](https://community.br-automation.com/u/alexander.hefner)\
**Post date:** [September 3, 2026, 9:54am UTC](https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504/2 "2026-09-03T09:54:49Z")

</div>

Hi,

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”).

Best regards!

---

<div class="post-metadata">

**Author:** ![kovarj](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/kovarj/32/537_2.png) [@kovarj](https://community.br-automation.com/u/kovarj)\
**Post date:** [September 6, 2026, 12:06pm UTC](https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504/3 "2026-09-06T12:06:14Z")

</div>

Maybe @job.franken can help to answer this question?

---

<div class="post-metadata">

**Author:** ![job.franken](https://avatars.discourse-cdn.com/v4/letter/j/FF8800/32.png) [@job.franken](https://community.br-automation.com/u/job.franken)\
**Post date:** [September 7, 2026, 7:22am UTC](https://community.br-automation.com/t/paho-mqtt-c-ar-library-resubscription-after-broker-restart/12504/4 "2026-09-07T07:22:39Z")

</div>

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.
