Matter 学习笔记 | 不知名LZJ的博客

这篇是 Matter 相关概念的整理和记录，方便自己以后回看。下面按这几块记：
全局理解：Matter 是干什么的、在智能家居生态里的角色；解决了哪些行业问题
基本概念：Matter Controller、Commissioning、Thread、Fabric、Node、mDNS、Device Model（Cluster / Endpoint）、Multi-admin、Thread border router、Matter 数据类型与 TLV、cluster 规范细节、ZAP 与 application cluster 对照、PASE/CASE、mDNS 细节（见 6）
实践应用：Secondary Controller + Custom Cluster 方案（项目里怎么用）
总结与关系网、故事线
附录：AI 工具使用参考

一、Matter 是谁，在生态里干什么？

1. 什么是Matter

Matter（前称 Project CHIP）是一套由 CSA（连接标准联盟）推动的开放式智能家居通讯协议。专为解决智能家居设备兼容性问题，使不同品牌、不同生态系统的设备能够无缝互操作。目的在于创建更多对象之间的连接，简化了制造商的开发流程，并提高消费者的兼容性。

它规定了一套规则，让你家里的不同品牌的智能设备能互相”对话”。

它强调本地控制，不像很多智能家居方案那样依赖云服务器（云服务器有延迟、隐私风险、依赖网络）。

它是硬件-厂商中立的，任何厂商生产的设备，只要遵守 Matter 协议，就能和其他 Matter 设备协作。

如果用一句最直白的话概括：

Matter 是一套“跨品牌统一语言 + 统一规则”的智能家居标准，目标是：让任何品牌的设备，在任何平台上都能互联互通，而且尽量在本地就能跑起来。

2. Matter的意义

在Matter之前

每个大厂都想建立自己的生态，每家有自己的协议、云和 App（例如小米、华为、Apple、Google、亚马逊）

Matter 想做的是

本地控制 - 不依赖云

本地优先：设备之间直接对话，Hub 做本地中枢。云可以是“增值层”，而不是“必需层”。

你的灯、门锁、摄像头都接入 Matter 协议

Hub 是本地的”大脑”，负责接收命令、转发控制

即使网络断了，灯仍然能开关（只要 Hub 还能和灯通讯）

隐私数据留在家里，不上云

统一认证 - 一套规则走天下

Matter 定义了统一的”配网和认证方式”（Commissioning）。灯、开关、场景、传感器都有统一的“语义”；

不管你的灯是飞利浦、松下还是小米的，接入 Matter Hub 时，流程都一样

用二维码或 PIN 码，约 30 秒完成配置

不用每个品牌都下一个 App，一个 Hub App就够了

跨生态协作 - 让品牌和平共处

Matter 打破了”非此即彼”的生态选择。

同一个 Hub 里，可以有苹果的、谷歌的、亚马逊的、三星的设备

它们互相可以联动（比如”门被打开时，灯自动亮”），不用再费劲”翻译”

多个 Hub 也能共存：家里装了苹果 HomePod 和谷歌 Home，它们各自也能接入 Matter 设备，不冲突

3. 对我们来说

从我们做的产品角度，只要认真做好一个 Matter 友好的本地中枢（Core Hub），就天然获得一个庞大的设备生态，不必为每个品牌定制协议适配。

二、基本概念

1. Matter Controller - “配网 + 控制的“大脑””

Controller 就是“能配网 + 能发指令 + 能接收上报”的控制端。

它负责：

Commissioning 新设备（帮你把设备拉进家）

维护设备身份、密钥、安全会话

发控制命令（开灯、关门、调温等）

接收设备上报的状态和事件

可以理解为，Hub App为校长，Controller为老师，灯/门窗为学生。校长负责决策，然后通知老师，老师再发送“全班站队”等指令。

2. Commissioning - “让新设备加入家庭（Fabric）的流程”

Commissioning 是设备接入 Matter 网络的整个流程（让一个“新来的设备”正式加入到你的家庭网络 + 安全域的过程）。

具体在干什么

参考：Commissioning 补充

发现设备

通过 BLE、SoftAP 或局域网找到那台待加入的设备。

验证它真的是“你要加的那一台”

用户通过扫描二维码或输入配对码（Setup Code），同时验证是否为正品（使用数字签名）

给它配网络

把你的 Wi‑Fi / Thread 网络信息安全发给设备，让它能连上家庭网络。

加入 Fabric（“加入家庭”）

给它分配 Node ID、证书等；

从此它就是你这个家庭的一员。

开始正常通信

Controller 可以读取/写入属性，订阅事件，发命令……

用户体验是什么样

作为用户，你不需要懂上面这些细节。你需要做的就是：

