QUESTION: How to wait for tb.loop() to complete a transaction

[AdrienAdB]

Hi,

Working with esp-idf + freeRTOS, our firmware is:

1. Wake up from deep sleep
2. Read data
3. Send data to TB
4. Goes back to deep sleep

Issue is that sometimes, the firmware will go to sleep before the tb.loop() transaction is completed.
We did a 1second vTaskDelay() to fix the issue, however, I would like to find a cleaner wait to ensure transaction is fully completed.

//...

Espressif_MQTT_Client mqttClient;
ThingsBoardSized<JsonMaxFields, MaxSubscriptions, MaxAttributes, MaxRPC> tb(mqttClient, JsonMaxBytes);

// .....

            tb.sendTelemetryData("t1", 1.1);
            tb.sendTelemetryData("t2", 1.2);
            tb.sendTelemetryData("t3", 1.3);
            tb.sendTelemetryData("t4", 1.4);
            tb.loop();

            // wait for mqtt transaction to complete
            vTaskDelay(1000 / portTICK_PERIOD_MS);

           ESP_ERROR_CHECK(esp_sleep_enable_timer_wakeup(sleep_s * 1000000));        
           ESP_LOGI(TAG, "esp_deep_sleep_start, bye...");
           esp_deep_sleep_start();

[MathewHDYT]

There is a way if you use the Espressif_MQTT_Client mqttClient;, according to the docs the publish method used by sendTelemetryData should be blocking by default.

Non-blocking mode can be enabled with set_enqueue_messages(true) on the mqttClient. But for your case this is perfect.

Additionaly if you use tb.loop() with the EspressifMQTTClient and ESP-IDF, the method does nothing at all. So they call is not even required, because the EspressifMQTTClient uses a seperate FreeRTOS task in the background that actually sends the data so no looping is needed.

---

So atleast from what is written in the docu the data should actually always be sent from the device, as long as you call the publish method which the code does per default. So the vTaskDelay should not be needed.

---

If that is not the case than there is another way that is more difficult. You could use QoS Level 1, meaning you receive a response if the message was received by the broker.

This response is then received by the device in the mqtt_event_handler method. Therefore you could add the MQTT_EVENT_PUBLISHED case to the method. And if that case is hit you can go into deep sleep.

You would need to adjust a little bit more in the EspressifMQTTClient to enable QoS support tough, so if the aforementioned easier way works that would probably be preferable.

[AdrienAdB]

@MathewHDYT thank you. I will do some testing in the next few days and come back to you.