第 12 章

Standalone Devices 與 Server Mode

理解 Stable 2.0.55 內的實驗性 Server Mode：每個設定都是獨立 Matter node、最多十個平面實體、第一個實體主導身份；在不執行 live 建立、配對或刪除的前提下，完成架構與 Controller 適配規劃。

Bridge 裡的裝置與獨立 node 不一樣

一般 Bridge 以 Aggregator endpoint 掛載多個 bridged devices；Server Mode 則把設備 endpoint 直接放在 Matter ServerNode 上，移除 bridged device identity，讓它看起來像獨立 Matter 裝置。這對掃地機器人等 Controller 只願意在獨立 node 上提供語音或 discovery 的類型特別重要。

Dashboard 的 /standalone-devices 頁面把每個 Server Mode 設定稱為 Standalone Device。它本質上仍使用一份 bridge data、filter、port、持久化身份與 commissioning 狀態，但啟動的執行路徑是 ServerModeBridge，而不是一般 Aggregator Bridge。

務必明確標示：Server Mode 路由與 feature flag 都存在於 Stable 2.0.55 release channel，但產品成熟度是 experimental（實驗性）。Controller 支援則是 per-device-type 的第三項事實；manifest 對 Server Mode 本身的 Apple、Google、Alexa、Aqara、SmartThings 都標 unknown，不能寫成所有平台正式支援。

本章是規劃與風險導覽，不要求你在 live 系統按 Create、Pair 或 Delete，也不展示任何 QR、手動配對碼或識別資料。實際 commissioning 與 Multi-Fabric 安全流程由下一章處理。

Server Mode 的 node、endpoint 與身份

項目一般 BridgeServer Mode／Standalone
Matter 結構一個 node 下有 Aggregator 與 bridged child endpoints。實體 endpoints 直接加到 ServerNode，沒有 Aggregator。
裝置身份每個 child 有 Bridged Device Basic Information。移除 bridged identity，root node 承載主要身份。
數量依 Bridge 規模與 Controller 容量規劃。每 node 硬上限十個實體。
主實體Bridge 自身身份與各 child 分開。第一個 include matcher 命中的可用實體是 primary，驅動 node identity 與 advertised device type。
組合裝置可用 autoComposedDevices 與 user composed endpoint。不支援 composed shape；回退成 flat standalone endpoint。
Plugins一般 Bridge 可依功能與成熟度使用 plugin surface。不可用；Server Mode bridge 沒有 pluginInfo 或 enable/disable methods。

除 vacuum 外，多數 domain 先沿用第 9–11 章 LegacyEndpoint 的相同映射，再透過 asStandaloneEndpointType 移除 bridgedDeviceBasicInformation。Vacuum 使用專用 ServerModeVacuumDevice／endpoint，同樣不含 bridged identity，且預設不加入不符合 RVC spec 的 OnOff cluster。

這表示 Standalone 不是另一套 domain 支援清單。燈、sensor、fan、select 等仍受相同 HA device class、Matter override 與 Controller device-type 支援限制；Server Mode 只改 node 結構，不能讓 Controller 突然支援原本標為 no 的類型。

最多十個、第一個 primary、其餘 sibling

Standalone Devices 建立表單接受精確 entity ID，每列必須符合 domain.object_id 形狀，不允許 wildcard，重複值也無效。前端與後端都固定上限十列／十個 endpoint；後端若收到更多，會略過超額項目並在 failed entities 回報。

第一個 include matcher 命中的實體是 primary。它的 HA device、friendly name、Entity Mapping identity override 與 Matter device type會驅動 root node identity 和 advertised device type；其餘最多九個實體是直接掛在同 node 的平面 sibling endpoints。多於一個實體的模式在 Stable 內仍是實驗性。

排序是架構資料：調整順序不只改畫面清單。若另一個實體成為第一個可用 endpoint，node 對外身份與 advertised type 可能跟著改變；已配對 Controller 可能快取舊資訊。先備份設定並評估是否要重新整理 Controller，不能把 reorder 當成無害拖曳。
分組策略適合不適合
一個 node 一個實體Vacuum／mower、需要清楚獨立身份、問題隔離。大量簡單 sensor，會增加 commissioning 與 node 管理成本。
一個 primary 加少量 sibling同一用途、同 Controller 支援輪廓的設備。混合 EVSE、稀有 detector、媒體與一般燈，可能讓 Controller discovery 失敗或 UI 混亂。
塞滿十個經測試且 Controller 能穩定呈現的受控場景。只為節省 node 數量；十個是硬上限，不是建議目標。

某 sibling 若被 primary 的 mapping 吸收，例如 vacuum 自動關聯電池或模式 select，後端會把重複項目標成「Already exposed through …」，而不是建立第二份 endpoint。disabled entity 會保留身份號碼但列為失敗，避免可逆停用造成重新編號。

Create、Edit、Reorder、Delete 的影響

Create 概念：Standalone Devices 頁面的 Add device 表單收名稱與一到十個精確實體；送出後後端自動配置可用 port，建立 filter include rows 並把 serverMode 設為 true。這會新建 Matter node 與持久化資料，不是唯讀預覽。本章只教你在紙上或變更單準備名稱與順序，不要求在 live 系統提交。