打开你的 Hub App

点”添加设备”

扫描灯上的 QR 码（或输入 PIN 码）

等 30 秒，设备自动加入

Commissioning 的核心目的：确保只有”被允许”的设备能加入你的家庭网络，陌生人的设备加不进来。

3. Thread - “低功耗Mesh物理传输层”

Thread是一种面向 IoT 的低功耗 Mesh 网络协议，不是 Matter 独有的，但 Matter 强烈推荐使用。 简单说：

Matter 可以运行在 WiFi 上

也可以运行在蓝牙上

也可以运行在 Thread 上

Thread 是最”原生”的选择。

为什么需要 Thread

Wi‑Fi：带宽高，但耗电大，适合摄像头、网关这类“大设备”；

蓝牙：适合近场配对，但不适合大规模、常在线的联动；

Thread：

每个设备都可以帮忙转发消息，形成 Mesh；
功耗低，适合传感器、门窗磁、简单开关、按钮这类“小设备”。

对 Matter 来说：

Matter 统一在 IP 层（IPv6）之上工作；

Thread 给低功耗设备提供了一个“会说 IP 的低功耗网络”。

举个例子

想象家里有 50 个智能设备（灯、窗帘、门锁、传感器……），都连 WiFi：

WiFi 路由器压力大：有限的连接数，容易掉线

功耗高：一个便宜的传感器 WiFi 芯片很贵，功耗也大

覆盖不全：家里某个角落的信号死角，WiFi 到不了

4. Fabric - “安全域”

Fabric 是 Matter 系统里的”信任域”或”家庭”的概念，是一套“共同信任关系”下的一群设备和控制端，可以看成是一个“虚拟家庭”。

换个角度说：在同一个 Fabric 里，大家互相信任，可以安全通信。

一个 Fabric 代表：

安全隔离：Fabric 内的设备用同一套加密密钥通讯，Fabric 外的设备看不懂它们的消息
权限统一：在这个 Fabric 里，只有被认可的用户和 Hub 才能控制这些灯
独立账户系统：每个 Fabric 有自己的”用户列表”、“设备列表”、“权限表”

关键点：

一个物理设备可以加入多个 Fabric：

灯既可以被”家庭 Hub”控制
也可以同时被”Apple HomeKit”控制
还可以被”Google Home”控制

用户可以有多个 Fabric：因为灯内部维护了多个 Fabric 的加密密钥。

家庭 Fabric：家里的灯、门锁、空调、摄像头
办公室 Fabric：办公室的灯、会议室屏幕
父母家 Fabric：远方父母的智能家居系统

5. Node - “设备实体”

Node 是 Matter 系统里对”物理设备”的抽象。每个 Node 有一个在 Fabric 内唯一的 Node ID，Node 内部再拆分为多个 Endpoint（子功能）。

可以这么理解：

灯 = 一个 Node

门锁 = 一个 Node

Hub 本身 = 一个 Node

温度计 = 一个 Node

稍微复杂一点的例子：

一个多功能智能插座可能有：

一个”插座”功能（Node A）
一个”功耗统计”功能（Node B）
它们住在同一块硬件里，但 Matter 系统看作两个 Node

6. mDNS 详解（重点） - “本地发现设备/服务”

1.1 mDNS 基础概念

Multicast DNS（多播 DNS）是一种零配置网络协议，在局域网内实现主机名解析与服务发现的机制，不依赖外部 DNS 服务器。它的核心价值是解决 “无中央服务器时，设备如何互相找到对方” 的问题 —— 这正是智能家居设备入网、控制的核心诉求。

区别于传统 DNS：

维度	传统 DNS	mDNS
解析方式	集中式服务器查询	局域网组播广播
角色定位	客户端 - 服务器模式	每个节点既是客户端也是服务器
适用范围	广域网	局域网（LAN）
配置依赖	需预先配置 DNS 服务器	零配置

为什么是智能家居（Matter）的标准选择？

零配置：无需用户手动设置 IP、DNS，设备上电即能被发现（契合智能家居 “小白用户” 场景）；

去中心化：无单点故障，即使某台设备离线，不影响其他设备的发现流程；

低延迟：局域网内直接组播通信，响应速度＜1 秒（满足设备控制实时性需求）；

广泛兼容：Apple Bonjour、Linux Avahi、Windows 10+ 原生支持，Matter 直接复用该生态；

标准化：基于 RFC 6762（mDNS）+ RFC 6763（DNS-SD），跨厂商设备互通无阻碍；

Matter 定制扩展：在标准 mDNS 基础上增加 Matter 专属服务类型与元数据，适配设备入网 / 控制双场景。

