AFR & ESP32: MQTT PUBLISH 0 could not be sent. Error NO RESPONSE #2746
Comments
Hi @dipen-1337lab, Thank you for this report. I will begin working on reproducing this issue. Thanks, Carl |
Hi @dipen-1337lab, Can you turn on the MQTT debug logging and provide another log? It seems that you are not getting the PUBACK packet, and since you are attempting QoS1 on the device, this is likely the issue. It may help to try to increase the timeout here. You can update the MQTT logging here. |
Namaste @lundinc2, Here, I made the below modification.
However, I could not see any additional information on the serial console. What am I missing for viewing the MQTT Debug logs? Also, browsing through the JSON logs on the AWS Console, I encounter the below QoS level. Why is this so, considering that I am setting
Also, changed the below #define to 5 seconds. Nevertheless, I continue to get the same error.
Let me know the next steps. Thanks | Regards, |
Hi @dipen-1337lab that change is incorrect, please set the macro I linked in the previous comment to Are you using the MQTT client found in the AWS IoT Test section? If so you can modify it to be at QoS1, by default it is QoS0. Thanks, Carl |
Namaste @lundinc2, Thank you for your assistance in order to obtain the Debug logs. Below is the corresponding log observed on the console.
I'm happy to inform that I have resolved this issue. Below is the root cause analysis. Hope it makes sense. I am running multiple threads as below.
Except for the Update Display thread, all the threads are running periodically by leveraging the It looks like the continuous execution of the I have tested the application for 30 minutes with all the threads running simultaneously. The
We can close this issue now. Many thanks again for your assistance on this issue! Appreciated. Thanks | Regards, |
Hi @dipen-1337lab, I am very happy to hear this is working for you. I am assuming you are only using one core on the ESP32, and if so only one thread can execute at a time. I hope that answers It is possible to pin a task specifically to the second core of the ESP32 which may be worth investigating for your use case. Thanks, Carl |
Namaste @lundinc2,
Yes, I'm using only one core on the ESP32. Maybe that is why I encountered this behaviour. My understanding was that the MQTT callback for PUBACK would be independent and, get called once the PUBACK is received. It would wake up the MQTT thread and process the PUBACK. Nevertheless, one thing's for sure, I still need to explore and understand the MQTT functionality.
Thank you for suggesting this. Yes, I'm aware. Will keep this in mind to leverage the second core, if need be in the future. Thanks | Regards, |
Namaste Community Member,
The FreeRTOS version in use for development is V202002.00.
The MQTT Demo runs as desired. However, after the required modifications in my application code, I am getting the below error for the MQTT Publish operation.
The
RunMqttDemo()
in theiot_demo_mqtt.c
source file has been modified as below.For debugging purpose, the below #define has been set to 1.
#define PUBLISH_RETRY_LIMIT ( 1 )
With this, the JSON response I get on the AWS IoT console when periodically publishing readings at 15 second interval and, the serial console log are as below.
The Serial Console Log is shared below.
The JSON Log is shared below.
The timestamp appended, which is part of the Publish payload message has the below values, corresponding to the 15 seconds interval -
Every 15 seconds, two MQTT messages are published. Further with the
PUBLISH_RETRY_LIMIT
set to 1, both these readings are sent again (retry) after which I receive the below message on the serial console.MQTT PUBLISH 0 could not be sent. Error NO RESPONSE.
Analysing the serial console logs, I realize that the
MQTT PUBLISH 0 successfully sent.
message is missing, which corresponds to the_operationCompleteCallback()
function not getting called.Requesting assistance to resolve this issue.
PS. Running the firmware for few minutes with PUBLISH_RETRY_LIMIT = 10 along with other application threads results in firmware restart, which as per my analyses is due to the Heap memory deallocation not happening because of the above MQTT Publish error.
Thanks | Regards,
Dipen
The text was updated successfully, but these errors were encountered: