第 17 章

Aqara、SmartThings 與控制器相容性

用可稽核的 yes/partial/no/unknown 矩陣規劃 Apple、Google、Alexa、Aqara 與 SmartThings;把協定可映射、產品成熟度及 Controller 呈現分開,避免承諾未被證實的完整支援。

「支援 Matter」不是一個布林值

Matter Hub 可以把 Home Assistant domain 映射成 Matter device type,但 Controller 是否接受 Bridge、是否顯示 Endpoint、是否提供命令、是否訂閱狀態,以及是否支援新 Matter 版本,是五個不同問題。Apple Home、Google Home、Alexa、Aqara Home 與 SmartThings 即使都使用 Matter,也不會有相同 UI 或 cluster 覆蓋。

本章矩陣是規劃起點,不是認證表。它綜合 v2.0.55 可達映射、feature manifest 與各 Controller 官方公開類型;「yes」只表示官方證據足以支持該類型的基本路徑,仍需在你的 Controller 版本實測;「partial」表示類型或基本能力可達,但進階功能、Bridge 呈現或版本有已知邊界;「unknown」表示沒有足夠固定證據,不能推測。

特別界線:本指南不承諾 Aqara 或 SmartThings 對 Matter Hub 的完整支援。兩者有 Matter 生態系統能力,不等於已逐型別驗證這個第三方 Bridge。

yes、partial、no、unknown 的證據規則

標記意義你仍要做的事
yesController 官方公開資料包含該 Matter 類型或基本能力,且 Matter Hub 有相應映射路徑。實測發現、基本命令、狀態回報與重啟;不是完整 cluster 保證。
partial只有部分子類型/命令/UI,需較新平台版本、workaround,或 Bridge-specific 證據不足。記錄缺少的功能,必要時分拆 Controller 專用 Bridge。
no固定來源明確排除,或專用 flag manifest 明確標該 Controller no。不要靠 reset 或重配嘗試把 no 變成 yes。
unknown官方資料未足以確認此 Bridge/類型組合,且沒有受控實測證據。小規模測試並保守揭露;不要寫成支援或不支援。

矩陣以「基本 device type 層級」呈現,不把每個 cluster 混在同一格。例如燈的 on/off 可能 yes,色彩或 transition 仍 partial;吸塵器出現可能 partial,房間清掃與進度仍 unknown。遇到這種情況以較保守狀態標示。

先套用三層邊界再看 Controller

層級本指南基準對矩陣的影響
Release channelHome Assistant Matter Hub Stable v2.0.55 exact commit;Add-on 固定 mirror commit。不把 Alpha、Testing 或後續功能列入。
產品成熟度一般 Bridge 與多數既有映射為 Stable;Server Mode 多實體、Camera/Security Plugins、部分 Matter 1.4 類型是 Stable 內實驗性。即使 Controller 支援類型,實驗性產品路徑仍不能標成穩定承諾。
Controller 支援依各官方 supported devices/Matter 說明;上游 manifest 多數 Controller 格為 unknown。沒有逐型別證據就保留 unknown;不以品牌宣傳頁補成 yes。

Matrix 的 yes 不會覆蓋成熟度。例如 Apple 新版家庭 App 可能支援某個較新 Matter 類型,但 Matter Hub 對該型別若仍是 Stable channel 中的實驗性映射,整體建議仍是小量試驗。反過來,Matter Hub 穩定映射也不會讓 Controller 自動新增 UI。

52 種 Matter override 的 Controller 相容性矩陣

Matter override identifierApple HomeGoogle HomeAlexaAqara HomeSmartThings
air_purifiernoyesyesyesunknown
air_quality_sensornoyesyesyesunknown
dishwashernonounknownunknownyes
basic_video_playernononoyesunknown
battery_storagenononoyesunknown
carbon_monoxide_sensorpartialnopartialyesunknown
color_temperature_lightyesyesyesyesyes
contact_sensoryesyesyesyesyes
dimmable_lightyesyesyesyesyes
dimmable_plugin_unityesnoyesyesyes
door_lockyespartialyesyesyes
doorbellnonononoyes
electrical_meternoyesnounknownyes
electrical_sensornonounknownunknownyes
electrical_utility_meternononounknownyes
evsenononoyesunknown
extended_color_lightyesyesyesyesyes
fannoyesyesyespartial
flow_sensornoyesnounknownunknown
formaldehyde_sensornonopartialyesunknown
generic_switchpartialnoyesunknownunknown
humidifier_dehumidifierunknownnoyesunknownunknown
humidity_sensoryesyesyesyesyes
light_sensoryesyesyesunknownyes
mode_selectnononounknownunknown
motion_sensoryesyesyesyesunknown
nitrogen_dioxide_sensornonopartialyesunknown
occupancy_sensorpartialyesyesyesyes
on_off_lightyesyesyesyesyes
on_off_plugin_unityesyesyesyesyes
on_off_switchyesyesyesyesyes
mounted_on_off_controlnononoyesyes
ozone_sensornonopartialyesunknown
pm1_sensornonopartialyesunknown
pressure_sensornoyesnoyesyes
pumpnoyesnoyesunknown
rain_sensornononoyesunknown
radon_sensornonopartialyesunknown
robot_vacuum_cleaneryesyesyesyesunknown
robotic_lawn_moweryesunknownyesunknownunknown
smoke_co_alarmyesnoyesyesyes
solar_powernonounknownunknownyes
speakernoyesnoyesunknown
temperature_sensoryesyesyesyesyes
thermostatyesyesyesyesyes
tvoc_sensornonopartialyesunknown
water_heaternonounknownyesunknown
water_heater_managementnonounknownunknownunknown
water_freeze_detectornononoyesunknown
water_leak_detectoryesnoyesyesunknown
water_valvenononoyesunknown
window_coveringyesyesyesyesyes
名稱陷阱:on_off_switch 的 yes 代表它以 Matter On/Off Light 呈現,不是原生 switch tile;真正牆面控制類型是實驗性的 mounted_on_off_control。表格的「可呈現」不等於 UI 名稱符合 identifier。

