Matter协议架构全解析:从数据模型到设备互联的完整技术图谱
文章目录
1、Matter概述
Matter(以前称为 Project Connected Home over IP 或 Project CHIP)是一个开源应用层,旨在创建跨智能家居设备、移动应用程序和云服务的统一通信标准。它支持广泛的现有技术,包括 Wi-Fi®、Thread 和蓝牙 ® LE,并使用基于 IPv6 的传输协议(如 TCP 和 UDP)来确保不同类型网络之间的连接。
以下是 Matter 的一些主要功能:
-
解决互作性、选择和易用性问题。
-
实现更轻松、更快速、成本更低的 IoT 开发并增加创新投资。
-
使用连接标准联盟提供的参考开源 Matter 堆栈开辟新天地。
-
加速在智能家居、建筑和商业用途中的采用。
以下页面根据 Matter 规范简要概述了 Matter 结构。
原则上,任何支持 IPv6 的网络都可以部署 Matter,只是此网络需支持很少的核心 IPv6 标准。在现有 Matter 规范中,重点关注三种链路层技术:
-
Matter over Wi-Fi
-
Matter over Thread
-
Matter over Ethernet
2、Nordic的Matter SDK合入
nRF Connect SDK v3.0.0 允许您使用 Matter 规范版本 1.4.1 和 Matter SDK 版本 1.4.1.0 开发应用程序。
有关可用示例的列表,请参阅 Matter 示例 ,或针对特定 Matter 应用,请参阅 Matter Weather Station 或 Matter bridge。如果您是 Matter 的新手,可以按照 Nordic Semiconductor 的 YouTube 频道上的视频教程进行作,例如使用 nRF Connect SDK 开发 Matter 1.0 产品 。
3、Matter标准概述
Matter技术规范是测试规范、测试工具和SDK的基础和准绳,可以说是Matter标准的核心内容。技术规范由四个主要文件组成,包括:
-
核心标准Core specification:定义了Matter协议架构、安全通信机制、配网流程、数据模型等实现Matter技术的重要内容
-
设备类型库Device library:Matter目前支持设备类型的具体定义
-
应用功能集库Application clusters:Matter目前支持的产品应用相关cluster的详细定义
-
语义标签命名空间 Standard Namespaces:标准中通用以及特定设备的语义标签命名定义
4、Matter架构
Matter 在基于 IPv6 的传输协议之上定义了一个应用程序层。这允许路由消息,而不管底层物理层和链路层如何。
在智能家居领域,Matter协议通过整合多种通信技术(如WiFi、Thread、BLE),旨在实现设备跨品牌、跨生态的互操作性。以下是各协议在Matter中的作用及角色分析:
4.1. WiFi
作用:
-
高带宽传输:支持需要大数据量传输的设备(如摄像头、智能电视、家庭中枢)。
-
直接互联网连接:通过家庭路由器直接接入互联网,无需网关。
-
低延迟交互:适用于需要实时响应的设备(如语音助手)。
角色:
-
终端设备:直接运行Matter协议的高性能设备(如智能音箱、电视)。
-
边界路由器(可选):部分WiFi设备可兼任Thread边界路由器,桥接Thread网络与IP网络。
适用场景:
-
持续供电、需要高速数据传输的设备。
-
家庭中的核心中枢设备(如Matter控制器)。
4.2. Thread
Thread是一种完全的无线Mesh网络协议。Thread解决了构建智能家居产品网络中出现的新需求。Thread 以6LoWPAN为基础,充分利用开放标准和 IPv6 技术,与其它无线标准相比具有许多技术优势:安全可靠,无单点故障,连接简单,功耗低。产品开发人员和消费者可以轻松地通过Thread安全地将250多个设备组成一个低功耗无线Mesh网络,并且网络中的每个设备都可以连接Internet,访问云服务。Thread协议栈是建立在电气和电子工程师协会(IEEE)和互联网工程任务组(IETF)现有的一系列标准之上的开放标准,而并非全新的标准(见下图)。

作用:
-
低功耗Mesh网络:基于IEEE 802.15.4标准,支持设备自组网,覆盖范围广且稳定性高。
-
IPv6原生支持:无缝集成到IP网络中,与WiFi设备互通。
-
高能效:适合电池供电设备(如传感器、门锁)。
角色:
-
终端设备:低功耗传感器、灯泡、开关等。
-
路由器节点:中继数据,扩展网络覆盖(部分Thread设备可充当路由器)。
-
边界路由器(Border Router):通过Thread边界路由器将Thread网络连接到WiFi/Ethernet(如智能音箱、机顶盒)。
适用场景:
-
电池供电的IoT设备(如温湿度传感器、门窗传感器)。
-
需要大规模设备连接的场景(如全屋照明系统)。
4.3. BLE(蓝牙低功耗)
作用:
-
设备配网(Commissioning):通过蓝牙快速将新设备加入Matter网络(如手机App扫描二维码配对)。
-
低功耗广播:用于设备发现和初始配置,无需持续连接。
-
临时控制通道:在Thread/WiFi断开时提供备用控制方式。
角色:
-
配网中介:作为设备初次连接的“桥梁”,将设备引导至Thread/WiFi网络。
-
辅助通信:在部分场景下提供补充控制(如近距离调试)。
适用场景:
-
新设备的初始配置(如通过手机App配对智能灯泡)。
-
无屏幕设备的简单交互(如通过BLE广播设备信息)
4.4. 协议协同工作流程
-
设备发现与配网:用户通过手机(BLE)扫描设备二维码,触发BLE配网流程。
-
网络接入:设备通过BLE获取WiFi/Thread网络凭据,加入Matter网络。
-
日常通信:
-
高性能设备(如智能音箱)通过WiFi直接通信。
-
低功耗设备(如传感器)通过Thread Mesh网络传输数据,由边界路由器桥接到IP网络。
-
-
跨协议控制:Matter协议层统一管理不同物理层的设备,实现无缝交互(如通过WiFi控制Thread灯泡)。
4.5.总结
-
WiFi:高性能、高带宽设备的骨干网络,适合中枢设备。
-
Thread:低功耗、高可靠性的Mesh网络,覆盖传感器和终端设备。
-
BLE:配网和临时控制的辅助协议,简化用户交互。
通过整合三者,Matter实现了设备互联的灵活性(覆盖不同场景需求)和互操作性(跨协议协作),同时平衡了功耗、性能和成本
5、协议栈架构
Matter 应用程序层可以分为几个主要组件,如下图所示。
在其最低层,Matter 协议栈与 Transport 层交互。有效负载沿传输设备上的协议栈向动,并沿接收设备上的协议栈向上流动。
5.1.应用层(Application)
应用层定义了特定终端产品的业务逻辑。例如,在门锁应用中,业务逻辑可能包括:根据特定虚拟助手技术发出的语音指令,控制某型号门锁的开启与闭合;接收特定数字键盘用户界面(UI)的输入;触发门锁型号上特定LED灯的响应等。
5.2.数据模型(Data Modle)
数据模型层通过属性(attributes)、命令(commands)和事件(events)这三个核心概念,将Matter节点支持的远程操作组织成逻辑化的功能模块(即功能集 cluster)。根据Matter应用功能集规范定义的cluster具有明确的功能边界和标准化的行为模式,这确保了不同厂商开发的Matter节点之间能够实现互操作性。Cluster本身是一个抽象的概念,用来定义一个一个的Matter设备。功能集(cluster)可以具备抽象特性,这意味着它们能够作为多种设备类型的通用基础架构,从而降低新设备类别接入Matter生态的时间与开发成本。Data Model层对主要是数据进行了抽象。

