一、慢到什么程度

算一下就知道了：

1 KB 要三十多毫秒，10 KB 要三分之一秒：这个速率传不了图、传不了语音，连一张缩略图都吃力。 所以它从设计上就不是给「人看的东西」用的。 它的目标场景根本不需要速率：温度传感器每 60 秒发 4 个字节，平均占用 0.5 bps； 门磁平时不动，平均 0 bps。 这些设备的「平均占空比」低到千分之一以下，250 kbps 的容量够接上千个。

二、省电靠三件事

三条，缺一不可：

第一行是主力：电池供电的设备，「睡」的时候电流只有几微安，「发」的时候是几十毫安。 所以「一秒发一次」和「一分钟发一次」，电池寿命差几十倍。 这就是为什么传感器都设计成「定时上报」而不是「实时上报」。 第三行那个「协议栈简单」很关键：ZigBee 芯片通常只有几十 KB 的 Flash、几 KB 的 RAM， 而 WiFi 芯片要几百 KB 起步。 芯片越小，静态功耗越低——这是「简单」在电池设备上的直接价值。 所以「一颗纽扣电池两年」不是靠某一项技术： 是「低占空比 + 小功率 + 小芯片」三件事乘出来的结果。 换成 WiFi 做同样的事，电池撑不过一天。

三、它还会自组网

这是它和蓝牙最大的差别：

第一行的「网状」意味着「信号可以跳着走」： 一个传感器到网关太远，可以经过中间的路由节点转两次。 所以「覆盖范围」不是「一个网关的半径」，是「整个网状的半径」。 第三行那个「上千节点」是它相对蓝牙的硬优势： 一栋楼的灯、一层的插座、一个厂区的表计，都是几十上百个点。 蓝牙连 7 个就满了，ZigBee 能连几百个。 但自组网有代价：路由节点必须一直醒着（不能睡），所以它们通常要接电源。 于是「电池设备」和「路由设备」在同一个网里分工不同—— 这也是 ZigBee 网络里「哪些是电池设备、哪些是常电设备」必须规划清楚的原因。

四、动手 Demo：ZigBee 慢得离谱，为什么还活着

先算「传多少字节约要多久」，再算几种传感器设备的「平均占用」。 最后那张表才是关键：平均占用只有几个比特每秒。

for n in (16, 128, 1024, 10240):
    print('%6d 字节需要 %.1f 毫秒' % (n, n * 8 / 250000.0 * 1000))

print('温度传感器：每 60 秒 4 字节 -> 平均 %.1f bps' % (4 * 8 / 60.0))
print('电表：每 15 分钟 20 字节 -> 平均 %.2f bps' % (20 * 8 / 900.0))
print('250 kbps 够接 %d 个温度传感器' % int(250000 / (4 * 8 / 60.0)))

实跑输出：

--------------------------------------------------------------------
ZigBee 慢得离谱，为什么还活着
--------------------------------------------------------------------
**ZigBee 的速率只有 250 kbps，比 2G 还慢。**可它活得很好——因为它优化的不是速率，
是「一颗纽扣电池能用两年」。

**先看速率有多慢**：
  要传的字节     需要毫秒（250 kbps 理想值）
  -------------------------------------------
  16             0.5
  128            4.1
  1024           32.8
  10240          327.7

**1 KB 要三十多毫秒，10 KB 要三百多毫秒**：**这个速率传不了图、传不了语音，连一张缩略图都吃力。**
**但它的目标场景根本不需要速率**：
  设备           数据量                 平均占用
  -------------------------------------------------------
  温度传感器     每 60 秒 4 字节        **平均 0.5 bps**
  门磁           事件触发 6 字节        **平时 0 bps**
  智能灯泡       开关指令 8 字节        **平时 0 bps**
  电表           每 15 分钟 20 字节     **平均 0.2 bps**

**第三列才是关键：它们的平均占用是「几个比特每秒」的量级**，
**250 kbps 的容量够接上千个这样的设备。**
**所以 ZigBee 的设计目标从一开始就不是「快」，是「省电 + 能组网」。**
**省电靠三件事**：**一是占空比极低（99% 的时间在睡）**；**二是发射功率小（室内十几米）**；
**三是协议栈简单（芯片小、漏电少）。**
**这三条加起来，才有「一颗电池两年」。**
**所以判断一个物联网技术该不该用，别看速率表**：
**先算「平均占空比」，再看「要不要自己组网」**——
**占空比低、要自组网、量大便宜，就是 ZigBee 的场子；**
**要传图传声，就得上 WiFi 或者蜂窝。**

1 KB 要 32.8 毫秒、10 KB 要 327.7 毫秒：这个速率连一张小图都传不动， 所以它从设计上就不服务「人看的界面」。 温度传感器平均只占 0.5 bps：250 kbps 除以 0.5 等于五十万， 理论上一个信道能接几十万个这种设备。 实际受限于协议开销与网络容量，但「上千个」是没问题的。 「平均占空比」这个思路可以推广： 判断一个物联网技术该不该用，先算「平均要多少 bps」，再看「要不要自己组网」。 占空比低、要自组网、量大便宜，就是 ZigBee 的场子； 要传图传声，就得上 WiFi 或者蜂窝。

30 秒实验

1. 算一下：一个「每 10 分钟发 50 字节」的水表，平均占用多少 bps？
2. 想一下：为什么 ZigBee 的「路由节点」通常要接电源，不能靠电池？
3. 对比一下蓝牙 5.0 的「长距离模式」，看它会不会抢 ZigBee 的场景。

常见误区

1. 以为 ZigBee「因为便宜才活下来」。 便宜是一部分，主要是「低功耗 + 能自组网」。
2. 以为「速率低就是落后」。 它优化的是占空比，250 kbps 对传感器绰绰有余。
3. 以为「所有节点都能靠电池」。 路由节点必须常醒，所以通常要接电源。

下一节换话题：拨号上网用的 PPP，为什么现在还在用。

• ☐ （本节完，下一节 3.5.1 PPP定义）

相关笔记

• WiMAX
• PPP定义
• 📚 图解TCP／IP · 索引