Is really a jewel to keep integrating functions like measuring Ampere-hours for days to survive a reboot:
use thing.set_property(); in loop() to save the values
and use
use thing.get_property(); in setup() to reinitialize the values upon rebooting to where they were before booting.
But then, don’t forget to also put another thing.handle(); and a few ms delay upfront in the setup() to “wake” thinger.io!
If you have only a thing.handle(); later in loop(); you won’t get an error, but the thing.get_property(); in setup() will just return zeroes and your persistence is gone!
I’d prefer to use FlashStorage to save the value so that my device can read the latest value after rebooting instead of being reset to the default one (if the property is not changing frequently).
Hi @rin67630, the best approach to avoid calling the handle in the setup, is to create a sub-class of the Thinger Client and call the read_property when the listener notifies Thinger.io is connected via THINGER_AUTHENTICATED . This way, even if you update the property while the device is disconnected, it can refresh the variable once it reconnects again, so it is always up-to day. It makes sense if this property is modified in the cloud, i.e., from a dashboard or similar.
Details about creating a sub-class and listen for events:
In the upcoming library version with IOTMP, it will not be required to create sub-classes, so it will be much more easy.
That is the core problem!
If you have a charger running and you want to integrate the Ah across eventual reboots, you will need frequent updates: once a minute is 1440 updates a day. After 100 days, expect problems with your EEPROM.