基于 ESP32 的 BLE Mesh 有向转发实战:多跳路由、节点密度与信道占用优化 基于 ESP32 的 BLE Mesh 有向转发实战:多跳路由、节点密度与信道占用优化文章目录基于 ESP32 的 BLE Mesh 有向转发实战:多跳路由、节点密度与信道占用优化一、二十个节点之后,Mesh 开始不听话了二、系统总体架构三、硬件选型与接线3.1 器件选型表3.2 接线总览3.3 引脚与接口接线表3.4 安装位置与信道规划四、软件流程设计4.1 转发判定:DF 与托管泛洪的差异4.2 路由表结构与老化策略4.3 路由建立与收敛流程4.4 低功耗节点与 Friend 特性五、完整代码实现5.1 工程结构5.2 数据结构5.3 路由表管理与老化5.4 转发判定核心逻辑5.5 路由请求与应答5.6 Friend 节点配置5.7 主循环与周期任务六、关键参数与容量规划七、部署与联调步骤八、常见问题排查九、总结与扩展一、二十个节点之后,Mesh 开始不听话了上一篇文章《基于 ESP32 的 BLE Mesh 组网智能家居实战》讲的是怎么把一个三室两厅的网络搭起来,当时那套方案跑得很顺,直到第二年客户又找上门。这次是个叠拼别墅,三层,带一个下沉庭院和两个采光很差的卫生间。业主在智能家居上砸了不少钱:全屋 46 个灯控节点、12 个开关面板、8 个温湿度传感器、4 个窗帘电机,加上 6 个中继。设备装完那天一切正常。问题出现在第三周。最典型的现象是"三楼卧室的灯偶尔不响应"。不是不亮,是延迟——从按下开关到灯亮,有时候要 3 秒以上,有时候按了根本没反应,得再按一次。我们最初怀疑是干扰,查了 Wi-Fi 频段、查了供电稳定性、查了节点信号强度,都没问题。真正的原因是在一次夜里的排查中浮出来的。那天我们把中继节点逐个断电测试,发现了一个让人后背发凉的事实:只要 6 个中继节点里有 4 个在同一个区域上线,这个区域内的节点互相通信就开始丢包。原因不难理解,但接受起来很难。BLE Mesh 默认用的是托管泛洪(managed flooding):一条报文发出来,范围内所有中继节点都会检查"这条消息我见过吗",没见过就转发一遍。于是每发一条消息,网络里就要有 N-1 次重传。我们的网络当时是这样的:区域节点数说明一楼客厅