三根管道、四个节点:手机和电脑先把请求交给云端,云端再把指令送到窗台,读数再沿原路回来。全程一步一步走,跟着那束光就知道数据到了哪。
两个传感器进 ESP32,一根信号线去水泵驱动模块,模块再把水泵接通。每颗孔旁边印着它自己在实物上叫什么,同一行另一头写着它要去的那颗孔:DHT11 的 S 出发,落在 ESP32 标着 21 的孔上。
后台把 .bin 传上网关,点一次升级要走完四道检查才下发;设备下载断了会从断点接着下,写坏了不切换分区,新固件三次启动没通过自测就退回原来那一版。
OTA 已排队 1.3.0 ← /firmware/v1.3.0.bin
第 1 次尝试 写入 524288 字节后连接结束
第 2 次尝试 Range: bytes=524288- → 206
续传到 1144000 字节,体积与后台一致
Update.end(true) 镜像自校验通过
切换启动分区 重启进入 1.3.0
v1.3.0.bin 上传就记成 1.3.0 版;带路径、不是 .bin、名字不成形的一律不入库。
产物在盘上、目标版本更高、网关连上了 broker、设备此刻在线——四条同时成立才写升级记录并下发。
从断点续传,最多试 3 次;45 秒没有新字节就主动认输,旧固件继续运行。校验通过才切换启动分区。
重启后连上 MQTT 并发出 capability 才算自测通过;后台再用上报的版本号对账,不采信设备自报成功。
每天 03:30 把全库和源码备一份,周日把备份真恢复到临时库核对;操作日志按人署名,删除也不抹审计。
一份数据库 dump、一份源码包,连同 SHA256SUMS 一起落盘;日备留 7 天,超期自动删。
在随机命名的临时库里恢复,核对行数与列数、应用账号读得动,退出时删掉临时库——生产库一行不动。
pull-backup.sh 一条命令把 dump 和源码拉回本机,逐份对 sha256;服务器那块盘坏了,手里还有一份。
断网照浇、刷坏了退回旧版、每天备份每周校验——三层兜底各自有一件事在没人看着的时候发生。
▲ 一个人的花园,也按能长期跑的标准做