Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 一次换了枢纽“心脏”的更新
背景 — Matter 服务器到底在做什么
时间线 — 从捐赠到单向 GA
变好的地方 — 重启、OTA、入网安全
代价 — RAM 翻倍、单程票、年轻的代码库
规范的速度 — Matter 1.5.1、1.6，以及 4 周
什么时候不该急
结语
参考资料

引言 — 一次换了枢纽“心脏”的更新

对在家里跑 Home Assistant 的人来说，刚过去的 6 月 23 日是安静却重大的一天。伴随Open Home Foundation 的公告，Matter Server 应用(原为附加组件/add-on)升级到了 9.0 — 这不只是一个版本号，而是整个实现的替换。原本用 Python 写成、包装官方 C++ Matter SDK 的服务器，被替换成了用 TypeScript 从零重写的 matter.js 服务器。

这与每个人都有关系，原因在于规模。按公告引用的选择性统计(opt-in statistics)，Matter 集成运行在 38% 的 Home Assistant 实例上，在所有集成中使用率排第 12 位。也就是说，在这 38% 的家庭里，与 Matter 设备对话的整个流程被整体换成了另一套代码库。而且这次迁移是单向的 — 借用官方 FAQ 的原话，「能否回到旧服务器」这个问题的答案是「No」。

智能家居生态整体的版图，我已经在去年写的 Matter/Thread 深度解析里梳理过了，这篇只聚焦这一次转型：为什么要换、实际变好了什么、账单上写了什么。

背景 — Matter 服务器到底在做什么

Home Assistant 对 Matter 的支持并不在核心(core)里面。Matter 集成(核心部分)通过 WebSocket 连接到一个独立进程 — Matter 服务器，实际的 Matter 控制器角色 — 入网(commissioning)、会话加密、订阅、OTA — 全部由这个服务器完成。由于每月的核心发布和服务器发布是解耦的，这次替换也和 2026.7 核心版本(7 月 1 日)分开，只靠一次应用更新就完成了部署。顺带一提，2026.7 发布说明里与 Matter 相关的条目只有新增土壤湿度传感器支持这一项 — 真正的大变化发生在核心之外。

把结构画成图是这样的。

[之前]  Home Assistant (Matter 集成)
          │  WebSocket
          ▼
        python-matter-server  ── Python 封装层
          │
          ▼
        官方 Matter SDK (C++ · project-chip/connectedhomeip)

[之后]  Home Assistant (Matter 集成)   ← 代码无需变更
          │  WebSocket (相同 API)
          ▼
        matterjs-server + matter.js (TypeScript 单一技术栈 · Node.js 运行时)

此前的服务器 python-matter-server 是在官方 C++ SDK 之上套了一层 Python，2025 年 3 月还和 Home Assistant 一起拿到了 CSA 认证 — 这是开源项目中的第一次。然而公告对这套结构的评价是「一个坚实的起点，但跟不上我们开源雄心的速度」。这句话里，就藏着为什么一套已经拿到认证的技术栈会在 15 个月后被放弃的原因。

matter.js 是一个用 TypeScript 完整重新实现 Matter 标准的项目。它的仓库自 Matter 正式发布后不久的 2022 年 11 月就存在了，据公告所说，Homebridge 和 openHAB 对 Matter 的支持也都跑在这个库之上。它的作者 Ingo Fischer 在 2025 年下半年全职加入 Open Home Foundation 的同时，把 matter.js 捐赠给了基金会，基金会随后在 2025 年 11 月 26 日的通讯中正式宣布了在 matter.js 之上重建 Matter 服务器的计划。

时间线 — 从捐赠到单向 GA

这次转型不是突袭，而是长达半年的公开迁移过程。以下日期全部来自 GitHub 的提交/发布记录。

日期	事件
2025-11-26	OHF 宣布接受 matter.js 捐赠及重建服务器的计划
2026-01-22	附加组件 8.2.0 — 打开 beta 开关即可切换到 matter.js 服务器(可双向切换)
2026-06-09	matterjs-server 1.0.0
2026-06-17	CSA 发布 Matter 1.6 规范
2026-06-23	应用 9.0.0 GA — matter.js 服务器成为默认项，迁移不可逆。同日 python-matter-server 仓库被归档(archive)
2026-07-01	HA 核心 2026.7 发布。matter.js 合并 Matter 1.6.0 支持的 PR
2026-07-15	应用 9.1.0 — 搭载 Matter 1.6.0 支持