有关数据模型的更多信息,请参阅 Matter 数据模型和设备类型 。
5.3.交互模型层(Interaction Model)
交互模型层在描述数据处理抽象的同时,定义模型层则明确了如何通过交互在节点之间交换这些数据。
交互模型层定义了客户端与服务器设备之间可执行的交互操作。例如:读或写服务设备的属性时的设备行为。发起交互的节点被称为发起方(通常为客户端设备),作为交互接收方的节点被称为目标方(通常为服务器设备)。Interaction Model层则用来定义节点与节点之间如何交换数据,交互作用与Data Madel层定义的元素。
5.4.操作帧构建层(Action Framing)
一旦使用了Interaction Model构造了一个动作(action),这action将被序列列化为规定的压缩二进制格式,以便进行编码以用于网络传输。此过程在 Action Framing 层中处理。
操作帧构建层将属于交互模型中交互的消息转换为序列化的二进制数据包。
5.5.安全层(Security)
安全层从操作帧构建层接收已编码的帧数据,对其进行加密处理,并附加消息认证码(MAC)。
5.6.消息帧构建与路由层(Message Framing and Routing)
这层主要把包头添加到数据中,组成一个真正的包。该层负责将有效载荷与必需和可选的头部字段组合成完整的通信单元。这些头部字段既包含消息的属性参数(如优先级、生命周期),也包含其逻辑路由信息(如源地址、目标地址)。
5.7.传输与IP帧构建层(Transport and IP Framing)
该层通过IP网络向对等设备管理有效载荷的传输。它支持两种传输机制:
-
传输控制协议(TCP);
-
用户数据报协议(UDP)与Matter消息可靠性协议(MRP)的组合方案。
其中MRP协议实现以下核心功能:-
消息重传机制
-
交付确认反馈
-
重复消息过滤
-
在设备配对阶段,系统可临时采用蓝牙LE(低功耗)上的蓝牙传输协议替代此层功能,以完成初始网络配置。
6、Matter数据模型和设备类型
数据模型层使用属性、命令和事件的概念描述 Matter 节点支持的远程作,这些概念被分组为称为功能集(cluster)的逻辑块。Matter 应用程序集群规范中包含的功能集(cluster)具有明确定义的范围和行为,以确保不同供应商开发的 Matter 节点之间的互作性。功能集(Cluster)可以是抽象的,这意味着它可以作为多种设备类型的基础,以减少向 Matter 引入新产品类别的时间和成本。

