基于 ESP32 的 BLE Mesh 中继节点 OTA 实战：错峰升级、转发自恢复与固件回滚
文章目录
- 基于 ESP32 的 BLE Mesh 中继节点 OTA 实战：错峰升级、转发自恢复与固件回滚
- 一、升级那个中继，整层楼的灯都灭了
- 二、系统总体架构
- 三、硬件选型与接线
- 3.1 器件选型表
- 3.2 接线总览
- 3.3 为什么必须加超级电容
- 3.4 引脚与接口接线表
- 四、软件流程设计
- 4.1 标准 Mesh Firmware Update 模型能做什么
- 4.2 三种升级策略对比
- 4.3 错峰升级的调度算法
- 4.4 转发权交接：让节点在升级前"变哑"
- 4.5 回滚机制：保证节点一定回来
- 五、完整代码实现
- 5.1 分区表设计
- 5.2 升级协调服务（网关侧）
- 5.3 转发权交接（节点侧）
- 5.4 版本协商与兼容性规则
- 5.5 回滚实现
- 5.6 完整升级时序实现
- 六、关键参数与时间预算
- 七、部署与联调步骤
- 八、常见问题排查
- 九、总结与扩展
一、升级那个中继，整层楼的灯都灭了
这是我们踩过最贵的一个坑。
那是一个 120 户的公寓项目，Mesh 网络里有 22 个中继节点分布在 11 层。运维要升级一次网关固件，顺带把中继固件一起升了版本（加了个新的中继角色配置项）。
升级是按楼层顺序做的，从 1 层开始。第一层两个中继升完，正常。第二层开始升第一个中继，出事了。
现象是：11 层到 16 层的所有节点集体失联。19 楼的住户反馈"早上起来灯全灭了，物业说网络升级"。
原因不复杂，但当时所有人都没想到：BLE Mesh 的中继节点一旦离线，覆盖它信号范围的区域就没有转发器了。那栋楼的电梯井是全楼的信号瓶颈，只有 2 号中继能覆盖 5 到 9 层。我们升级的恰好是这两个之一。节点还在线，但报文出不去。
更糟的是第二件事：升级完之后我们没能自动切回去。
升级后的固件增加了一个配置项，网关下发时没带上这个新配置，节点启动后配置校验失败，卡在一个"配置未就绪"的状态，既不转发也不上报。结果这个中继等于永久下线，直到工程师带着笔记本去现场用串口恢复了配置。
这两个问题合在一起，造成了 4 小时的整层失联。这一篇要讲的就是怎么把这两件事都做对：
- 升级期间如何保证网络不断；
- 升级之后如何保证节点一定回来。
二、系统总体架构
中继节点 OTA
