We are encountering an issue with the Azure IoT SDK for ESP32.
SDK version: LTS_03_2024
When the following error trace appears:
Error: Time: File:./components/esp-azure/port/src/tlsio_esp_tls.c Func:tlsio_esp_tls_send_async Line:552 tlsio_esp_tls_send_async without a prior successful open
Error: Time: File:./components/esp-azure/azure-iot-sdk-c/umqtt/src/mqtt_client.c Func:sendPacketItem Line:393 Failure sending control packet data
the connectionStatusCallback with the result IOTHUB_CLIENT_CONNECTION_UNAUTHENTICATED is not being triggered, and the error appears indefinitely. In all other cases of connection and disconnection, the callback is triggered correctly. (so , in general, the callback worked excepting this case)
In this case, the hub sees the client as disconnected, but our software cannot take any action to reconnect without the callback, as it is our only tool to get connectivity feedback.
What other method can we use to confirm that the periodic control packet has been sent successfully?
It's crucial for us to keep data consumption minimal. We know that if any telemetry is sent in this state, your SDK reports that the message wasn't delivered and our software can start the reconnection procedure.. However, constantly sending messages for connectivity checks isn't feasible.
Essentially, we need a method to detect and handle this situation effectively.
We are encountering an issue with the Azure IoT SDK for ESP32.
SDK version: LTS_03_2024
When the following error trace appears:
Error: Time: File:./components/esp-azure/port/src/tlsio_esp_tls.c Func:tlsio_esp_tls_send_async Line:552 tlsio_esp_tls_send_async without a prior successful open
Error: Time: File:./components/esp-azure/azure-iot-sdk-c/umqtt/src/mqtt_client.c Func:sendPacketItem Line:393 Failure sending control packet data
the connectionStatusCallback with the result IOTHUB_CLIENT_CONNECTION_UNAUTHENTICATED is not being triggered, and the error appears indefinitely. In all other cases of connection and disconnection, the callback is triggered correctly. (so , in general, the callback worked excepting this case)
In this case, the hub sees the client as disconnected, but our software cannot take any action to reconnect without the callback, as it is our only tool to get connectivity feedback.
What other method can we use to confirm that the periodic control packet has been sent successfully?
It's crucial for us to keep data consumption minimal. We know that if any telemetry is sent in this state, your SDK reports that the message wasn't delivered and our software can start the reconnection procedure.. However, constantly sending messages for connectivity checks isn't feasible.
Essentially, we need a method to detect and handle this situation effectively.
Thank you.