访问联盟网站

【Nordic博文分享系列】Matter开发,看这一篇就够了

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技术规范:

Specifications Download Request

其中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已经下载完整和正确。