Matter 协议介绍
什么是 Matter
Matter 是由 CSA(Connectivity Standards Alliance,连接标准联盟) 制定的智能家居互联互通协议。它是一个基于 IP 的应用层协议,旨在解决智能家居领域长期存在的碎片化问题 —— 不同品牌、不同生态的设备无法互相通信。
Matter 的前身是 Project CHIP(Connected Home over IP),由 Apple、Google、Amazon、Samsung 等巨头于 2019 年联合发起。2022 年 10 月,Matter 1.0 正式发布。
核心特性
| 特性 | 说明 |
|---|---|
| 互操作性(Interoperability) | 一个设备可同时被 Apple Home、Google Home、Alexa 等多个生态控制 |
| 本地化(Local) | 设备通信在局域网内完成,不依赖云端,降低延迟和隐私风险 |
| 安全性(Security) | 基于证书的设备认证,所有通信加密 |
| 简单配网(Easy Setup) | 通过扫描二维码或 NFC 完成配网(Commissioning) |
| 多管理员(Multi-Admin) | 同一设备可被多个控制生态同时管理 |
网络层支持
Matter 运行在 IP 网络之上,底层传输支持:
- Wi-Fi:适合高带宽设备(摄像头、显示器)
- Thread:低功耗 mesh 网络,适合传感器、门锁等电池设备
- Ethernet:有线连接,适合网桥、Hub 等
- BLE(Bluetooth Low Energy):仅用于设备配网阶段
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────┐
│ Application Layer │
│ (Matter) │
├─────────────────────────────────────────┤
│ Transport (TCP/UDP) │
├─────────────────────────────────────────┤
│ Network (IPv6) │
├──────────┬──────────┬───────────────────┤
│ Wi-Fi │ Thread │ Ethernet │
│ (802.11) │(802.15.4)│ │
└──────────┴──────────┴───────────────────┘
BLE 仅用于 Commissioning
Matter 数据模型
Matter 采用层次化的数据模型来描述设备能力,这是理解整个协议的关键:
1
Node → Endpoint → Cluster → Attribute / Command / Event
核心概念
| 概念 | 说明 |
|---|---|
| Node(节点) | 网络中一个可寻址的实体,对应一个物理设备,拥有唯一的 Node ID |
| Endpoint(端点) | 节点内的功能单元。Endpoint 0 固定为根端点(Root Node),Endpoint 1+ 为应用功能 |
| Cluster(簇) | 功能的最小模块化单元,包含属性、命令和事件。分为 Server(提供数据)和 Client(消费数据) |
| Attribute(属性) | Cluster 中的状态数据,支持 Read / Write / Subscribe |
| Command(命令) | Cluster 中可调用的动作(如 On、Off、Toggle) |
| Event(事件) | 设备主动上报的状态变化通知 |
Device Type(设备类型) 定义了一个端点必须实现的最小 Cluster 集合。例如 “Dimmable Light” 设备类型要求实现 OnOff Cluster 和 LevelControl Cluster。
示例:一个调光灯泡
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Physical Device (Node ID: 0x0001)
├── Endpoint 0 (Root Node)
│ ├── Basic Information Cluster
│ │ └── Attributes: VendorName, ProductName, SoftwareVersion...
│ ├── Network Commissioning Cluster
│ └── Descriptor Cluster
│
└── Endpoint 1 (Dimmable Light)
├── OnOff Cluster (server)
│ ├── Attributes: OnOff (bool)
│ └── Commands: On, Off, Toggle
├── Level Control Cluster (server)
│ ├── Attributes: CurrentLevel (uint8)
│ └── Commands: MoveToLevel, Step
└── Descriptor Cluster
└── Attributes: DeviceTypeList, ServerList, ClientList
Matter 与米家 MIoT SPEC 协议对比
小米的 MIoT SPEC 是米家生态的设备描述协议,定义在 iot.mi.com。两者有相似的设计哲学,但定位和开放程度截然不同。
数据模型对比
| 维度 | Matter | 米家 MIoT SPEC V3 |
|---|---|---|
| 层次结构 | Node → Endpoint → Cluster → Attribute/Command/Event | Device → Module → Service → Property/Action/Event |
| 设备标识 | Device Type ID(数字) | URN:urn:miot-spec-v2:device:<type>:<vendor>:<version> |
| 分组层 | Endpoint(多功能设备的功能分区) | Module(硬件模组划分) |
| 功能单元 | Cluster(如 OnOff、LevelControl) | Service(如 light、fan) |
| 状态量 | Attribute(支持 Read/Write/Subscribe) | Property(支持 Read/Write/Notify) |
| 操作 | Command | Action |
| 通知 | Event(带时间戳的日志型) | Event(上报型) |
MIoT SPEC V2 协议的层次为 Device → Service → Property/Action/Event,缺少 Module 层。目前米家生态中绝大部分设备仍使用 V2 协议。
概念映射
1
2
3
4
5
6
7
8
9
Matter MIoT SPEC V3
─────────────────────────────────────────────
Node ←→ Device
Endpoint ←→ Module
Cluster ←→ Service
Attribute ←→ Property
Command ←→ Action
Event ←→ Event
Device Type ←→ Device URN Type
生态与定位对比
| 维度 | Matter | 米家 MIoT SPEC |
|---|---|---|
| 制定方 | CSA(Apple、Google、Amazon 等联合) | 小米 |
| 开放性 | 开放标准,任何厂商可实现 | 封闭生态,需接入小米平台 |
| 跨生态 | 原生支持多生态控制 | 仅限米家/HomeKit(部分设备) |
| 通信方式 | 局域网 IP 通信(Wi-Fi/Thread) | 蓝牙 mesh / Wi-Fi / ZigBee,依赖网关 |
| 云依赖 | 本地优先,不依赖云 | 大量功能依赖小米云 |
| 认证体系 | CSA 统一认证 | 小米自有认证 |
| 设备规模 | 截至 2025 年约 3000+ 款认证产品 | 米家生态链数千款产品 |
具体 SPEC 示例对比:风扇灯
风扇灯是一个典型的多功能设备,同时具备风扇和灯两种能力,非常适合展示分组层(Endpoint / Module)的作用。
Matter(Fan Light):
一个物理设备通过两个 Endpoint 分别暴露灯和风扇的能力:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Fan Light Node
├── Endpoint 0 (Root Node)
│ └── Basic Information, Descriptor...
│
├── Endpoint 1 (Dimmable Light)
│ ├── Device Type: Dimmable Light (0x0101)
│ ├── OnOff Cluster
│ │ ├── Attribute: OnOff (bool)
│ │ └── Commands: On, Off, Toggle
│ └── LevelControl Cluster
│ ├── Attribute: CurrentLevel (0-254)
│ └── Commands: MoveToLevel
│
└── Endpoint 2 (Fan)
├── Device Type: Fan (0x002B)
├── FanControl Cluster
│ ├── Attribute: FanMode (Off/Low/Medium/High/Auto)
│ ├── Attribute: PercentCurrent (0-100)
│ └── Commands: Step
└── OnOff Cluster
└── Commands: On, Off, Toggle
MIoT SPEC V3(风扇灯):
V3 通过两个 Module 分别描述灯模组和风扇模组:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
{
"type": "urn:miot-spec-v2:device:fan-light:0000A012:yeelink-fancl1:1",
"modules": [
{
"iid": 1,
"type": "urn:miot-spec-v2:module:light-module",
"services": [
{
"type": "urn:miot-spec-v2:service:light",
"properties": [
{"type": "urn:miot-spec-v2:property:on", "format": "bool", "access": ["read","write","notify"]},
{"type": "urn:miot-spec-v2:property:brightness", "format": "uint8", "value-range": [1,100,1]}
]
}
]
},
{
"iid": 2,
"type": "urn:miot-spec-v2:module:fan-module",
"services": [
{
"type": "urn:miot-spec-v2:service:fan",
"properties": [
{"type": "urn:miot-spec-v2:property:on", "format": "bool", "access": ["read","write","notify"]},
{"type": "urn:miot-spec-v2:property:fan-level", "format": "uint8", "value-range": [1,5,1]},
{"type": "urn:miot-spec-v2:property:mode", "format": "uint8", "value-list": [
{"value": 0, "description": "Normal"},
{"value": 1, "description": "Natural Wind"}
]}
]
}
]
}
]
}
从这个例子可以清楚看到:Matter 的 Endpoint 和 MIoT SPEC V3 的 Module 解决的是同一个问题 —— 将一个多功能物理设备的不同能力划分到独立的命名空间中,使控制端可以分别寻址和操作。
可以看到两者的设计思路非常接近,都是”功能分组 + 属性/命令”的模式。V3 新增的 Module 层与 Matter 的 Endpoint 异曲同工 —— 都是在设备和功能单元之间增加一层分组抽象,用于描述多功能设备的内部结构(如空调的”压缩机模组”和”显示模组”)。
主要区别在于 Matter 是跨生态的开放标准,而 MIoT SPEC 服务于小米封闭生态。
Matter 版本演进
| 版本 | 发布时间 | 主要新增 |
|---|---|---|
| 1.0 | 2022.10 | 基础设备类型:灯、开关、插座、门锁、恒温器、窗帘等 |
| 1.1 | 2023.05 | ICD(间歇连接设备)支持、场景管理 |
| 1.2 | 2023.10 | 冰箱、洗衣机、扫地机器人等家电设备类型 |
| 1.3 | 2024.05 | 能源管理、电动车充电桩、微波炉、烤箱等 |
| 1.4 | 2024.11 | 增强型设备组合、扩展 ICD |
| 1.5 | 2025.11 | 摄像头、门窗类设备(Closures)、增强能源管理 |
Matter 1.5:摄像头支持
摄像头一直是 Matter 最受期待的设备类型。Matter 1.5(2025 年 11 月发布)终于引入了对摄像头的完整支持。这是一个复杂的设备类型 —— 不同于灯泡、开关等简单的状态控制,摄像头涉及实时音视频流传输、编解码协商、隐私控制等多方面能力。
Matter 1.5 为摄像头新增了三个核心 Cluster:
Camera AV Stream Management Cluster
该 Cluster 负责摄像头音视频能力的描述和流资源的管理,是摄像头设备类型的核心。
关键 Attributes:
| Attribute | 说明 |
|---|---|
MaxConcurrentVideoEncoders | 设备能同时运行的最大视频编码器数量 |
MaxEncodedPixelRate | 最大编码像素率(用于约束分辨率×帧率的上限) |
VideoSensorParams | 图像传感器参数(物理分辨率、最大帧率等) |
NightVisionCapable | 是否支持夜视 |
SupportedSnapshotParams | 支持的快照参数(分辨率、编码格式) |
HDRModeEnabled | HDR 模式是否开启 |
RateDistortionTradeOffPoints | 码率-质量权衡点,帮助控制端选择合适的编码参数 |
MicrophoneCapabilities | 麦克风能力(采样率、声道数、编码格式) |
SpeakerCapabilities | 扬声器能力(用于双向对讲) |
TwoWayTalkSupport | 双向对讲支持类型(半双工/全双工) |
AllocatedVideoStreams | 当前已分配的视频流列表 |
AllocatedAudioStreams | 当前已分配的音频流列表 |
AllocatedSnapshotStreams | 当前已分配的快照流列表 |
关键 Commands:
| Command | 说明 |
|---|---|
VideoStreamAllocate | 分配一路视频流,指定编码格式、分辨率、帧率、码率等 |
VideoStreamDeallocate | 释放视频流 |
AudioStreamAllocate | 分配一路音频流 |
AudioStreamDeallocate | 释放音频流 |
SnapshotStreamAllocate | 分配快照流(用于抓图) |
SnapshotStreamDeallocate | 释放快照流 |
CaptureSnapshot | 触发一次快照捕获 |
SetStreamPriorities | 设置多路流的优先级(资源不足时低优先级流降级) |
这个设计体现了”能力描述 + 资源管理”的思想:设备先通过 Attributes 告知控制端自己的能力边界,控制端再根据需求通过 Commands 申请具体的流资源。
WebRTC Transport Provider Cluster
该 Cluster 负责 WebRTC 会话的信令交换,是实时视频传输的通道建立层。
设计思路:Matter 协议本身作为信令通道,承载 WebRTC 的 SDP Offer/Answer 和 ICE Candidate 交换,无需额外的信令服务器。实际的音视频数据通过 WebRTC 的媒体通道点对点传输,不经过 Matter 消息层。
Attributes:
| Attribute | 说明 |
|---|---|
CurrentSessions | 当前活跃的 WebRTC 会话列表 |
MaxSessions | 最大并发会话数 |
Commands:
| Command | 说明 |
|---|---|
SolicitOffer | 控制端请求摄像头发起 SDP Offer(由摄像头主导协商) |
ProvideOffer | 控制端向摄像头发送 SDP Offer(由控制端主导协商) |
ProvideAnswer | 回复 SDP Answer,完成媒体协商 |
ProvideICECandidate | 交换 ICE 候选地址,用于 NAT 穿透和连接建立 |
EndSession | 终止 WebRTC 会话 |
WebRTC 会话建立流程:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌──────────┐ ┌──────────┐
│ 控制端 │ │ 摄像头 │
│(手机/Hub) │ │ │
└─────┬────┘ └─────┬────┘
│ │
│ 1. ProvideOffer (SDP Offer) │
│────────────────────────────────────────►│
│ │
│ 2. ProvideAnswer (SDP Answer) │
│◄────────────────────────────────────────│
│ │
│ 3. ProvideICECandidate (双向交换) │
│◄───────────────────────────────────────►│
│ │
│ 4. ICE 连通性检查 & DTLS 握手 │
│◄═══════════════════════════════════════►│
│ │
│ 5. SRTP 音视频流 (P2P 直连) │
│◄═══════════════════════════════════════►│
│ │
步骤 1~3 通过 Matter 消息层传输(信令),步骤 4~5 是 WebRTC 媒体层的直接通信。
Push AV Stream Transport Cluster
该 Cluster 支持摄像头主动将视频流推送到指定接收端,适用于以下场景:
- 持续录像:将视频流推送到 NVR(网络录像机)或云存储
- 事件触发:检测到运动/声音后,主动推送视频到 Hub 或手机
- 多接收端:同一摄像头的视频流同时推送到多个目标
Commands:
| Command | 说明 |
|---|---|
AllocatePushTransport | 注册一个推送目标,指定传输协议和目标地址 |
DeallocatePushTransport | 移除推送目标 |
FindTransport | 查找已注册的推送传输 |
SetTransportStatus | 启用/暂停推送 |
与 WebRTC Transport Provider 的区别:WebRTC 是”拉”模式(控制端按需请求查看),Push AV Stream 是”推”模式(摄像头主动发送)。两者互补,覆盖了摄像头的典型使用场景。
为什么选择 WebRTC
Matter 选择 WebRTC 而非 RTSP、私有协议等方案作为视频传输技术,有以下考量:
| 对比维度 | WebRTC | RTSP | 私有协议 |
|---|---|---|---|
| 延迟 | 极低(<500ms,典型 <200ms) | 中等(1~3s) | 取决于实现 |
| NAT 穿透 | 原生支持(ICE/STUN/TURN) | 需额外处理 | 需额外处理 |
| 加密 | 强制(DTLS + SRTP) | 可选(RTSPS) | 不确定 |
| 生态成熟度 | 浏览器/移动端原生支持 | 需专用播放器 | 需专用 SDK |
| 双向通信 | 原生支持 | 单向为主 | 取决于实现 |
| 编码灵活性 | H.264/H.265/VP8/VP9/AV1 | 主要 H.264/H.265 | 取决于实现 |
核心优势总结:
- 零额外基础设施:信令复用 Matter 通道,媒体 P2P 直连,无需部署 STUN/TURN 服务器(局域网场景)
- 端到端安全:强制加密符合 Matter 的安全设计哲学
- 广泛兼容:控制端(手机、智能音箱)无需额外 SDK 即可接入
Matter 1.5 摄像头的完整数据模型
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Camera Node
├── Endpoint 0 (Root Node)
│ ├── Basic Information Cluster
│ ├── Network Commissioning Cluster
│ └── Descriptor Cluster
│
└── Endpoint 1 (Camera)
├── Camera AV Stream Management Cluster
│ ├── Attributes:
│ │ ├── MaxConcurrentVideoEncoders (uint8)
│ │ ├── MaxEncodedPixelRate (uint32)
│ │ ├── VideoSensorParams (struct)
│ │ ├── NightVisionCapable (bool)
│ │ ├── HDRModeEnabled (bool)
│ │ ├── SupportedSnapshotParams (list)
│ │ ├── MicrophoneCapabilities (struct)
│ │ ├── SpeakerCapabilities (struct)
│ │ ├── TwoWayTalkSupport (enum: None/HalfDuplex/FullDuplex)
│ │ ├── AllocatedVideoStreams (list)
│ │ ├── AllocatedAudioStreams (list)
│ │ └── AllocatedSnapshotStreams (list)
│ └── Commands:
│ ├── VideoStreamAllocate / Deallocate
│ ├── AudioStreamAllocate / Deallocate
│ ├── SnapshotStreamAllocate / Deallocate
│ ├── CaptureSnapshot
│ └── SetStreamPriorities
│
├── WebRTC Transport Provider Cluster
│ ├── Attributes:
│ │ ├── CurrentSessions (list)
│ │ └── MaxSessions (uint8)
│ └── Commands:
│ ├── SolicitOffer
│ ├── ProvideOffer / ProvideAnswer
│ ├── ProvideICECandidate
│ └── EndSession
│
└── Push AV Stream Transport Cluster
└── Commands:
├── AllocatePushTransport
├── DeallocatePushTransport
├── FindTransport
└── SetTransportStatus
Matter 1.5 其他新增
除了摄像头,Matter 1.5 还引入了:
- Closures(门窗类设备):车库门、百叶窗等需要精确位置控制和安全状态反馈的设备
- 增强能源管理:更精细的用电监控、智能调度和需求响应能力
Matter 的配网流程(Commissioning)
设备加入 Matter 网络的过程称为 Commissioning,典型流程如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌──────────┐ BLE/SoftAP ┌──────────────┐
│ │ ◄─────────────────────────► │ │
│ 新设备 │ 1. 发现 & PASE 安全通道 │ Commissioner │
│ │ │ (手机 App) │
└──────────┘ └──────────────┘
│ │
│ 2. 设备认证 (DAC 证书链验证) │
│◄────────────────────────────────────────│
│ │
│ 3. 网络配置 (Wi-Fi/Thread 凭证下发) │
│◄────────────────────────────────────────│
│ │
│ 4. 建立 CASE 安全会话 │
│◄────────────────────────────────────────│
│ │
│ 5. 完成,设备加入 Fabric │
│◄────────────────────────────────────────│
关键安全机制:
- PASE(Passcode-Authenticated Session Establishment):基于设备配网码建立初始安全通道
- CASE(Certificate-Authenticated Session Establishment):基于证书建立运行时安全通道
- DAC(Device Attestation Certificate):设备认证证书,确保设备来自合法厂商
- Fabric:Matter 网络中的信任域,同一 Fabric 内的设备互相信任
总结
Matter 协议试图为智能家居建立一个真正的”通用语言”。它的数据模型(Cluster/Attribute/Command)与米家 MIoT SPEC(Service/Property/Action)在设计哲学上殊途同归,但 Matter 的开放性和多生态支持使其具备成为行业标准的潜力。
Matter 1.5 引入的摄像头支持采用 WebRTC 技术栈,兼顾了低延迟、安全性和互操作性,是协议成熟度的重要里程碑。随着更多设备类型的加入和生态的完善,Matter 有望真正实现”买任何品牌的设备,用任何平台控制”的愿景。
参考资料