Comment by puterbonga 18 hours ago
Every time someone does a project like this, it exposes how trivial “IoT” really is once you strip away vendor lock in and buzzwords. A $3 sensor, a 10 line script, and a 40 year old ham protocol outperform half the commercial weather APIs out there.
you can have 2 identical partitions on the ESP, the OTA flashes the inactive partition and signals to bootloader to attempt to boot it from there.
the device is restarted, if the new firmware is working correctly you signal the update process that everything is all right and it sets the new partition as default.
if the device doesn't boot correctly, or your sanity checks don't pass, either you or the watchdog restarts the device and it boot from the known-working partition.
I didn't ask what can you have. We could have whatever safety processes we wanted with multiple levels of redundancy. However, that's not what's available on COTS IoT devices though, so speculation does not help.
Flashing the firmware of a cheap IoT device remotely OTA is not without risk.
With respect, this misses some important constraints. Scale it to thousands of locations and target 99% SLA. Now you have a maintenance problem in remote physical places, requirements for hardware reliability, subcontractors to manage, need a reliable network connectivity, etc. You also need to collect and redistribute the data (API or whatever) - while this is a trivial problem today, still you incur costs for hosting, network, etc. While I actually agree with the sentiment, it is not just a $3 sensor either.
To be generous, this solution 'outperforms' commercial weather APIs for exactly one hyperlocal geographic location, and underperforms on 99.999999% of the remaining locations that may also be experiencing weather of some sort.