matter原来叫Connected Home over IP (CHIP）项目，2021年5月12日正式更名为matter，是由原来的Zigbee联盟牵头，谷歌、苹果、亚马逊三巨头联合的一个项目，目标是针对智能家居场景，做到设备之间的互联互通。

CHIP项目2019年就成立了，成立之初项目进展一直非常缓慢，国内工信部苗圩部长看到对应新闻后有指示研究我也参与了工信部组织的几次研讨，2020年年初做了一版提案，2020年底成立了国内的开放智联联盟，目前基本是半荒废状态。

这类项目技术上往往不是最复杂的，但是在协议的规范性、对不同场景考虑的兼容性非常值得借鉴。

文档整理了这个项目的最新进展，对主要的实现做了梳理。

官网：Matter | Smart Home Device Solution - CSA (csa-iot.org)

Github：project-chip/connectedhomeip: Matter (formerly Project CHIP) is creating more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance (formerly Zigbee Alliance). (github.com)

1 Matter的历史

2014年7月Google以802.15.4为基础，基于网际协议（IP）开发了个新的协议—Thread。并联合了苹果公司一起推广基于IP的Thread协议。

Zigbee和Thread都是基于2.4GHz的802.15.4的协议，所以联盟推出了一个Dotdot，Dotdot是基于Thread和Zigbee之上的应用协议。目的在于统一Thread和Zigbee的互操作。

Thread协议市场反应一般，认证的产品很少，Dotdot也没多少认证产品，在2019年12月18日Google和Apple公司一起加入了Zigbee联盟，联合Zigbee联盟共同推广新的基于IP的协议，也就是Connected Home over IP (CHIP）工作组。

2021年5月12日Connected Home over IP (CHIP)项目正式更名为Matter

2 解决什么问题？好处有哪些？

主要解决不同厂商设备之间互联互通的问题！

2.1 没有生态壁垒

在 Matter 推出之前，每家设备厂商生产的智能家居设备只能通过自己的 App 控制，无法和其他生态设备互联。但通过 Matter 协议，所有支持 Matter 的 App 和硬件设备均可轻松无缝互联，协同工作。

目前，亚马逊、苹果、谷歌和三星等公司均已宣布支持 Matter。这意味着我们日常生活中常见的智能设备控制终端（如 iOS/安卓手机、语音助手、智能音箱等）均将支持 Matter 协议。用户甚至不需要单独的 Matter 设备 App，就可直接控制 Matter 设备。

2.2 更加自动化

Matter 允许设备间直接进行高效的通信，整个过程无需特定的转发设备。例如，Matter 智能开关或传感器可以直接打开/关闭 Matter 灯泡，而无需借助任何 App、云或其他特别操作。一旦完成配置，Matter 设备间的通信和控制都会直接在本地局域网络中实现。而且该系统对传感器或灯泡的厂商没有任何限制。

2.3 没有通信壁垒

Matter 协议可以让多种支持 IP 网络的设备协同工作，如 Wi-Fi 和 Thread/802.15.4 设备。您的手机通过 Matter 协议可以控制所有上述设备。

举个例子，您可以将一个 802.15.4 传感器设置为无需通过 App 或云，就直接打开/关闭一个 Wi-Fi 灯泡。当然，它也支持您通过手机 App 进行控制。Wi-Fi 和 Thread 设备之间通信时需要一个可以同时支持 Wi-Fi 和 802.15.4 协议的“Thread 边界路由器”，它可以让设备在两个网络之间进行通信。

值得一提的是，由于上述所有通信都在本地 Wi-Fi 或 Thread 网络中进行，因此即使在断网情况下，设备仍可正常工作。

Matter 还可以帮助目前的一些存量 Zigbee 或 Bluetooth LE Mesh 设备通过桥接方式接入 Matter 生态网络。

之前的提案中核心也是这个观点，传统的CS架构，厂商之间的设备通过云云对接，不光容易受到厂商的排他控制，而且全部绕云，对联动控制不友好。

2.4 更多生态系统

智能设备厂商通常还会同步推出生态系统，为终端用户提供更多功能。Matter 的出现使设备厂商能够以更低的成本支持多个生态系统。也就是说，一款 Matter 设备可以同时支持来自自家和其他厂商的多种生态系统。此外，它还可以降低设备厂商适配多种手机操作系统或语音助手的投入，集中精力为终端用户提供更多创新功能。

3 Matter 是什么？

是一个基于IPV6的应用层协议！

Matter定义了部署在设备上的基于 IPv6 网络的用层，以实现互操作性架构目标。Matter最初将以 Wi-Fi 和 Thread 作为底层通信的核心、未来将会支持蓝牙低功耗 (Bluetooth Low Energy)，Cellular，Ethernet等通信协议。

Matter应用层可以进一步细分为7个模块：

 

  • 应用层：设备的高阶商业逻辑。例如，专注于照明的应用程序可能包含打开/关闭灯泡以及灯泡颜色控制的逻辑。

  •  数据模型层：描述设备各种功能的数据原型。当应用程序有意与设备交互时，应用程序对这些数据结构进行操作。

  • 互动模型层：表示可以在设备上执行的能于设备交互的一组操作。例如，在设备上读取或写入属性将相当于和设备进行交互。这些操作对数据模型层定义的数据结构进行操作。

  • 动作框架层：一旦使用交互模型构建了一个动作，它就会被构造成一个方便 在“连接”上表示的，规范的二进制格式封包。

  • 安全性&加密和签名：对交互的数据进行加密和签名，以确保数据包的发送方和接收方都对数据进行加密和验证。

  • 消息构架和路由：与加密和签名的交互，通过可选的或需要的包头创建需要的数据构造，指定消息的属性以及一些路由信息。

  • IP 成帧和传输管理：将交互的数据进行IP封包，并将其发送到底层传输协议以进行数据的 IP 管理。

3.1 Matter的网络拓扑结构：

 

  • 设备通过蓝牙加入到Matter网络

  • 设备通过Wi-Fi 或Thread相互连接

  • Thread设备通过边界路由器（Border Routers)连接到其他的基于IP的网络

  • 网桥可以连接到其他协议的设备，例如Zigbee 和 Z-Wave

4 Matter的数据模型

4.1 数据模型结构

实现互联互通，上来就是看物模型，物模型统一，数据才能统一，才能互通流转，我们搞超级APP、搞统一云上来先统一物模型也是一样的逻辑。

Matter的物模型做了分层。

 

以照明为例：

 

Node（节点）：节点通常被定义为一个具有某些功能的网络可寻址实体，具有唯一性。用户可以看到的智能设备实体，比如我们的这个照明系统，就是一个节点。

Endpoint（端点）：端点可以被想象为一个可提供某种或某些服务的虚拟设备，每个节点可以拥有多个端点。比如，我们照明系统节点就拥有不止一个端点，Dimmable Light 和 On/Off Light 都是照明系统节点的端点。

Matter 规范定义了一些常见的 Device Types（设备类型），可代表一组常用功能。例如，我们的 Dimmable Light 和 On/Off Light 均为 Matter 规范中定义的标准设备类型。

Cluster：多个常用操作组合为一个可复用的模块。

以上图为例，我们的 Dimmable Light (Endpoint 1) 中有 2 个标准 Cluster：On/Off Cluster 和 Level Control Cluster。其中，On/Off Cluster 可完成打开或关闭设备的操作，Level Control Cluster 可完成配置设备电平的操作。也就是说，在实际的的 Dimmable Light 应用中，On/Off Cluster 可以控制灯泡的开关，Level Control Cluster 可以调节灯泡的亮度。

更进一步，假设我们还希望使 Dimmable Light 支持颜色控制功能，那么在该 Endpoint 中，还需要引入一个名为 Color Control 的标准 Cluster，用于控制灯泡的颜色。

我们照明系统中的另一个灯泡 On/Off Light 仅支持打开或关闭功能，因此只包括一个 On/Off Cluster。

从上图中，我们可以看到，每个 Cluster 内都有自己的 Attribute 和 Command。

Attribute：Attribute 表示可以读取或写入的内容。比如，On/Off Cluster 包含一个 OnOff Attribute，代表设备实际打开或关闭的状态；Level Control Cluster 包含一个 CurrentLevel Attribute，代表设备的电平等级。

Attribute 既可以长期有效，也可以在设备重启之后失效；读写权限也可设置为“只读”或“可读可写”。

Matter 规范中的 Attribute 支持丰富的数据类型：包括典型值、布尔值、整数（有符号/无符号）、浮点数、枚举数、字符串，甚至集合（列表或数据结构）。

Command：Command 代表触发 Cluster 进行某种行为的能力。每条 Command 可以有自己的参数。以上图为例，On/Off Cluster 中的 Toggle（切换开关）Command，可以改变 Cluster 的 OnOff Attribute；Level Control Cluster 中有 MoveToLevel、Move、Step 等 Command，可以调整 Cluster 的 CurrentLevel Attribute。

Matter 规范提供了一系列标准 Cluster（及其 Attribute 和 Command）。用户可根据具体设备，从列表中寻找适合自己设备的 Cluster。

4.2 Cluster 服务器和 Cluster 客户端


每个 Matter Cluster 均有自己的服务器以及对应的客户端。以我们的照明系统为例，Dimmable Light 和 On/Off Light 均可提供照明服务，因此均作为服务器，而用户通过 Cluster 客户端与服务器进行交互。

Cluster 服务器和客户端之间的关系如下图所示，其中：

 

  • 在 Dimmable Light 的例子中，Dimmer Switch（调光开关）作为 OnOff Cluster 和 Level Control Cluster 的客户端，可以控制作为 Cluster服务器的灯泡。

  • 在 On/Off Light 的例子中，Simple Switch（简单开关）作为 OnOff Cluster 的客户端，可以控制作为 Cluster 服务器的灯泡。

  • 此外，我们还可以将手机 App 作为 Cluster 的客户端，它同样可以控制作为 Cluster 服务器的灯泡。

  • 请注意，这里的 Dimmer Switch、Simple Switch、Dimmable Light、On/Off Light 和手机 App 均为 Matter 节点。

 

4.3 Endpoint 0

最后，让我们回到前文未作介绍的 Endpoint 0。Endpoint 0 的设备类型为“根节点”。作为一个特殊的 Endpoint，它提供了一些适用于整个节点的 Cluster，包括：

  • Basic Information Cluster Server（基本信息 Cluster 服务器）：提供有关节点的基本信息，如固件版本、制造商等。

  • ACL Cluster Server（ACL Cluster 服务器）：允许配置可访问控制此节点的其他节点列表。

  • Network Commissioning Cluster Server（网络调试 Cluster 服务器）：允许在节点上配置网络（Wi-Fi、以太网、Thread 等）。

4.4 借鉴

在现有我们的物模型设计中，例如固件版本等这些基础信息是通过单独的接口封装的，但是类似IP地址、网络信号强度、丢包率等之前并没有涉及，计划是通过单独的物模型来加入，在Matter的设计中基本的Attribute和Command与我们的物模型属性与服务类似，但是做了分层，Node（节点）下有Endpoint（短点），再往下才是物模型的具体值，同时通过强制预留的Endpoint 0来存储一些基本信息，这一点考虑的就比目前多数的物模型设计要完善。

5 怎么做本地控制？

使用 Matter 可以不需要借助任何云或手机 App，直接通过本地网络即可进行交互。

每个 Matter Cluster 都有一个 Cluster 服务器及其对应的客户端，Matter 设备之间的通信实际上就是 Cluster 服务器和客户端之间的通信。如上图所示，部署在开关中的 OnOff Cluster 客户端，可以打开或关闭部署在灯泡中的 OnOff Cluster 服务器。

不难理解，要实现这样的交互，开关需要通过某种方式了解有关灯泡的细节信息，这种方式即为设备绑定。绑定代表一种持久的连接关系，为一个端点与其他一个或多个端点进行安全交互提供了可能。用户可以（通过 Matter 手机 App）将来自不同厂商的不同设备绑定起来。

Matter 设备之间的交互方式有两种：

5.1 同步控制

以上述开关为例，开关作为绑定 Cluster 服务器，用户通过手机 APP 中的绑定 Cluster 客户端来发送绑定指令。能够提供绑定服务的绑定开关收到绑定指令后，会主动和灯泡建立一个安全的通信链路，从而实现灯泡和开关的绑定成功，之后用户对开关的任何操作（开或关）就会同步反映至灯泡上。具体过程如下：

同样地，如果我们希望通过一个 Dimmer Switch（调光器开关）控制一个 Dimmable Light（可调光灯泡），则 Dimmer Switch 还需要部署一个 OnOff Cluster 客户端、一个 Level Control Cluster 客户端以及一个 Binding Cluster 服务器。

5.2 异步通知（订阅—报告）

这种异步通知的交互方式允许订阅者接收来自发布者的数据报告，报告的内容可以是发布者的 Attribute 或 Event。

比如，恒温器就采用了这种异步交互方式，即恒温器订阅了传感器的 Attribute。首先，用户需要将恒温器与传感器绑定。完成后，恒温器就可以订阅传感器的 Attribute，并定期或在传感器 Attribute 变化时，接收来自传感器的数据。具体过程如下：

 

6 已有设备怎么互通？

通过网关桥接实现！

6.1 Matter 桥接设备是什么？

Matter 桥接设备可以让非 Matter 设备加入 Matter 生态系统（即下图中的 Matter Fabric），允许用户无差别得控制自己的 Matter 和非 Matter 设备。 

在 Matter 生态系统中，非 Matter 设备可以作为“被桥接设备”节点，通过桥接设备完成其他协议（如 Zigbee）和 Matter 协议之间的映射，从而与系统中的 Matter 设备进行通信。

下图所示 Matter-Zigbee 桥接设备可以让两个 Zigbee 灯泡加入 Matter 生态系统：

 

6.2 Matter 桥接设备的数据模型

是一个 Matter 桥接设备的数据模型示例。

 

  • Endpoint 0 中的设备类型为 Bridge。PartsList 字段列出桥接设备的所有端点，每个端点代表一个非 Matter 设备。

  • 每个端点上的 Descriptor（描述符）Cluster 可以提供有关特定被桥接设备的信息。

Matter 桥接设备除了充当协议“翻译”外，还可以具有 Matter 原生功能：比如一个智能恒温器设备既可以作为桥接设备，完成 Zigbee 等协议与 Matter 生态的通信，也可以同时作为一个标准的 Matter 智能恒温器设备，通过 Matter 协议向暖通系统发送控制指令。下图中的 Endpoint 1 即为智能温控，而其他端点代表“被桥接设备”。

 

以下是使用 Matter 协议在手机上控制 Zigbee 设备的工作流程：

第一步：Matter 桥接设备，作为一个 Matter 协议中定义的设备类型，需要首先遵循标准的 Matter 配网流程，使其加入 Matter 网络（即 Matter fabric）。

第二步：这个 Matter-Zigbee 桥接设备需要同时加入 Zigbee 网络。与 Matter 协议不同的是，Zigbee 协议并没有用定义标准的配网流程，而是由各厂商自行决定如何分发网络密钥。（Zigbee 3.0 以来最常见的入网方式是通过Install Code 来完成设备认证并入网。）

第三步：桥接设备一旦加入 Zigbee 网络，就会通过广播 Match Descriptor Request 命令的方式，来发现 Zigbee 网络中的设备。该命令包括所需的配置文件、In-Clusters（相当于服务器）和 Out-Clusters（相当于客户端）。在这个例子中，桥接设备加入 Zigbee 网络后，会广播一个类似“谁是支持 OnOff Cluster 的灯泡？”的问题。相应地，满足条件的 Zigbee 设备将回复一个 Match Descriptor Response 并附上自己的网络地址。之后，桥接设备将为每一个匹配的 Zigbee 设备添加一个动态端点，使其作为被桥接设备加入 Matter 网络。

第四步：Matter 系统将通过 Matter 规范中定义的 Operational Discovery（设备发现）机制发现这些桥接设备。

第五步：这样一来，Matter 系统中的控制器就可以在桥接设备的帮助下，控制 Zigbee 网络中的灯泡。

7 总结

Matter的整体实现上是中规中矩，并没有什么太多超出认知的巧妙实现，但是对不同设备的完善性、对老设备的兼容性考虑比较周到，在产品技术架构上有很多借鉴之处。相关代码实现已经开源，尤其在一些架构设计上可以作为实现落地的重要