Comment by puterbonga
6 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.
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.
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?
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.
2 replies →
same recovery mechanism as when the Crowdstrike OTA goes wrong
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.