艾睿电子-技术资讯

为什么需要Matter

在目前的智能家居产品中，如果要组建一个全屋互联的智能网络，就只能选择同一生态下的产品，亦或者是兼容多种生态的产品，比如苹果的Homekit、亚马逊的Alexa、小米的米家或是三星的SmartThings等等。然而这样割裂的生态迫使消费者的选择受到了限制，人们不得不因为品牌而妥协，而不是从功能、价格和质量上来做出选择。

目前在家居设备中，大到冰箱、电视、空调，小到门铃、灯泡、音响都已实现了智能化应用。随着物联网技术的不断优化，智能家居市场呈现着门庭若市的局面。但碍于不同的厂商都在打造自有的智能家居生态，出现了不能跨平台互联的问题，使得智能家居“碎片化”严重，没有统一的互联体系让智能家居略显鸡肋，也导致了智能家居与最初万物互联的发展愿景背道而驰。产品开发者必须考虑支持不同生态系统的接入协议，智能家居厂商多年来也被各种标准协议伤透了脑筋，尽可能让自己的产品支持更多的协议和软件生态，然而私有标准的存在让他们束手束脚。

为解决这一问题，2019 年 12 月，亚马逊、谷歌、苹果、CSA（连接标准联盟，原 Zigbee 联盟）等联合发起了智能家居互联协议 CHIP (Connected Home over IP)，即 Matter 的前身。CHIP 致力于打造一个基于开源生态的新智能家居协议，打破平台间的割裂和开发路径的差异。Matter 可实现智能家居和语音服务的兼容，例如亚马逊 Alexa、苹果 HomeKit 的 Siri、Google Assistant 等。Matter为塑造一个大一统的智能家居生态开辟了道路，未来这一市场上不再存在“消费者是谁的客户”的概念。如今开源标准Matter的出现终于让智能家居厂商有了参与标准制定的机会，减少了支持多协议多标准的产品与APP开发成本，直接面向所有消费者。

参与Matter开发的部分成员

协议开源，硬件互联

Matter 的第一个规范版本将基于现有的网络技术，包括以太网 (IEEE 802.3)、Wi-Fi (IEEE802.11) 和 Thread (IEEE 802.15.4)，可应用低功耗蓝牙简化设备调试流程。其中，Thread 由谷歌 Nest 部门主导开发，和 Zigbee 同样基于 IEEE802.15.4，但在传输层实现了 IPv6 支持，解放了设备互联的限制，支持低功耗设备直接接入互联网。

Matter软件分层

Matter 是一个统一的应用层，是一种用于在不同 IP 协议下运行设备的统一“语言”。设备只要遵循Matter 协议，就可以在不同平台上进行通信。Matter 让设备厂商更容易构建与智能家居和语音服务兼容的设备，例如设备厂商为了支持亚马逊 Alexa、苹果 HomeKit 的 Siri、Google Assistant ，原本需要准备三套方案，现在只要支持 Matter，就可以同时支持这三大平台。

其中以太网、WiFi、Thread用于设备之间通讯，而BLE用于设备的加网和设置。Matter把网络当做共享资源处理，没有指定排他性的网络所有权和访问权，这使得多个Matter网络可以共存于同一IP网络中，技术上实现了把Matter设备加入到不同的生态中,从而实现了广泛的兼容性。

Matter中定义了3种设备：

Border Router 用来连接Thread设备和WiFi设备。
Matter Device 被控终端设备，比如灯、插座。
Matter Controller 用来引导设备入网和发出控制指令的设备，比如手机。

Matter协议可以在无需连接到云端的情况下，实现本地设备的控制。对于Thread设备可以通过Border Router，比如Homepod mini来和其他的WiFi设备通信。

Matter的设备NODE

Matter的设备统称为NODE，一个NODE可以加入到一个或多个Fabrics，一个NODE下面又可以用Endpoint 表示不同的功能模块。比如一个双孔插座，用Endpoint 1，Endpoint 2 来表示插孔1和插孔2，Endpoint 0 来表示设备特性。Endpoint用Cluster来描述功能，定义了Attributes和Commands等元素，熟悉ZigBee的朋友会发现这和ZigBee是类似的，毕竟ZigBee联盟是发起者之一嘛。

