You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal is to buffer the readings in the ESP32 heap memory when transmission to the backend fails and then send the data once the connection recovers again.
Because the ONE and Open Air hardware doesn't support a battery-backed RTC, it is probably the easiest to use a backend provided timestamp as a base to tag the readings with a timestamp. This also means that we won't be able to buffer data upon power failure, but still it does improve the situation if only the internet drops out and then recovers within a few hours.
The text was updated successfully, but these errors were encountered:
Do you mean when transmission failed, buffer every failed transmission until it success send the first failed transmission? So basically send in a FIFO manner?
This approach can take a lot of heap if offline in a long time, do you have any recommendation to prevent this @nick-4711 ?
Yes, we have to limit the buffer size to avoid to run out of heap. I made an experiment once where I was able to keep 100 measurement cycles in RTC memory (which is only 8KB). So I expect that buffering data for a few hours is feasible.
The goal is to buffer the readings in the ESP32 heap memory when transmission to the backend fails and then send the data once the connection recovers again.
Because the ONE and Open Air hardware doesn't support a battery-backed RTC, it is probably the easiest to use a backend provided timestamp as a base to tag the readings with a timestamp. This also means that we won't be able to buffer data upon power failure, but still it does improve the situation if only the internet drops out and then recovers within a few hours.
The text was updated successfully, but these errors were encountered: