• Yes, sorry, I should have provided more context. In my particular case, I am using an Espruino WiFi, however I can see how some sort of notification might be helpful in other situations.

    In my case, I have a long setInterval of a half-hour or more. At the interval time, the program exits deep sleep, the WiFi connects, then the MQTT connects, and then the message can publish. After the message is published, everything disconnects and the board is put back into deep sleep. The real issue is being sure the message was sent before slipping back into dreamland.

    My issue is actually tangent to the main protocol. Right now, although the module accepts a QoS option, it doesn't really do anything different in such cases. I can see that it does accept PUBREC and PUBREL and replies correctly in those cases, but PUBACK and PUBCOMP are ignored. There should be a mechanism for retransmission if with a duplicate message if the broker doesn't acknowledge receipt. Then maybe the side benefit is emitting an event of success so that the user program can do something useful (such as go back to sleep in my case).

    The good news is that most of the scaffolding is already in place to correctly handle QoS 1 and 2. It just needs to store and retransmit duplicate messages until the proper acknowledgment is received.

About

Avatar for ScottyMT @ScottyMT started