企业官网建设流程全解析

基于 ESP32 的 BLE Mesh 有向转发实战：多跳路由、节点密度与信道占用优化

一、二十个节点之后，Mesh 开始不听话了

上一篇文章《基于 ESP32 的 BLE Mesh 组网智能家居实战》讲的是怎么把一个三室两厅的网络搭起来，当时那套方案跑得很顺，直到第二年客户又找上门。

这次是个叠拼别墅，三层，带一个下沉庭院和两个采光很差的卫生间。业主在智能家居上砸了不少钱：全屋 46 个灯控节点、12 个开关面板、8 个温湿度传感器、4 个窗帘电机，加上 6 个中继。设备装完那天一切正常。

问题出现在第三周。

最典型的现象是"三楼卧室的灯偶尔不响应"。不是不亮，是延迟——从按下开关到灯亮，有时候要 3 秒以上，有时候按了根本没反应，得再按一次。我们最初怀疑是干扰，查了 Wi-Fi 频段、查了供电稳定性、查了节点信号强度，都没问题。

真正的原因是在一次夜里的排查中浮出来的。那天我们把中继节点逐个断电测试，发现了一个让人后背发凉的事实：只要 6 个中继节点里有 4 个在同一个区域上线，这个区域内的节点互相通信就开始丢包。

原因不难理解，但接受起来很难。BLE Mesh 默认用的是托管泛洪（managed flooding）：一条报文发出来，范围内所有中继节点都会检查"这条消息我见过吗"，没见过就转发一遍。于是每发一条消息，网络里就要有 N-1 次重传。

我们的网络当时是这样的：