4、无线通信协议对比：Zigbee、BLE Mesh、Wi-Fi、Thread 的延时特性
做照明控制，选无线协议是个头疼事。
我见过太多项目，前期没仔细评估延时，结果装上去发现灯控响应慢半拍。用户一挥手，灯要等几百毫秒才亮，体验极差。今天咱们就把 Zigbee、BLE Mesh、Wi-Fi、Thread 这四兄弟的延时特性掰开揉碎讲清楚。
4.1 先搞清楚延时的构成
很多人以为延时就是「发出去到收回来」的时间。其实没那么简单。
一个完整的控制链路，延时由三部分组成：
- 协议栈处理延时：数据从应用层到物理层，再回来的时间。这部分跟协议栈实现质量关系很大。
- 空中传输延时：射频信号在空气中传播的时间。说实话，这个在室内场景基本可以忽略，光速太快了。
- 网络调度延时：节点等待信道空闲、等待时隙、等待信标的时间。这是大头。
我习惯把前两个叫「硬延时」，第三个叫「软延时」。软延时才是我们优化的主战场。
核心观点：照明控制场景下，网络调度延时通常占总延时的 80% 以上。选协议时，重点看它的调度机制。
4.2 Zigbee 的延时特性
Zigbee 在照明领域是老大哥了。它的延时表现，嗯，中规中矩。
典型延时数据：
- 单跳点对点：15-30ms
- 多跳（3跳）：50-80ms
- 加入网络：200-500ms
为什么会有这个范围？因为 Zigbee 有两种模式：
- 信标模式：节点必须等信标帧才能通信。信标间隔可配，默认 15.36ms。你想想看，如果刚好错过一个信标，就得等下一个，这 15ms 就搭进去了。
- 非信标模式：节点可以随时发，但需要先做 CSMA/CA 信道检测。冲突了就得退避重试。
我在项目中遇到过一个问题：一个 Zigbee 网络里挂了 80 个灯，用的信标模式。结果发现有些灯响应要 200ms 以上。查了半天，是信标间隔设得太长，加上路由节点处理不过来。后来把信标间隔调到 5ms，延时降到了 40ms 以内。
避坑指南：Zigbee 的延时跟网络规模强相关。节点越多，冲突概率越大，延时越不稳定。我曾经在一个 200 节点的项目里，实测延时抖动从 20ms 到 300ms 不等。所以，Zigbee 适合中小规模网络，别贪多。
4.3 BLE Mesh 的延时特性
BLE Mesh 是后来者，很多人觉得它功耗低就选它。但延时嘛，有点一言难尽。
典型延时数据：
- 单跳：20-50ms
- 多跳（3跳）：100-300ms
- 加入网络：1-3秒
为什么会这么慢？说白了，BLE Mesh 用的是「泛洪」机制。一个消息发出去，所有节点都转发。好处是可靠性高，坏处是——延时爆炸。
你想想看，一个消息要经过 3 跳，每跳都要做：
- 接收完整数据包
- 检查是否转发过
- 重新封装发送
每跳至少 30-50ms 就没了。
我记得有一次帮客户调试 BLE Mesh 的灯控系统，20 个灯组网，从手机发指令到所有灯亮起，平均要 1.2 秒。客户直接说「这不行，用户会骂人的」。后来我们改用了定向转发，把延时压到了 200ms 以内，但代价是网络复杂度上去了。
注意：BLE Mesh 的延时跟消息类型也有关系。可靠消息（需要 ACK）比不可靠消息慢 2-3 倍。照明控制里，开关指令可以用不可靠消息，但调光指令最好用可靠消息，否则丢包了灯就停在半路了。
4.4 Wi-Fi 的延时特性
Wi-Fi 大家最熟悉。家里路由器一装，手机连上就能用。但 Wi-Fi 做照明控制，有它的特殊性。
典型延时数据：
- 单跳（AP到设备）：5-15ms
- 多跳（Mesh Wi-Fi）：20-50ms
- 加入网络：2-5秒
Wi-Fi 的延时优势很明显：带宽大、处理快。但问题也突出：
- 竞争激烈：Wi-Fi 信道就那几个，手机、电视、电脑都在抢。你发一个灯控指令，可能得等别的设备发完。
- 功耗高：Wi-Fi 模块待机电流几十毫安，电池供电的设备扛不住。
- 连接数限制：普通家用路由器带 20-30 个设备就吃力了。商用 AP 能带 100 个左右，但价格也上去了。
我个人的经验是：Wi-Fi 适合做网关或者控制中心，不适合做终端节点。比如用 Wi-Fi 的智能音箱做语音控制，然后通过 Zigbee 或 Thread 去控制灯，这样延时和功耗都能兼顾。
一个真实案例：某智能家居项目，全部用 Wi-Fi 灯。结果用户家里 50 个灯加上其他设备，路由器直接死机。后来改成 Wi-Fi 网关 + Zigbee 灯，问题解决。Wi-Fi 的延时优势在大量设备面前，会被调度开销吃掉。
4.5 Thread 的延时特性
Thread 是后起之秀，基于 IPv6 的 Mesh 网络。说实话，我一开始对它持怀疑态度，但用下来发现，延时表现确实不错。
典型延时数据：
- 单跳：10-20ms
- 多跳（3跳）：30-60ms
- 加入网络：300-500ms
Thread 的延时优势来自它的调度机制：
- 使用 TDMA 和 CSMA 混合调度，关键消息可以抢占时隙
- 路由机制优化过，多跳时延增加比较线性
- 支持低功耗监听模式，待机时也能快速响应
我在一个智能楼宇项目里用过 Thread，200 个灯节点，控制延时稳定在 50ms 以内。说实话，这个表现让我挺意外的。后来查了资料才知道，Thread 的协议栈在延时方面做了很多优化，比如消息聚合、快速重传等。
个人建议：如果你做的是新项目，没有历史包袱，Thread 是个不错的选择。它延时低、功耗低、安全性好。但要注意，Thread 的生态还在发展中，芯片和模块的选择没有 Zigbee 那么丰富。
4.6 四者对比总结
好了，咱们把四个协议放在一起看看：
| 协议 | 单跳延时 | 多跳延时（3跳） | 入网延时 | 延时稳定性 | 适用场景 |
|---|---|---|---|---|---|
| Zigbee | 15-30ms | 50-80ms | 200-500ms | 中等 | 中小规模照明 |
| BLE Mesh | 20-50ms | 100-300ms | 1-3秒 | 较差 | 小规模、低功耗 |
| Wi-Fi | 5-15ms | 20-50ms | 2-5秒 | 较好 | 网关、控制中心 |
| Thread | 10-20ms | 30-60ms | 300-500ms | 好 | 中大规模照明 |
从延时角度看，Wi-Fi 和 Thread 表现最好。但 Wi-Fi 有功耗和连接数限制，Thread 生态还不够成熟。
Zigbee 是「老黄牛」，稳定可靠，但延时上限摆在那里。BLE Mesh 嘛，说实话，做照明控制有点勉强，除非你对延时要求不高。
4.7 选型建议
最后，我根据实际项目经验，给几个选型建议：
- 家庭照明（20-50个灯）：Zigbee 或 Thread。Zigbee 生态成熟，Thread 延时更好。
- 商业照明（100-500个灯）：Thread 优先，或者 Zigbee + 网关方案。别用 BLE Mesh，延时扛不住。
- 工业照明（500+个灯）：建议有线 + 无线混合。无线部分用 Thread 或 Zigbee，关键链路用有线。
- 对延时要求极高（<10ms）：别用无线了，上 DALI 或者 DMX512 有线方案。
最后提醒一句：协议延时只是理论值。实际项目中，芯片性能、协议栈实现、天线设计、环境干扰都会影响延时。我建议你在选型阶段就做原型测试，别等量产了才发现问题。我曾经吃过这个亏，一个项目用了某款 BLE Mesh 芯片，结果实际延时是 datasheet 的 3 倍，最后只能换方案，损失惨重。
好了，这一章就讲到这里。下一章咱们聊聊「低延时控制链路中的时钟同步问题」，这个坑更多，到时候细说。