重点：
mDNS = 局域网内 “无服务器的 DNS + 服务发现”
Matter 中核心作用：设备入网前发现（配网）+ 入网后控制（操作）

1.2 工作原理

核心参数（Matter 场景固定值）

类型	细节
组播地址	IPv4：224.0.0.251；IPv6：ff02::fb
通信端口	mDNS 协议端口：5353/UDP；Matter 操作端口：5540/TCP
服务类型	入网发现：`_matterc._udp.local.`；操作发现：`_matter._tcp.local.`

核心工作机制（3 步循环）

服务注册（Service Announcement）

设备上电 / 入网后，向局域网组播地址发送 “服务公告”，宣告自身存在：

未入网设备（待配网）：注册 _matterc._udp.local. 服务，携带 “区分符、配网方式” 等元数据；

已入网设备（可控制）：注册 _matter._tcp.local. 服务，携带 “Fabric ID、Node ID” 等归属信息；

所有支持 mDNS 的设备（控制器、其他终端）都会监听组播地址，缓存公告信息。

查询（Query）

控制器（如手机、网关）需要发现设备时，向组播地址发送 “针对性查询”：

配网场景：查询 _matterc._udp.local.，可附加 “区分符” 筛选（如只找二维码中的设备）；

控制场景：查询 _matter._tcp.local.，可附加 “Fabric ID” 筛选（只找自己网络内的设备）。

响应（Response）

匹配查询条件的设备，向组播地址发送响应包，包含 3 类关键记录：

PTR 记录：确认 “我提供目标服务”（如 ABC123._matterc._udp.local.）；

SRV 记录：告知 “我的网络位置”（主机名 + 端口，如 light-abc.local.:5540）；

TXT 记录：携带 “设备元数据”（厂商 ID、产品 ID、设备类型等）；

A/AAAA 记录：响应后续主机名解析，返回设备 IP 地址。

DNS-SD：mDNS 的 “服务发现搭档”

mDNS 解决 “名字→IP” 的解析问题，而 DNS-SD（DNS-based Service Discovery）解决 “局域网有哪些可用服务” 的问题 —— 两者配合实现 Matter 设备的完整发现：

Matter 场景典型流程（配网阶段）：

手机（控制器）广播查询：“谁提供 _matterc._udp.local 服务？（区分符=3840）” → DNS-SD 查询

Matter 特有：双场景完整流程

TXT 记录：Matter 设备的 “身份名片”

TXT 记录是键值对格式的元数据，Matter 协议对其字段有严格规范，不同场景字段不同：

字段	含义	适用场景	示例值	备注
`D`	区分符（Discriminator）	入网发现	`3840`（0xF00）	匹配配网二维码 / 手动代码
`V`	供应商 ID（Vendor ID）	所有场景	`0x1234`	16 位整数，Matter 联盟分配
`P`	产品 ID（Product ID）	所有场景	`0x5678`	16 位整数，厂商自定义
`C`	连接方式（Connectivity）	所有场景	`0x03`	位掩码：0x01=Wi-Fi，0x02=Thread
`R`	设备角色（Role）	所有场景	`0`	0 = 终端设备，1 = 控制器
`K`	配网方法（Commissioning）	入网发现	`0x01`	位掩码：0x01=BLE 配网
`S`	配网状态（State）	入网发现	`1`	1 = 就绪，0 = 未就绪
`L`	设备型号（Model Name）	可选（所有场景）	`SmartLight-100`	厂商自定义名称

解析示例（待配网设备）：

TXT 记录：D=3840, V=0x1234, P=0x5678, C=0x03, K=0x01, S=1, L=SmartLight-100

含义：

这是一台待配网的 Matter 设备（K=0x01 支持 BLE 配网，S=1 已就绪）

区分符 3840（配网时需匹配该标识）

厂商 ID 0x1234，产品 ID 0x5678，型号为 SmartLight-100

同时支持 Wi-Fi（0x01）和 Thread（0x02）连接

解析示例（已入网设备）：

TXT 记录：V=0x1234, P=0x5678, C=0x02, R=0

服务实例名：2906C908D115D362-8FC7772401CD0696._matter._tcp.local.

含义：

已加入 Matter 网络，Fabric ID=2906C908D115D362，Node ID=8FC7772401CD0696

角色为终端设备（R=0），仅支持 Thread 连接（C=0x02）

7. Device Model - “设备模型”

Matter 的 Device Model（设备模型）是把所有 “灯/插座/开关/摄像头/传感器” 的能力，都被拆成一套统一的结构。是 Matter 系统里对”设备能做什么”的完整描述

[重点] Cluster - 功能模块（开关、亮度、温度……）

Cluster 是设备功能的”分类”。一个 Endpoint 里可以有多个 Cluster。