此表逐列對應 v2.0.55 的 52 個 MatterDeviceType identifier;Apple/Google/Alexa/Aqara 以固定 picker snapshot 為準,SmartThings 依同版 compatibility 文件,沒有逐型別證據就保留 unknown。此表的 no 只在 v2.0.55 固定相容矩陣或 Controller 官方類型清單有排除證據時使用;unknown 不會因一次配對失敗改成 no。另有 Controller-specific flag:alexaPreserveBrightnessOnTurnOn 對 Alexa 是 yes、對 Apple 與 Google 是 no;那是 flag 支援,不是整個 light 類型的 no。

五個生態系統的合理期待

  • Apple Home:家庭 App 與家庭中樞提供 Matter Controller;基本類型可先建基線。對感測器卡片、事件、吸塵器與較新類型要依 Apple 平台版本驗證,「無回應」先查 IPv6、mDNS、session 與 subscription。
  • Google Home:依 Google 官方 supported device types 與相容 Hub;optimized template 是 Matter Hub 起始設定,不是 Google 認證。room/name 不等同 HA Area/name。
  • Alexa:第一座 commissioning Bridge 優先使用 5540;規模約 80–100 只作上游實務規劃。Cover-as-light、亮度保留、vacuum flags 是 workaround,宜放 Alexa 專用 Bridge。
  • Aqara Home:Aqara 官方公開清單涵蓋許多類型,v2.0.55 也包含 Aqara quirks;矩陣可對有來源的基本類型標 yes,但未列出的類型保持 unknown,且不因此承諾 Matter Hub 全型別完整支援。
  • SmartThings:官方列出 Matter 支援與相容 Hub,但第三方 bridge 的 device type/cluster 呈現仍依平台與 driver。先小量驗證,不把 SmartThings 支援 Matter 寫成 Matter Hub 全支援。

Controller 的帳號、房間、名稱、自動化與分享權限彼此獨立。Multi-Fabric 讓同一 Bridge 受多個 Fabric 管理,不是讓五個生態系統的管理資料互相同步。

用小量測試建立你的相容證據

  1. 列出需求而非全部 HA 實體

    按房間與 device type 列出真正要從各 Controller 操作的裝置,標示安全敏感、狀態唯讀與進階功能。紀錄中不包含任何內部識別資料。

  2. 套用官方上限

    逐一查看 Apple、Google、Amazon、Aqara、SmartThings 官方 Matter 文件。未列或描述含糊的項目先標 unknown,不從其他品牌經驗類推。

  3. 建立最小核心 Bridge

    只加入各目標 Controller 都有基本證據的燈、開關等低風險型別,備份後納管第一個 Fabric。

  4. 逐一新增 Fabric

    每次重新開啟 commissioning window,只加一個 Controller;完成後驗證顯示、命令、狀態與重啟,不分享或保存配對資料。

  5. 一次測一種特殊類型

    新增一個窗簾、風扇、感測器或吸塵器代表,將每項功能記為 yes/partial/no/unknown。不要只記「配對成功」。

  6. 按證據分拆 Bridge

    若某 Controller 需要不同 device type 或 flag,建立專用 Bridge;例如 Alexa cover-as-light 不要污染 Apple/Google 的窗簾語意。

  7. 版本升級後重測

    Controller firmware、App 或 Matter Hub 更新都可能改變矩陣。保留版本與日期,但不記任何 Fabric/Node 內部值或 live 網路資料。

共享核心或 Controller 專用 Bridge

