1. Matter介绍
作者：Kevin Ai, Nordic Semiconductor
Matter（以前称为 Project Connected Home over IP 或 Project CHIP）是由CSA联盟制定的一个应用层面的标准，旨在打造一个统一的智能家居应用标准，以消除智能家居市场的碎片化。在Matter出来之前，智能家居市场是比较混乱的，每一个生态都有自己的协议，比如苹果有自己的 Homekit，Google有自己的Weave，亚马逊有自己的Echo，ZigBee联盟有自己的Zigbee，这种割裂让设备商很头疼，他们需要为不同的生态制造不同的设备，最终用户也很头疼，他们需要学习各种生态的智能家居设备的使用方式。为此CSA提出了Matter技术，以打造一个统一的标准，让一个设备可以在各个生态中工作，并给最终用户呈现统一的使用界面。
需要说明的是，Matter只是一个应用标准，它的传输是建立在支持IPv6的TCP和UDP协议上的，Matter不对传输层进行约定，Matter也不对网络进行约定，但是Matter约定了只能使用Thread/Wi-Fi/Ethernet三种连接协议。Thread协议由Thread Group制定，所以Matter over Thread产品必须通过Thread Group的认证。Wi-Fi则由Wi-Fi联盟进行规范，所以Matter over Wi-Fi产品必须通过Wi-Fi Alliance认证。为了让Matter产品加入Matter网络，需要一个配网的过程，Matter支持三种类型的配网方式，而低功耗蓝牙则是首选配网方式，所以Matter产品一般都会要求支持低功耗蓝牙功能。
Matter技术包含了三份规格书及其他要求文档，大家可以从以下链接获取Matter技术规范：
其中Core specification是它的核心规范，Application cluster specification对Matter组件cluster进行了详细规定，Device library specification则是对设备层面的一些约束和规定。
不像蓝牙和Wi-Fi，即使你不过认证，也照样可以使用蓝牙和Wi-Fi技术。由于Matter采用了PKI技术，而且它又是一个应用规范，你要使用Matter技术，必须通过Matter认证。为此CSA提供了多种资源帮助大家学习了解Matter，大家可以参考如下资源网站：
https://groups.csa-iot.org/wg/all-users/home/matter-resource-kit
Matter是一个非常复杂而又现代的标准，但是短短4年时间，Matter就实现了从提出到落地到追捧的成绩，不得不说这是一个“Matter奇迹”。下面我们一起来了解一下这个“奇迹”的更多细节。
1.1Matter架构
如下展示了Matter协议栈在整个系统中的位置，可以看出Matter就是一个应用协议。
Matter协议栈本身又是由application, data model, interaction model, action framing, security, Message Framing and Routing和Transport and IP Framing组成，如下：
Application
Application层定义最终产品的业务逻辑。例如，对于门锁应用程序，业务逻辑可以根据来自特定语音命令来打开和关闭门锁。它还可以定义用PIN码开锁或者LED反应等。
Data Model
Data Model层用来描述Matter节点支持的远程操作，这里面主要运用了attributes, commands和events三个Matter概念，我们把相应的attributes，commands和events组合，就成了Matter设备里面的一个基石：cluster。Cluster本身是一个抽象的概念，用来定义一个一个的Matter设备，具体定义可参见之前的：Matter Application Cluster Specification。正因为有了cluster，才能让用户快速开发出自己的Matter产品，同时保证互联互通。
Interaction Model
Data Model层对数据进行了抽象，而Interaction Model层则用来定义节点与节点之间如何交换数据。通俗地讲，Interaction model就是用来规定交互命令集的，我们把发起交互的节点叫initiator (一般都是client设备)，而接收者称为target (一般为server设备)。
Action Framing
Action Framing层用来把Interaction Model层的命令转成serialized格式。
Security
Security层把上面的数据进行加密并添加MAC。
Message Framing and Routing
这层主要把包头添加到数据中，组成一个真正的包。
Transport and IP Framing
这层把数据传输到对端，主要是利用TCP或者UDP协议，同时Matter定义了Message Reliability Protocol (MRP)协议，用来信息确认，重传和拒绝重复信息。如前所述，在配网（commissioning）过程中，通信是建立在Bluetooth Transport Protocol （BTP）协议之上。
1.2Matter拓扑结构
Matter可以同时支持Wi-Fi/Thread/Ethernet，也就是说Matter可以让不同网络中的设备进行互联互通通信，这个主要是指Thread board router 可以实现Wi-Fi和Thread通信互转。不仅如此，Matter还允许接入其他网络设备，比如ZigBee设备，这主要通过一个Matter bridge设备来实现。在Matter拓扑结构中，还有一个节点非常重要：Matter controller，Matter controller用来完成配网和远程控制设备，比如苹果的HomePod mini和Home app就是一个典型的Matter controller节点。如下为一个典型的Matter拓扑结构：
一般来说，一个Matter网络称为一个Fabric，共享同一个根操作证书的所有节点可以归为同一个Fabric，简单来说，一个生态就是一个Fabric（当然也可以包含多个），比如家里同时有苹果Google亚马逊的音箱，那么你可以认为你家里有三个Matter fabric，每个fabric是独立的，但这里要强调的是，Matter支持一个设备接入多个fabric，也就是可以同时用苹果Google亚马逊控制同一个Matter设备，比如门锁。
1.3数据模型(Data Model)和设备类型
如下为一个典型的data model表示：
Node
节点(Node)是一个逻辑上独立的设备，有自己唯一的网络地址。每个Matter设备由一个或多个Node组成。
Endpoint
一个Node包含多个Endpoint，每个endpoint是一个逻辑上独立的功能模块。比如门锁，它除了可以包含门锁这个endpoint外，它还可以包含温度传感器这个endpoint。
注意：endpoint 0预留为Matter的utility cluster，而且每个Matter设备都必须强制包含它。
Cluster
Endpoint由一个或多个cluster组成，cluster可以认为是一个基本功能集，它包含attributes， commands和events三个组件。比如前面说的门锁endpoint，它除了可以包含开锁/关锁这个cluster外，它还可以包含报警cluster以实现报警功能。
Matter定义了两种类型的Cluster：
Server –提供Attributes, Commands和Events
Client – 对Server发起交互（interaction）操作
Cluster的详细规格定义请参见Matter Application Cluster Specification。如何通过cluster组成endpoint，进而组成设备类型，这个则是Matter Device Library Specification规定的内容。
Attribute
Attribute就是一条条表示物理量或者状态的数据记录，他们保存在设备的存储器中。
Command
Command就是下文所说的action，用来触发server的特定行为，比如关锁命令用来触发关锁操作。
Event
Event其实是一种特殊的attribute，它用来更新设备的状态，因此你可以把event当成是一种历史数据记录。
1.4交互命令和模型(Interaction Model)
通俗地讲，Interaction model就是用来规定交互命令集的，我们把发起交互的节点叫initiator (一般都是client设备)，而接收者称为target (一般为server设备)。
Matter定义了如下interaction类型：
Read
用来读取attributes或events的值
Write
用来修改attribute的值
Invoke
用来发送commands
Subscribe
用来订阅target的数据报告，从而不用定时去查询相关数据，我们可以订阅attribute，也可以订阅event。
Interaction本身由transaction组成，而transaction又由action组成，每个action包含1条或者多条信息，如下：
下面我们以门锁为例子来具体讲讲interaction模型。
1.4.1 Interaction例子：门锁
下面例子假设initiator为Matter controller，target为door lock。
Read interaction
如下为读取DoorLock cluster 中的LockType attribute 的交互图：
Write interaction
如下为修改DoorLock cluster 中的OperatingMode attribute的交互图（修改为privacy模式意味着门锁只能从建筑内打开）：
Invoke interaction
如下为调用DoorLock cluster的UnlockDoor command的交互图，其中Timed request用来定时命令的有效时间，为可选项。
Subscribe interaction
如下为订阅DoorLock cluster 的LockState attribute状态值的交互图，这是一个持续进行的交互，除非一方停止或者返回失败。
1.5Matter网络安全
Matter使用128-bit AES-CCM 算法来加密数据，为了得到AES密钥，根据两种不同的应用场景，Matter定义了两种会话（session）建立方式：Passcode-Authenticated Session Establishment (PASE)和Certificate-Authenticated Session Establishment (CASE)
1.5.1 PASE
PASE仅用于配网（commission）过程中，SPAKE2+算法通过8位passcode来建立一个安全通道，为了减轻设备端计算负担，可以直接把离线计算好的SPAKE2+ Verifier用来验证passcode。
1.5.2 CASE
CASE用于正常业务通信过程中，CASE是建立在前面配网成功基础上的，配网成功后，节点会得到一个节点操作证书（Node Operational Certificate，NOC）。当两个节点使用CASE进行通信时，他们的NOC必须共用同一个根证书，也就是他们必须属于同一个Fabric。有了NOC，就可以使用SIGMA算法来得到前述AES密钥了。
需要注意的是，Matter message包含如下元素：
Message Header – 会话和传输有关的信息
Protocol Header – Matter消息的语义规定
Payload – 真正的内容
虽然AES-CCM算法可以保证三个元素的完整性，但是只有Protocol Header和Payload会加密。
1.6Matter网络配网
Matter配网（commissioning）就是把一个设备加入Matter Fabric（也叫Matter操作网络）的过程，此过程包含两个角色：
Commissioner device，一般放在Matter controller中，用于发起配网过程。
Commissionee device，就是还未添加到Matter网络中的设备。
为了完成配网，commissionee必须提供如下onboarding信息：
16-bit Vendor ID and 16-bit Product ID
12-bit device discriminator
27-bit setup passcode
8-bit Discovery Capabilities Bitmask
上面这些信息可以以下面三种方式提供：
手动配对码（Manual Pairing Code）
二维码（QR Code）
QR Code Payload
双方必须支持Manual Pairing Code，但推荐使用二维码，当然各个生态系统也可以定义自己的discriminator和setup passcode。
配网流程如下图所示：
如果上述配网流程成功，那么设备将得到如下信息：
由fabric ID和node ID组成的实例名
Node Operational Certificate(NOC)
NOC对应的私钥
Access Control List
操作网络的其他信息
1.7Matter重要概念介绍
1.7.1 Matter Node(节点)
Matter node就是一个Matter设备的实例，一个Matter设备有可能包含一个或多个node，每个node通过64bit的node id来标识。我们也可以把不同的node组成一个group，并用16bit的group id来标识。
1.7.2 Matter controller(控制器)
Matter controller也是Matter网络的一个节点，它可以远程配置和控制附件设备，如下为两种典型的controller。
PC机中我们常见的controller就是CHIP Tool，当然Android或者iOS也支持CHIP Tool，开发者在调试Matter设备的时候，用得最多的就是CHIP Tool，如何在各大平台中配置和使用CHIP Tool，大家可以参考：
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/getting_started/testing/index.html#ug-matter-gs-testing
对于商用Matter生态系统，controller是一个组合体，比如苹果Matter生态，它的controller应该是iOS里面的Home app和HomePod音箱的组合体。
1.7.3 Matter Fabric(网络)
一个Matter Fabric就是一个Matter网络，一个Matter Fabric中的所有节点共享同一个根证书，所以他们可以相互通信，每个Matter Fabric会分配一个64bit的ID进行标识。一般来说，一个Matter生态就是一个Matter fabric，比如苹果的Home就是一个fabric，谷歌的home又是另一个fabric。
1.7.4 Multi-fabric/multi-admin接入多生态
一个Matter node(节点)可以接入一个Matter fabric，也可以同时接入多个Matter fabric，比如同时被苹果/谷歌/亚马逊的音箱控制，这个特性就称为multi-fabric或者multi-admin。Multi-fabric将保证不同的生态可以相互兼容，提高Matter应用的互联互通性能。
1.7.5 Matter bridge
智能家居是一个非常碎片化的市场，除了Matter技术外，还有很多其他技术运用在智能家居市场中，比如蓝牙和ZigBee。为了将这些现有的智能家居产品一揽子接入Matter生态，Matter规范里面提出了Matter Bridge这个设备类型，通过Matter bridge，我们可以把非Matter设备快速接入Matter生态。如下网络拓扑结构演示了如何将一个蓝牙灯泡接入Matter网络，然后Matter controller像控制正常Matter设备一样去控制它。
1.7.6 Matter标准OTA
Matter规范要求设备必须支持设备升级功能，虽然Matter定义了一整套设备升级标准，但Matter没有强制规定设备必须采用这套标准的OTA升级方式，也就是说设备也可以采用其他方式来升级，比如使用基于蓝牙或者Wi-Fi的SMP方式进行升级。
Matter标准OTA定义了两个角色：OTA Provider和OTA Requestor，OTA Provider和OTA Requestor都是cluster，因此他们都有client和server角色之分，要升级固件的设备叫OTA requestor，而提供固件的设备（比如controller）叫OTA provider。
1.7.7 Distributed Compliance Ledger(DCL)
通俗地说，DCL是CSA运营的一个分布式数据库服务器，既然DCL是一个记账簿，它不会不断地更新和发展的。每当成员公司有新品发布，他们就会把这个新品的认证信息写到DCL中。如果颁发了新的PAA证书，这个信息也会写入DCL中。前面提及的Matter标准OTA，新image的URL信息也可以写入到DCL中。CSA也可以撤销或者作废DCL中的一些证书或者认证信息。总之，DCL就是一个分布式数据库服务器，保证了PKI系统的正常运行，同时也保证了Matter各个生态的互联互通。
1.7.8 Certificate Declaration(CD)
每当一个产品通过了Matter认证，CSA就会颁发一个CD证书给它，CD证书包括Vendor ID，Certificate ID，certification type等，由于一个产品类别下所有设备共用同一个CD，因此CD都是hard code在应用中的。
2. 支持Matter的nRF设备介绍
2.1Matter over Thread nRF设备
Nordic支持Matter over thread应用的SoC主要包括nRF5340和nRF52840两款。
2.1.1 nRF5340主要特性
带1 MB 闪存和 512 KB 内存的128/64 MHz Arm Cortex-M33 应用处理器
带256 KB 闪存和 64 KB 内存的64 MHz Arm Cortex-M33 网络处理器
低功耗蓝牙
蓝牙测向
Matter
Bluetooth mesh, Thread, Zigbee
ANT
NFC
高级安全性
USB, QSPI, HS-SPI
105 °C 扩展工作温度
1.7-5.5 V 电源电压范围
开发nRF5340应用时，在nRF Connect SDK中选择的开发板类型为：nrf5340dk_nrf5340_cpuapp。
2.1.2 nRF52840主要特性
64 MHz Arm Cortex-M4 带FPU
1 MB闪存 + 256 KB RAM
低功耗蓝牙，蓝牙mesh
2Mbps
2.4 GHz 收发器
ANT, 802.15.4, Thread, Zigbee
长距离
+8 dBm 发射功率
-95 dBm 灵敏度
支持IEEE 802.15.4无线电
Matter
Thread
Zigbee
1.7V至5.5V供电电压范围
全速12 Mbps USB
NFC-A tag
PWM
UART, SPI, TWI, PDM, I2S, QSP
高速 32 MHz SPI
Quad SPI 接口32 MHz
12位/200 ksps ADC
128位 AES CCM, ARM CryptoCell
USB 2.0
开发nRF52840应用时，在nRF Connect SDK中选择的开发板类型为：nrf52840dk_nrf52840
2.2Matter over Wi-Fi nRF设备
要实现Matter over Wi-Fi应用，需要同时使用nRF5340和nRF7002/nRF7001两款芯片，nRF7002/nRF7001是Wi-Fi 6协同IC，他们只运行Wi-Fi有关的MAC层，Matter的其他部分还是跑在nRF5340上。
2.2.1 nRF7002主要特性
Wi-Fi 6站点(STA)
2.4 GHz和5 GHz双频段
符合802.11a/b/g/n/ac/ax标准
用于物联网的低功耗安全Wi-Fi
与低功耗蓝牙的理想共存
目标唤醒时间（TWT）
SPI / QSPI
1个空间流（SS）
20MHz通道带宽
64 QAM (MCS7)，86 Mbps PHY
OFDMA（下行链路和上行链路）
BSS着色
共存接口
nRF Connect SDK提供支持
开发nRF5340+nRF7002应用时，在nRF Connect SDK中选择的开发板类型为：nrf7002dk_nrf5340_cpuapp。
2.2.2 nRF7001主要特性
nRF7001跟nRF7002功能差不多，但它只支持2.4G频段，不支持5G频段。
3. nRF Connect SDK
和Matter SDK
开发Matter应用，你可以选择Nordic自己的SDK：nRF Connect SDK来开发，也可以选择Matter官方SDK：Matter SDK来开发。其实两套SDK基本上差不多，并且是相互包含的关系，也就是说，nRF Connect SDK里面已经包含了Matter SDK，站在nRF Connect SDK角度来看，Matter SDK就是它的一个模块。同样，Matter SDK里面也包含了nRF Connect SDK，站在Matter SDK角度来看，nRF Connect SDK就是它的一个模块。由于两者的互包含关系，导致两者的版本无法同步，也就是说，当nRF Connect SDK开始下一个版本开发的时候，它会锁定Matter SDK一个版本，比如nRF Connect SDK v2.5.0开发的时候，由于Matter SDK v1.2.0.0还没有发布，因此它锁定的版本就是Matter SDK v1.1.0.1；同样当Matter SDK v1.2.0.0开始开发的时候，由于nRF Connect SDK v2.5.0还没有发布，因此它锁定的版本就是nRF Connect SDK v2.4.0。这就导致一个现象，Matter SDK锁定的nRF Connect SDK版本总是落后于Nordic最新版本，nRF Connect SDK锁定的Matter SDK版本也总是落后于Matter官方最新版本。
如果你是做一个商业产品开发，强烈建议你使用nRF Connect SDK来进行开发，因为每个nRF Connect SDK版本的发布都会对Matter所有例子进行考核和测试，以保证他们的质量和稳定性，这也是为什么nRF Connect SDK会对Matter SDK打很多补丁以保证其质量。而且nRF Connect SDK同时支持Windows/MacOS/Linux平台，让你不再局限于Linux开发平台（经过一定修改后，我们也可以让Matter SDK跑在Windows平台，下文会对此进行介绍）。
如果你想测试Matter最新的特性，而这个特性nRF Connect SDK暂时又没有，那么可以使用Matter SDK来进行开发和调试，待下版本nRF Connect SDK包含了该特性，你就可以直接移植过去，快速发布你的产品。
欲查看Matter SDK锁定的nRF Connect SDK版本，大家可以打开这个文件：config/nrfconnect/.nrfconnect-recommended-revision，如下：
由于nRF Connect SDK会对它锁定的Matter SDK版本进行修改，我们没办法一眼看出它锁定的版本，但是大家可以从如下网站找到每个版本的nRF Connect SDK锁定的Matter SDK版本以及它遵守的Matter规范版本。
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/index.html
虽然nRF Connect SDK和Matter SDK相互包含，但他们使用同一套工具链，而且这套工具链是伴随nRF Connect SDK一起下载和安装的，另外，不管你使用Matter SDK来开发Matter应用还是使用nRF Connect SDK来开发Matter应用，nRF Connect SDK都必须下载和安装，下面我们会以nRF Connect SDK为主来讲解Matter应用开发流程，然后在此基础上再讲解Matter SDK开发Matter应用的流程。实际上，你只要熟悉了nRF Connect SDK开发流程，也就熟悉了Matter SDK开发流程，因为两者几乎一模一样。
4. nRF Connect SDK
开发环境搭建
关于nRF Connect SDK搭建和介绍，这里有一篇博文：https://www.cnblogs.com/iini/p/14174427.html，推荐大家去看一下。下面我们会对博文内容进行浓缩，简要介绍nRF Connect SDK。
4.1前置安装
在我们开始正式的开发环境配置之前，我们先需要下载如下三个工具：
Visual Studio Code：https://code.visualstudio.com/，
这个就是我们的跨Windows/Linux/MacOS平台的IDE工具。
nRF command line tools：https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools/Download#infotabs，这个就是j-link驱动以及nrfjprog等Nordic提供的一些有用的命令行工具。
west，git和Python，这三个工具是可选的，不过大家手动安装他们一下，某些场合还是蛮有用处的。请注意，即使大家没有手动安装这3个工具，Nordic工具链也会自动包含这三个工具，只不过大家使用工具链里面自带的工具，会有一点麻烦，所以这里建议大家可以先手动安装他们。
4.2VS Code开发环境搭建
Microsoft Visual Studio Code（VS Code）是Nordic推荐的开发nRF Connect SDK应用的跨平台IDE工具，所以nRF Connect SDK开发环境搭建都是在VS Code中进行的。
4.2.1 插件安装
首先下载相应的插件。打开VS Code，进入Marketplace，搜索“nrf”，然后选择“nRF Connect for VS Code Extension Pack”进行安装，一旦nRF Connect for VS Code Extension Pack安装成功，所有nRF插件都自动安装成功。目前Nordic开发了如下nRF插件：
4.2.2 nRF Connect SDK安装
由于nRF Connect SDK放在GitHub服务器上，下载和安装nRF Connect SDK的时候请一定要使用VPN，否则很有可能就会下载不完整或者失败。
上面的nRF Connect for VS code插件安装成功后，点击左边的插件图标，进入WELCOME面板，选择Manage SDKs，如下：
然后在右边列表框中选择Install SDK，如下：
然后选择相应版本的nRF Connect SDK，如下：
请注意，如果你是一个新用户，强烈建议你选择最新版本，即列表里面版本最高的版本，上面是v2.5.0（截止本文第一次发表时），但是当你读到这时，最高版本有可能已经到v2.6.0，v2.7.0，甚至更高，请选择此时最高版本。(注意：*.*.99之类的版本是开发专用版本，不能用于量产)
选择好版本后，然后选择SDK安装根目录，一般使用默认推荐的目录即可，如下。大家千万不要使用很长的目录作为安装根目录，否则在Windows上编译例子的时候，经常会碰到目录名太长的编译报错。
然后VS code开始下载nRF Connect SDK，如下：
下载完成之后，你就可以打开SDK所在的根目录，如下：
SDK在下载过程中，经常碰到下载不完整的情况，而且这种情况又不会报错，为此我们可以通过下面的方式去检验nRF Connect SDK是否下载完整和正确，选择Manage west workspace，然后选择West Update，如下：
如果nRF Connect SDK还缺少一些组件没有下载完整，此时在OUTPUT窗口，你将会看到类似下面这样的报错信息：
如果nRF Connect SDK已经完整下载并正确，此时在OUTPUT窗口，你将会看到下面的信息输出：
除了上述的VS code安装成功确认方式，我们也可以通过目录和命令行的方式来确认nRF Connect SDK是否完整安装正确。
nRF Connect SDK和工具链安装成功后，都放在Windows如下目录里面：
打开CMD，进入相应SDK根目录，然后输入命令：git show，以确认安装版本是否正确：
然后，我们可以手动输入命令：west update，以同步nRF Connect SDK所有仓库，从而确认SDK是否下载完整和正确，如下：
如果最后没有出现报错信息，说明所有关联仓库都已经下载并同步成功，nRF Connect SDK已经下载完整和正确。