Cluster 是一组相关功能的集合，可以理解为设备上的一个功能模块。

每个 Cluster 定义了：

Attributes（属性）：状态和配置

Commands（命令）：可执行的动作

Events（事件）：发生过的关键事情

Data Report（数据上报）：属性/事件的推送机制

Attribute / Event / Command / Data Report 分别干什么？

Attribute（属性状态/配置）

表示设备“现在是什么状态 / 怎么配置”
例子：

OnOff = true/false（灯是亮的还是灭的）
CurrentLevel（亮度）
MeasuredValue（当前温度）

Event（事件）

表示“刚刚发生了一件有意义的事情”
例子：

门被打开
过载保护触发
设备重启

Command（动作命令）

Controller 发给设备的动作指令
例子：

On() / Off() / Toggle()

Data Report（数据上报）

Data Report 是设备周期性地汇报某个 Attribute 的值。

设备按订阅或条件，把 Attribute / Event 主动推给 Controller；
避免 Controller 轮询，提高响应性。

Cluster 类型例子

智能灯的 Device Model

Matter 协议中 Node 的 Endpoint 0 详解

Endpoint 0 是 Matter 协议中唯一强制要求的端点，所有 Matter 设备必须包含它，被永久保留给 Matter 的 Utility Clusters，提供设备的基础管理和服务功能，而非具体应用功能（如开关灯、温度控制等）。核心功能：设备身份与基础信息管理、网络与安全配置、设备发现与诊断、软件更新管理、全局属性与设置。

7.1 Endpoint 0 包含的主要 Cluster

必选集群 (Mandatory Clusters)：Basic Information、Access Control、Descriptor 等

常见可选集群 (Common Optional Clusters)：Network Commissioning、Software Update、Fault Management 等

7.2 Endpoint 0 的关键特性

唯一性与强制性：

每个 Matter 设备必须且只能有一个 Endpoint 0

是唯一强制存在的端点，其他端点 (1,2,3…) 都是可选的

功能边界：

只包含通用服务和管理功能，不包含设备特定应用功能

设备特定功能 (如灯的开关、温度控制) 应放在其他端点 (1,2 等)

与其他端点关系：

作为整个设备的 “根节点”(Root Node)，提供基础服务

Descriptor Cluster 会列出设备所有端点及其支持的集群，包括 Endpoint 0 自身

7.3 Endpoint 0 的典型应用场景

设备配网阶段：通过 Network Commissioning Cluster 配置网络参数

设备管理：管理员通过 ACL Cluster 设置访问权限

设备发现：控制器通过 Descriptor Cluster 获取设备完整功能列表

固件更新：通过 Software Update Cluster 执行 OTA 升级

故障排查：通过 Fault Management Cluster 诊断设备问题

Endpoint 0 是 Matter 设备的 “控制中枢”，负责设备的基础管理和服务功能，是设备接入 Matter 网络的必要条件。它通过一组标准化的 Utility Clusters 提供了设备发现、配置、安全和维护等核心功能，确保不同厂商设备间的互操作性。

记住：如果一个设备声称支持 Matter 协议，它必须包含 Endpoint 0 及其核心集群 (至少包括 Basic Information、Access Control 和 Descriptor 集群)。

Custom Cluster

Custom Cluster 是自定义的功能块，不在官方标准 Cluster 列表里。

用途：

标准 Cluster 不够用时，你可以定义自己的功能：

比如某个摄像头有“特殊 AI 识别模式”，标准里没有；
你可以自定义一个 Cluster，定义自己的属性和命令。

设计建议：

尽量先用标准 Cluster；

确实找不到合适的，再考虑 Custom Cluster，但要保持良好的文档，让第三方容易集成。

Endpoint - “设备里的“子设备/子功能块”

Endpoint 是设备上的“逻辑端点”，用来区分不同的功能实体，是 Device Model 的容器。一个 Node 可以有多个 Endpoint。每个 Endpoint 内再包含多个 Cluster。

举例

用户体验：你的 Hub App 里会看到”客厅灯”这个设备，点进去有两个功能区：“主灯”和”装饰灯”，各自可独立控制。

可以理解为：

Endpoint = 设备内部的“子设备/子模块”；

每个 Endpoint 暴露一组 Cluster 作为自己的功能接口。

8. Multi-admin 模式 - “一个设备被多个平台同时控制”

Multi-admin = 同一台 Matter 设备可以同时被多个独立的 Controller / 平台控制。

表现形式是：

设备加入多个 Fabric；

每个 Fabric 都可以有自己的管理员（Controller）和用户应用。

现实场景：

用户家里有：