6.1.节点(Nodes)
每个设备(Device)由一个或多个节点(Node)组成,这些节点是在单一协议栈上实现的完整Matter应用功能单元。每个节点通过唯一的网络地址在网络中被识别,并可直接与网络内的其他节点通信。
6.2.端点(Endpoints)
每个节点包含一个或多个端点,这些端点分别封装了设备不同功能特性的集合。例如:
-
在语音控制门锁设备中,一个端点可能包含控制锁舌操作的完整功能集;
-
另一个端点可能包含管理温度传感器的功能模块。
端点0(Endpoint 0)
端点0始终专用于Matter的实用簇(Utility Clusters),这些簇提供设备基础管理功能(如设备信息、网络配置等)。这是每台Matter设备唯一强制要求的端点。
6.3.簇(Clusters)
端点由一个或多个簇(Clusters)组成,这些簇将一组属性(Attributes)、命令(Commands)和事件(Events)归类到单一功能单元中。例如:
-
在控制门锁锁舌的端点中,某个簇可能包含开锁/闭锁位置移动的属性集;
-
另一个簇则可能归类非法开门时的报警控制属性。
6.3.1.簇类型
-
服务簇(Server):负责维护属性、命令和事件的状态值,是功能的实际执行者。Server :提供Attributes, Commands和Events。
-
客户端簇(Client):主动发起与其他服务簇的交互操作。对Server发起交互(interaction)操作。
补充说明:
- 根据CSA联盟《应用簇规范》,官方定义的设备类型(Device Type)必须基于特定端点上的簇集合组合而成
- 簇的设计遵循面向对象的封装原则,例如"Door Lock Cluster"会包含开锁逻辑、报警阈值、操作记录等完整功能要素
6.4.属性(Attributes)
属性是表示物理量或状态的数据实体,具有两种存在形式:
-
静态存储:固化在设备内存中的持久化数据(如设备型号、序列号)
-
动态计算:按需实时生成的瞬态数据(如当前电量百分比、传感器采样值)
专业示例:
恒温器设备中的CurrentTemperature属性既可能是从ADC采集的原始数据,也可能是经过滤波算法处理后的有效值
6.5.命令(Commands)
命令是用于触发其他设备产生特定行为的操作指令。例如:
-
门锁设备的
Lock Door命令会驱动电机完成机械闭锁动作 -
烟雾探测器的
Self-Test命令可启动内部传感器自检流程
技术特征:
- 命令具有方向性,通常由客户端簇向服务簇发起
- 支持同步响应(如获取执行结果)和异步通知(如长周期任务启动)
6.6.事件(Events)
事件是一种特殊的属性类型,用于表征设备状态的变更记录,具有双重特性:
-
即时通知:当设备状态发生预设条件变化时立即广播(如烟雾浓度突破阈值)
-
历史追溯:以日志形式存储过往关键状态变迁(如最近五次门锁开启时间戳)
设计要点:
- 事件采用分级报告机制,支持紧急事件立即上报和普通事件定期汇总
- 在蓝牙配对阶段,事件系统会通过端点0的
Network Commissioning簇传递配网状态码
6.7.数据模型示例:Door Lock
下图说明了常见门锁设备的数据模型结构。
每个Matter节点必须确保其端点0(Endpoint 0)满足根节点设备类型(Root Node Device Type)的技术规范要求。该设备类型强制规定必须包含用于Matter设备配网及节点后续管理的关键功能簇。
除根节点端点外,该门锁设备还提供端点1(Endpoint 1),该端点遵循《Matter设备库规范》定义的门锁设备类型(Door Lock Device Type)功能架构。此设备类型强制要求实现标识功能簇(Identify Cluster)和门锁功能簇(DoorLock Cluster)的核心能力。
6.7.1.标识功能簇(Identify Cluster)
标识功能簇是跨多种设备类型的通用功能模块,提供触发设备定位提示(如LED闪烁)的指令,便于用户物理定位设备。
6.7.2.门锁功能簇(DoorLock Cluster)
门锁功能簇是针对智能锁设备设计的核心功能模块,包含丰富的属性参数、控制指令和状态事件。
典型属性:
-
LockType:锁型标识,用于定义设备所属的物理锁具分类(如死锁、把手锁等)
-
LockState:锁状态实时反馈,包含锁定/解锁/运动中等状态值
控制指令示例:
-
LockDoor/UnlockDoor:远程锁定/解锁操作指令
-
SetCredential:凭证管理指令,用于设置开锁凭证(如PIN码、生物特征等)
事件反馈示例:
- DoorLockAlarm:安全告警事件,记录锁具异常状态(如机械卡死、PIN验证失败次数超限等)
每个Matter节点必须确保其端点0(Endpoint 0)满足根节点设备类型(Root Node Device Type)的技术规范要求。该设备类型强制规定必须包含用于Matter设备配网及节点后续管理的关键功能簇。
除根节点端点外,该门锁设备还提供端点1(Endpoint 1),该端点遵循《Matter设备库规范》定义的门锁设备类型(Door Lock Device Type)功能架构。此设备类型强制要求实现标识功能簇(Identify Cluster)和门锁功能簇(DoorLock Cluster)的核心能力。
每个Matter节点必须确保其端点0(Endpoint 0)满足根节点设备类型(Root Node Device Type)的技术规范要求。该设备类型强制规定必须包含用于Matter设备配网及节点后续管理的关键功能簇。
除根节点端点外,该门锁设备还提供端点1(Endpoint 1),该端点遵循《Matter设备库规范》定义的门锁设备类型(Door Lock Device Type)功能架构。此设备类型强制要求实现标识功能簇(Identify Cluster)和门锁功能簇(DoorLock Cluster)的核心能力。
6.8.Matter设备类型规范
Matter设备类型是官方定义的功能需求集合,规范一个或多个端点的技术实现。该分类机制旨在确保不同品牌设备在市场上的互操作性。
所有设备类型定义均收录于《Matter设备库规范》(可通过CSA连接标准联盟规范下载页面获取)。每个设备类型的定义包含以下核心要素:
-
设备类型标识符(Device Type ID) - 唯一类型编码
-
设备类型修订号(Device Type Revision) - 版本追踪标记
-
必备功能簇及其最低版本要求 - 列明必须实现的功能模块及其兼容版本
《Matter设备库规范》中的设备类型定义会随技术演进更新。此类变更通过设备类型修订号进行版本追踪(初始值为1),更新内容不会影响设备原有功能实现,仅用于增强特性描述。
当设备类型需要整合其他设备类型构建复合功能时,则形成组合型设备类型(Composed Device Type),体现模块化设计理念。
6.8.1.Matter设备类型概览
以下表格列明Matter协议当前支持的应用层设备类型。
各设备类型的描述文本均直接引用自《Matter设备库规范》。
设备状态列标明该类型是否具备认证资质:
- 预发布状态(Provisional)表示该设备类型实现尚未通过完整测试认证,虽技术实现可能就绪,但使用需自行承担风险。
专用示例列提供nRF Connect SDK中对应设备类型的参考实现链接(如有)。
若某设备类型暂无nRF Connect SDK专用示例,开发者可通过以下方式实现支持:
-
使用Matter: Template基础模板
-
参照《向Matter应用添加功能簇》用户指南(描述如何编辑Matter应用的功能簇架构)
Lighting device types
| 设备类型 | 描述(来自设备库规格) | 设备状态 | nRF Connect SDK中的专用示例 |
|---|---|---|---|
| 开关灯 | 开关灯是一种可以通过绑定控制器设备(如开关或非彩色控制器)进行开关控制的照明设备。此外,开关灯还可以通过绑定的占用传感器进行开关控制。 | 可认证 | 无 |
| 调光灯 | 调光灯是一种可以通过绑定控制器设备(如调光开关或非彩色控制器)进行开关和亮度调整的照明设备。此外,调光灯还可以通过绑定的占用传感器进行开关控制。 | 可认证 | Matter: Light Bulb |
| 色温灯 | 色温灯是一种可以通过绑定控制器设备(如色温控制器)进行开关、亮度调整和色温调整的照明设备。色温灯支持通过色温调整颜色。 | 可认证 | 无 |
| 扩展色灯 | 扩展色灯是一种可以通过绑定控制器设备(如色温控制器)进行开关、亮度调整和色温调整的照明设备。该设备支持通过色调/饱和度、增强色调、颜色循环、XY坐标和色温调整颜色。此外,扩展色灯还可以通过绑定的占用传感器进行开关控制。 | 可认证 | 无 |
7、Matter 交互模型和交互类型
7.1.Matter 交互模型与交互类型
交互模型层定义了客户端(Client)与服务器设备(Server)之间可进行的交互类型。发起交互的节点称为“发起方”(通常是客户端设备),接收交互的节点称为“目标方”(通常是服务器设备)。
以下是交互模型中的交互类型:
-
读取(Read)
用于获取属性(Attributes)或事件(Events)的值。 -
写入(Write)
用于修改属性(Attributes)的值。 -
调用(Invoke)
用于发送命令(Commands)。 -
订阅(Subscribe)
用于与目标方建立订阅关系,从而定期接收数据报告,而无需反复轮询(Polling)。订阅可关联属性和事件。
每个交互由多个“事务(Transactions)”构成,事务又由多个“动作(Actions)”组成。每个动作可通过一个(n)或多个消息(n, n+1)传递。
7.2.通俗讲解:
想象你通过手机控制家里的智能灯泡(假设灯泡支持 Matter 协议):
1. 读取(Read)
- 你在手机上查看灯泡当前亮度:手机会向灯泡“问”:“你现在亮度是多少?”→ 灯泡回答:“50%”。
- 本质:获取设备的状态信息。
2. 写入(Write)
- 你把亮度调成 80%:手机对灯泡说:“请把亮度改成 80%。”→ 灯泡执行并确认。
- 本质:修改设备的某个参数(比如亮度、颜色)。
3. 调用(Invoke)
-
你点击“关闭灯泡”按钮:手机发送一条指令:“现在关灯!”→ 灯泡执行关灯动作。
-
本质:触发设备的某个特定功能(比如关灯、启动扫地机器人)。
4. 订阅(Subscribe)
-
你设置“灯泡状态变化时通知我”:手机告诉灯泡:“以后你亮度变了,随时主动告诉我,别等我问你。”→ 灯泡之后每次亮度变化都会自动上报。
-
本质:设备主动推送数据,避免手机反复询问(省电、省网络流量)。
重要概念补充:
-
事务(Transactions)与动作(Actions):
比如你让灯泡“先调成红色,再调成 80% 亮度”,这可能需要多个步骤(动作),组合成一个完整操作(事务)。-
事务 = 多个动作的合集(比如“开灯→调亮度→调颜色”)。
-
动作 = 单个最小操作(比如“调亮度”)。
-
-
消息(Messages):
每个动作通过消息传递,可能分多次完成。例如,灯泡可能在收到第一条消息后回复“收到”,执行完再发第二条消息确认结果。
为什么需要交互模型?
-
统一标准:不同品牌设备用同一种“语言”交互,不再需要各自的 App 单独适配。
-
本地控制:多数交互无需经过云端,响应更快、更可靠(即使断网也能控制)。
-
灵活性:订阅机制减少设备频繁通信,更省电(尤其对电池供电的设备)。
举个实际例子:
你用苹果手机(Client)控制小米灯泡(Server),通过 Matter 的 Read 查看亮度,用 Write 调亮度,用 Invoke 关灯,再用 Subscribe 让灯泡在电量低时自动通知你——整个过程无需小米或苹果的云端中转,直接本地完成。

