2. 蓝牙Mesh协议栈解析

说实话，刚接触蓝牙Mesh的时候，我被这五个概念绕晕过。节点、元素、模型、状态、消息——每个词都认识，但放在一起就不知道谁是谁了。后来做项目踩了坑才明白，这五个概念就是Mesh网络的“五根柱子”。搞懂它们，你就能看懂任何Mesh协议栈的代码。

我个人习惯把这五个概念分成两组：硬件抽象层（节点、元素）和软件抽象层（模型、状态、消息）。咱们一个一个来。

2.1 节点（Node）—— 入网才是自己人

节点，说白了就是已经加入Mesh网络的设备。一个灯泡、一个开关、一个传感器，只要它成功配网（Provisioning），就成了网络里的一个节点。

没入网的设备叫什么？叫未配网设备（Unprovisioned Device）。它就是个“孤儿”，谁都不认识它，它也不认识谁。

我在项目中遇到过一个问题：一个灯控节点配网后死活收不到开关发来的命令。查了半天，发现是配网时分配的地址跟另一个节点冲突了。嗯，地址管理这事儿，后面专门讲。

2.2 元素（Element）—— 节点里的“分身”

一个节点可以有多个元素。元素是什么？你可以把它理解成节点内部的功能单元。

举个例子：一个双路开关面板，左边控制客厅灯，右边控制走廊灯。这个面板是一个节点，但它内部有两个元素——每个元素对应一个独立的控制通道。

节点	元素数量	说明
单路灯泡	1	一个元素，控制亮灭
双路开关面板	2	两个元素，分别控制两路
温湿度传感器	2	一个元素上报温度，一个上报湿度

2.3 模型（Model）—— 定义“能干什么”

模型是蓝牙Mesh里最核心的概念。它定义了元素的行为——这个元素能干什么、能响应什么消息、能发出什么消息。

模型分三种：

• 服务器模型（Server Model）：维护状态，响应客户端请求。比如灯的“通用开关服务器模型”，它知道灯是开还是关。
• 客户端模型（Client Model）：发送请求，读取或修改服务器状态。比如开关的“通用开关客户端模型”，它发命令让灯亮或灭。
• 控制模型（Control Model）：既当服务器又当客户端，常见于复杂设备。

你想想看，一个灯泡节点里至少有一个元素，这个元素里至少有一个“通用开关服务器模型”。模型才是真正干活的。

2.4 状态（State）—— 设备当前“是什么”

状态就是模型维护的数据。灯的开关状态（开/关）、灯的亮度值（0x0000~0xFFFF）、色温值——这些都是状态。

状态有几种类型：

• 布尔状态：开或关，0或1
• 数值状态：亮度、温度、湿度等连续值
• 复合状态：多个值组合在一起，比如灯的“亮度+色温”

状态还有个重要特性——绑定（Binding）。什么意思？一个状态变了，另一个状态自动跟着变。比如你把灯的亮度调到0，它的开关状态自动变成“关”。这就是状态绑定。

2.5 消息（Message）—— 节点间的“对话”

消息是节点之间通信的载体。一个节点通过消息告诉另一个节点：“嘿，把你的状态改一下”或者“嘿，告诉我你现在什么状态”。

消息分两大类：

消息类型	方向	例子
GET（请求）	客户端 → 服务器	“你现在是开还是关？”
SET（设置）	客户端 → 服务器	“给我关掉！”
STATUS（状态回复）	服务器 → 客户端	“我现在是关的”

消息还有个关键属性——是否需要应答。需要应答的消息叫可靠消息，不需要的叫不可靠消息。开关灯这种操作通常用不可靠消息（丢了就丢了，再按一次），但固件升级这种关键操作必须用可靠消息。

2.6 五者关系：一张图说清楚

咱们用个实际场景串一遍：

1. 节点：一个智能灯泡，已经入网。
2. 元素：这个灯泡只有一个元素（主元素）。
3. 模型：元素里有一个“通用开关服务器模型”。
4. 状态：模型维护一个“开关状态”，当前值是0（关）。
5. 消息：开关面板发来一条SET消息，把状态改成1（开）。灯泡收到消息，更新状态，灯亮了。

你看，这五个概念环环相扣。节点是躯壳，元素是器官，模型是功能，状态是数据，消息是语言。缺一个，Mesh网络就跑不起来。