Apple Home（HomePod）
Google Home（Nest）
或者我们公司自己的 Core Hub

一盏的灯：

既出现在 Apple Home App 里；
也出现在我们的 Web / App 控制端里；
也可以被语音音箱控制。

对实现的影响：

Core 只是“众多大脑之一”

不能假设我们控制的是“唯一真相”；

要通过订阅（Data Report / Events）始终保持状态同步。

设计要足够宽容

当设备状态被别的平台改变时，要正确更新 UI、自动化决策；

自动化逻辑应基于“当前实际状态”，而不是“上一次下的命令”。

从产品定位上看，这是机会

不需要去“抢走控制权”，而是提供：

更强的本地自动化
更本地化的视觉分析能力
更可编程的插件系统（JS 插件、Go 插件等）

让 Core 成为“高级玩法”和“开源玩法”的中心，而不是和 Apple/Google 直接竞争。

9. Thread border router - “Thread边界路由”

作用：Thread border router 充当 Thread 网络（一个低功耗、基于IP的无线 Mesh 网络）与其他网络（如 Wi-Fi 或以太网）之间的 Gateway。它允许连接到 Thread 网络的设备与外部网络（如互联网或其他 Matter 设备）进行通信。

为什么需要：因为 Thread 网络内部的设备通常无法直接连接外部网络，通过边界路由器，可以实现这些设备的外部访问和互联。

10. Matter primitive 数据类型

定义：Matter 协议中定义的基本数据类型，包括整数、浮点数、字符串、布尔值等。

特别注意：bitmap 类型，可以用二进制位来表示多个状态。例如，一个 8 位的 bitmap 可以表示 8 种开关状态，每一位代表一种状态的开启或关闭。

11. TLV 格式

定义：TLV（Type-Length-Value）是一种数据编码格式，用于 Matter 协议中传递结构化数据。

组成：由三部分组成：

Type（类型）：表示数据的种类。
Length（长度）：表示后面值的长度。
Value（值）：实际的数据内容。

例如，传输一个温度值 30.5℃ 可以表示为：类型为温度，长度为 4（假设是 32 位浮点数），值为 30.5。

12. cluster 规范的细节

subscribe 机制：允许设备订阅其他设备的特定属性，如果被订阅的属性发生变化，例如温度变化，相关设备会自动发送更新通知，无需客户端轮询。

Feature：指 cluster 支持的可选功能，比如一个温度传感器可能支持的高温报警功能。

Conformance：指设备必须满足的具体要求。如果某设备实现了某个 cluster，它必须实现该 cluster 的一些必选属性或命令。

Quality：指数据的质量属性，比如可读性、可写性，以及是否支持订阅等。

13. ZAP XML/json 定义的 cluster 例子

定义：ZAP（Zigbee Cluster Library (ZCL) Advanced Platform）是用于定义 cluster 的工具，使用 XML 或 JSON 格式来描述 cluster 的结构（属性、命令、事件等）。

例子：举个简单的 cluster（如 On/Off Cluster），在 XML 中可能会有 OnOff 这个属性（布尔值），而相关文档会说明这个属性用于表示灯的开关状态。

14. PASE / CASE

PASE（Passcode-Authenticated Session Establishment）：用于设备配网时通过输入配对码来建立安全会话，用户需要进行验证。

CASE（Certificate Authenticated Session Establishment）：用于已连接网络中的设备之间的安全会话，使用证书进行身份验证，通常更安全，适用于设备间的通信。

重点：我们只需知道它们都是用于建立加密通信的安全协议，其中 CASE 是相对更重要的。

15. mDNS 小结

mDNS 在 Matter 中的用途与细节（入网发现、操作发现、TXT 字段等）见上文 6. mDNS 详解。mDNS 不止 Matter 用，我们 core 里也会用到，是本地设备发现的标准选择。

总结：

1. 从底层网络到 Core Hub

网络 & 组织层：

Thread：低功耗设备用的物理/链路层网络
Fabric：安全信任域/“家庭”
Node：Fabric 里的“设备个体”

设备功能层（Device Model）：

Endpoint：设备里的“子设备/子功能块”
Cluster：功能模块（开关、亮度、温度……）

Attribute：状态/配置
Command：动作
Event：发生过的事
Data Report：上报机制

交互和接入层：

Matter Controller：做配网 + 控制的“大脑”
Commissioning：让新设备加入家庭（Fabric）的流程
mDNS：本地发现设备/服务
Multi-admin：一个设备被多个平台同时控制

2. 关系网

Thread：给大量低功耗设备（传感器、小开关）用的 Mesh 网络，是 Matter 底层可选物理网络之一。

Fabric：一个安全信任域/家庭，里面有一组 Controller + 一组设备（Node）。

