Handling disconnect/reconnect in "permanent" MQTT session
Posted: Tue Jun 04, 2024 10:11 am
Hello,
using esp-aws-iot component master branch with IDF5.2.1, and having managed to run shadow updates and jobs, one major area admittedly remains a puzzle - any thoughts hugely appreciated:
Our IoT device, unlike the examples' central philosophy, needs to have a "permanent" MQTT session - and it will regularly do things with shadow, events, jobs. Unlike the examples, it would not demolish the MQTT session with underlying transport (TLS) connection after each e.g. shadow update. We did this "permanent" session with IDF3.x in the past, and now wondering:
1. Once EstablishMqttSession() (as per MQTT helpers in shadow and other examples) establishes the transport and then MQTT session, how would we find out if something at any layer disconnected? and how to act on it?
Some parts in example and library code state that to some extent reconnection would be 'handled' but... one would have to find out one has to call EstablishMqttSession() again if there was disconnect? Possibly with non-clean session, unlike on our first post-boot connection?
2. Then if we do look at e.g. xTlsConnect() called by EstablishMqttSession(), its status is opaque (many status codes are defined in enum in the library but nothing sets them nor propagates them up to caller).
Additionally, PublishToTopic() (as per examples) can be made to propagate up an MQTTStatus_t value, BUT: this, at most, might tell us that there was a failure in receive or send operations.
The reasons for those disconnects can be many, from certificate/authentication to network dropouts to whatever.
==> In summary, if we imagine we establish an MQTT session and we want to ensure it 1. notices disconnects, 2. acts on the them, 3. re-establishes the session and carry on: how it this possible to do with the new AWS IoT component?
Many thanks in advance as even after lot of dives into library source code and the examples, the above remains a mystery.
using esp-aws-iot component master branch with IDF5.2.1, and having managed to run shadow updates and jobs, one major area admittedly remains a puzzle - any thoughts hugely appreciated:
Our IoT device, unlike the examples' central philosophy, needs to have a "permanent" MQTT session - and it will regularly do things with shadow, events, jobs. Unlike the examples, it would not demolish the MQTT session with underlying transport (TLS) connection after each e.g. shadow update. We did this "permanent" session with IDF3.x in the past, and now wondering:
1. Once EstablishMqttSession() (as per MQTT helpers in shadow and other examples) establishes the transport and then MQTT session, how would we find out if something at any layer disconnected? and how to act on it?
Some parts in example and library code state that to some extent reconnection would be 'handled' but... one would have to find out one has to call EstablishMqttSession() again if there was disconnect? Possibly with non-clean session, unlike on our first post-boot connection?
2. Then if we do look at e.g. xTlsConnect() called by EstablishMqttSession(), its status is opaque (many status codes are defined in enum in the library but nothing sets them nor propagates them up to caller).
Additionally, PublishToTopic() (as per examples) can be made to propagate up an MQTTStatus_t value, BUT: this, at most, might tell us that there was a failure in receive or send operations.
The reasons for those disconnects can be many, from certificate/authentication to network dropouts to whatever.
==> In summary, if we imagine we establish an MQTT session and we want to ensure it 1. notices disconnects, 2. acts on the them, 3. re-establishes the session and carry on: how it this possible to do with the new AWS IoT component?
Many thanks in advance as even after lot of dives into library source code and the examples, the above remains a mystery.