7.3.交互示例:门锁
以下部分展示了上述交互类型的实际案例。假设 Matter 控制器作为交互发起方,智能门锁作为目标设备。
1. 读取交互(Read)
Matter 控制器可以通过读取交互,从门锁设备的 数据模型层 获取一个或多个属性或事件的值。例如,控制器可以读取 DoorLock 集群的 LockType 属性,以便向用户显示对应的门锁图标。下图展示了完成此交互所需的步骤:

2. 写入交互(Write)
写入交互用于修改门锁设备的属性。例如,控制器可以修改 DoorLock 集群的 OperatingMode 属性,将门锁设置为“隐私模式”(此模式下只能从室内手动开锁)。下图展示了完成此交互所需的步骤:

3. 调用交互(Invoke)
调用交互允许控制器触发门锁的某个命令。例如,控制器可以通过 DoorLock 集群的 UnlockDoor 命令远程开锁。下图展示了完成此交互所需的步骤:
注意:
此为“定时交互”(Timed Interaction)的特殊案例,发送实际命令前需要额外交换两条消息,以防止攻击者截获并重放命令(例如在户主不在家时恶意开锁)。

4. 订阅交互(Subscribe)
订阅交互用于持续监控门锁属性或事件的变化。例如,控制器可订阅 DoorLock 集群的 LockState 属性,当其他用户手动开锁时收到通知。下图展示了此交互的步骤:
注意:
这是一个长期运行的交互,由多个事务构成,直到任意一方终止或返回错误状态。