Node：设备在某个 Fabric 中的逻辑身份（在实现里就是一个 Device）。

Endpoint：设备内部的逻辑子设备/子功能区。

Cluster：Endpoint 上的功能模块：

Attribute：状态/配置；
Command：动作；
Event：发生的事件；
Data Report：上报方式。

Custom Cluster：标准不够用时，自定义的功能模块。

Matter Controller：在某个 Fabric 中，负责 Commissioning + 控制 + 收事件的“大脑”。

Commissioning：把一个新设备拉进某个 Fabric，变成 Node 的过程（验证身份、配网、建安全信任）。

mDNS：在局域网里发现设备/服务的“广播式 DNS”，Controller 用它找到设备，我们也可以用它发现容器化组件。

Multi-admin：同一物理设备可加入多个 Fabric，被多个平台/Controller 同时控制。

3. 举个例子：用”故事线”串起来——一台新灯加入我们的 Core

按时间顺序看一遍，这些概念怎么串到一起。

步骤 1：设备物理接入网络（Thread / Wi‑Fi）

灯通电后，通过 Wi‑Fi 或 Thread 加入家里的局域网：

如果是 Wi‑Fi 灯：直接连路由器；
如果是 Thread 灯：连到 Thread Mesh，再通过 Border Router 进局域网。

这里涉及的名词：

Thread：给大量低功耗设备用的 Mesh 网络，让“小东西”能稳定在线；

步骤 2：在局域网里“找到它”（mDNS）

灯一上电，会通过 mDNS 在本地“喊一声”：

“我是一个支持 Matter 的设备，我在这里，有这些服务。”

我们的 Matter Controller 通过 mDNS 发现这台新灯。

这里涉及的名词：

mDNS：本地服务发现机制，相当于“局域网里的广播式 DNS”，让 Controller 知道“有哪些 Matter 设备在场”。

步骤 3：把灯“收编进家庭”（Commissioning + Fabric + Node）

这一步就是 Commissioning：

用户在 App/界面里触发“添加新设备”；

Controller 引导用户扫二维码 / 输入配对码；

Controller 与灯建立安全连接，验证身份；

配置灯的网络参数（如果需要）；

把灯加入某个 Fabric，并给它分配一个 Node ID。

涉及名词：

Commissioning：从“新设备”到“我家设备”的完整入网+绑定流程。

Fabric：我们这套 Core + Controller + 设备共同形成的“信任域/家庭”。以后，Apple Home / Google Home 也可以把这台灯加入它们自己的 Fabric。

Node：这台灯在我们这个 Fabric 下的逻辑身份，拥有一个 Node ID。在 Go SDK 中，一般会有一个 DeviceNode 对象对应它。

步骤 4：理解“这台灯会什么”（Node → Endpoint → Cluster）

Commissioning 完成后，Controller 会读取这台灯的 Device Model：

在我们的 Fabric 中，这台灯是一个 Node；

这个 Node 里有多个 Endpoint，比如：

Endpoint 0：设备信息（系统级，比如 Basic Info）
Endpoint 1：灯本体功能（开关、亮度、颜色等）

每个 Endpoint 下面有多个 Cluster。

比如 Endpoint 1：

On/Off Cluster：

Attribute：OnOff（当前开/关状态）
Commands：On(), Off(), Toggle()
Event：某些实现会在状态变化时产生事件

Level Control Cluster：

Attribute：CurrentLevel（亮度）
Commands：MoveToLevel(), Step(), …

涉及名词：

Endpoint：逻辑子设备/子功能区。同一物理设备里可以有多个 Endpoint。

Cluster：功能模块。例如：

On/Off（开关）
Level Control（亮度）
Color Control（颜色）每个 Cluster 内部有：
Attribute：状态/配置（比如当前亮度值、是否打开）。
Command：能发给设备的动作（开、关、调亮度……）。
Event：记录“发生过什么事”（如过载、传感器触发）。
Data Report：设备主动把 Attribute/Event 推给 Controller 的机制。

在 Core Hub 里，这一层基本就是：

步骤 5：Core Hub 开始接管逻辑（Controller ↔︎ Core）

Matter Controller：

管理 Fabric / Node / Commissioning；
直接跟设备说 Matter 协议。

Core Hub（Golang）：

通过某种 RPC / WebSocket 接口与 Controller 通信；
只关心：

有哪些 Node、Endpoint、Cluster
它们的 Attribute 状态
能触发哪些 Command
订阅到哪些 Event / Data Report

于是整个链路变成这样：

关键词：

Controller：协议层执行者（配网、加密、发命令、收上报）

