选协议本质是在做取舍

“智能家居该用哪种协议”是一个经常被问、但很少被答好的问题。因为它没有统一答案：同一套房子里，门磁用 WiFi 会三个月换一次电池，摄像头用 Zigbee 又根本传不动视频流。真正的选型方法是先明确这个设备的三个约束，再看协议能不能满足。

先问供电方式，再问数据量，最后问是否需要中继——把这三件事定下来，协议基本就只剩一两个候选。

三个约束的具体含义是：供电方式决定了功耗预算，电池设备通常只有几十微瓦的平均功耗预算，而常电设备可以忽略这项；数据量决定了带宽需求，开关状态只需几个字节，视频流却需要几兆比特每秒；覆盖范围决定了是否需要网状中继，水泥墙多的大户型尤其明显。

WiFi：带宽充裕的耗电大户

WiFi 的优势一目了然：路由器家家都有，不需要额外网关；带宽足够，摄像头、智能音箱、大屏这类设备几乎没有替代方案；生态最成熟，联网即用。它的短板同样明确，而且都和“为高带宽设计”这一出发点有关。

  • 功耗高：WiFi 收发时的峰值电流常在百毫安级，即使采用省电模式，平均电流也远高于低功耗协议，电池设备往往只能撑几周到几个月。
  • 连接容量有限：普通家用路由器同时稳定承载几十台设备已属不易，设备一多就会出现随机掉线。
  • 配网相对麻烦：多数设备只支持 2.4GHz 频段，双频合一的网络常常导致配网失败。
  • 依赖路由器与云端：部分设备断网后连本地控制都无法完成。

结论很清晰：WiFi 适合常电、高带宽、数量不多的设备——路由器本身、智能音箱、摄像头、电视。凡是靠电池供电且数量成规模的传感器，尽量不要用 WiFi。

Zigbee 与 Thread：低功耗网状网络

Zigbee 与 Thread 属于同一类思路：低速率、低功耗、自组网。设备之间可以互相转发电报文，形成网状拓扑，因此只要节点分布得开，信号就能绕过墙体一路兜到网关。两者的关键差异在寻址与生态。

Zigbee 与 Thread 的关键差异
  • 寻址方式Zigbee 传统上使用自有寻址体系；Thread 直接基于 IPv6，每个节点都有可路由地址，与其他 IP 网络天然互通。
  • 互联标准Thread 是 Matter 的主要承载网络之一，Zigbee 设备则通常经由厂商网关转换后进入统一中枢。
  • 组网角色两者都依赖常电设备充当路由节点，纯电池设备通常作为终端节点不转发报文，部署时要注意这一点。
  • 干扰环境两者都工作在 2.4GHz 频段，与 WiFi 共享频谱，需要通过信道规划减少冲突。

使用网状网络有一条容易被忽略的部署原则：常电的路由节点要均匀铺开。如果全屋只有网关附近有一个常电节点，那么离网关最远的电池传感器其实一直在借道离它最近的邻居，一旦邻居断电，最远的设备就会失联。因此智能插座、常电灯具在这类网络里不只是用电设备，更是网络基础设施。

蓝牙与 BLE Mesh：配网与近场

经典蓝牙在智能家居里的存在感通常在“配网”和“近场”两个环节：设备首次上电时用蓝牙与手机通信完成配网，之后切换到 WiFi 或 Thread 工作；门锁、体重秤这类近距离交互设备也常驻蓝牙。BLE Mesh 则把蓝牙扩展到网状组网，让灯带、灯控等设备能互相转发指令。

BLE Mesh 的特点是配网体验好、成本低、延迟可控，缺点是对网关的依赖和生态相对薄弱：手机通常无法直接与 Mesh 网络通信，需要专门的网关或中枢转发。因此在灯控、氛围照明这类场景表现良好，在需要全屋统一编排的场景中则更依赖中枢的抽象能力。

三种不同覆盖范围的信号波纹并置对比的扁平插画
左起三组波纹代表不同的覆盖与穿透能力：范围越大、能耗往往越高。理解这层取舍，比记住参数表更有用。

用计算代替感觉：两组估算

选型讨论中最常见的分歧来自“感觉”——有人觉得 WiFi 设备也能撑一年，有人觉得 Zigbee 一定省电。与其争论，不如把功耗算出来。下面的估算模型足够简单，却能把量级差异一次性讲清楚。

# 用占空比估算电池寿命：平均电流 = 工作电流×占空比 + 休眠电流
def battery_life_years(capacity_mah, active_ma, sleep_ma, duty_ratio):
    i_avg_ma = active_ma * duty_ratio + sleep_ma
    if i_avg_ma <= 0:
        return float("inf")
    return capacity_mah / i_avg_ma / (24 * 365)

# 同一颗门磁，两节 AA 电池约 2000mAh，仅通信方式不同
wifi   = battery_life_years(2000, 120, 2.0,  0.02)    # 每次上报约 2 秒
zigbee = battery_life_years(2000, 30,  0.02, 0.001)   # 帧更短、休眠更省

print(f"WiFi 方案预估续航  : {wifi:.2f} 年")
print(f"Zigbee 方案预估续航: {zigbee:.2f} 年")

运行结果是 WiFi 约 0.05 年、Zigbee 约 4.6 年，差距接近两个数量级。这就是为什么门磁、水浸、温湿度传感器几乎清一色采用低功耗协议——不是偏好问题，而是物理约束决定的。

第二个需要算的是网络的采集压力。同一网关下挂的设备越多，轮询一轮所需时间越长，一旦占空比接近上限，就会出现丢包与延迟。下面这段代码用帧长与节点数估算单轮占空，指导是否需要对设备分组或调整上报周期。

# 估算单轮轮询占空比：帧耗时 × 节点数 / 轮询周期
def duty(frame_ms, nodes, period_ms):
    return frame_ms * nodes / period_ms

for nodes in (20, 50, 100):
    d = duty(frame_ms=30, nodes=nodes, period_ms=1000)
    level = "已超载，需缩短帧长或分组上报" if d > 0.7 else "余量充足"
    print(f"节点数 {nodes:>3}：单轮占空 {d * 100:>4.0f}%  {level}")

按每帧 30 毫秒、周期 1 秒计算，50 个节点时占空比已经接近 1.5 倍上限，说明必须分组或者把上报周期拉长到数秒。这类估算在规划阶段花十分钟，能避免上线后花两周排查随机丢包。