5.简单举例说明:
假设你有一个支持 Matter 的智能门锁,通过手机 App(Matter 控制器)控制它:
1. 读取交互(Read)
-
场景:你打开 App,想知道门锁类型(是密码锁还是磁力锁)。
-
流程:App 问门锁:“你是什么类型?”→ 门锁回答:“我是磁力锁”。
2. 写入交互(Write)
-
场景:你设置门锁进入“隐私模式”(防止快递员误操作)。
-
流程:App 告诉门锁:“切换为隐私模式!”→ 门锁执行并回复:“已切换”。
3. 调用交互(Invoke)
-
场景:你在回家前远程开锁。
-
安全机制:
-
App 先问门锁:“5 秒内能执行命令吗?”→ 门锁确认:“可以”。
-
App 再发送开锁指令(带密码验证)→ 门锁执行开锁。
-
-
意义:防止攻击者截获长期有效的开锁指令。
4. 订阅交互(Subscribe)
-
场景:你想实时知道门锁是否被打开。
-
流程:
-
App 告诉门锁:“以后每次开锁都通知我”。
-
当有人手动开锁时,门锁会主动推送状态给 App(如:“门已开”)。
-
-
优势:无需反复刷新 App,省电且即时。
6.关键概念总结:
-
数据模型层(Data Model Layer):设备功能的抽象表示(如门锁的“开锁状态”、“工作模式”等属性)。
-
集群(Cluster):一组相关功能的集合(如
DoorLock集群包含所有与门锁相关的属性和命令)。 -
定时交互(Timed Interaction):通过时间窗口限制命令有效期,增强安全性(类似银行验证码过期机制)。
-
订阅的长期性:一次订阅,持续生效(除非网络断开或主动取消)。
7.为什么这些交互重要?
-
安全性:定时交互防止重放攻击,确保远程控制安全。
-
效率:订阅机制减少不必要的轮询(尤其对电池供电设备至关重要)。
-
兼容性:所有 Matter 设备遵循相同的交互规则,跨品牌协作无障碍。
实际案例:
你用苹果手机订阅了小米门锁的开关状态,当家人用指纹开锁时,你的手机会立刻收到通知——无需小米或苹果的专属协议,完全基于 Matter 标准实现。
8、Matter的网络拓扑
8.1.Matter网络组成
Matter网络可由以太网、Wi-Fi®和Thread设备组成。Matter将这些设备统一接入本地Matter网络架构(基础设施)中,使得设备即使底层使用不同网络技术,也能通过相同的Matter应用层协议互相通信。所有通信均基于IPv6实现,即使在没有连接互联网的IPv6基础设施(例如防火墙隔离的网络)中,Matter网络仍可运行。蓝牙® LE可用于将Matter设备配网加入Matter网络。
8.2.Matter网络拓扑
Matter网络拓扑指Matter设备与IPv6网络之间的连接结构。不同的IPv6网络可通过中心枢纽(如Thread边界路由器或Wi-Fi接入点)互联。Matter还支持通过Matter网桥连接其他协议(如Zigbee)的外部网络。
下图展示了一个典型的Matter拓扑示例,包含两个Thread边界路由器(其中一个可选连接互联网),以及三个作为其他协议设备网桥的Wi-Fi设备。
一般来说,一个Matter网络称为一个Fabric,共享同一个根操作证书的所有节点可以归为同一个Fabric,简单来说,一个生态就是一个Matter fabric(当然也可以包含多个),比如家里同时有苹果、Google、亚马逊的音箱,那么你可以认为你家里有三个Matter fabric,每个fabric是独立的,但这里要强调的是Matter支持一个设备接入多个fabric,也就是可以同时用苹果、Google、亚马逊控制同一个Matter设备,比如门锁或窗帘。简单理解:比如苹果的Home就是一个fabric,谷歌的home又是另一个fabric。
8.3.Matter网络核心概念
以下是Matter网络中的关键概念(按字母顺序排列):
-
绑定(Binding)
允许在单个或两个独立Matter节点的端点之间建立关系。这些关系由设备内存中持久存储的"绑定条目"描述,并由"绑定集群"管理。绑定用于指定节点上客户端集群的目标设备,使设备知道应作用于哪个远程设备。绑定行为由应用定义,不受Matter核心规范限制,支持自定义场景(例如按下开关按钮控制一组灯泡)。 -
网桥(Bridge)
用于将非Matter兼容的Mesh设备(如Zigbee设备)接入Matter网络的设备。网桥确保Matter与非Matter设备间的安全通信。 -
控制器(Controller)
负责配对和远程控制Matter配件设备,通过蓝牙® LE配网后使用IPv6通信。例如智能手机或智能音箱。 -
边界路由器(Edge Router)
协调不同IPv6网络互通(如Thread边界路由器或Wi-Fi接入点),支持多实例部署以避免单点故障。 -
架构(Fabric)
一组逻辑上互联的节点(可属于不同物理网络),共享相同的信任根和配置状态,通过64位唯一Fabric ID标识。 -
多架构(Multi-fabric)
允许设备加入多个独立架构(每个架构有独立管理员),支持跨生态系统协作(如家庭与访客共享设备权限)。 -
节点(Node)
Matter网络中的单个设备实例,拥有唯一64位节点ID,可加入多个架构。例如温控器或门锁。 -
OTA服务提供者/请求者
OTA服务提供者负责提供固件更新包,请求者负责请求并接收更新。
8.4.通俗易懂的讲解:
1.Matter网络就像"多语种联合国"
-
不同协议设备:相当于来自不同国家的代表(Wi-Fi说英语,Thread说法语,以太网说中文)。
-
边界路由器:担任"翻译官",让不同协议设备能互相理解。
-
控制器:类似"联合国主席",负责协调设备间合作。
2. 绑定:设备之间的"好友关系"
- 当开关和灯泡绑定后,就像互加微信好友,按下开关就直接通知灯泡亮灭,无需每次都重新介绍。
3. 网桥:跨协议"中介"
- 类似把传统Zigbee设备"包装"成会说Matter语言的翻译器,让老旧设备也能加入智能家居新生态。
4. 多架构:家庭的"分层权限"
-
主架构:家人完全控制所有设备。
-
访客架构:朋友只能控制客厅灯光。
-
服务商架构:维修人员仅查看空调状态。
5. OTA升级:设备的"在线教育"
-
OTA提供者:像学校老师,准备好新知识(固件)。
-
OTA请求者:像学生主动请求学习,完成后变得更聪明(功能升级)。
举个生活场景例子:
假设你有一个Matter智能家居系统:
-
早晨起床:绑定的窗帘自动打开(Binding功能)。
-
离家模式:通过手机(Controller)一键关闭所有设备。
-
父母来访:通过多架构赋予他们控制空调的权限,但无法修改安防设置。
-
Zigbee旧设备:通过网桥接入,与新的Thread门锁协同工作。
-
固件升级:灯泡自动从边界路由器获取更新,支持新配色模式。
这种设计让不同品牌、不同协议的设备能像一支训练有素的团队一样协同工作,而用户无需关心背后的技术细节。
9、Matter网络安全
Matter使用128-bit AES-CCM 算法来加密数据,为了得到AES密钥,根据两种不同的应用场景,Matter定义了两种会话(session)建立方式:Passcode-Authenticated Session Establishment (PASE)和Certificate-Authenticated Session Establishment (CASE)
1. Matter 的加密基础:AES-CCM
- 简单解释:Matter 用了一个叫 AES-CCM 的“加密锁”来保护数据。这个锁超级安全(128-bit 强度,比银行用的还强),它会加密数据,让别人看不懂。但要用这把锁,设备得先有“钥匙”(AES 密钥)。Matter 根据不同情况,提供了两种拿钥匙的方式:PASE 和 CASE。
2. PASE:初次配网时的“临时密码锁”
-
什么时候用:只在设备第一次设置时用,比如你刚买了个智能灯泡,要把它连到家里网络(这叫“配网”)。
-
怎么工作:设备让你输入一个8位数的简单密码(passcode,就像手机连 Wi-Fi 时输的密码)。系统用一个叫 SPAKE2+ 的算法来验证这个密码,然后生成一把临时钥匙(AES 密钥)。这样,配网过程的数据就安全了。
-
为啥简单:为了不让小设备(如灯泡)累趴下,Matter 允许提前算好一个“密码验证器”(SPAKE2+ Verifier),直接用它来检查密码,省电又快速。
-
打个比方:就像你第一次设置新手机时,输入一个临时密码(比如 12345678),手机和路由器互相确认后,就能安全连接了。
3. CASE:日常通信时的“身份证验证锁”
-
什么时候用:配网成功后,设备正常工作时用,比如灯泡告诉插座“开灯”。
-
怎么工作:配网时,设备会拿到一个“数字身份证”(Node Operational Certificate,简称 NOC)。两个设备要通信时,它们必须检查彼此的身份证是否来自同一个“家族”(同一个根证书,也叫同一个 Fabric)。如果身份证对得上,就用一个叫 SIGMA 的算法生成那把永久钥匙(AES 密钥)。
-
关键点:NOC 就像一个员工工牌,根证书就像公司总部——只有同一个公司的设备才能互相信任。
-
打个比方:就像你去公司上班,进门要刷卡(NOC),保安检查你的卡是不是本公司发的(同一个根证书),确认了才给你进办公室(安全通信)。
4. Matter 消息的结构:信封、标签和内容
-
消息有三个部分:
-
Message Header(信封):记录会话和传输信息,比如消息从哪来、到哪去、顺序号等(就像快递单号)。
-
Protocol Header(标签):说明消息是干啥的,比如是“开灯”还是“关灯”(就像包裹上的标签,写着“易碎品”)。
-
Payload(内容):真正的数据,比如灯泡的亮度设置(就像包裹里的东西)。
-
-
加密和完整性:
-
AES-CCM 会检查整个消息的“完整性”(就像检查包裹没被拆过),确保三个部分都没被篡改。
-
但只对 Protocol Header 和 Payload 进行“加密”(只有标签和内容被锁起来,别人看不到),而 Message Header 是明文的(像快递单,谁都能看,但不改它就行)。
-
为什么这样设计:Header 需要公开才能路由消息,但核心内容必须保密。
-
6.总结一下
-
PASE:配网用,靠简单密码拿钥匙,适合新手设置,简单高效。
-
CASE:日常用,靠身份证(证书)拿钥匙,确保设备是“自己人”。
-
消息安全:整个包裹防篡改,但只有核心部分加密。
10.Matter网络配网
配网(Commissioning)是将设备加入Matter架构(运行网络)的过程。
10.1.配网设备角色
-
委员设备(Commissioner device):执行配网的Matter控制器(如手机/智能音箱)。
-
被配网设备(Commissionee device):待加入网络的Matter配件设备(如灯泡/门锁)。
10.2.配网前提条件
控制器需从配件设备获取"入职信息",包含:
-
16位厂商ID(Vendor ID)和产品ID(Product ID)
-
12位设备识别码(Discriminator)
-
27位设置密码(Setup Passcode)
-
8位发现能力位掩码(Discovery Capabilities Bitmask)
10.3.配网信息格式
上面这些信息可以以下面三种方式提供:
-
手动配对码:一串数字,适用于大多数控制器。
-
二维码:通过手机扫描快速配网。
-
二维码负载:字母数字组合,用于命令行工具或NFC标签打印。
10.4.配网流程阶段
配网过程的各个阶段如下图:

-
设备发现(Device discovery)
-
配件设备通过以下方式广播存在:
-
蓝牙LE(首次加入网络时使用)
-
DNS-SD(已接入Wi-Fi/Thread的设备)
-
未来支持:Wi-Fi热点模式(未联网设备)
-
-
-
PASE安全会话建立(PASE security setup)
- 使用密码验证建立加密会话(类似设备间交换临时密码本)。
-
启用故障保护( Fail-safe establishment)
- 备份原配置并启动计时器(类似"后悔药"机制,超时自动回滚)。
-
初步节点配置(Perliminary configuration)
- 设置时区、地理位置等基本信息(类似给设备发身份证)。
-
设备认证证书验证(DAV verification)
- 验证设备是否为官方认证产品(类似海关检查护照真伪)。
-
安装运行证书(Installing credectials)
- 颁发节点操作证书(NOC)和操作ID(类似给设备发员工工牌)。
-
网络凭证配置(Network commissioning)
- 写入Wi-Fi或Thread的网络密码(类似给新人发门禁卡)。
-
运行网络发现(Operational discovery)
- 通过DNS-SD发现设备IP地址(类似在通讯录中查找电话号码)。
-
CASE安全会话建立(CASE security setup)
- 使用证书验证建立长期加密通信(类似公司内部加密电话系统)。
-
关闭故障保护(CASE resumption )
- 删除备份并停止计时器(确认配网成功后"销毁后悔药")。
如果上述配网流程成功,那么设备将得到如下信息:
-
由fabric ID和node ID组成的实例名:“我是谁,住哪栋楼几零几?” -> 精确定位设备在网络中的位置。
-
Node Operational Certificate(NOC):这是我的官方工作证。” -> 证明设备是可信网络中的合法成员。
-
NOC对应的私钥:“这是我的秘密印章,证明工作证是我的。” -> 用于身份验证和建立安全通信的核心秘密。
-
Access Control List:“谁可以来我家,来了能干什么?” -> 控制谁有权操作设备以及能做什么操作。
-
操作网络的其他信息: “小区大门钥匙和小区地图。” -> 让设备能实际连接到家庭网络进行通信。
10.5.通俗易懂讲解:
情景比喻:新员工入职流程
假设你要把一台智能灯泡(被配网设备)加入家庭Matter网络(公司),你的手机(委员设备)就是HR:
-
投简历(设备发现)
- 灯泡通过蓝牙广播:“我是XX牌灯泡,求加入!”
-
面试(PASE安全验证)
- HR(手机)和灯泡核对入职密码(27位设置密码),确保是合法设备。
-
签试用期合同(故障保护)
- 备份灯泡原有设置,设定30分钟试用期(超时自动恢复原厂设置)。
-
填个人信息(初步配置)
- 记录灯泡的型号、生产批次(厂商ID/产品ID),设置时区为北京时间。
-
背景调查(证书验证)
- 检查灯泡的"学历证书"(设备认证证书),确认不是山寨产品。
-
发工牌(安装证书)
- 颁发带有唯一编号的工牌(节点操作证书),允许访问公司资源。
-
配门禁卡(网络配置)
- 告知Wi-Fi密码,让灯泡能进入公司内网(家庭网络)。
-
录入通讯录(运行发现)
- 将灯泡的IP地址加入公司通讯录(DNS-SD服务发现)。
-
开通加密邮箱(CASE协议)
- 建立加密通信通道,确保灯泡与其他设备安全交流。
-
转正(关闭故障保护)
- 试用期通过,销毁备份配置,灯泡正式成为网络成员。
典型场景示例
-
蓝牙配网:就像用手机蓝牙连接新耳机,但更安全(需输入27位密码)。
-
多设备协作:配网后,灯泡自动出现在智能音箱的控制列表中,无需重复设置。
-
防山寨机制:若检测到设备证书无效,手机会提示"该产品未被Matter认证"。
通过这种类人化的入职流程,Matter确保了设备加入网络的安全性和可靠性,同时隐藏了背后的技术复杂性,让用户像管理团队成员一样管理智能设备。
11、Matter在nRF Connect SDK中的集成
Matter作为子模块仓库集成到nRF Connect SDK中,使用West工具(Zephyr的元工具)管理,基于专用的Matter分支。这意味着nRF Connect平台与Matter集成的代码存储在Matter仓库中,在编译示例项目时自动构建。

