蓝牙 Mesh 群控：有一盏灯没亮，要不要整组重发？

设想这样一个现场：按下会议室的“全部开灯”，大部分灯亮了，角落里有一盏没动。手机却提示“发送成功”。

你又点了一次。现在灯都亮了，但另一个问题来了：以后每次群控，都要靠人抬头检查吗？

最容易想到的办法，是让每盏灯都回一句“收到了”，没回的就再发。

这个思路能提供更多反馈，但如果所有设备一起回答、控制器又不停追问，确认消息本身也可能成为负担。

先给结论：不要一看到缺少反馈就整组重发。先分清三件事——命令有没有发出去、设备报告了什么状态，以及灯实际上有没有亮。它们不是同一份证据。

上述会议室是解释问题的假设场景，不是现场测试报告。本文讨论 SIG Mesh 的组播与模型消息，不代表米家等具体产品的实现；没有实测成功率、时延或节点容量。文中的状态管理与补偿流程为工程建议，不是协议自动提供的完整方案。

一、“发送成功”，到底成功到了哪一步？

手机上的四个字，可能只表示应用已把请求交给网关，也可能表示模组接受了发送任务。具体含义，要查应用接口和日志，不能从提示文字猜。

把证据分成三层，问题会清楚很多：

第一层：发送端接受了任务。 说明控制请求走到了某个发送环节，不足以证明目标灯已经收到。

第二层：收到了目标模型的状态。 比如 Generic OnOff Status，报告的是对应元素的 Generic OnOff 状态。要识别消息来源，区分当前值、目标值，以及适用时的剩余过渡时间。

第三层：实际照明效果符合要求。 这还涉及驱动、电源、光源和现场条件。模型说“开”，不等于它带有独立光学检测，更不能凭软件状态排除灯珠或驱动故障。

三层不是要求每次操作都增加三套确认，而是提醒你：界面上写到哪一步，证据就应该支持到哪一步。

你先查什么？ 找到“发送成功”对应的代码或接口说明，确认它是请求入队、模组返回，还是目标状态回报。这个定义不清，后面的成功率统计就可能从起点算错。

二、一条组命令，为什么不能当成一份全员签收单？

SIG Mesh 常用发布、订阅机制做组控：开关向组地址发送消息，灯上的相关模型订阅这个地址。

这更像“对会议室这个组说一句开灯”，而不是控制器依次拨通每盏灯的电话。

它的好处，是不必把同一个控制意图逐台发送。但组地址本身不会替你生成一张“所有预期成员都已执行”的清单。

首先，预期成员是谁，需要管理侧知道。 新装的灯有没有配好对应模型订阅？更换过的设备是否还在旧清单里？这些不能只靠收到几条状态消息倒推。

其次，收到状态的节点，不一定覆盖了全部成员。要按预期元素和模型核对，不能简单数数据包：同一来源的重复消息，不是多一盏灯完成。

你先查什么？ 拿安装清单与实际配置对照，确认模型、AppKey 绑定和组订阅。若只是某盏灯持续不响应，先看它是否真的在这个控制组里，不要立刻把所有中继和重传参数调大。

三、让所有灯都回复，不是更可靠吗？

先看协议里的两种消息。以 Generic OnOff 为例：

• Generic OnOff Set 是需要模型响应的消息，其响应是 Generic OnOff Status。
• Generic OnOff Set Unacknowledged 不要求针对该请求返回模型响应。

这里说的是模型层响应，不是把底层传输确认、网关接口回包和业务执行结果混成一个“ACK”。

在一对一操作中，等待对应设备的响应很有用。但同一条组命令如果让许多节点响应，接下来占用无线资源的，就不只是一条控制消息了。

Bluetooth SIG 的规模设计文章专门讨论了这个问题：大批节点响应组播请求，再叠加控制器的追问和重试，可能形成密集消息流。它建议产品设计重视无确认消息在多播控制中的使用，而不是默认所有操作都要全员应答。

这不意味着“无确认等于必达”，也不意味着“组控不能用确认”。 它意味着要把控制与确认的流量一起算进预算，按业务要求选择，而不是把响应数量越多当成越可靠。

另外，不要求这次请求的响应，也不等于设备永远不上报状态。状态发布和请求响应是需要分别核对的配置与行为。

你先查什么？ 当前到底发送了哪个消息，控制端等待什么响应，设备又配置了哪些状态发布？先把这些流量列出来，再谈重试次数。

四、没有收到状态，先标“未知”，别直接判“失败”

同样是没收到预期反馈，背后可能是不同情况：

灯没有收到命令；灯已经执行，但状态回程没有到达；设备仍在过渡；或者控制端把一个旧状态当成了新结果。

只看“有没有收到回包”，分不清这些原因。

管理侧可以先采用更诚实的表达：

• 已请求：本次控制意图已提交，但尚无足够的目标反馈。
• 状态已确认：收到了满足本次判断条件的模型状态，并记录来源与时间。
• 待核实：在约定观察窗口内，没有取得足够证据。

