Matter 协议介绍
Matter 是由 CSA(Connectivity Standards Alliance,连接标准联盟) 制定的智能家居互联互通协议。它是一个基于 IP 的应用层协议,旨在解决智能家居领域长期存在的碎片化问题 —— 不同品牌、不同生态的设备无法互相通信。
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):仅用于设备配网阶段
┌─────────────────────────────────────────┐│ Application Layer ││ (Matter) │├─────────────────────────────────────────┤│ Transport (TCP/UDP) │├─────────────────────────────────────────┤│ Network (IPv6) │├──────────┬──────────┬───────────────────┤│ Wi-Fi │ Thread │ Ethernet ││ (802.11) │(802.15.4)│ │└──────────┴──────────┴───────────────────┘ BLE 仅用于 CommissioningMatter 采用层次化的数据模型来描述设备能力,这是理解整个协议的关键:
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。
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小米的 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(上报型) |
Matter MIoT SPEC V3─────────────────────────────────────────────Node ←→ DeviceEndpoint ←→ ModuleCluster ←→ ServiceAttribute ←→ PropertyCommand ←→ ActionEvent ←→ EventDevice Type ←→ Device URN Type| 维度 | Matter | 米家 MIoT SPEC |
|---|---|---|
| 制定方 | CSA(Apple、Google、Amazon 等联合) | 小米 |
| 开放性 | 开放标准,任何厂商可实现 | 封闭生态,需接入小米平台 |
| 跨生态 | 原生支持多生态控制 | 仅限米家/HomeKit(部分设备) |
| 通信方式 | 局域网 IP 通信(Wi-Fi/Thread) | 蓝牙 mesh / Wi-Fi / ZigBee,依赖网关 |
| 云依赖 | 本地优先,不依赖云 | 大量功能依赖小米云 |
| 认证体系 | CSA 统一认证 | 小米自有认证 |
| 设备规模 | 截至 2025 年约 3000+ 款认证产品 | 米家生态链数千款产品 |
风扇灯是一个典型的多功能设备,同时具备风扇和灯两种能力,非常适合展示分组层(Endpoint / Module)的作用。
Matter(Fan Light):
一个物理设备通过两个 Endpoint 分别暴露灯和风扇的能力:
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, ToggleMIoT SPEC V3(风扇灯):
V3 通过两个 Module 分别描述灯模组和风扇模组:
{ "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 服务于小米封闭生态。
| 版本 | 发布时间 | 主要新增 |
|---|---|---|
| 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 最受期待的设备类型。Matter 1.5(2025 年 11 月发布)终于引入了对摄像头的完整支持。这是一个复杂的设备类型 —— 不同于灯泡、开关等简单的状态控制,摄像头涉及实时音视频流传输、编解码协商、隐私控制等多方面能力。
Matter 1.5 为摄像头新增了三个核心 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 申请具体的流资源。
该 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 会话建立流程:
┌──────────┐ ┌──────────┐│ 控制端 │ │ 摄像头 ││(手机/Hub) │ │ │└─────┬────┘ └─────┬────┘ │ │ │ 1. ProvideOffer (SDP Offer) │ │────────────────────────────────────────►│ │ │ │ 2. ProvideAnswer (SDP Answer) │ │◄────────────────────────────────────────│ │ │ │ 3. ProvideICECandidate (双向交换) │ │◄───────────────────────────────────────►│ │ │ │ 4. ICE 连通性检查 & DTLS 握手 │ │◄═══════════════════════════════════════►│ │ │ │ 5. SRTP 音视频流 (P2P 直连) │ │◄═══════════════════════════════════════►│ │ │步骤 13 通过 Matter 消息层传输(信令),步骤 45 是 WebRTC 媒体层的直接通信。
该 Cluster 支持摄像头主动将视频流推送到指定接收端,适用于以下场景:
- 持续录像:将视频流推送到 NVR(网络录像机)或云存储
- 事件触发:检测到运动/声音后,主动推送视频到 Hub 或手机
- 多接收端:同一摄像头的视频流同时推送到多个目标
Commands:
| Command | 说明 |
|---|---|
AllocatePushTransport | 注册一个推送目标,指定传输协议和目标地址 |
DeallocatePushTransport | 移除推送目标 |
FindTransport | 查找已注册的推送传输 |
SetTransportStatus | 启用/暂停推送 |
与 WebRTC Transport Provider 的区别:WebRTC 是”拉”模式(控制端按需请求查看),Push AV Stream 是”推”模式(摄像头主动发送)。两者互补,覆盖了摄像头的典型使用场景。
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 即可接入
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 还引入了:
- Closures(门窗类设备):车库门、百叶窗等需要精确位置控制和安全状态反馈的设备
- 增强能源管理:更精细的用电监控、智能调度和需求响应能力
设备加入 Matter 网络的过程称为 Commissioning,典型流程如下:
┌──────────┐ 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 有望真正实现”买任何品牌的设备,用任何平台控制”的愿景。
参考资料