Post

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/EventDevice → 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)
操作CommandAction
通知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.02022.10基础设备类型:灯、开关、插座、门锁、恒温器、窗帘等
1.12023.05ICD(间歇连接设备)支持、场景管理
1.22023.10冰箱、洗衣机、扫地机器人等家电设备类型
1.32024.05能源管理、电动车充电桩、微波炉、烤箱等
1.42024.11增强型设备组合、扩展 ICD
1.52025.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支持的快照参数(分辨率、编码格式)
HDRModeEnabledHDR 模式是否开启
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、私有协议等方案作为视频传输技术,有以下考量:

对比维度WebRTCRTSP私有协议
延迟极低(<500ms,典型 <200ms)中等(1~3s)取决于实现
NAT 穿透原生支持(ICE/STUN/TURN)需额外处理需额外处理
加密强制(DTLS + SRTP)可选(RTSPS)不确定
生态成熟度浏览器/移动端原生支持需专用播放器需专用 SDK
双向通信原生支持单向为主取决于实现
编码灵活性H.264/H.265/VP8/VP9/AV1主要 H.264/H.265取决于实现

核心优势总结:

  1. 零额外基础设施:信令复用 Matter 通道,媒体 P2P 直连,无需部署 STUN/TURN 服务器(局域网场景)
  2. 端到端安全:强制加密符合 Matter 的安全设计哲学
  3. 广泛兼容:控制端(手机、智能音箱)无需额外 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 有望真正实现”买任何品牌的设备,用任何平台控制”的愿景。


参考资料

This post is licensed under CC BY 4.0 by the author.