手上一堆蓝牙设备，怎么接进 Apple Home 和 Matter？
自家的蓝牙开关和灯想进 Apple Home，不必给每个设备换芯片，加一台 Matter 网关做桥接就行。这篇记录我们的整体架构、关键选择，以及接下来要解决的问题。
最近在做一个项目：把一批蓝牙设备接进 Apple Home。
设备不复杂，1～4 路的墙壁开关、调光灯、调色灯，再加一种贴在墙上的无线开关。它们用蓝牙 Mesh 组网，原本靠自家 App 控制，用起来没什么问题。
问题出在客户那边。被问得最多的一句话是：「能不能用 Apple Home 控制？」 接着还会问 Google Home、Home Assistant 能不能接。
苹果、Google、亚马逊这几年都在推 Matter。用户已经习惯在一个 App 里管全家的设备，不支持 Matter 的产品，往后只会越来越难卖。
这篇是整个项目的总纲：为什么这么做，整体架构长什么样，以及现在做到了哪一步。后面会按芯片、主控、协议栈、认证这些主题，一篇一篇拆开写。
两条路：给设备换芯片，还是加一台网关
让蓝牙设备进 Matter，大体有两种做法。
第一种，改设备本身。 把每个设备的芯片换成支持 Matter 的 Thread 或 Wi-Fi 方案，固件重写，然后每个型号分别去做 Matter 认证。
第二种，设备不动，加一台网关。 网关一边用蓝牙连着这些设备，一边以 Matter 的身份接入家庭网络。Apple Home 看到的是一台 Matter 网关，下面挂着一串开关和灯。Matter 规范里管这种设备叫 Bridge（桥接器）。
| 对比项 | 改设备 | 加网关 |
|---|---|---|
| 设备成本 | 每台都要换更贵的芯片 | 不变 |
| 固件工作量 | 每个型号都要重写 | 设备端改动小，主要工作在网关 |
| Matter 认证 | 每个型号单独认证 | 网关认证一次 |
| 已经卖出去的设备 | 用不上 | 刷新固件后可以接进来 |
| 用户需要多买的东西 | 无 | 一台网关 |
我们的设备型号多、单价低，还有不少已经在用户家里装着。逐个改芯片不现实，所以选了网关这条路。
代价也很清楚：用户得多买一台网关；网关断电、掉线，整个蓝牙网络都会受影响。这两点后面在设计时都要正面处理。
整体架构
整套系统从上到下分四层：
Apple Home / Google Home / Home Assistant
│ Matter（Wi-Fi 或网线）
▼
【Linux 网关】
├─ Matter Bridge：每个开关、每盏灯都是一个设备
├─ 设备表：有哪些设备、几路、是否在线
├─ 映射层：Matter 命令 ↔ 蓝牙 Mesh 消息
└─ Mesh 适配层：通过串口指挥蓝牙模组
│ 串口
▼
【蓝牙模组】组网、配网、收发 Mesh 消息
│ 蓝牙 SIG Mesh
▼
开关 / 调光灯 / 调色灯 / 无线开关- 最上面是各家的智能家居平台。它们只认 Matter，不知道下面是蓝牙。
- 网关主板跑 Linux，上面只跑一个程序。它对外是一台 Matter 网关，对内管理所有蓝牙设备。
- 蓝牙模组单独放一颗芯片。蓝牙 Mesh 协议栈跑在模组里，Linux 主机通过串口给它发指令。
- 最下面是设备，用的是蓝牙技术联盟的标准 Mesh 协议，也就是 SIG Mesh。
这样分层，最直接的好处是蓝牙部分和 Matter 部分可以分开调试、分开替换。以后想换主控芯片，蓝牙模组和设备固件都不用动；想换蓝牙模组厂商，也只改适配层。
网关里最关键的一层：翻译
网关真正干活的地方是映射层。它要把 Matter 的设备类型和命令，翻译成蓝牙 Mesh 能听懂的消息。
| 我们的设备 | 在 Apple Home 里显示为 | 需要换算的地方 |
|---|---|---|
| 1～4 路开关 | 每一路是一个开关（On/Off Light） | 无 |
| 调光灯 | 可调亮度的灯（Dimmable Light） | Matter 亮度 1～254，Mesh 亮度 0～65535 |
| 色温灯 | 可调色温的灯（Color Temperature Light） | Matter 用 mireds，等于 1,000,000 除以开尔文色温 |
| 彩色灯 | 彩色灯（Extended Color Light） | 色相、饱和度的数值范围不同 |
| 无线开关 | 按键开关（Generic Switch） | 短按、长按、双击要转成 Matter 的按键事件 |
一个四路开关，在 Apple Home 里会变成四个独立的开关，可以分别放进不同房间、加进不同的场景。这是 Bridge 的标准做法，用户也最容易理解。
翻译本身不难，难的是两个容易被忽略的细节。
一是物理按键。 用户在墙上按了开关，Apple Home 里的状态也得跟着变。所以每个设备状态一变，都要主动把新状态发给网关，网关再同步到 Matter。只做「App 控制设备」这一半是不够的，「设备告诉 App」这一半同样重要。
二是掉线。 灯被墙上的总闸断了电，Apple Home 里应该显示「无响应」，而不是一直挂着最后一次的状态。我们让每个设备定时向网关发心跳，连续几次收不到，就把它标成离线。
还有一个和用户体验有关的设计：无线开关直接控制灯，不经过网关。 开关把命令发到房间的组地址，灯直接响应，网关只是旁听、同步状态。这样即使网关断网甚至坏了，墙上的开关照样能开灯。网关是锦上添花，不能变成单点故障。
几个关键选择
方案里有几处是反复比较过才定下来的。这里先说结论，理由后面单独写。
- 设备和网关之间用 SIG Mesh，不用私有协议。 标准协议有标准的开关、灯模型，网关和设备可以用不同厂商的芯片，只要都按标准来就能互通。
- 网关的蓝牙用芯科（Silicon Labs）模组，设备端用泰凌（Telink）。 网关这边看重文档和工具：芯科的模组可以当协处理器用，串口协议有正式文档。设备这边看重成本和国内供应链，泰凌更合适。
- 主控按需求分档。 只做桥接，用瑞芯微 RK3506 这样的入门芯片就够；想留余量做本地自动化、Web 管理，选 RK3562；要带屏幕做中控，再往上选 RK3576。
- Matter 协议栈用 Rust 写的 rs-matter。 它编出来是一个独立的程序，占用小，也支持运行时动态增删设备，正好适合 Bridge。
现在做到哪一步
目前完成的是软件原型：
- 用一台 Windows 电脑模拟网关，在 Apple Home 里扫码添加成功；
- 用手机模拟蓝牙设备，网关能发现它，并在 Apple Home 里显示成可控制的设备；
- 在 Apple Home 里开关，模拟设备能收到命令；设备增删后，Apple Home 里会跟着出现或消失。
也就是说，「Matter ↔ 网关 ↔ 蓝牙设备」这条链路已经在软件上走通，Apple Home 能识别并控制桥接出来的设备。
还没做的是真实硬件：芯科模组和泰凌设备的联调，以及在 Linux 网关板上跑起来。开发板正在采购，接下来几周的重点就是这部分。
接下来要解决的问题
这几个问题决定了方案能不能量产，后面每个都会单独写：
- 两家芯片能不能互通。 芯科的网关配泰凌的设备，理论上靠标准协议能通，实际要上板验证。
- 一台网关能带多少设备。 一个家庭几十个设备不成问题，商业场景动辄上百个，要压测。
- 网关坏了怎么办。 断电重启、换蓝牙模组之后，已经配好的设备要能自动回来，不能让用户重新配一遍。
- 认证。 Matter 认证、HomeKit 相关的要求、无线电认证，各要多少钱、先做哪个。
最后
把蓝牙设备接进 Matter，技术上没有想象中那么玄。真正花时间的，是芯片怎么选、设备怎么同步、网关坏了怎么兜底，还有认证这些量产前绕不开的事。
我会把这个项目从原型到量产的过程，按主题陆续写出来，包括走过的弯路。
如果你手上也有一批蓝牙设备想接入 Matter，或者正在做类似的网关，欢迎来聊。方案思路、芯片选型和踩过的坑，都可以交流：linktr.ee/weiyii