nRF Connect SDK仓库结构
尽管nRF Connect SDK与Matter仓库相互依赖,但两者独立开发,确保各自支持对方的最新稳定版本。Matter分支作为开源仓库,在nRF Connect SDK发布流程中维护验证。
Matter仓库包含文档文件,部分内容集成到nRF Connect SDK文档的"Matter"标签页下。
11.1.Matter协议栈架构
从网络角度看,Matter位于应用层顶端,通过中间层整合nRF Connect SDK提供的蓝牙LE、Thread和Wi-Fi协议栈。对于Thread协议,多协议服务层(MPSL)驱动允许蓝牙LE与Thread在同一射频芯片并发运行。

11.2.支持的硬件平台设计
- SoC多协议设计
-
Thread+蓝牙LE方案
适用开发板:架构差异:
-
nRF5340:网络核运行蓝牙控制器和IEEE 802.15.4射频驱动
-
nRF52840/nRF54L15:所有组件运行在应用核
-

2. Wi-Fi+蓝牙LE方案
适用开发板:
| 配套芯片 | 开发板名称 | 目标板标识 |
|---|---|---|
| nRF7002+NRF5340 | nRF7002 DK | nrf7002dk/nrf5340/cpuapp |
| nRF5340 | nRF5340 DK | nrf5340dk/nrf5340/cpuapp |
通信方式:
-
nRF5340 DK通过SPI连接nRF7002扩展板
-
nRF7002 DK通过QSPI直连