Core Hub Engine：逻辑/自动化/可视化层，围绕 Node/Endpoint/Cluster 来建模和运算

步骤 6：Multi-admin：这台灯同时归多个“家长”管

Multi-admin 的本质：

同一台物理设备，可以加入多个 Fabric；

每个 Fabric 里，这台设备有自己的 Node ID 和控制通道。

比如：

Fabric A：Apple Home（Apple Controller + 该灯 Node A）

Fabric B：我们的 Core Hub（Python Controller + Node B）

Fabric C：厂商云网关（Node C）

这几个“世界”互相隔离，但都控制的是同一个物理灯。

对我们的 Core 来说，这里的关键联系是：

Fabric：划分不同“控制世界”的边界；

Multi-admin：允许设备属于多个世界；

我们只能在“自己那一块 Fabric 世界”里操作该设备，不知道其他 Fabric 的具体细节；

但实际物理效果会互相影响（HomePod 关灯，我们这边也要看到灯已经关了），依靠 Data Report/Event 同步状态。

实践应用：Secondary Controller + Custom Cluster 方案

概念理清之后，顺便记一下项目里怎么用。参考：Matter Custom Cluster 问答、Matter Controller 问答。方案大概是下面这样。

一、一句话总结

在不自己做主 Controller、不马上走认证的前提下：

让 Google / Apple / Aqara 做 Primary Controller + Thread Border Router （主要控制）（边缘路由）

嵌入式 Hub 或 Android App 作为 Secondary Controller（次要控制）

利用 Multi‑Admin 直接和设备通信，同时支持 Custom Cluster，通过自定义的 YAML/JSON 物模型来解释和展示这些私有能力。

目标是：“寄生大厂 Matter 生态 + 保留自己的私有扩展能力 + 前期不做重资产认证”。

（下面主要是从两个问答里整理出的有效结论，这里记一下。）

二、终端设备端：Custom Cluster 方案

3.1 要实现的能力

让设备支持自定义功能（Custom Cluster）。

这些能力由客户用 YAML/JSON/XML 描述：

一份进设备固件（变成真正的 Matter Custom Cluster）。
一份存到平台（让 Secondary Controller 能读得懂）。

3.2 设备端的正确做法（必须走 codegen）

协议支持

Matter 1.x 全版本支持 Vendor/Manufacturer Specific Cluster。

自定义 Cluster 一般用厂商自己的 Cluster ID 段（测试可用 0xFFF1～0xFFF4，正式用自己 VID 范围）。

开发流程（这是“必须”的路径）

客户在平台上用 YAML/JSON 定义设备模型：

Cluster ID、Attribute ID、类型（int8/uint16/bool/string 等）、命令、事件。

工具链： YAML/JSON → Matter XML/.zap → ZAP/官方 codegen → C/C++ 代码 → 编译进固件

终端固件中的 Custom Cluster 就是按这个 XML 生成的代码在跑。

为什么不能“动态搞定”

对资源受限的 End Device，动态 Endpoint/Cluster 太复杂、占 RAM，官方也不推荐。

所以：设备端必须通过官方工具链（ZAP + XML）生成并编译代码，这是现在各家芯片的标准姿势。

三、控制器端（Hub / App）如何处理 Custom Cluster

3.3 协议层：什么 Controller 都能“盲操作”

Matter 的 Interaction Model + TLV 是自描述的：

Controller 不知道 0xFFF1/0x0005 是什么含义，也能读出“这是个 uint16，值是 50”。

这就是为什么调试工具能显示：

Unknown Cluster 0xFFF1 Attr 0x0005 = 50。

但：主流生态 App 会把这些未知东西在 UI 上直接忽略。

3.4 当前方案：元数据驱动解析 —— 完全成立

方案可以落成两条清晰路径：

路径 A：设备端（编译期）

客户的 YAML/JSON 设备定义：

被转换为 Matter 标准 XML/.zap；
ZAP 生成 C/C++，编译进设备固件；
设备对外暴露 Custom Cluster。

路径 B：Secondary Controller（运行期）

设备发现：

Hub/App 作为 Secondary Controller，通过 Multi‑Admin 加入设备 Fabric。

读取 Basic Information Cluster → 拿到 VendorID / ProductID / SoftwareVersion。

云端拉取 Schema：

用 (VID, PID, FirmwareVersion) 向云端请求对应的物模型（即 YAML/JSON 解析后的 schema）。

解析 TLV：

Controller 从设备读/订阅 Custom Cluster，拿到 TLV 原始值。

用刚才拉到的 Schema 做映射：

Cluster 0xFFF1 / Attr 0x0005 → “motor_speed” → 类型 uint16 → 50。

然后渲染成 UI、自动化条件等。

