- Thu Jun 30, 2016 8:09 am
#49993
I like this idea. And instead of re-inventing the wheel. Me-no-dev or Craigfoo, did you eventually integrated it into your project, and would you care to share the code? 
- Sat Jan 07, 2023 8:49 am
#95722
Necro-posting ...... did anyone follow this through to a working example of OTA update with roll back yet?
- Sun Jan 08, 2023 6:55 am
#95730
I don't use the roll back methodology myself as I want to avoid the complexity and the extra flash memory needed and in a lot of cases the apps don't have a button or are inconvenient to access. Instead I use a couple of strategies to lower the risk of an OTA stopping future OTAs from working.
The risk is that a bug in a new version might cause the OTA check to stop working. I assume first of all that the OTA code; either on-line checking or client initiated (e.g. via server.handleClient(); in the loop) is well-tested and stable.
So the first strategy is to test any new version in a local dev environment to ensure that the new version can still perform its OTA before doing a real OTA to a target.
The second strategy when I have an accessible button and am feeling paranoid is to sense the button on start up and use a flag to disable/skip all other functionality in the setup and loop other than the OTA itself.
The risk is that a bug in a new version might cause the OTA check to stop working. I assume first of all that the OTA code; either on-line checking or client initiated (e.g. via server.handleClient(); in the loop) is well-tested and stable.
So the first strategy is to test any new version in a local dev environment to ensure that the new version can still perform its OTA before doing a real OTA to a target.
The second strategy when I have an accessible button and am feeling paranoid is to sense the button on start up and use a flag to disable/skip all other functionality in the setup and loop other than the OTA itself.
