ESP32 Forum

Hello ESP32 experts.

I’m working on a battery-powered device for monitoring some simple peripherals, display status on a tiny e-ink display and send/retrieve data using Wi-Fi. However, I would like the device to be updateable, in case there are bugs and updates for new devices and functionality. I read about OTA updating, but the thing is that the devices can be placed far from my residence.
I have experimented with Arduino and MicroPython, but would like to hear your opinions, regarding how to create the best solution.

Here are the criterias:

• A device must be able to either pull an update from the Internet or be able to have one pushed to it, using an app.

• A failed update must not lead to a bricked unit, since it does not contain any USB-port for restoring the software. It does contain a serial port connector for the software, which is only intended for preconfiguring the device.

• The device should use minimum power. It wakes up at certain, preprogrammed points in time, makes measurements and then hibernates. Normally, it’s interval is 1 hour.

• Since it’s battery operated, it must preserve power – so: wake up from hibernation, connect to Wi-Fi, send/receive data, update display and enter hibernation mode again as fast as possible. I would say that recharging the battery once every three months is acceptable.

In order to avoid a bricked unit (not good at all) I considered several techniques:

Arduino:

• Divide the storage space into two, so that when an update is made, a backup is kept – and when successfully updated, the reference is switched when the device boots successfully for the first time.

• Push the software, using Arduino OTA and an app… but what happens, if the update causes a bug in the Wi-Fi connectivity?

MicroPython:

• Pull an update from the Internet in Micropython, so that the Wi-Fi code and a timer interval will be thoroughly tested, but never changed. With intervals, it connects to the internet and if an update is available, the script is downloaded and stored.
  If a script has a bug, I can produce a new version and have every device out there will still be able to download it.

• Drawback: I read that MicroPython is a bit more powerhungry and has a longer boot time – but I really don’t have a clue at the moment, how long a 5 – or 800mAh battery will last.

If ESP-IDF is also an option, the belt-and-braces option is to have a factory plus two OTA update partitions. The factory partition is filled with a known-good 'gold' firmware that may not have all the functionality of later OTA'ed firmwares but is tested and proven to be able to configure WiFi and download an update to the OTA partitions. The OTA partitions work in a ping-pong fashion: when OTA1 runs, it can download to OTA2 and reverse. ESP-IDF has rollback functionality; when you boot newly OTA'ed firmware for the first time, that firmware needs to get past a certain point in bootup that marks the firmware as stable. If that does not happens, the firmware is seen as 'faulty' and reverts to the older firmware. In case the absolute worst happens and the OTA is broken but somehow marked as non-faulty, you can use some button combination to reboot the ESP into the factory firmware, which will always load a new firmware from the 'net into the OTA partitions.

Wow, I didn't know about ESP-IDF.
Thank you for your help.