基于 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 次重传。
我们的网络当时是这样的：
| 区域 | 节点数 | 说明 |
|---|---|---|
| 一楼客厅 |
