蓝牙 Mesh 怎么选？先用一份灯控验收清单验证方案
自定义 Mesh、SIG Mesh 和米家接入方案怎么选？从断网控制、整组灯响应、状态一致性到掉电恢复，把协议选型变成一份能执行、能记录的验证清单。
前四篇分别讲了三种方案的关系、自定义广播怎样走向多跳、SIG Mesh 配网与模型绑定，以及支持 SIG Mesh 为什么不等于能接米家。
到了真正选型的时候，问题往往又回到一句话：我们到底该用哪一种？
我的建议是先别急着回答。把“蓝牙 Mesh 怎么选”换成一个具体问题：这套方案在我们准备交付的房间里，能不能稳定完成用户要做的事？
同样是开灯，有人只要墙壁开关可用，有人必须接米家，还有人要自己做网关，再把设备桥接到 Matter。这些需求不该用一张泛泛的协议优缺点表决定。
下面用“一间会议室和相邻走廊的灯控”串起验证方法。房间、设备与故障都是设计示例，不是已经完成的现场实测；文中的清单是工程建议，不是标准认证测试，也不承诺任何方案一定达标。
一、先写用户动作，再写协议名称
假设用户有三个要求：墙上按一下，整组灯响应；互联网断了，基本照明还能用；手机显示的状态，不能一直与灯的实际状态相反。
这些话仍然太宽泛，必须继续问：
- “断网”指断开互联网，还是连路由器、网关也一起断电？
- “整组灯响应”指最后都亮，还是第一盏与最后一盏之间不能有明显落差？
- “状态正确”指灯具固件接受了命令，还是驱动器或传感器确认了实际输出？
- “手机控制”必须使用米家，还是允许安装自己的 App？
如果米家是交付条件，平台支持的品类、接入流程与目标网关就是硬约束，不能等无线部分开发完才去确认。如果目标是自研网关，设备协议、密钥管理和本地接口的可获得性就要提前落实。
生态要求先筛选，性能要求再验证。 顺序反过来，很容易把一个“开发板演示成功”的方案当成交付方案。
二、按责任边界选，而不是给协议排座次
自定义 Mesh、SIG Mesh 和小米 Mesh 并不是三个完全并列的标准。自定义组网是一组设计选择，SIG Mesh 定义标准化网络与模型机制，小米接入还包含产品身份、功能描述及平台流程。
| 项目主要目标 | 优先核对的路线 | 最早要拿到的证据 |
|---|---|---|
| 设备与控制端都由自己维护，功能边界较窄 | 自定义方案也可以进入评估 | 报文、安全、配网、版本兼容和维护责任明确，有可复现的验证结果 |
| 自研网关管理多种设备，希望复用标准模型 | 评估 SIG Mesh 的具体芯片与 SDK 实现 | 两端元素、模型、可选功能、配网与密钥管理能对上，不只是一句“支持标准” |
| 产品要进入米家，由米家 App 或目标网关管理 | 评估小米当前支持的接入方案 | 目标品类、产品身份、平台模板、固件和目标网关的适配证据 |
这些路线并非绝对互斥，但混合方案也不会自动继承所有优点。选择了标准，不代表已经完成跨厂商互通验证；选择了平台方案，也不代表断网后的所有操作都可用。
Bluetooth SIG 的入门资料说明了标准模型、发布订阅与多跳通信的基础。小米文档则另外描述了网关转换、云端消息流和产品模板要求。它们解决的不是同一层问题，不能用其中一层的“支持”替另一层作保证。
三、把“断网也能用”拆成三次测试
先画出每个动作的路径。例如，自研系统里的墙壁开关可能直接发送 Mesh 消息，也可能只是通知主机，再由主机转发。路径不一样，拿掉网关后的结果自然不同。
建议分开验证三个故障：
- 互联网断开，本地设备继续运行。 分别试墙壁开关、手机控制和已经配置的自动化，记录哪些能力依赖云端。
- 网关停止运行，其他网络和设备保留。 看哪些控制确实发生在设备之间，哪些必须经过网关。不要把这次结果归到“断互联网”里。
- 一个承担中继的节点掉电。 观察远处灯具是否仍可达，以及恢复供电后的表现；前提是部署中确有依赖中继的路径。
SIG Mesh 的标准机制允许模型之间通过消息交互，不要求业务消息都经过云端。但具体产品有没有实现这种控制，仍取决于模型、配置与应用。
反过来，小米当前 BLE Mesh 基础文档明确区分网关通信、手机直连和消息中继，还说明其描述的非低功耗设备可以转发消息，但设备间不能相互控制。能替别人转发无线包，不等于能独立完成墙壁开关到灯的业务控制。
所以，测试报告应写“互联网断开后，某型号开关仍能控制某组灯”，而不是只写“支持离线”。
四、单灯成功，不等于整组灯成功
一盏灯近距离开关正常，只能说明这条简单路径有机会工作。整组控制还涉及中继、重发、状态上报和无线环境。
芯科的网络优化文档特别提醒：过多中继、过高发布频率和不合适的重发配置会增加流量，影响网络表现。不是中继越多、重发越密就越可靠。
建议把一次组控至少拆成三个观察量：
- 在约定观察窗口内，每盏目标灯有没有达到目标状态。
- 第一盏与最后一盏达到目标状态的时间差。
- 控制端何时收到足够的状态证据，是否把未响应节点错误显示为成功。
如果没有取得每盏灯的状态，就不要把“收到一个回复”写成“整组成功”。使用无确认消息时，也应由测试观测或后续状态核对判断结果，而不是把“没有报错”当作完成。
先以正常位置建立基线，再增加设备与背景业务，最后改变中继布局；一次尽量只改一个因素。记录固件、配置、供电、距离、墙体和干扰条件，否则两份“延迟测试”可能根本不是同一个实验。
五、把命令回复、设备状态和真实负载分开
这一点在第四篇提到过：小米文档描述的服务器、网关与设备通信是异步过程，网关对控制请求的立即回复，不等于设备已经执行；属性还有缓存和上报过滤。
自研系统也容易犯同样的错误。串口写成功、SDK 返回成功、远端模型报告状态，以及灯具真实发光，是几种不同证据。
做样机验收时，可以把日志与视频对照起来：记录动作发起、主机提交、设备回报，再用固定机位观察灯的实际变化。有光传感器或其他反馈条件时，可以进一步量化；只有固件状态时，就明确标注“协议状态”，不要假装测到了真实负载。
如果时钟没有对齐，也不要直接拿两台设备的时间戳相减当端到端延迟。可以在同一采集端计时，或者先建立并说明同步方法。
六、掉电恢复和换设备，才容易暴露维护成本
配网成功是开始，不是维护流程的结束。接着检查：
- 主机和无线模块分别重启后，地址、密钥与模型配置是否仍然一致。
- 配置过程中断电，恢复后会继续、重查还是重复配置，能否看懂结果。
- 更换一盏灯后，旧身份如何移除，新设备如何加入原有业务分组。
- 配置备份里保存了什么，恢复依赖什么；备份和日志是否妥善保护敏感信息。
恢复测试应在隔离测试环境中进行，先按芯片和 SDK 文档核对序列号、防重放及持久化要求，不要随手复制整份存储镜像到另一台设备。平台方案还要按供应商流程保留身份与证书数据，不能把全片擦除当作通用恢复手段。
运维记录中使用脱敏设备标识即可，不把 NetKey、AppKey、DevKey 或设备私钥贴进共享报告。
七、最后交付的是一份有条件的结论
可以先用下面这张表组织样机测试。阈值应在测试前由项目确认，不能看完结果再改及格线。 这不是拿来宣称“通过了 Bluetooth 认证”的清单。
| 测试项目 | 先约定什么 | 结果至少记录什么 |
|---|---|---|
| 单灯与组控 | 目标设备、观察窗口、成功条件 | 尝试次数、逐灯结果、超时与重试 |
| 控制体验 | 计时方法、完成时限、允许的组内时间差 | 典型与较慢样本、最大值、失败样本；样本足够时再看分位数 |
| 断网与故障 | 断开哪一段、哪些功能必须保留 | 功能变化、故障提示、恢复过程 |
| 状态一致性 | 采用协议状态还是真实负载证据 | 命令、回报、现场观察及不一致持续时间 |
| 扩容与恢复 | 节点与业务规模、配置版本、重启顺序 | 变更前后差异、配置保存与恢复结果 |
例如“发起了一百次操作”并不能单独证明可靠性。要说明是一次单灯控制，还是每次控制一整组；一次失败是按命令算，还是按目标灯算。超时的样本不能从延迟统计里悄悄删掉，只留下成功样本的漂亮平均数。
最终结论最好长这样：在列明的设备、固件、配置、布置和业务负载下，哪些用户动作达到约定要求，哪些没有，下一步准备调整什么。
这比“某协议更快、更省电、更稳定”窄得多，但它能指导下一次采购、开发和部署。
协议决定了可用的机制，具体产品决定了能用的能力，验证决定了我们能承诺到哪里。 对蓝牙 Mesh 选型来说，先写清最后这一项，往往比先争论该买哪颗芯片更有价值。
参考资料
- Bluetooth SIG：The Bluetooth Mesh Networking Primer，标准机制与模型通信的入门说明。
- Silicon Labs：Bluetooth Mesh Networking Principles，中继、TTL、重发、发布频率与防重放相关说明。阅读时页面显示版本 11.0.2；具体项目以实际 SDK 版本为准。
- 小米 IoT：BLE Mesh 基础知识，网关与设备消息、异步回复、缓存和接入模板。页面标注更新于 2026-08-04，并说明 2026-08-06 起的模板调整。
资料核对日期：2026-11-05。文中的测试组织、观测方式和验收表为工程建议，未执行实机测试。