Hello,
I’m running a shadow connection application that is based on the 202011 Shadow demo. In this implementation the MQTT connection is establish by calling code MQTT functions - MQTT_Init & MQTT_Connect.
One of the MQTT_Init parameters is a user event callback of type MQTTEventCallback_t that notify the user about incoming packet events but not MQTT events like disconnect.
So how can I know that I lost the MQTT connection?
Thanks,
Eyal
You can check if MQTTRecvFailed is returned by MQTT_ProcessLoop. If the MQTT connection is no longer active, this status is returned.
Thank you for your response.
I’m a bit confused about the role of the MQTT_ProcessLoop.
I would expect the MQTT to run forever when I’m working with a shadow, that is, waiting for delta message from the broker in the callback and send updates on a need to basses but in the Shadow demo I don’t see such a infinite loop calling MQTT_ProcessLoop.
In such a case of an infinite loop I can understand the MQTT status check for disconnection with the return value but this the case in the shadow demo.
Can you please elaborate on the usage of the MQTT_ProcessLoop?
Thanks
The Shadow demo is using prvWaitForDeleteResponse to call MQTT_ProcessLoop. It will run for a duration of MQTT_PROCESS_LOOP_TIMEOUT_MS. This is done by passing a timer function called prvGetTimeMs in mqtt_demo_helpers.c. Note that the user event callback is called by MQTT_ProcessLoop whenever an incoming MQTT packet is received from AWS IoT Core.
Thank you for this info, I can’t see prvWaitForDeleteResponse in 202011 but in 202012 I can see it.
In the MQTT agent demo I see a use of MQTTAgent_CommandLoop that is part of FreeRTOS-Plus-MQTT.
This library is not part of the 202012 AFR, what is the relationship between this MQTTAgent_CommandLoop and the MQTT_ProcessLoop?
The MQTT agent sits on top of coreMQTT. MQTTAgent_CommandLoop() is part of the MQTT agent, whereas MQTT_ProcessLoop() is part of coreMQTT. Note the agent is not complete yet - but when using the agent you call MQTTAgent_CommandLoop() to have a separate thread manage MQTT for your application so the application does not have to call MQTT_ProcessLoop() at all. The MQTTAgent_COmmandLoop() only returns if there is an error that probably requires the creation of a new connection.
Thanks for that explanation.
So if I’m standing now in a point where I’m porting my existing product FW that is based on 202002 to 202012 and I don’t want to restructure the code again in a month or so then should I use the FreeRTOS-Plus-MQTT as it is in the MQTT agent demo and upgrade it when it will be ready or should I use the core MQTT directly (that is using MQTT_ProcessLoop)?
Other than the readme notes about code standards, and that this new Agent is still green, is there a technical reason this wouldn’t work with iot_ble_mqtt_transport.c?
The file mqtt_demo_ble_transport.c right now seems like it would/could/should be mostly replaced with this agent with the exception of the channel and callback inits. Seems like it would make sense to commonize software esp for demos. Any idea on that?
There is a file at amazon-freertos/libraries/c_sdk/standard/mqtt/src/iot_mqtt_agent.c updated recently for CoreMQTT. Similar function names and responsibilities. Can I assume this is obsolete and only for backcompat?
I’m afraid I don’t know enough about the BLE transport implementation to know for sure, but suspect it will work.
That is the idea behind the “transports” right? Provide CoreMQTT a send and receive and away it goes?
The only annoyance I have is MQTT get serialized, then the MqttOverBle transport will de-serialize, then re-serialize into CBOR. A waste, but this is what the official demos do now so maybe there was no better option.
Any idea if between the two Agents one will be left standing?