碎片化困局与统一标准的动机

智能家居诞生二十多年，最大的障碍从来不是技术不够先进，而是各家生态把设备锁在自己的云端。同一个灯泡，A 品牌的 App 能调亮度，B 品牌的音箱喊不动它；用户买设备时先要确认“你归谁管”，这在消费电子领域是相当反常识的体验。厂商也有苦衷：每一家都希望用户留在自己的生态里，于是协议越做越封闭，互联互通被安全性、商业利益和技术债三重因素卡住。

Matter 要解决的核心问题只有一个：让设备应用层说同一种语言，让控制器不再需要为每个品牌写一套私有驱动。

Matter 由连接标准联盟（CSA）推动，得到了苹果、谷歌、亚马逊、三星等主要生态的共同支持。它的定位不是发明一种新的无线技术，而是在既有的无线网络之上，统一应用层的数据模型与交互方式。这一点非常关键：底层仍然可以是 Thread、WiFi 或以太网，Matter 关心的是“上面怎么表达和控制”。

Matter 是什么：协议栈与认证

把 Matter 的技术栈从上往下看，大致是四层：应用层定义设备类型、簇与属性；交互模型定义订阅、上报、读写等操作；安全层基于证书与密钥体系完成设备身份认证与会话加密；传输层则把报文承载在 Thread 或 WiFi/Ethernet 之上，并用 IPv6 统一寻址。

几个必须分清的概念
  • Matter 与 ThreadMatter 是应用层标准，Thread 是一种低功耗网状网络。设备可以走 Thread，也可以走 WiFi，两者是并列的承载方式。
  • 边界路由器把 Thread 网络与家中 IP 网络打通，同时担任 Thread 网络的管理职责，通常由智能音箱或中枢设备承担。
  • 认证与生态通过认证意味着设备实现了标准行为；能否被某个 App 控制，取决于该 App 是否为认证控制器，而不是取决于品牌。
  • 多管理员同一台设备可以同时被多个控制器控制，这是实现“跨生态互联”的机制基础。

理解“认证”的意义很重要。Matter 不要求厂商使用统一芯片，也不要求统一的云；它要求的是设备符合标准数据模型与安全要求，并能在本地被控制器直接发现与控制。这使得生态之间的壁垒从“协议不通”降级为“功能差异”，这是实质性的进步。

数据模型：端点、簇与属性

Matter 用一套层次化的数据模型描述设备，这套模型是理解它一切行为的钥匙。最外层是节点，一台设备就是一个节点；节点内部按功能划分为若干端点；每个端点挂载若干簇；每个簇里包含属性、命令与事件。

  • 端点（Endpoint）：表示设备的一个功能单元。一盏带开关的灯通常一端点是灯、另一端点是开关，它们各自有独立能力。
  • 簇（Cluster）：一组相关能力的集合。开关类用 OnOff 簇，亮度用 LevelControl 簇，色温用 ColorControl 簇，测量类用各种 Measurement 簇。
  • 属性（Attribute）：簇里的具体状态，例如 OnOff 簇里的 OnOff 属性就是一个布尔值。
  • 命令（Command）：可被调用的动作，例如 OnOff 簇的 Toggle 命令；属性可读写时也可通过写属性实现控制。

这套模型的最大好处是可预测。控制器不需要为每台设备写驱动，只要知道“这是个灯”，就知道去读 1 号端点的 6 号簇 0 号属性；知道“这是个门磁”，就知道去读 BooleanState 簇的 StateValue。设备之间的差异被限制在能力的组合方式上，而不是各自发明的私有指令里。

本地化优先与配网模型

Matter 的一项设计取向非常明确：控制应当尽量在本地完成，云端是增强而不是前提。控制器与设备在同一局域网内时，可以通过组播发现、直接建立加密会话，不经过厂商云服务器。这带来三个直接收益：响应快、断网可继续工作、隐私数据不出家门。

配网流程也体现了这个思路。新设备被加入网络时，通过二维码或配对码提供一次性凭证，控制器据此与设备建立安全的初始通道，随后把设备接入 Thread 或 WiFi 网络，并写入网络凭据与操作凭证。整个过程不依赖“必须先用厂商 App 注册账号”，这也是它区别于早期生态配网的关键差异。

各类智能设备图标沿圆环排列并汇聚到中心徽章的对称插画
同一个圆环上的设备来自不同品牌，却共享同一套数据模型与安全机制。Matter 的真正价值不在于统一硬件，而在于统一对话方式。

从代码看控制路径

要让 Matter 设备被程序控制，通常需要一个常驻控制器进程承担协议栈与证书管理，上层程序通过它的接口存取属性。社区里常用的 python-matter-server 就是这样一层，它对外暴露 WebSocket 接口，把复杂的协议细节收进命令与事件里。下面这段代码读取一盏灯的开关属性。

import asyncio, json, websockets

WS = "ws://192.168.1.30:5580/ws"
NODE_ID  = 12        # Matter 分配给该设备的节点号
ENDPOINT = 1         # 灯所在的端点
CLUSTER_ONOFF   = 6  # OnOff 簇
ATTR_ONOFF      = 0  # OnOff 属性

async def main():
    async with websockets.connect(WS) as ws:
        await ws.send(json.dumps({
            "message_id": "1",
            "command": "read_attribute",
            "args": {
                "node_id": NODE_ID,
                # 属性路径格式：端点/簇/属性
                "attribute_path": f"{ENDPOINT}/{CLUSTER_ONOFF}/{ATTR_ONOFF}",
            },
        }))
        print("读取结果:", json.loads(await ws.recv()))

asyncio.run(main())

读属性适合初始化状态，但持续监控更好的方式是订阅。订阅之后设备状态发生变化时会主动推送，不需要控制器反复查询，这在有几十台设备的环境里能显著降低网络与设备功耗。

import asyncio, json, websockets

async def main():
    async with websockets.connect("ws://192.168.1.30:5580/ws") as ws:
        # 订阅属性变化：只在状态真正改变时收到推送
        await ws.send(json.dumps({
            "message_id": "10",
            "command": "subscribe_attribute",
            "args": {"node_id": 12, "attribute_path": "1/6/0"},
        }))
        while True:
            msg = json.loads(await ws.recv())
            if msg.get("event") == "attribute_updated":
                print("设备状态更新:", msg.get("data"))

asyncio.run(main())

两段代码放在一起看，就能看清 Matter 给开发者带来的便利：控制一台设备所需的信息，只有节点号与属性路径——其余全部由标准定义。换一个品牌、换一种承载网络，代码不需要改动。