ZigBee单播、广播与组播怎么选？从寻址机制看通信效率

ZigBee 网络需要控制多台设备时，寻址方式会直接影响消息的目标范围、传输过程和结果确认。以一个包含 30 台终端的网络为例，控制器可以逐台发送命令，也可以通过广播或组播面向多个设备发送信息。三种方式都能用于设备控制，但不能简单地认为发送次数越少，网络效率就越高。

真正需要判断的是：目标设备是否明确、消息应该传播到什么范围、业务是否要求逐台确认，以及设备未完成任务时能否及时发现。只有把这些条件与 ZigBee 的寻址和转发机制结合起来，才能选出合适的通信方式。

一、单播、广播与组播的核心区别

单播（Unicast）：面向指定目标

**单播（Unicast）**通过目标地址指定通信对象，适合设备配置、状态查询和定向控制。如果目标设备不在发送节点的直接通信范围内，消息可以通过路由节点逐跳转发。

单播的特点是目标明确，便于围绕某台设备建立独立的通信事务。例如，控制器只需修改 30 台终端中某一台的采样周期，就可以向该设备发送配置命令，不必让其他终端参与这项业务处理。

单播也便于定向核验，但需要区分确认机制。IEEE 802.15.4 MAC 层确认反映相应链路上的帧接收情况；启用 APS 确认时，获得的是 APS 层相应的确认信息。具体行为取决于协议栈和配置。两者都不能直接证明设备已经完成应用层动作，涉及继电器切换、参数修改等业务时，仍需根据要求核对设备状态。

广播（Broadcast）：面向协议规定的接收范围

**广播（Broadcast）**使用 ZigBee 定义的广播地址发送消息，接收与转发范围取决于广播类型及协议规则。符合条件的节点可以接收消息，满足转发条件的路由节点也可能继续传播消息。

广播适合公共通知和范围性控制信息。例如，控制器需要向一定范围内的设备发布统一的工作模式通知，就不必逐个指定目标地址。

但广播并不意味着网络内每台设备都必然收到消息。网络拓扑、节点状态、广播地址类型以及协议栈行为都会影响实际传播结果。ZigBee PRO 网络层可以使用广播事务记录等机制抑制重复转发，并根据实现采用相应的被动确认机制，但这些机制不能等同于逐台设备的应用层执行确认。

因此，广播的关键不是简单地扩大接收范围，而是确认这种传播范围是否符合业务需求，以及业务能否接受无法直接获得逐设备结果的限制。

组播（Groupcast）：面向指定群组

**组播（Groupcast）**通过群组标识确定目标设备集合。ZigBee 群组标识为 16 位，应用可以按照区域、功能或控制关系组织设备。例如，同一区域的灯具可以归入一个群组，由控制器统一发送亮度调整命令。

组播适合目标集合相对明确、成员关系能够持续维护的批量控制任务。与广播相比，它的业务目标由群组关系定义，而不是单纯依靠广播地址及其覆盖范围。

需要注意，群组寻址不意味着只有群组成员参与消息转发。部分非群组成员的路由节点仍可能承担网络层转发工作，但消息是否交付相应应用进行处理，要依据寻址和群组关系判断。

组播通常不提供逐个目标设备的端到端确认。如果业务要求核实每台设备是否执行成功，就需要另外设计状态回报或定向查询机制。群组成员发生变化时，也必须及时维护相关配置，否则即使消息发送正常，实际控制对象仍可能与预期不一致。

二、通信效率不能只看发送次数

三种寻址方式的开销，来自不同环节。比较时如果只统计控制器发送了几次命令，就容易忽略网络转发、链路重传、确认信息和业务结果回报。

以 30 台终端接收同一条控制命令为例，逐台单播通常意味着控制器需要分别发起多个通信事务；广播或组播则可以一次面向多个目标发送消息。但这并不能直接推出广播或组播的整体网络开销一定更低。

原因在于，发送次数、网络传播成本和业务完成成本是三个不同的指标。单播可能需要多次发送，但能够针对特定设备进行确认和补发；组播减少了逐台指定目标的需要，却可能需要额外收集设备状态；广播的覆盖范围如果超出实际需求，也可能造成不必要的接收和处理。

此外，路由跳数、设备分布、信道竞争、消息长度、发送频率和重传情况都会改变实际开销。因此，在没有固定网络拓扑、协议栈配置和测试条件的情况下，不宜直接给出三种方式的固定效率排名，更不能用未经测试的比例推导性能提升。

三、工程选型应从四个条件判断

1. 目标设备是否明确

如果业务针对单台设备，例如修改参数、读取状态或处理故障，单播通常更直接。如果目标是具有稳定业务关系的一组设备，可以考虑组播。如果消息面向符合特定范围条件的节点，且不需要逐个指定接收对象，可以评估广播。

这里首先要明确的是业务目标，而不是先决定如何减少发送次数。

2. 是否需要逐台确认

如果任务要求控制器明确知道某台设备的状态，单播通常更容易开展定向核验。广播和组播可以用于统一下发命令，但如果必须确认每个目标是否执行成功，就要增加应用层状态回报、超时判断或定向查询。

对于批量控制，可以把消息下发与结果核验分开：先采用合适的方式发送命令，再针对未返回预期状态的设备进行补查。这样能够避免把“发送成功”误判为“所有设备执行成功”。

3. 目标集合是否稳定

组播是否合适，取决于群组成员关系能否正确维护。对于区域照明、分区控制等设备集合相对稳定的业务，群组管理通常具有明确的应用价值；如果目标设备频繁变化，则需要考虑成员更新、重新入网后的配置恢复，以及群组状态与实际业务关系的一致性。

广播不依赖同样的群组成员配置，但必须确认广播地址所对应的接收范围符合需求，不能将其当作无差别的全网可靠送达机制。

4. 任务是否允许部分设备未完成

对于允许设备延迟更新的公共通知，较轻量的消息传播方式可能已经满足业务要求。对于需要核对每台设备实际状态的控制任务，则必须定义完成条件，并考虑超时、补查和重试。

重试策略还应与命令语义相匹配。例如，重复设置一个目标亮度值，与重复执行一次状态翻转动作，可能产生不同后果。工程设计需要先明确命令能否安全重复执行，再确定异常恢复策略。

四、结合 WS8806 的模组应用设计

无声讯通（Silent Smart）的 WS8806 采用 Silicon Labs EFR32MG21 芯片，工作于 2.4 GHz 频段，产品资料标称发射功率约 20 dBm，并提供 UART 接口，可用于 ZigBee 无线通信设备的集成。

实际开发时，主控 MCU 通过模组提供的接口与无线通信功能交互。项目如果需要使用单播、广播或组播，应先核实具体固件开放的寻址接口、群组配置方式、确认机制和返回信息，不能仅根据底层芯片具备 ZigBee 能力，就认定现有固件已经支持所有相关操作。

WS8806 的 STATUS 引脚用于指示模组唤醒状态，ASSOCIATE 引脚用于指示连接状态。这些信号可以辅助主控了解模组自身的运行状态，但不能代替对目标终端接收情况和实际执行结果的核验。

对于批量控制项目，测试应覆盖正常通信、部分设备离线、群组成员变化和状态回报超时等情况，并记录网络规模、拓扑、固件版本和成功判定标准。只有测试条件与结果定义明确，才能据此评估寻址方式是否满足具体项目的要求。

结语

ZigBee 单播、广播与组播分别适用于定向通信、范围性通知和群组批量控制。工程选型的关键是匹配目标范围、确认需求和设备管理方式，而不是单纯追求更少的发送次数。