在 beta 阶段，数据会自动迁移，同时仍可以切回 Python 服务器，但从 9.0.0 GA 开始就不再支持了。因此公告和 FAQ 反复建议在更新前先做备份 — 因为备份是唯一的回滚手段。如果节点数量多，首次启动(存储迁移 + 全量询问)会耗时不短，迁移 FAQ 也明确建议暂时关闭会在中途强制重启的 HA watchdog。

变好的地方 — 重启、OTA、入网安全

剥掉营销措辞，只留下 FAQ 和更新日志里写明的具体变化，是这样的。

重启与重连。 旧服务器每次启动都要从零重新发现设备、跑一次全量询问(full interview)。新服务器会记住设备的最后地址、直接连接，重连时只用局部询问(partial interview)拉取变化的数据。在 Thread 设备较多的环境里，FAQ 还单独写明连接会顾及 Thread 网络的带宽限制 — 意思是不会把一场重启风暴倾泻到低功耗的 mesh 网络上。

OTA 更新。 旧服务器为了给设备固件做 OTA，会在 Matter 网络上额外起一个临时节点，FAQ 自己也承认这「经常引发问题」。新服务器把 OTA 逻辑整合进了控制器内部。

入网安全默认值。 旧服务器默认情况下，连只持有开发/测试证书的未认证设备也会予以入网(commissioning)。这对接入 DIY 设备很方便，但也是恶意设备悄悄混入 fabric 的一条通道。新服务器把这个默认值反过来了 — 要接入测试证书设备，现在必须显式打开 Test-Net DCL 选项。入网时新增了证书吊销(revocation)列表检查。

离线入网。 服务器现在会内置一份发布时刻的 DCL 数据快照，用于证书校验，这样即使没有网络，也能为截至该时间点已注册的设备完成入网。一旦联网，会在后台更新这份数据。不过正如 README 所说，内置数据可能会过时，在此期间发布的新设备可能在离线状态下入网失败 — 这提醒我们，从 local-first 的角度看，控制可以是本地的，但入网时刻的信任验证依然想要联网。

网络可视化。 服务器的 Web UI 新增了 Thread/Wi-Fi 拓扑视图。每个节点都会显示其角色(leader、router、sleepy end device)，连接质量用连线颜色表示 — 在设备与边界路由器之间要经过多跳的 Thread mesh 里尤其有用。旁边还附了一条诚实的注脚 — 处于休眠状态的电池供电设备不会频繁刷新网络信息，所以可视化里出现的「Unknown devices」或「External routers」有可能是过期数据，FAQ 提前打了这个预防针。

此外，更新日志里还在不断累积一些条目，比如让入网走 Home Assistant 蓝牙栈(包括 ESPHome BLE 代理)的实验特性 ble_proxy，以及 9.1.0 中新增的设备时间同步(time_sync)和 ICD(间歇连接设备)管理的实验性支持。

代价 — RAM 翻倍、单程票、年轻的代码库

接下来轮到账单了。

内存。 这是官方数字：新服务器的 RAM 用量约为旧服务器的 2 倍，CPU 用量也略高一些(依据迁移 FAQ，属于厂商自述，测量条件未公开)。附加组件容器里整套塞进了 Node.js 运行时，这不算意外。发布说明也提醒在更新前先确认主机是否还有余量 — 尤其是在 Raspberry Pi 级别的板子上塞了好几个附加组件这种常见配置下。

单向迁移。 再强调一次，GA 之后没有官方途径回到 Python 服务器。备份是唯一的退路。

刚出生的代码库。 GA 也并非一帆风顺。9.0.0 发布后十天之内，附加组件连出了四个补丁(9.0.1 至 9.0.4)，9.0.4 的更新日志把服务器从 1.1.2 升到 1.1.7，给出的理由是「解决已报告的问题，并大幅优化 RAM/CPU 用量」。数一数 matterjs-server 的更新日志，从 GA 到 7 月 16 日这三周多一点的时间里，服务器发布了 14 次。这个数字既可以读作响应迅速，也可以读作还在震荡当中 — 大概两者都是事实。FAQ 的故障排查部分已经写上了迁移失败导致存储损坏时手动清空数据目录的步骤，以及首次启动后设备一直显示离线(mDNS 广播缺失)时把设备断电重启的建议。