联合已有的智能家居生态

尽管Matter给出的愿景看上去很美好，但也让不少消费者心生疑虑，自己已有的那些Zigbee、Z-Wave智能家居设备是不是就此淘汰了，并非如此。

“Any problem in computer science can be solved by antherlayer of indirection.计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。”

这句话几乎概括了计算机软件体系结构的设计要点，整个体系结构从上到下都是按照严格的层次结构设计的，不仅计算机软件整个体系是这样的，体系里面的每个组件本身，很多应用程序、软件系统甚至很多硬件结构都是按照这种层次的结构组织和设计的。Matter解决这个问题所使用的方法也不例外。

Matter使用bridge来连接非Matter设备

解决方案是添加一个bridge设备到Matter的fabric里，这个bridge设备负责Matter设备与非Matter设备通信，bridge把每个非Matter设备虚拟成对应的Endpoint，就像一个NODE里有多个不同功能的Endpoints一样，使得网络中的Matter设备可以通过bridge设备与非Matter设备通信。像乐鑫、Silicon Labs等厂商都在开发或已发布了提供桥接功能的方案，通过打造一个网关类的Matter桥接设备，连接已有的非Matter设备。

除此之外，一些较新的ZigBee设备，如果Flash够大的话，也有机会通过软件OTA升级来支持到Matter，毕竟Zigbee和Thread都建立在802.15.4无线电标准上。但不可避免的是，还会有一批智能家居设备被排除在Matter的阵营外，这也是技术迭代难以逃避的事实。所以待到Matter席卷整个智能家居市场之后，目标必将是建立一个无桥接的生态。

也有消费者疑虑，Matter设备既然支持多个平台，新购买的设备到底要加入哪一个平台？入网会不会更麻烦？其实不会，你使用哪家的APP，那么就将引导设备加入到对应的云平台，举例来说：如果你使用的小米的APP，那么就会引导Matter设备加入到小米的云平台，消费者无需知道中间的具体协议细节。

未来，消费者、企业和开发人员将借助Matter获得更多选择和兼容性。消费者可以在挑选设备时选择自己喜欢的品牌，而无需购买单一品牌的“全家桶”，更多的关心产品的功能和价格，而不是产品是否兼容家中的智能系统；开发者可以减少开发工作量，无需适配多个平台，并获得开源的参考实现；企业的供应链可以降低为不同平台备货的不确定性；对市场来说，Matter增强了互联互通，进一步推动了设备品类的增长。

Silicon Labs对Matter的支持

Matter代码贡献者

Silicon Labs贡献了Matter协议 21%的代码，是Matter的第三大贡献者（第一是苹果，第二是谷歌），主要在3个方面，ZAP工具，应用层Framework和示例代码。

1. Silicon Labs目前已支持Matter的芯片

Silicon Labs基于OpenThread的Matter芯片

Border Router用来连接Thread 设备和WiFi设备，只是用来通信，所需片上资源较小，所有的2.4G OpenThread芯片都可以满足要求。

Matter Device 被控终端设备，因为要处理应用逻辑，所需片上资源较多，就要选择Flash比较大的MG12和MG24芯片。如果还需要OTA升级功能，那只能选择1536K Flash的MG24了。

Silicon Labs基于WiFi的Matter芯片

目前基于WiFi的Matter芯片可以选择 RS9116 和 WF200，Silicon Labs提供了基于NCP架构的freertos的参考代码，后续还将开发一款基于Soc架构的SIX917芯片。

2、Silicon Labs支持Matter 的SDK

目前的Matter 的GSDK 是4.0版本。由于Matter GSDK的正式版本还没有发布，当前的测试版本和正式版本可能会有较大的差异，因此Matter GSDK目前还没有集成到SimplicityStudio IDE中，所以目前如果要想体验Matter的开发者，只能通过命令行工具来编译固件。

在2022年上半年Silicon Labs将发布GSDK 4.1版本，该版本支持将Zigbee设备通过bridge接入Matter，在2022年下半年，Silicon Labs将发布GSDK 4.2版本，并且计划将Matter SDK集成到SimplicityStudio中，届时Matter的应用开发将更加容易。

艾睿代理Silicon Labs芯片，如需了解更多，请持续关注并与我们联系。