3. Thread/Wi-Fi切换方案
特点:
-
同一固件支持双协议
-
通过非易失存储标志位决定启动协议(默认Wi-Fi)
-
按下开发板Button 3切换协议,触发恢复出厂设置并重启
-
示例参考:门锁示例中的协议切换功能

11.3.通俗易懂讲解:
1. 整体架构类比:智能家居的"中央厨房"
-
nRF Connect SDK:好比智能设备开发的"中央厨房",提供各种现成"食材"(协议栈)和"厨具"(驱动)。
-
Matter模块:就像标准化的"菜谱",确保不同厨师(设备)做出的菜(功能)口味统一。
-
West工具:相当于"厨房管理系统",自动调配所需原料(代码库)。
2. 多协议运行原理:交通指挥系统
-
单芯片多协议:类似一个交警同时指挥汽车(Wi-Fi)、自行车(Thread)和行人(蓝牙),通过:
-
时间分片:快速切换处理不同任务
-
专用通道:为每种协议划分独立"车道"
-
MPSL驱动:相当于智能信号灯系统,协调不同交通工具的通行时段
-
3. 开发板选择指南
| 开发场景 | 推荐装备 | 优势 |
|---|---|---|
| 入门学习 | nRF52840 DK | 性价比高,适合基础Thread开发 |
| 高性能需求 | nRF5340 DK + nRF7002扩展板 | 支持Wi-Fi 6和蓝牙5.3 |
| 未来技术预研 | nRF54L15 DK | 最新低功耗设计,适合创新产品 |
4. 协议切换功能:网络"变形金刚"
-
应用场景:
当设备从Wi-Fi覆盖区移动到Thread网络区域时(如从客厅到花园),自动切换通信方式保持连接。 -
操作流程比喻:
-
按下按钮3:相当于拉下"紧急切换杆"
-
清除旧配置:像格式化U盘准备重新写入
-
重启后连接:自动匹配新网络的"方言"
-
5. 开发实战技巧
-
快速验证:使用门锁示例测试协议切换,观察LED状态变化
-
调试要点:
-
Wi-Fi连接时检查SPI通信速率
-
Thread组网时确认边界路由器状态
-
协议切换后验证NVM存储标志位
-
-
常见问题:
-
切换失败:检查nRF7002扩展板供电
-
配网超时:延长故障保护计时器时长
-
通过这种模块化设计,开发者可以像搭积木一样快速构建支持多协议的Matter设备,而Nordic的硬件方案确保了通信效率和稳定性,让智能设备在各种网络环境中游刃有余。
12、Matter开发之旅
Matter开发主要包括两方面的工作:
-
一是Matter应用本身的开发
-
二是非Matter应用
开发Matter应用开发本质上就是cluster/endpoint/node的添加、编辑、删除以及相关回调事件处理等,如前所述,这个需要通过zcl编辑工具zap来生成ember层的代码,以及手动添加或者修改其他c++文件来实现,下面一一对此进行介绍。
非Matter应用开发包括蓝牙服务,传感器应用开发等,这部分代码是用C语言撰写的。一般来说,Matter应用这块,大家都不要怎么动,直接使用SDK里面自带的例子即可,所以对大家C++编程能力要求并不高。大家绝大部分时间还是花在非Matter应用开发,这个是C语言编程要求,这个相信大家都很熟了。
13、Matter的远程开门流程

关键结论:Matter门锁通过证书链验证→ACL权限检查→动态签名校验→物理状态确认四层安全关卡,所有校验在本地安全元件中完成,即使断网也能阻止未授权访问。开发时需严格实现Door Lock Cluster接口,并在nRF SDK中启用CONFIG_CHIP_USE_DEVICE_CONFIG_CERTIFICATE等安全配置。
13.1.开发者不应该关心的领域(SDK已保障)
1. 基础安全机制(SDK自动处理)
-
✅ 证书链验证(OpCert/DAC/PAA)
-
✅ 指令签名校验(ECDSA-SHA256)
-
✅ ACL基础权限检查
-
✅ 防重放攻击(时效令牌)
2. 通信安全(传输层保障)
-
✅ 会话加密(AES-CCM)
-
✅ 数据完整性保护
-
✅ 设备身份认证

关键原则:
- 绿色信任区(SDK处理):所有到达应用层回调的指令都已完成"身份认证+权限校验+完整性验证"
- 红色执行区(开发者负责):只需关注业务实现和物理世界交互
14、总结
Matter本质上并不是一种新的通信协议,而是一个建立在IPv6网络之上的统一应用层标准。它通过整合 Wi-Fi、Thread 和 BLE 等不同通信技术,将设备之间复杂的互联逻辑抽象为统一的数据模型与交互模型,从而解决智能家居长期存在的生态割裂与互操作性问题。
在架构设计上,Matter通过 Node → Endpoint → Cluster → Attribute / Command / Event 的数据模型结构,将设备功能进行模块化抽象,使不同厂商设备能够在统一语义下进行通信。同时,交互模型(Read / Write / Invoke / Subscribe)则定义了设备之间标准化的数据交换方式,从而让跨品牌设备能够直接协作。
在网络层面,Matter利用 IPv6 构建统一通信基础,并通过 Thread Mesh 网络、Wi-Fi 高带宽网络以及 BLE 配网机制形成协同体系,使系统在功耗、稳定性与用户体验之间取得平衡。
从开发者角度来看,Matter最大的价值在于标准化设备能力与安全通信机制。开发者只需要基于SDK实现对应的Cluster逻辑与设备行为,而安全通信、证书验证、加密机制等复杂系统能力则由协议栈自动处理。这使得智能设备开发从“协议拼接”逐步转变为标准化能力构建。
可以说,Matter正在把智能家居从“设备互联”阶段推进到真正的设备协作时代。
更多推荐
所有评论(0)