Edit／Reorder 概念：清單卡片的 Open details and pairing 進入既有設定；一般 Bridge 詳情／編輯路由可管理 filter 與 Entity Mapping。Standalone 建立對話框本身沒有已建立 node 的拖曳編輯器。要改 primary，就必須改 include matcher 的順序，並評估身份與 Controller 快取；要改 Matter 類型，使用 Entity Mapping，而不是改 HA entity ID。

Delete 概念：清單有刪除按鈕與確認對話框。固定 UI 文案明確指出：刪除 Matter node 並從 Controller 取消配對，無法復原。刪除不是一般排錯步驟；執行前應備份持久化 storage 與設定、記錄所有已加入的 Controller、確認重建與重新 commissioning 的維護時段。

變更可能影響安全返回點
新增 node新 port、storage、commissioning 狀態與 Controller 裝置。提交前取消；提交後先停止而非直接刪除，確認設定備份。
增加／移除 siblingendpoint 結構改變、Controller 重新發現或留下快取。一次只改一個，保留原 include 順序。
重排 primaryroot identity 與 advertised device type 可能變動。先恢復原順序；不要同時重命名或改 override。
刪除 node取消配對且不可復原，需重新建立與 commissioning。只有事前備份與重建計畫；按下確認後沒有 undo。

Vacuum、mower 與 Controller fit

原始碼明確把 Server Mode vacuum 的目的寫為：避免 Bridged Device Basic Information，使它以 standalone device 出現，符合 Apple Home Siri 指令與 Alexa discovery 的需求。前端 Filter Preview 也會在一般 Bridge 包含 vacuum 時建議考慮 Server Mode。這是 device-specific 相容策略，不是 Server Mode 對所有 Controller 都有全面 yes。

類型固定 device-type 支援Server Mode 規劃
robot_vacuum_cleanerApple、Google、Alexa、Aqara yes。Apple 語音與 Alexa discovery 優先一 node 一 vacuum；保留標準 RVC，不盲開 OnOff。
robotic_lawn_mowerApple、Alexa yes；Google、Aqara unknown。仍以 RVC 類型顯示，獨立 node 有助隔離，但不會產生 mower 專用 UI。
evseAqara yes；Apple、Google、Alexa no。不應因 Standalone 就放入 Alexa；來源註記 bridged EVSE 可能破壞 Alexa 辨識。
air_purifier／fanApple no；Google、Alexa、Aqara yes。獨立 node 仍無法改變 Apple no。
mode_selectApple、Google、Alexa no；Aqara unknown。Standalone 不解決 UI 缺口；需要兩態 switch fallback 或保留 HA。

Vacuum 的 Service Area、Clean Mode、Operational State 與 Power Source 沿用第 11 章邏輯。房間、按鈕、吸力、拖地與充電關聯仍可能吸收其他實體；若把那些關聯實體又列成 sibling，後端會拒絕重複暴露。Mower 只有存在電池資訊才加 Power Source，且 Controller 可能稱它為 robot vacuum。

建議：為 vacuum 或 mower 建立專用 standalone node，比混入十個不同 device type 更容易定位 discovery、語音與區域問題。這是架構建議，不是宣稱 Server Mode 已脫離 experimental。

Commissioning 與 Multi-Fabric 概念

每個 Standalone Device 都是自己的 Matter node，因此有獨立的 commissioning 入口、Fabric 關係、session 與 Controller 裝置紀錄。清單卡片的 Open details and pairing 只是一個入口；你仍需先確認網路、IPv6、mDNS、Controller 帳號權限與維護窗口。

安全流程分成四段：先建立並啟動 node、再查看其 commissioning 狀態、在 Controller 端加入、最後回到 Matter Hub 驗證 Fabric 與 subscription health。QR 與手動資料都是秘密；只在你自己的受控畫面臨時顯示，不截圖、不貼到工單、不寫入本指南，也不使用任何真實示例。

Multi-Fabric 是把同一 node 加入第二個 Controller 生態，不是再建一份 Standalone。是否能開啟新的 commissioning window、Controller 如何分享，以及移除 Fabric 的影響，應依第 13 章固定流程；不要用 Delete Standalone Device 來移除單一 Controller，因為 Delete 會移除整個 node。

Controller 分拆：有些 workaround（例如 Alexa 專用 vacuum 或不相容類型排除）適合不同 node／Bridge，而 Multi-Fabric 適合同一裝置由多平台控制。這兩種設計不能互換。

Server Mode 沒有 Plugins

Stable 2.0.55 的 Server Mode bridge 不提供 pluginInfo，也沒有 plugin enable／disable 等方法。Plugin API 會在清單略過 Server Mode，對單一 Server Mode bridge 的 plugin 操作回覆不支援，而不是安裝 plugin。

因此 Camera 與 Security Plugins 即使在 Stable channel 內有路由，產品成熟度仍是 experimental，且不可用於 Standalone／Server Mode。不要把第 11 章 experimental doorbell 當成 Camera Plugin；doorbell 只提供事件／switch 類型，不含影像。也不要用多實體 Standalone 嘗試「組合」camera、doorbell、lock 來繞過限制。