这是一种应用层界面设计建议，不是新增的 Mesh 标准状态。

“状态已确认”也不应无限期有效。设备之后可能被墙壁开关、传感器或自动化再次控制。界面最好同时显示最后确认时间，别把昨天的“开”画成现在的实时状态。

还要注意：Generic OnOff Status 不携带 Set 请求中的 TID。 不应假设能靠响应里的事务号一一对单。连续控制、状态发布和多控制端并存时，需要结合来源、状态值、接收时间及业务上下文判断；不要仅凭“刚收到一条开状态”就认定本次请求已完成。

五、缺一盏，为什么不建议无限重发整组？

重发有时能补到丢失的控制，但它不是免费的。

如果大多数灯已经完成，重复整组控制还会让网络继续处理同一目标；如果现场问题来自订阅缺失、设备断电或驱动异常，继续发也解决不了根因。

更可控的方向，是把动作拆开：

先发组控制，再观察反馈；必要时限速核对少量待核实成员，最后只对确有需要的对象做有限补偿。

不要把这句话实现成“组控后立刻逐台查询全部设备”。那只是把同一笔流量换了个时间发出来。查询范围、节奏、截止条件和最大尝试次数，都要和现场规模及业务时效一起测试。

若应用决定重试，也要遵守具体模型的事务规则。Generic OnOff Set 的 TID 用来区分新事务与同一事务的重发，不应每重发一次就随意递增，也不能让后续独立操作一直沿用旧值。完整时间窗口与匹配条件应查对应版本规范和 SDK；本篇不提供通用重试间隔。

还有一个容易漏掉的问题：补偿前，用户是否已经发出了新的控制意图？如果刚刚按了“关灯”，系统却仍在补发上一次的“开灯”，那不是可靠性变好了，而是旧任务正在干扰新任务。

六、把这张表带到联调现场

下面是排查建议，不是认证程序，也不是已经验证的产品默认策略。

看到的现象	先核对什么	不要急着得出的结论
界面提示成功，个别灯没亮	提示代表的层级、订阅配置、设备供电	协议已经保证全员执行
灯亮了，界面却显示失败	状态回程、接收处理、观察窗口	没有反馈就一定没有执行
单控正常，组控偶发异常	组配置、请求响应与发布流量、同时操作负载	再加重传就一定更稳
状态显示“开”，现场仍不亮	状态含义、过渡过程、驱动与光源	软件回报等于光学验收
连续开关后，状态反复跳变	状态新旧、多控制源、旧补偿任务	最后到达的消息一定最新
某台设备一直缺少反馈	清单、模型、密钥绑定、订阅、供电与覆盖	整组重发一定能修好

测试时，建议分别保留三类记录：发送端结果、设备模型状态，以及现场观察结果。样本、时间窗口和预期成员范围要一致，别把三种口径拼成一个“成功率”。

日志记录 SDK 版本、消息类型、来源和目标、时间与相关配置即可；设备身份按需要脱敏，不公开 NetKey、AppKey、DevKey 或客户信息。

联调也别只试一次“全部开灯”。在隔离测试环境里，试试个别设备断电、连续操作和正常业务同时运行，观察系统怎样显示未知、怎样停止重试，以及恢复后会不会执行过时任务。不要对公共照明或承担安全职责的系统直接做故障注入。

七、群控的可靠，不只是“最后都亮了”

“全部开灯”看上去只有一个按钮，背后却有三份不同的问题：

怎么发得有效率，怎么知道当前掌握了什么，以及不知道时怎么补救而不添乱。

不必让每次操作都变成全员点名，但也不能把没有反馈包装成百分之百成功。

比起先问“重发几次最稳”，更值得先写清楚的是：哪些设备应该响应、什么证据算完成、什么时候停止等待，以及新的指令来了以后，旧的任务如何退出。

这些边界清楚了，角落里那盏没亮的灯，才不只是一个催你再点一次按钮的问题。

延伸阅读：蓝牙 Mesh 配网成功，为什么灯还不受控？、蓝牙 Mesh 怎么选？先用一份灯控验收清单验证方案。电池节点的接收等待另见第六篇。

资料与适用范围

• Bluetooth SIG：Mesh Model v1.1，重点为 3.2.1 的 Generic OnOff 消息字段及响应定义。用于说明 Set、Set Unacknowledged、Status、TID 与过渡字段；具体产品仍需核对采用的规范与 SDK。
• Bluetooth SIG：How Bluetooth Mesh Networking puts the ‘large’ in large-scale wireless networks，2018-06-26。用于解释共享无线资源、组播及集中响应的负担；这是历史设计文章，不将其中示例规模或参数当成当前产品指标。
• Silicon Labs：Lighting Demonstration，11.0.1，用于核对发布、订阅与按组控制的基本机制，不代表所有厂商实现。

资料核对日期：2026-11-06。本文是机制分析与工程排查建议，未进行硬件或现场性能测试。

封面为 AI 生成的会议室群控示意插画，并非实测现场照片。