这条链路在协议和实现层面都是完全可行的。

四、Multi‑Admin 架构下：方案在 Google/Apple 上的可行性

3.5 通信路径 & 能否收 Custom Cluster

当用户把设备通过 Multi‑Admin 分享给我们：

设备上新建一个 Fabric（比如 Fabric Index 2）给我们；
Google/Apple 使用 Fabric 1，我们使用 Fabric 2。

我们与设备之间的流量直接走 IP（Wi‑Fi 或经由对方 Border Router 转到 Thread），不会经过 Google/Apple Hub。

Custom Cluster 数据完全可以在我们的 Fabric 上传输，Google 不会拦截，也不会知道具体内容。

只要设备 ACL 没有限制 Vendor（一般不会），Secondary Controller：

能读/写/订阅 Custom Cluster；

用云端 Schema 解释它们。

3.6 自动发现新设备：不会自动同步

当我们已经是 Secondary Controller 后：

用户在 Google Home 中新加了一个灯；
这个灯不会自动加入我们的 Fabric。

每个新设备都必须再执行一次“分享给我们”的流程：

Open Commissioning Window + Pairing Code + 我们这边再配一遍。

Android 端有时会在 Google 配网结束后弹个“顺便加到某某 App 吗”，那是 Google 的产品优化，不是协议自动同步。

五、整套方案的简版蓝图

3.7 设备端

客户定义 YAML/JSON 设备模型：

明确 Matter 类型：int8/uint16/float/string/enum/bitmap 等；
工具链：
YAML/JSON → Matter XML/.zap → ZAP codegen → C/C++ 固件 → Custom Cluster 生效。

3.8 平台端（云）

存储设备物模型元数据：

索引键必须是 VID + PID + FirmwareVersion 三元组；
支持版本演进（同一 VID/PID 不同固件版本结构可能不同）。

3.9 Secondary Controller（嵌入式 Hub / Android App，两种形态）

共性：

都是 Secondary Matter Controller，通过 Multi‑Admin 被加入设备 Fabric；

控制链路： Controller ↔︎ 设备（Custom + 标准 Cluster）， Thread 路由完全依赖 Google/Apple/Aqara 的 Border Router；

收到 Custom Cluster 数据后：

读取 Basic Info → 拿 VID/PID/FW；

向云端拉对应 Schema；

用 Schema 解析 TLV，按统一物模型展示并做自动化。

差异：

嵌入式 Hub：

推荐：Linux 盒子 + python-matter-server（或同类服务）作为协议引擎；
核心逻辑用 Go，和该服务通过 WebSocket/JSON‑RPC 通信。
定位：稳定自动化中枢。

Android App 两种用法并存：

作为 Secondary Controller：

集成 Matter Android SDK / Google Mobile SDK，自己有 Fabric；

通过 Multi‑Admin 控制同一批设备（Thread 通过 Nest/HomePod 路由）。

定位：强力遥控器。

作为 Companion：

不持有 Fabric，仅与嵌入式 Hub 通信，由 Hub 做 Controller；

App 只是 UI + 辅助配网。

当前方案的重点：不管是 Hub 还是 Android，只要是通过 Multi‑Admin 加入的 Controller，都可以完整收发 Custom Cluster 数据；通过云端元数据即可“看懂”并做 UI/自动化。

六、这套架构需要特别注意的三个技术点

类型映射严格化

在 YAML/JSON schema 中必须用 Matter 原生类型定义，而不是模糊的 number：

例如：uint8, int16, uint32, boolean, char_string, octet_string, enum8 等。

保证设备端 XML 和平台 Schema 严格一致。

版本治理

元数据索引必须至少：VID + PID + FirmwareVersion；

设备升级固件 → SoftwareVersion 变化 → Secondary Controller 需重新从云端拉取 schema。

ACL 与安全边界

设备固件中对 Custom Cluster 的访问，一般跟随默认 ACL：Admin Fabric 可完全访问；

我们作为 Secondary Controller 通常拥有 Admin 权限，这样自定义功能才能被访问；

依然必须遵守 Matter ACL 机制，不要走私有旁路。

附录：AI 工具使用参考

如果你主要做：

Google 文档、表格、邮件协作
图片/视频内容分析
理工科研究/作业 → Gemini 3 Pro 更自然。

如果你主要做：

合同、法规、政策、论文等长文本分析
需要极长上下文，一次性塞进整本书或大项目文档 → Claude Sonnet 4.5 很合适。

如果你想要：

一个通用“最强全能型助手”
同时写代码、写文案、搭建 Agent、连各种工具
做自己的 AI 产品或自动化流程 → GPT‑5 / GPT‑5.1 往往是最好的“默认首选”。