Server Mode 同樣不支援 composed mappings：若設定 composedEntities 或 climateExposeFan，程式會警告並把 primary 回退為 flat endpoint。自動關聯電池、vacuum mode 等仍可附著在該 endpoint，但不等於任意 composed device parent。

功能一般 BridgeServer Mode
Legacy entity mapping可用可用，改成 standalone endpoint type。
Vacuum 專用 endpointBridged RVCStandalone RVC，適合 Apple Siri／Alexa discovery。
User composed device需 autoComposedDevices 等條件不可用，回退 flat。
Camera／Security Plugins功能本身為 Stable 內 experimental不可用。

不碰 live node 的規劃演練

  1. 列出目標實體與 Controller

    在離線變更單中使用 vacuum.example_cleaner 等文件 placeholder，標記每個 device type 的 yes／partial／no／unknown；不要貼入 live entity 清單或網路資料。

  2. 決定一 node 一實體或小型群組

    Vacuum／mower 優先獨立 node。若規劃群組，限制在十個以內，且只放支援輪廓相近的實體。

  3. 指定 primary 與順序

    把應主導名稱、vendor identity 與 advertised type 的實體放第一列；在變更單記錄原順序與預期順序，評估 Controller 快取影響。

  4. 在 UI 做唯讀定位

    確認導覽列有 Standalone Devices，查看既有卡片的名稱、實體摘要、status 與 entity problem；可開啟 details 查看狀態，但不要在本次演練按 Create、Pair、Delete 或儲存編輯。

  5. 完成備份與回復計畫

    記錄需備份的 Matter Hub storage／設定、已配對 Controller 類別、停止與重啟窗口，以及若 primary 變更失敗時恢復原 include 順序的方法。

  6. 把實際執行交給 commissioning 流程

    取得核准後依第 13 章在受控時段執行；秘密資料只留在本機畫面。沒有核准或備份時，本章的安全完成點就是「規劃完成、未提交」。

Server Mode 卡關與安全返回點

  1. Standalone Devices 路由不存在

    先核對版本確為 Stable 2.0.55 與前端 routes；不要用其他 channel 截圖或假設路由名稱。路由存在不等於功能 maturity 已 stable。

  2. 顯示 no entity 或 entity problem

    查看 include 是否為精確 entity ID、實體是否更名／移除／disabled，以及 HA registry 是否可用。空 registry 在 HA 重啟時會延後 reconcile，不應立刻刪 endpoint。

  3. 第十一個實體沒有建立

    每 node 硬上限十個；超額會列 failed entity。把額外實體移到另一個 node，而不是用 wildcard 規避，前端本來就禁止 wildcard。

  4. Controller 名稱或類型由錯誤實體主導

    檢查第一個 include matcher 與第一個實際成功建立的 endpoint。規劃恢復原順序；不要同時刪 node、改 custom name 與重新配對。

  5. Vacuum 建立但語音或 discovery 不工作

    確認它真的在 Server Mode、使用標準 RVC clusters、沒有不必要的 OnOff，並查 Controller device-type 支援。Server Mode 自身仍是 experimental，不保證每個平台版本。

  6. 找不到 Plugin 操作

    這是設計限制，不是權限錯誤。Server Mode 不 host plugins；改用一般 Bridge 評估 experimental plugin，或保留功能在原平台。

  7. 準備刪除來解決快取問題

    停止。Delete 會移除 node 並取消所有 Controller 配對且不可復原。先備份、收集已遮蔽診斷、恢復最近 mapping／順序；只有核准的重建計畫才進入刪除。

常見問題

Server Mode 在 Stable 2.0.55 算正式穩定功能嗎？
它在 Stable release channel，但 maturity 是 experimental。這兩個標籤要同時保留；Controller 支援又是第三項獨立事實。
一個 Standalone Device 只能放一個實體嗎？
不是。可放一到十個平面 sibling endpoints，但第一個是 primary，超過一個的模式明確標為 experimental。十個是硬上限，不是建議塞滿。
調整順序只是改列表嗎？
不是。第一個成功 endpoint 驅動 root identity 與 advertised device type，重排可能影響 Controller 快取與呈現。
Standalone 能讓 Apple 顯示 air purifier 或 fan 嗎？
不能這樣推論。固定 device-type 矩陣對 Apple 的 air_purifier 與獨立 fan 都是 no；node 結構不會改變 Controller 類型支援。
可以在 Standalone 裝 Camera 或 Security Plugin 嗎？
不可以。Server Mode 沒有 plugin surface；Camera／Security 本身也屬 Stable 內 experimental，不能混寫為可用於 Standalone。
刪除後可以按 Undo 恢復嗎？
不行。固定 UI 明示刪除 node、從 Controllers 取消配對且不可復原；只能靠事前備份與重建、重新 commissioning。

Stable 2.0.55 固定來源

所有來源固定到 exact commit。本章不包含任何實際 commissioning 秘密、live node 識別或環境資料。