ZigBee 网络需要控制多台设备时，寻址方式会影响命令的传输路径、接收范围以及应用层的结果处理。比如，一个控制器需要同时调整 30 台终端的工作状态，既可以逐台发送命令，也可以向多个设备广播，还可以将目标设备划分到指定群组后统一控制。
这三种方式都能用于设备控制，但它们解决的问题并不相同。单播适合明确指定目标，广播适合向一定范围内的设备传递公共信息，组播则适合对具有相同业务关系的设备进行批量操作。真正影响系统设计的，不只是命令发出去需要多少次，还包括网络如何转发消息、如何判断设备是否收到命令，以及部分设备异常时怎样恢复。
一、ZigBee单播、广播与组播的寻址机制
1. 单播：目标明确，适合定向控制
**单播（Unicast）**面向指定的网络目标。控制器向某台终端发送命令时，网络根据目标地址及当前拓扑选择传输路径。如果目标设备不在直接通信范围内，消息可以经过路由节点逐跳转发。
单播的优势是目标明确，适合参数配置、设备查询、故障处理等需要针对某台设备执行的操作。例如，30 台终端中只有一台需要调整采样周期，控制器可以直接向该设备发送配置命令，而不必让其他终端接收并判断是否与自己有关。
但需要注意，单播不等于设备已经完成命令要求的动作。IEEE 802.15.4 MAC 层确认可以表明相应链路上的帧已被接收；如果启用了 APS 确认，还可以获得 APS 层的确认信息。两者的作用范围和含义不同，都不能直接替代设备应用层的执行结果。
如果业务要求确认某台设备已经完成参数修改或继电器动作，应用层仍需设计状态回报、结果码或后续状态查询机制。具体使用哪种确认方式，还要结合协议栈能力和设备固件配置决定。
2. 广播：面向一定范围内的设备
**广播（Broadcast）**使用 ZigBee 定义的广播地址发送消息，不需要逐个指定接收设备。符合接收条件的节点可以处理该消息，具备相应转发条件的路由节点也可能继续传播消息。
广播地址并不只有一种，不同广播地址对应不同的接收范围和转发行为。因此，不能简单地将所有广播都理解为"整个网络中的每台设备必然收到"。实际覆盖范围取决于所使用的广播类型、网络拓扑以及协议栈的处理方式。
广播适用于公共通知、网络范围内的控制信息等场景。例如，控制器需要通知一批设备进入某种工作模式，如果这些设备都应接收相同信息，广播可以避免逐台指定目标。
广播的限制在于接收结果不够明确。IEEE 802.15.4 的普通广播帧不会像可确认的单播帧那样获得逐接收方 MAC 确认。因此，即使命令已经发送，也不能据此判断每台目标设备是否收到，更不能确定它们是否执行成功。ZigBee PRO 网络层可能通过广播事务记录、被动确认等机制处理重复转发和广播可靠性问题，但这些机制并不等于向应用层提供逐设备执行结果。
3. 组播：通过群组关系控制多个设备
**组播（Groupcast）**面向指定群组中的设备。ZigBee 群组由 16 位群组标识区分，应用可以根据设备的业务关系建立群组，例如将同一区域的照明设备划入一个群组，再由控制器统一下发亮度调整命令。
与广播相比，组播的目标范围由群组关系决定。控制器不必在每次操作时逐台列出成员地址，而是向指定群组发送消息。需要强调的是，群组成员关系必须在应用设计中正确维护：设备加入、退出或重新入网后，群组配置也需要保持一致。
组播并不意味着只有群组成员会参与消息传输。根据网络层的转发机制，非群组成员的路由节点也可能承担消息转发工作，但只有符合群组寻址和端点群组关系的设备才应将消息交付相应应用进行处理。
组播尤其适合经常对同一批设备执行相同操作的场景。不过，群组消息通常不提供逐目标设备的端到端确认。控制器不能只凭一次组播发送，就认定所有成员都已执行任务。如果业务需要掌握每台设备的实际状态，就必须在应用层增加状态回报、超时判断或异常设备补查。
二、寻址方式如何影响网络通信开销
比较单播、广播和组播时，不能只计算控制器发送了几次消息。消息还可能经过多个路由节点，网络需要处理转发、重复消息抑制、链路重传和状态回报等工作。实际开销与网络拓扑、节点分布、通信距离、消息长度、发送频率及协议栈实现都有关系。
以 30 台终端执行同一项控制任务为例，三种方式的差异主要体现在以下几个方面。
| 比较维度 | 单播 | 广播 | 组播 |
|---|---|---|---|
| 目标确定方式 | 指定设备地址 | 指定广播地址及其覆盖范围 | 指定群组标识 |
| 典型适用任务 | 单台配置、状态查询、故障处理 | 公共通知、范围性控制 | 固定设备集合的批量控制 |
| 消息传输 | 可经路由逐跳转发 | 可能由符合条件的路由节点继续转发 | 可能涉及路由转发，具体行为取决于协议栈 |
| 接收结果 | 可结合确认机制判断，但须区分确认层级 | 通常无法直接获得逐设备接收结果 | 通常无法直接获得逐成员接收结果 |
| 主要设计成本 | 多台设备逐一发送时，控制器和网络需处理多次事务 | 接收范围及可靠性处理需要明确 | 群组维护及成员状态管理需要设计 |
如果控制器依次向 30 台终端发送单播命令，通常需要发起多个独立的发送事务；如果使用广播或组播，一次逻辑发送便可以面向多个目标。但这并不意味着广播或组播的网络总开销必然更低，也不代表它们一定能更快完成业务。
例如，单播可以对关键设备进行定向确认和补发；组播虽然便于批量下发，却可能需要额外收集成员状态；广播的接收范围更广时，也可能让不需要处理该业务的设备消耗额外的接收与处理资源。因此，选型应围绕实际业务目标，而不是仅以发送次数判断效率。
三、批量控制不能只设计命令下发
对应用开发而言，寻址方式只是控制流程的一部分。真正需要设计的是：命令发出后，系统如何判断任务进展，以及发现异常时怎样处理。
可以将批量控制任务拆分为四个环节。
第一步：明确目标集合。 如果任务只涉及某台设备，使用单播通常更直接；如果所有符合范围条件的设备都需要接收公共信息，可以考虑广播；如果目标设备具有明确的业务分组关系，组播更便于统一管理。选择之前，应先确认目标范围是否准确，而不是先追求减少发送次数。
第二步：定义命令的成功条件。 需要区分消息发送成功、协议层确认、应用收到命令以及设备完成动作这几个不同状态。例如，控制器成功发送一条继电器控制命令，不代表继电器已经切换到目标状态。如果业务要求动作可验证，就应明确由设备返回什么状态，以及控制器依据什么条件判定成功。
第三步：处理超时和异常设备。 单播任务可以针对未获得预期响应的设备单独查询或重试。广播和组播任务则需要通过设备状态回报、预期成员清单和超时机制识别未完成任务的设备，再根据需要转为定向补查或重试。重试之前还要考虑命令是否具备幂等性：重复设置某个目标值与重复执行一次计数、脉冲或切换动作，可能产生不同结果。
第四步：形成任务结果。 对于要求所有设备完成操作的业务，控制器应根据预期目标清单和实际结果生成完成、部分完成或失败等状态。若业务允许部分设备暂时离线，也应提前定义允许的缺失数量或完成条件，而不是把"命令已发出"作为整个任务的结束标志。
这一流程的关键不是为每种寻址方式重复实现一套机制，而是将目标选择、消息发送、结果收集和异常恢复分开设计。这样，后续即使从逐台单播调整为组播，应用层的业务判定逻辑也不必全部推倒重来。
四、ZigBee应用开发中的几个注意事项
1. 群组关系必须与业务目标一致
组播是否适用，首先取决于目标设备是否能够稳定地归属于同一个群组。若群组成员频繁变化，设备重新入网后没有及时恢复群组配置，或者不同端点的群组关系维护不一致，控制器即使发送了正确的群组消息，也可能无法得到预期的业务结果。
因此，群组设计不仅包括群组标识，还应包括成员加入与退出、设备重入网后的配置恢复，以及群组信息与设备实际业务状态的一致性维护。
2. 可靠性要求决定确认和补偿机制
并非所有业务都需要逐设备确认。对于允许个别设备延迟更新的公共信息，较轻量的发送方式可能已经满足需求；对于照明控制、阀门控制或其他需要核对设备实际状态的任务，则应根据业务风险决定是否收集逐设备状态。
如果采用组播或广播进行批量下发，也可以将控制与核验分开：先统一下发命令，再通过设备主动上报或控制器定向查询核实结果。这样既保留了批量发送的便利，也避免把无逐设备确认的消息误判为全体执行成功。
3. 测试应验证业务结果，而非只观察无线状态
工程验证需要同时关注寻址和应用行为。测试时可以记录目标设备清单、命令发送结果、协议确认信息、设备状态回报、超时数量以及补查结果，并在不同拓扑和负载条件下比较任务完成情况。
对于组播，还应测试成员加入、退出及部分节点离线等情况；对于广播，需要确认所用广播地址的实际覆盖范围和协议栈处理行为；对于单播，则应验证多跳路径、确认超时和重试逻辑是否符合预期。
测试结果应明确测试条件、固件版本、网络规模和成功判定标准。没有这些信息，仅凭某一次发送成功或某个节点亮灯，无法推导出整个网络的可靠性结论。
五、结合 WS8806 进行模组应用设计
无声讯通（Silent Smart）的 WS8806 采用 Silicon Labs EFR32MG21 芯片，工作于 2.4 GHz 频段，产品资料给出的发射功率最高约 20 dBm，并提供 UART 接口，可用于 ZigBee 设备的嵌入式集成。
在实际应用中，控制器或主控 MCU 可以通过模组提供的接口与 ZigBee 通信功能交互，再根据具体固件支持的能力实现设备寻址、命令下发和业务状态处理。若项目需要使用单播、广播或组播，应在选型和开发阶段核实模组固件的寻址接口、群组管理方式、确认机制以及相关返回信息，不能仅凭芯片支持 ZigBee 就推断产品固件已经开放全部功能。
WS8806 的 STATUS 引脚用于指示模组唤醒状态，ASSOCIATE 引脚用于指示连接状态。这些信号可以辅助主控观察模组状态，但不能代替应用层对目标设备执行结果的核验。尤其是在组播或广播控制中，即使本地模组处于正常工作或连接状态，也不能据此认定所有目标终端都已收到命令。
因此，基于 WS8806 开发批量控制功能时，应先核实具体固件接口和协议栈行为，再根据业务要求设计状态回报、异常补查和任务完成判定。硬件选型、协议能力和应用层可靠性是相互关联但不能相互替代的三个环节。
结语
ZigBee 单播、广播与组播分别适合定向控制、范围性通知和群组批量操作。工程设计的重点不仅是选择哪种寻址方式，还要明确消息确认的含义、设备执行结果的判定方法，以及异常设备的恢复流程。
对于嵌入式开发项目，先定义目标范围和成功条件，再选择寻址方式并设计结果闭环，通常比单纯追求减少发送次数更有价值。
无声讯通（Silent Smart）｜物联网应用方案提供商与无线通讯解决者