目標與使用者
- 要解決跨生態控制、語音入口，還是集中裝置？
- 誰負責 Home Assistant、Matter Hub 與 Controller 的日常維運？
- 哪些裝置涉及門鎖、警報、攝影機或高功率負載？
- 可接受的停機窗口、回復時間與變更審核方式是什麼？
Matter Hub 導入手冊 · Stable 2.0.55
先確認網路、規模與 Controller，再談相容
這份手冊協助你做探索會議、適用性判斷、分階段部署與驗收。Matter Hub 是把 Home Assistant 實體橋接給外部 Controller 的工具，不替代 Controller，也不保證每種裝置在每個生態系都呈現相同能力。
探索會議先問什麼
現況盤點
- Home Assistant 版本、實體總數、domain 與區域分布。
- 預計建立幾座 Bridge、每座暴露多少 endpoint。
- Apple、Google、Alexa、Aqara、SmartThings 的 hub／app／帳號狀態。
- 路由器、VLAN、IPv6、mDNS、Wi-Fi／Thread 邊界路由器現況。
適用性判斷
| 情境 | 判斷 | 原因與下一步 |
|---|---|---|
| HA 已有穩定實體，想讓外部 Matter Controller 使用 | 適合試點 | 先用低風險燈具／感測器做小 Bridge，驗證名稱、控制與同步。 |
| 期待 Matter Hub 直接配對實體 Matter 裝置 | 角色不符 | 這是 Matter Controller 的工作；先釐清 HA Matter 整合與 Matter Hub 的分工。 |
| 跨 VLAN 且 IPv6 或 mDNS 不可用 | 先改善網路 | 配對與發現可能失敗；先完成 multicast、路由與防火牆測試。 |
| 要求所有 Controller 功能完全一致 | 需重設期待 | Controller 對 device type、cluster 與 UI 的支援不同，應逐類驗收。 |
| 大量安全關鍵裝置要一次切換 | 不建議直接上線 | 先分批試點、備份、建立回復方案與人工替代流程。 |
Controller 評估矩陣
| Controller | 試點重點 | 不可預設 |
|---|---|---|
| Apple Home | 家庭中樞、房間整理、No Response、裝置類型顯示 | 不可因能配對就推論全部 cluster 與進階能力都可用。 |
| Google Home | Google Home App、裝置同步、房間、語音與 optimized template | 不可預設 HA 名稱、類型與控制項會原樣呈現。 |
| Amazon Alexa | 首次配對埠、裝置規模、語音名稱、特定 feature flags | 不可把觀察到的規模經驗寫成硬上限或保證值。 |
| Aqara | Hub 韌體、支援 device type、地區與 app 顯示 | 不可從其他 Controller 的結果推論 Aqara 一定相同。 |
| SmartThings | Hub 狀態、driver／device type 呈現、多 Fabric 行為 | 不可承諾所有映射與第三方功能都完整暴露。 |
銷售用語：說「可依 v2.0.55 與指定 Controller 做可驗收試點」，不要說「全相容」「一定可用」或「所有裝置都支援」。
網路、IPv6 與 mDNS
上線前條件
- Matter Hub 主機與 Controller 之間有可用 IPv6 路徑。
- mDNS 可在所需網段發現；跨 VLAN 反射器已測試，不只「已開啟」。
- 防火牆規則依實際連線流量最小化放行。
- 主機時間、DNS、網卡與固定租約穩定。
- Wi-Fi 與 Thread 基礎建設由各 Controller 需求另行確認。
診斷證據
- 記錄來源／目的網段、測試時間與失敗階段。
- 保留去識別化的 mDNS test、Health、Network Map 與系統紀錄。
- 不要在交付文件放私有 IP、hostname、token、QR payload 或配對碼。
- 若跨網段不穩，先回到同網段建立基準，再逐項加入網路限制。
裝置、Controller 與 Bridge 規模
規模不是只看 Home Assistant 實體總數。請同時記錄 Bridge 數、每座 endpoint、裝置類型組合、每個 Controller 的 Fabric、事件頻率、主機資源與同步時間。Controller 的可用規模可能受韌體與帳號環境影響，因此先用代表性資料集壓測，不把單次成功外推成保證。
| 分拆依據 | 建議 |
|---|---|
| 家庭／樓層／租戶 | 用獨立 Bridge 降低變更與故障影響範圍。 |
| 安全關鍵與一般裝置 | 門鎖、警報等先排除或獨立驗證，不與大量一般端點混批。 |
| Controller 差異 | 必要時使用不同 filter／feature flags，並各自留驗收紀錄。 |
| 同步與資源壓力 | 逐批增加 endpoint；觀察啟動、同步、記憶體與回應時間。 |
建議部署階段
- 發現與基線：鎖定 v2.0.55、建立功能清單、網路圖與 Controller 清單，只讀蒐證。
- 實驗室試點：以少量燈、開關、感測器測 Bridge、filter、名稱與 Controller 呈現。
- 代表性試點：加入 cover、climate、lock 等不同類型；逐個 Controller 驗收。
- 分批上線：依區域或風險批次擴大，每批保留回復點與變更紀錄。
- 營運移交：交付備份、診斷、升級、憑證保管、責任分工與定期複驗流程。
主要風險與控制
| 風險 | 影響 | 控制方式 |
|---|---|---|
| Controller 支援差異 | 配對成功但功能或 UI 不完整 | 按裝置類型與 Controller 分開驗收。 |
| IPv6／mDNS 不穩 | 找不到、配對失敗、No Response | 先做同網段基準，再驗證 VLAN 與防火牆。 |
| filter 過寬 | 暴露不必要或敏感實體 | 預設最小 include，使用預覽與同儕審查。 |
| 身份或 Fabric 變更 | 重配對、重複裝置、服務中斷 | 持久化資料、備份、變更窗口與回復演練。 |
| 實驗性功能 | 行為變動或支援有限 | 明確標示成熟度，與正式 Bridge 分離。 |
安全與資料界線
- 管理介面不直接暴露到公網；反向代理、Ingress、Basic Auth 與 IP allowlist 依環境最小化設定。
- Basic Auth 只視為單層驗證，不描述成多帳號、RBAC 或 SSO。
- QR payload、manual pairing code、setup PIN、discriminator、Fabric／Node ID、token、cookie、憑證不得進文件或截圖。
- Plugin 安裝、reset、restore、Fabric 移除前，先說明備份、影響、停機與回復路徑。
- 建立最小暴露原則；安全關鍵實體需要額外業務批准與人工替代流程。
驗收清單
功能驗收
- 版本顯示為 Stable 2.0.55，來源 commit 已記錄。
- Bridge 重啟後身份、名稱、endpoint 與 filter 結果穩定。
- 每個指定 Controller 均完成配對、基本控制、狀態回報與重新連線測試。
- 逐類驗證燈、開關、感測器、cover、climate 等實際採用類型。
- 多 Fabric 只在批准範圍測試，移除與 orphan cleanup 有紀錄。
營運驗收
- Health、mDNS、system log 與資源基線已留存。
- 備份已驗證可讀，復原步驟與責任人明確。
- 防火牆、代理、帳密與秘密管理通過安全審查。
- No Response、配對失敗、同步失敗有可執行 runbook。
- 實驗性功能、Controller 限制與未驗收項目已列為例外。