Hacker News Reader

Comment by puterbonga | Hacker News Reader

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.

View on HN

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.

JFY, there are thousands of weather stations reporting the temperature across the globe on the APRS network. Fairly easy to check temperatures for most places at zero cost and without internet.

https://aprs.fi/

There's a magical world out there where Tuya leave us with the ability to OTA flash custom firmware of we have physical access, and then we can all just run ESPHome on private wifi networks.

And what recovery mechanisms do you have in place when the OTA flash goes wrong?

same recovery mechanism as when the Crowdstrike OTA goes wrong

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.

Surely the basic flashing mechanisms used nowadays will first check checksum (and hopefully a device magic), and then you have a relatively short time window when it actually does the flashing after which it reboots? Even small devices nowadays seem to have the memory for it. So there is a window of failure, but it's not a very long one.

Well, in addition to flashing the incorrect or buggy firmware.

That actually is exactly how it works today with ESPHome flashed to the Tuya related chips. It's also the only way to do OTA: download into second partition, switch boot.

But more widely: you just don't need to flash devices very often.

Moreover OTA is just because that's something we used to be able to do till Tuya shutdown the cloud cutter hack which could do it (which also requires physical access - you have to reboot the device into flashing mode, you can still do it but you can't custom flash anymore OTA on most newer ones).

I'm sorry I wasn't clear. This is already implemented on the ESP32 by the hardware vendor.

EDIT: to further clarify, there are no gotchas or anything, you can use your own servers and require the images to be signed or not.

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.

Reply on news.ycombinator.com