策略適合情境優點風險
一座共享核心 Bridge少量基本燈、開關,各 Controller 的基本類型已驗證。Endpoint 單一、HA 篩選簡單、多 Fabric 看同一狀態。一個 Controller 的 workaround 可能影響全部;故障範圍較大。
按 Controller 分拆Alexa 需要 cover-as-light,或 Aqara/SmartThings 只接受較小子集。可獨立選型別、flags、規模與維護窗。可能重複暴露同一 HA 實體,造成使用者混淆與自動化競態。
按類型分拆吸塵器、窗簾、鎖、感測與新 Matter 類型需要隔離。特殊類型失敗不拖累基本照明,測試證據清楚。Bridge 數量、埠與 commissioning 管理增加。
按區域分拆大型住宅或小型辦公室需限制故障及 Controller 規模。命名與責任範圍清楚,單座 Endpoint 較少。跨區裝置與房間命名需一致規則。

不要把同一實體同時放進共享 Bridge 與 Controller 專用 Bridge,除非你刻意測試且能承受重複卡片與競態。若必須重複,先用一個非安全關鍵裝置驗證,並清楚命名來源。

四個可執行的分拆觸發條件

  1. 型別觸發:同一 Matter device type 在某 Controller 是 partial/unknown,且會拖慢或阻止整座 Bridge 探索。
  2. 語意觸發:需要 cover-as-light、簡化 vacuum on/off 等會改變其他 Controller UI 的 workaround。
  3. 規模觸發:接近 Controller 實務容量或納管、重啟、訂閱延遲明顯增加;Alexa 的約 80–100 只作規劃訊號,不等問題發生才拆。
  4. 風險觸發:鎖、安全、實驗性 Plugin 或新 Matter 類型不應和核心照明共享故障範圍。

分拆前先備份與輸出不含秘密的設定摘要,從原 Bridge 的 Filter 排除目標實體,再確認 Controller 端舊配件處理方式。不要同時 delete、reset、建立新 Bridge 與加入五個 Fabric;每個階段都要有可驗證返回點。

安全裝置:門鎖、警報與任何 Security Plugin 不應只靠矩陣的類型欄決定上線。還要驗證授權、語音政策、狀態回報、失聯行為與人工備援;產品成熟度若為實驗性,就不能視為主要安全控制。

跨 Controller 常見卡關

  1. 同一 Bridge 在 Apple 可用、Aqara 看不到

    保留 Apple Fabric,不 reset。把 Aqara 組合標 unknown,核對 Aqara Hub 型號、區域、firmware 及 bridged device type;用只含一個基本燈的專用 Bridge 試驗。

  2. SmartThings 配對成功但功能很少

    將該 device type 標 partial,對照 SmartThings 官方 Matter 支援與實際 UI/driver;分開記命令與狀態,不宣稱整體支援。

  3. Alexa workaround 讓 Apple 類型變錯

    這是共享 Bridge 的語意衝突。回復該 flag,建立 Alexa 專用 Bridge 測試;不要刪除 Apple Fabric 來遷就 Alexa。

  4. Google 有控制、Apple 只有狀態

    把命令層標 partial,核對 Apple 支援的 cluster 與平台版本。先用同型別基本裝置對照,不修改所有映射。

  5. 新增特殊類型後整座探索變慢

    回退最近一批 Filter/Mapping 變更,將特殊類型分拆。檢查 Controller 規模與 Endpoint 複雜度,不用 reset 清空證據。

  6. 不知道該填 no 還是 unknown

    沒有明確官方排除或受控失敗證據時填 unknown;一次失敗通常只證明當下環境失敗,不足以宣告 Controller 全面 no。

常見問題

Aqara Hub 支援 Matter,是否代表完整支援 Matter Hub Bridge?
不代表。Hub 的 Matter Controller 能力、可接受的 bridged device types 與 Aqara Home UI 都要逐項證明;本固定來源沒有足夠證據承諾完整支援。
SmartThings 官網列出某 device type,就能標 yes 嗎?
只能支持生態系統基本類型,仍需確認第三方 Bridge Endpoint、cluster、命令與狀態。若只有部分功能,應標 partial。
Multi-Fabric 會讓五個 Controller 顯示完全相同嗎?
不會。它們共享同一 Bridge 的 Matter 能力與狀態,但各自決定 UI、房間、名稱、自動化、權限及 cluster 使用方式。
矩陣的 yes 是產品保證嗎?
不是。yes 是基本類型有官方與上游路徑證據,仍需在指定版本實測;進階 cluster 與重啟恢復可能是 partial。
Stable 內的實驗性功能要怎麼填?
同時標出 release channel=Stable、maturity=experimental,再另填 Controller support。Controller 類型為 yes 也不會把產品成熟度變成 stable。

固定版本與 Controller 官方來源

官方頁面會隨生態系統版本更新;本章把無法由固定上游與官方類型共同證實的組合保留為 partial 或 unknown。