重新认证还没到。 2025 年拿到的 CSA 认证属于那套 Python 服务器。matterjs-server 的 README 明确写着，当前实现「尚未通过 CSA 重新认证，计划在未来完成」。如果认证状态对你所在的环境很重要，那么现在的服务器就处在这段空档期里。

规范的速度 — Matter 1.5.1、1.6，以及 4 周

这次转型真正的意义，要把它叠在今年 CSA 的发布日历上才看得出来。

3 月 31 日，CSA 发布了 Matter 1.5.1 — 这是在 1.5 引入的摄像头/门铃支持之上的一次增量发布，加入了多流传输(录制用的高清流 + 移动端用的低清流 + 分析用的流，全部放在一个会话里)、HEIC 快照、基于 CMAF 的 HLS/DASH 上传，以及 PTZ 动作的改进。6 月 17 日，Matter 1.6 发布。这次没有新的设备类别，核心内容是仅靠 NFC 即可完成整个入网流程的 NFC 入网(1.4.1 里的 NFC 标签只承载安装信息、仍需要 BLE — 在装好吸顶灯之前先拿手机碰一下完成注册的场景，如今已经写进了规范)、让多个生态系统共同管理同一个 fabric 的 Joint Fabric，以及给恒温器发送限时建议、而非直接指令的 Thermostat Suggestions。

这里就能看出新技术栈的速度。规范公开是 6 月 17 日，matter.js 的 Matter 1.6.0 支持 PR 合并是 7 月 1 日，搭载它的服务器 1.2.0 是 7 月 9 日，推送给 Home Assistant 用户的应用 9.1.0 是 7 月 15 日 — 从规范到稳定通道，正好 4 周。公告在 6 月说「1.6 快了」的时候，那个「快了」其实是 3 周。在被官方 C++ SDK 的发布周期束缚的年代，这样的速度在结构上很难做到，也正是「官方 SDK 跟不上我们的速度」这句话的一次实证。

从标准生态的角度看，这也有意义。当一份规范事实上只依赖单一实现时，那个实现的 bug 就会变成标准的实际行为。就像 TLS 或 HTTP 那样，多一个大规模运行的独立实现，对标准的健康是件好事 — 如今 Matter 并存着商用生态整体所用的 C++ 实现，以及在最大开源家庭平台上真正部署的 TypeScript 实现。

什么时候不该急

归纳一下，出现以下情况时，先别急着点更新按钮比较合理。

主机内存紧张时。 RAM 约翻倍是官方数字。如果已经在 2GB 级别的板子上塞满了好几个附加组件，先算算账。
Matter 节点多、中断代价高时。 首次启动要跑迁移 + 全量询问，耗时不短，回滚只能靠恢复备份。这不是工作日晚上可以随手做的事。
使用开发/测试证书的 DIY 设备时。 如果一直在接入自己编译的 Matter 固件(比如 ESP32)，现在必须打开 Test-Net DCL 选项才能完成入网。不知道这一点的话，问题会看起来像是设备坏了。
认证状态是硬性要求时。 如果「尚未通过 CSA 重新认证」这件事在你的环境里是个问题，这就是等一等的理由。
想再观察几周时。 三周内发布 14 次的补丁速度，既是活跃度的证明，也是一个信号 — 你的具体配置里可能还埋着尚未踩到的坑。先把 issue tracker 翻一遍再决定也不迟。

反过来说，如果你家里接了几十个 Thread 设备，服务器每次重启都要死上好几分钟一直是老毛病 — 光是局部询问和地址缓存这两点，这次升级就已经值回票价。

结语

全球最大的开源智能家居平台，把一套已经拿到认证的官方 SDK 技术栈，在 15 个月后放弃，换成了 TypeScript 重写版。理由不是抽象的性能，而是速度的主导权 — 它在 GA 之后仅 4 周就把最新规范(1.6)送上稳定通道，用行动证明了这个理由。代价也是明确的 — RAM 翻倍、单向迁移、重新认证的空档期，以及年轻代码库都会经历的早期补丁潮。

如果你的 Home Assistant 只是安静地跑着几个 Matter 设备，这次转型你大概率不会察觉 — 因为目标就是无缝兼容，而且大体上做到了。但更新前请务必先做一次备份。这张票，是单程的。