Open Timmwardion opened 3 months ago
Timmwardion
commented
3 months ago Update: I've now changed my code to call the primary HTTP post via the esp_rmaker_work_queue_add_task(). Which...honestly does something but the problems are still there.
Seems to mainly be a watchdog issue on the rmaker_queue_task function that seems to run a continuous loop which as far as I can tell has no opportunity for a wdt refresh. See line 58-60 of work_queue.c.
vikramdattu
commented
3 months ago Hi @Timmwardion,
You do not have to explicitly call esp_insights_send_data. This is taken care already by esp_insights.
If you still wish to trigger data sends explicitly as well, you should have some delay in the loop.
e.g.,
while(1){
//other code goes here
ret = esp_insights_send_data(); //purge insights buffer
if (ret != ESP_OK) {
ESP_LOGE(TAG, "Failed to send data to ESP Insights, err:0x%x", ret);
} else {
ESP_LOGI(TAG, "Data sent to ESP Insights");
}
/* Trigger data sends every 5 seconds */
vTaskDelay(pdMS_TO_TICKS(5 * 1000));
}This will save you from tirelessly performing the task and avoiding the watch dog.
Timmwardion
commented
3 months ago I've tried that - and tried taking out the explicit call to esp_insights_send_data() all together stripping the implementation back to a minimal version and I still get the WDT timeout on rmaker_queue_task.
Is there a way I can stop the timer-based calls to send data and instead trigger it explicitly in code? I'm wondering if the timer-based sends are the issue.
My firmware runs some continuous loops so it makes sense to sync the insights posts with those loops anyway.
vikramdattu
commented
2 months ago Hi @Timmwardion It is not currently possible to not report insights data via configurations currently. I would encourage you to use internal reporting. It does not cost any extra task, as it simply adds the task to rmaker_task_queue which already is initialised. As far as Watchdog is concerned, you should not tirelessly do the operation. Instead you should have some delay between two report calls.
If you still want to do reporting from your custom code:
What you can do instead is simply increase the reporting interval to a very large number so that the internal reporting is scheduled less often.
Also, if you want to, you can make changes in the esp_insights.c and remove these lines which schedule the reporting: https://github.com/espressif/esp-insights/blob/3318d7f02a38646cbc1bd1559feb2f2f8c55f7bc/components/esp_insights/src/esp_insights.c#L863
Hi there - implementing ESP-Insights for the first time and struggling with a situation I think has to do with multiple HTTP POST requests happing on my device.
Essentially my device has two key jobs:
The primary task executes well until I try and implement ESP-Insights along-side it.
When I implement ESP-Insights though I get a cascade of things going wrong (see below)
In my mind all of that points to the insights post taking too long (possibly because of task collision with the other POST task), maxing out memory trying to store new metrics, and triggering the dog while waiting for the connection and crashing.
I don't see in any of the documentation a way to set the insights timeout or somehow manage a semaphore between the two tasks so I'm wondering how I can manage this. My primary task has the potential to be fairly active but even if I slowed it down temporarily there is likely to be collisions into the future.
I notice that documentation on transport sharing focusses on MQTT. Does this mean MQTT is recommended? I don't have the rainmaker agent running at this point so unless I'm wrong, it seems like I won't get any benefit from transport sharing unless there is some benefit to getting the insights POST client and my primary POST client aligned.
I also notice that documentation points out that "The RTC memory is limited and flooding too many messages, makes RTC storage full. Once full, the framework has to drop the messages. One solution is to increase the data reporting frequency to cloud, and thereby emptying the RTC store frequently." But I can't find any reference to how to increase the data reporting frequency. I have found the esp_insights_send_data() function but that seems to just add to the rainmaker queue - which if it's blocked or in the process of timing out, won't succeed in purging the metrics in the RTC_STORE.
EDIT: I found the settings for this in menuconfig. You can set max and min interval for posts:
Also below is the minimal code for my implementation of ESP-Insights. pretty much a copy/paste from the examples.
`