coreMQTT-Agent-demos, Lab-Project-ota-example and QoS

Partners & Sponsors AWS
1

Hi,

First of all, I don’t know if the coreMQTT-Agent-demos repository is still up to date.

We’ve seen that the demos for the new OTA modular approach doesn’t use coreMQTT-Agent and only use QoS 0. But we try to understand the best way to handle QoS1 with completion result using coreMQTT-Agent as the OTA library was using QoS1 for job request (maybe is it not necessary anymore ?)

When looking into the ota over mqtt demo (in coreMQTT-Agent-demos), I see that an interface to publish on MQTT was passed to the OTA library. In this interface, the pointer to the message is passed in a structure which will get handled by coreMQTT-Agent. Then there is a wait for a configurable timeout. This interface could be called by requestJob_mqtt where the message buffer is allocated locally in the function; this function also using QoS1 with (in the interface wrapper) a callback which will notify a task by a handle stored in a structure locally allocated too. With a finite timeout, we end up quitting functions scopes sometimes (for example when losing connection) and having problems with pointers. We would have to define equivalent to mqttWrapper_publish using coreMQTT-Agent but then we may have the same problematics.

The interface (wrapper) approach is interesting but the coreMQTT-Agent documentation states that structures must remain in scope until the command is completed, so what would be robust ways to handle this ? Is it enough to play with the timeout value ?

2

Hi @steriDeca, thanks for reaching out! Our team will take a look shortly!

3

Hello @steriDeca,

QoS0 and QoS1 both work with OTA. Since the MQTT stream operates over TCP/IP protocol, it ensures in-order and guaranteed delivery unless the connection breaks.

I see your point though. With finite timeouts, it is difficult to manage memory. If the agent doesn’t get incoming data within that timeout, then it is always confusing about the next step. I am afraid that there is no simple way around it.

You can allocate the memory using heap (using malloc) and then send that data to the Agent. Then Agent incoming publish callback would be responsible for cleaning up that memory (using free). This might be something you may or may not want to do depending on your system and your requirements.

Let us know if that works.

Thanks,
Aniruddha