Mesh 网络核心概念：从节点到消息，把抽象变具体
说实话，刚接触蓝牙 Mesh 的时候，我也被那一堆术语搞得头大。节点、元素、模型、状态……每个词都认识，凑在一起就不知道在说什么了。
后来我做了几个项目，踩了不少坑，才慢慢理清楚。今天我就用最直白的方式，把这些概念串起来讲给你听。
一句话总结：Mesh 网络里，节点是设备，元素是设备上的功能单元，模型定义了行为，状态是数据，消息是通信载体，发布/订阅是通信方式。
节点（Node）—— 网络里的每一个设备
节点就是 Mesh 网络中的每一个设备。一个灯泡、一个开关、一个传感器，只要加入了 Mesh 网络，就是一个节点。
每个节点都有一个唯一的 单播地址，就像门牌号。我习惯把节点想象成「一栋楼」，楼里可以有很多房间，每个房间就是元素。
我的经验：选型时一定要看节点支持的并发消息数。有些低端模组一次只能处理 2-3 条消息，在密集场景下很容易丢包。我踩过这个坑，后来全换了。
元素（Element）—— 节点里的功能单元
一个节点可以包含多个元素。每个元素都有自己的地址，也能独立收发消息。
举个例子：一个双路开关面板，里面有两个继电器。每个继电器就是一个元素。你控制左路，消息只发给左路对应的元素，右路不受影响。
| 节点类型 | 元素数量 | 说明 |
|---|---|---|
| 单色灯泡 | 1 | 一个元素，控制亮灭 |
| 双路开关 | 2 | 两个元素，分别控制两路 |
| RGB 灯带 | 4 | 三个颜色通道 + 一个亮度，共 4 个元素 |
注意：每个节点至少有一个元素，也就是主元素。主元素的地址就是节点地址。其他元素的地址依次递增。
模型（Model）—— 定义设备能做什么
模型定义了元素的行为。说白了，模型就是「这个元素能干什么」的说明书。
蓝牙 Mesh 标准定义了很多模型，比如：
- Generic OnOff Server：控制开关，比如灯泡的亮灭
- Generic Level Server：控制亮度、温度等连续值
- Light Lightness Server：专门控制灯光亮度
- Sensor Server：上报传感器数据
每个元素可以包含多个模型。比如一个灯泡，既有 OnOff 模型，又有 Level 模型，还能有 Lightness 模型。
关键点：模型分为 Server 模型（提供服务）和 Client 模型（发起请求）。开关是 Client，灯泡是 Server。一个设备可以同时拥有 Client 和 Server 模型。
状态（State）—— 设备当前的数据
状态就是模型当前的值。比如灯泡的亮灭状态（On/Off）、当前亮度（0-65535）、色温值等。
状态可以是一个布尔值、一个整数，也可以是一个复杂结构体。每个模型都有一组关联的状态。
我记得有一次联调，对方说灯不亮。我查了半天，发现是状态同步出了问题——开关发了 On 消息，但灯泡的状态没更新。后来加了状态绑定才解决。
避坑指南：状态绑定（State Binding）是个好东西。比如你把亮度状态和开关状态绑定，关灯时亮度自动归零，开灯时恢复。省了很多逻辑。
消息（Message）—— 网络里的通信单元
消息就是节点之间传递的数据包。Mesh 网络里的一切通信，都是通过消息完成的。
消息有几种类型：
- GET：请求读取状态
- SET：请求设置状态
- STATUS：回复当前状态
比如开关发一条 Generic OnOff Set (1)，灯泡收到后把状态改成 On，再回复一条 Generic OnOff Status (1) 确认。
// 消息格式示例（简化）
opcode: 0x8201 // Generic OnOff Set
parameters: 0x01 // 1 = On, 0 = Off
注意：消息有长度限制。单条消息最多 11 字节（不含网络层头部）。如果你要传大量数据，得拆包或者用分段传输。
发布/订阅（Publish/Subscribe）—— 消息怎么传
这是 Mesh 网络最核心的通信机制。说白了，就是「谁发消息，谁收消息」的规则。
发布（Publish）：节点把消息发到一个组地址或虚拟地址。
订阅（Subscribe）：节点监听某个地址，收到消息就处理。
举个例子：
- 开关订阅了组地址 0xC001
- 灯泡也订阅了组地址 0xC001
- 开关按一下，发布一条 On 消息到 0xC001
- 灯泡收到，执行开灯
一个节点可以订阅多个地址，也可以发布到多个地址。这种机制让 Mesh 网络非常灵活——你可以把 100 个灯分到 10 个组，每个组独立控制。
| 地址类型 | 范围 | 用途 |
|---|---|---|
| 单播地址 | 0x0001 - 0x7FFF | 点对点通信，发给特定节点 |
| 组地址 | 0xC000 - 0xFFFF | 一对多通信，发给一组设备 |
| 虚拟地址 | 基于 UUID 生成 | 灵活分组，常用于大规模部署 |
我的建议：发布/订阅配置一定要在量产前固化。我见过有人把配置写在 App 里，结果用户手机丢了，整个网络都控制不了。最好在模组出厂时就烧好默认的发布/订阅关系。
把这些概念串起来
现在回头看，其实很简单：
- 节点是物理设备，比如一个灯泡
- 灯泡里有 元素，比如主元素控制亮灭
- 元素里有 模型，比如 OnOff Server 模型
- 模型维护 状态，比如当前是 On 还是 Off
- 节点之间通过 消息 通信
- 消息通过 发布/订阅 机制路由到正确的接收方
你想想看，这就像邮局系统：节点是邮局，元素是窗口，模型是窗口能办什么业务，状态是当前业务数据，消息是信件，发布/订阅就是寄信地址和收件人名单。
最后说一句：这些概念是 Mesh 网络的基石。后面讲配置、讲安全、讲性能优化，全都离不开它们。花点时间理解透，后面会省很多事。