KNXD 22 章教學離線手冊

本章任務卡

你已經熟悉 Home Assistant 的 Add-on、整合與實體。這一章不要求你安裝或設定任何東西，只先把四個角色放對位置。角色分清楚，之後看到像設備通訊道路的 KNX、像設計圖工具的 ETS或像翻譯櫃檯的 KNXD時，就不必靠猜。

目的

能用自己的話分清 Home Assistant、ETS、KNXD 與 KNX 裝置網路。

準備

只要會使用 Home Assistant；不需要懂 KNX、Linux 或網路工程。

時間

約 10 分鐘。

系統變更

不修改 Home Assistant。

預期結果

能分清 Home Assistant、ETS、KNXD 與 KNX 裝置網路，且知道程序執行不等於 bus 成功。

停止條件

• 需要輸入真實 KNX 位址、主機資料或秘密。
• 步驟要求連接 KNX bus 或控制實體設備。

先守住安全界線

本章是認識角色的閱讀任務。你不會啟動 Add-on，也不會傳送像道路短訊息的 KNX telegram，或讀寫像共同信箱的群組位址。畫面上即使出現「執行中」，也只能說某個程序正在執行，不能說 KNX 裝置網路已經接通。

請記住：程序正在執行，不等於 bus 已成功。就像翻譯人員已經坐到櫃檯，不代表電話線已接好，也不代表大樓裡的設備收到訊息。本章不證明 ETS 專案、Home Assistant KNX 整合或實體設備控制有任何成果。

環境識別資料包括真實主機名稱、IP、個體位址與群組位址。秘密或裝置識別資料包括 USB 序號、token 與憑證；兩類資料都不要抄錄或分享。

用大樓櫃檯認識四個角色

開始前只要知道這些

你不需要準備硬體、ETS 專案或網路資料。先用一張紙寫下四格：Home Assistant、ETS、KNXD、KNX 裝置網路。接著把每個角色的一句白話說明放進對應格子即可。

• Home Assistant 是你提出需求的控制櫃檯。
• ETS 是規劃與設定 KNX 專案的工具，不是 KNXD 的另一個名稱。
• 在本指南採用的路徑中，KNXD 是翻譯櫃檯；Add-on 是 Home Assistant 管理它的包裝。
• 在本站的責任圖裡，KNX 裝置網路放在設備側；其他程序的狀態不能替它作證。

用四句話走一遍

現在只做口頭演練，不操作任何介面。每一步都問「誰負責」，不要問「要填什麼值」。

1. 先找操作入口。你在 Home Assistant 提出需求，所以它是控制櫃檯。
2. 再找專案規劃。需要描述 KNX 專案如何設計時，那是 ETS 的角色，不是 Home Assistant Add-on 的角色。
3. 再找中間翻譯。本指南採用的 Add-on 路徑把 KNXD 放在 Home Assistant 管理端與 KNX 裝置網路之間；Add-on 負責在 Home Assistant 中管理這個程序。
4. 最後守住結果邊界。KNXD 程序出現或正在執行，只能證明程序層狀態；KNX bus 是否接通仍未由此證實。

若你能在不提任何 IP、位址或設定值的情況下說完四句，就已完成本章的白話主線。

完成檢查

用下面清單自我檢查。這裡的完成是「心智模型完成」，不是系統部署完成。

• 我能說出 Home Assistant 是控制櫃檯，ETS 是大樓設計圖與設定工具。
• 我能說出 KNXD 是翻譯櫃檯，KNX 是設備通訊網路。
• 我知道 Add-on 顯示執行中，不能當成 KNX bus 的成功證據。
• 我沒有連接 bus、操作 ETS、讀寫群組或控制實體設備。

下一步：前往第 2 章，用同一個大樓比喻看懂資料責任會依序經過哪些角色。

角色放錯時怎麼辦

這一章不會遇到服務故障，常見問題是把角色或證據層級混在一起。請用下列方式把說法改回正確位置。

• 把 ETS 當成 Home Assistant 整合：拆開來看；ETS 是 KNX 專案的規劃與設定工具，整合是 Home Assistant 內的另一個角色。
• 把 KNXD 當成 KNX 裝置：把 KNXD 放回翻譯櫃檯；裝置網路仍在它的下游。
• 看到「執行中」就以為 bus 接通：把結論降回程序層，bus 維持「未由此證實」。
• 覺得一定要先取得現場資料：停止收集；本章只需要角色名稱，不需要任何環境識別資訊。

進階補充與常見問題

本章任務卡

第 1 章分清了四個角色。這一章把本站 KNXD Add-on 指南使用的四個責任點排在一起：Home Assistant、KNXD、像設備閘門的連接介面，以及像設備通訊道路的 KNX bus。你只會學習分層，不會建立連線。

目的

能指出資料路徑上每一段由誰負責，並知道應從哪一層開始找問題。

準備

先完成第 1 章；不需要硬體、位址、ETS 專案或網路參數。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant。

預期結果

能按順序說出 Home Assistant、KNXD、連接介面與 KNX bus 的責任，且不跨層推論。

停止條件

• 需要建立真實 KNX 連線。
• 不得宣稱 KNX bus 成功；上游或程序狀態都不能證明它。

先守住安全界線

示意圖中的連接線表示「單次外送請求的責任接到下一站」，不是「現場資料已經通過」。這張圖不提供完整的 KNX 資料方向資訊，因此不能拿它判定其他方向。

任何一站顯示存在或正在執行，都不能替下一站作證。例如 KNXD 程序正在執行，只能說程序層有狀態；不能因此說連接介面可用，更不能說 KNX bus 已成功。本章沒有安裝、設定、啟動或連線步驟。

先看責任路徑

開始前只要準備一張圖

把上一節的四站抄成空白流程圖即可。不要在圖上寫環境連線資料，例如 IP、位址或連接埠。也不要寫裝置與秘密資料，例如裝置路徑、序號或憑證；這些值都不是理解責任分層的前提。

• 在每一站下面留一格「這一站能證明什麼」。
• 再留一格「這一站不能證明什麼」。
• 沿用示意圖的讀圖規則，把連接線當成責任交接。
• 若你還不能分清 ETS 與 KNXD，先回到第 1 章複習四個角色。

完成這張空白圖就可以繼續。

沿著四站走一遍

以下步驟只是在圖上辨認責任，不是連線程序。每走一站，就停下來說出它的工作與證據邊界。

1. 站在 Home Assistant。它是你提出需求的地方。此時只知道需求從哪裡開始，下游狀態仍是未知。
2. 走到 KNXD。它是中間的翻譯角色。即使程序層有狀態，也不能替連接介面或 bus 宣告結果。
3. 走到連接介面。它像通往設備道路的閘門，負責 KNXD 與設備側之間的一段交接。介面名稱存在，不等於硬體已準備好。
4. 最後到 KNX bus。這是設備通訊道路，也是本教學不接觸的邊界。前面三站的狀態都不能直接變成這一站的成果。

把四站連起來後，在圖下方寫「責任路徑，不是成功證據」。這句話能避免日後只看一個綠色狀態就跨層推論。

完成檢查

你不需要截圖或日誌來完成本章。只要能看著流程圖回答下列問題，就代表已理解架構責任。

• 我能按順序說出 Home Assistant、KNXD、連接介面、KNX bus。
• 我知道連接線是責任交接，不是現場狀態證據。
• 我知道 KNXD 程序層的狀態不能證明介面或 bus 的結果。
• 我沒有填入連線值、啟動服務、操作 ETS、傳送訊息或控制設備。

下一步：前往第 3 章，使用白話八項清單完成無實值預檢。預檢通過只代表能閱讀下一章的條件式流程，不代表可以忽略隔離、核准或 artifact provenance。

責任看不清楚時

這裡處理的是「圖看錯」，不是現場故障。簡單起點是：先從最接近症狀的責任層開始分類，不要從整條路徑一起猜。

• 看不到 Add-on 管理畫面：先把症狀歸在 Home Assistant 管理層。
• 只知道 KNXD 程序沒有狀態：先歸在 KNXD 程序層，不往介面或 bus 推論。
• 只知道設備閘門沒有狀態：先歸在連接介面層。
• 只剩設備是否收到訊息不明：歸在 KNX bus／裝置層；這已超出本章，停止，不用實體控制來測試。

若只是把連接線看成現場結果，將標籤改回「責任交接」。若把 KNXD 與連接介面合成一站，重新拆成翻譯櫃檯與設備閘門兩格。

進階補充與常見問題

本章任務卡

把 KNXD Add-on 想成準備進駐大樓的翻譯櫃檯。正式開門前，你先確認管理權限、備份、來源、建置證明與停止方法。這一章只做檢查，不加入 repository、不安裝、不啟動，也不收集現場值。

目的

完成一張不含環境資料的安裝前檢查表，得到「可以進入第 4 章」或「先停止補資料」的判斷。

準備

可以登入 Home Assistant，並知道誰有 Add-on 管理權限。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant；只做無實值預檢。

預期結果

完成八項分類；本站缺少核准 artifact digest 時，明確得到安裝仍被封鎖的判斷。

停止條件

• 無法建立或確認可用備份。
• 需要公開主機、位址、USB 序號、憑證或裝置路徑。

先守住資料與操作界線

檢查表只記分類與占位標記，例如「管理權限：符合」或「網路規劃：未知」。不要把真實值換成看似匿名但仍可回推環境的縮寫。

不得抄錄或分享：主機名稱、IP、KNX 個體位址、群組位址、USB 序號、帳號、密碼、token、憑證與裝置路徑。看到這些內容時，只記「已遮罩」或「未知」，不要貼到文件、截圖、聊天或 issue。

本章不執行像道路短訊息的 KNX telegram，不執行群組寫入，禁止 ETS 群組讀取；也禁止把工程設計寫入裝置的 ETS programming／download與實體控制。若檢查需要接線、開啟裝置或測試設備反應，已經超出本章。

用開門清單理解預檢

準備一張無實值檢查表

建立八列檢查表：Home Assistant 安裝類型、管理權限、Home Assistant 備份、來源與版本、介面類別、網路規劃、停止條件、還原決策。每列只能選「符合、不符合、未知」，再加一句不含實值的說明。來源與版本列必須同時核對來源鎖、核准的 artifact/image digest，以及把該 digest 綁到固定 commit 的 source-to-build attestation。

• 安裝類型只記「支援 Add-on 管理」或「待確認」，不記主機資訊。
• 權限只記角色是否能管理 Add-on，不記帳號或登入資料。
• 備份只記時間範圍與涵蓋範圍是否已核對，不附檔案、不貼名稱。
• 介面與網路只記方案類別和是否經負責人確認，不記任何端點或識別值。

逐項完成安全預檢

1. 確認 Home Assistant 安裝類型。只判斷目前環境是否提供 Add-on 管理介面。若不確定或畫面不同，記「未知」並停止，不用其他主機方式繞過。
2. 確認管理權限。由實際管理者人工確認你是否能安裝、啟動與停止 Add-on。權限不清楚就停止，不借用或分享憑證。
3. 確認備份或回復點。人工核對 Home Assistant 備份的時間、涵蓋範圍與還原責任人。沒有能說明範圍的備份，就不要進入安裝。
4. 核對來源與版本。預期repository（指定軟體書庫）身分是 da-anda/hass-io-addons，本站來源鎖固定在commit（精確來源存檔） 60d4a702e2011e75c90a0f1012dfbd916eb24ce0，來源版本邊界是 Add-on 0.6.1。還必須取得核准的 artifact/image digest 與 source-to-build attestation，證明待安裝 image 由該固定來源建置。商店顯示 0.6.1 不能完成這項證明。本站目前沒有核准 digest，所以這一列應記「未知」，安裝仍被封鎖。
5. 確認介面類別。只由負責人選定「USB 類、序列類、網路類或尚未決定」等分類。本章不選driver（入口轉接說明），不填裝置、端點或 KNX 位址。
6. 確認隔離規劃。只記是否已有非正式使用中的測試 Home Assistant、無 KNX／USB／裝置映射、實體 bus 斷開、網路暴露受限、備份／回復負責角色與在場管理者的核准安排。任一項未知，就在加入 repository 與安裝前停止；不得為填表而掃描網路、測試端點或記錄 IP。
7. 寫下停止條件。至少包括版本不符、備份不清楚、出現識別值、介面意外連接、非預期程序行為，以及任何實體設備反應。
8. 寫下還原決策。分清「停止 Add-on」與「還原 Home Assistant 備份」。指定由誰判斷、依哪個變更範圍處理；不要先假設停止等於還原。

完成檢查

八列都為「符合」才進入第 4 章的條件式操作區。任一列為「未知」或「不符合」，結果就是先停止，不用加入 repository 或嘗試安裝來找答案。由於本站目前沒有核准 artifact/image digest，現階段「來源與版本」必須保持未知；你可以閱讀第 4 章，但不能執行生命週期動作。

• 安裝類型與管理權限已有明確分類，但沒有記錄主機或帳號資料。
• 我已核對備份的時間與涵蓋範圍，並知道停止不等於還原。
• 我已把 Add-on 0.6.1 的來源版本邊界、artifact/image digest 與 source-to-build attestation 分開；沒有核准 digest 時保持「未知」。
• 我只記介面和網路方案分類，沒有抄錄任何真實值。
• 我已寫下停止條件、操作人與還原決策人。

下一步：全部符合時，前往第 4 章。若有缺項，先看開始前是否準備好與停止及還原。

預檢卡住時怎麼辦

• 不知道安裝類型：請 Home Assistant 管理者只回覆是否有 Add-on 管理能力；不要索取系統畫面或主機資料。
• 找不到備份：停止後續動作。先依目前 Home Assistant 版本的官方介面建立並核對備份；本章不猜按鈕位置。
• 來源或版本不同：保留「不符」分類並停止。不要把 0.6.1 的設定宣告套到其他版本。
• 有人要求提供連線資料：拒絕抄錄，改用「網路類，待核准」等分類；若仍必須提供實值才能繼續，就結束本章。
• 停止方法說不清楚：先閱讀停止與還原條目，由管理者確認責任後再重新預檢。

進階補充與常見問題

本章任務卡

這一章把 KNXD Add-on 的生命週期想成「進駐、值班、換班、下班」。但櫃檯不能先搬進正式大樓：完整隔離、書面核准與 immutable build 證明都要在加入 repository 或安裝前完成。本站目前沒有核准的 artifact/image digest，所以你只能閱讀條件式介面導覽，不能實際安裝或啟停。

目的

分清 installed、running、stopped 與匿名日誌證據，並知道生命週期操作何時仍被封鎖。

準備

第 3 章八項預檢全部符合；六項隔離條件、核准紀錄與 artifact provenance 已由管理者證明。

時間

約 20 分鐘。

系統變更

本站目前缺少核准 artifact digest，因此不加入 repository、不安裝、不啟停；日後仍須先通過完整 isolated-test 閘門。

預期結果

能分辨來源、artifact 與程序證據，並在證明不完整時停在第一個變更前。

停止條件

• 不得傳送 telegram、執行群組讀寫或實體控制。
• 無法說明變更影響或還原方法。

先確認本章不會碰什麼

本章的證據只限程序／狀態／日誌。日後最多只能觀察「Add-on 已安裝」「程序顯示 running」「程序已停止」或「日誌出現某類匿名訊息」。Add-on running 不等於 KNX bus 已接通，也不能提升成 ETS、Home Assistant KNX 整合、群組操作或設備控制成果。

不要連接 KNX 介面或 bus，不得傳送像道路短訊息的 KNX telegram；禁止群組讀寫與ETS programming／download，也禁止實體控制。不得抄錄、收集、分享或發布真實主機、IP、位址、USB 序號、憑證、token 或裝置路徑。

加入 repository、安裝、啟動、重新啟動、停止、移除與還原都屬環境變更。完整 isolated-test gate、書面核准與 immutable artifact provenance 必須先完成。所有動作只由在場管理者逐步手動確認，不使用 shell、API、腳本或自動化。

用櫃檯值班理解狀態

所有動作前的完整閘門

介面導覽提示：Home Assistant 的 Add-on 商店、repository 管理及備份介面會隨版本改變。請依Home Assistant 官方 Add-on 文件辨認目前版本的地標與流程。名稱或位置不同時，先回官方文件核對；不要猜按鈕。

在加入 repository 或安裝前，由在場管理者逐項證明下列六項；不是正式使用中的 Home Assistant 才有資格繼續：

• 這是非正式使用中的測試 Home Assistant，不是家中、辦公室或客戶現場正在提供服務的系統。
• 系統沒有映射 KNX、USB 或其他裝置路徑。
• 實體介面與 bus 都保持斷開，也沒有可讓測試程序碰到現場設備的替代連線。
• 可能開啟的服務只在管理者核准的 bounded network 測試範圍，不會意外被一般區域網路或公開網路連到。
• 已核對安裝前 Home Assistant 備份、最小回復方法，以及負責停止、移除或還原的角色。
• 具 Add-on 管理權限的管理者全程在場，能在異常時立即停止。

任一項無法證明，就在加入 repository 與安裝前停止。正式使用中的 Home Assistant 不得安裝未通過上述閘門的 Add-on。

書面核准紀錄

操作前要建立 privacy-safe change record。公開或教學紀錄只放不含環境線索的 ID；私人核准者證明、精確操作範圍與六項隔離證據留在有存取控制的紀錄中。下列欄位缺一，就不繼續。

變更／核准紀錄 ID

使用組織核發、無姓名、主機、地址或時間線索的 privacy-safe ID；本站不提供可誤用成真實紀錄的範例值。

受控紀錄參照

只記可由授權人員查回的受控參照；它必須綁定私人核准者證明、精確操作範圍與六項隔離證據，但公開頁面不放姓名、系統路徑或連結。

核准者角色

只記角色，不記姓名，例如「Home Assistant 管理者」；私人核准者證明保留在受控紀錄。

核准動作與範圍

逐項列出此次是否包含加入 repository、安裝、啟動一次、重新啟動一次、停止、移除或備份還原；精確操作範圍不含 KNX 介面、bus、telegram、ETS 或實體設備。

隔離證據參照

綁定上方六項隔離證據的受控紀錄，只公開符合／不符合／未知分類，不公開環境值。

核准日期與時間

時間保留在受控紀錄；公開教材只顯示「已記錄」狀態，避免串聯現場活動。

停止條件

綁定本次適用的停止條件；隔離失效、狀態不明、證明不符或非預期行為都要立即停止。

隱私界線

不記主機名稱、主機 ID、IP、KNX 位址、USB 序號、裝置路徑、帳號、密碼、token、憑證或其他秘密。

Immutable build／artifact provenance 閘門

來源鎖固定 da-anda/hass-io-addons 的 commit 60d4a702e2011e75c90a0f1012dfbd916eb24ce0，其中宣告 Add-on 0.6.1。這只能證明來源內容。商店顯示的 0.6.1 不能證明待安裝 image 就等於鎖定 commit。

• 受控紀錄中有管理者核准的 artifact/image digest，且演算法與完整 digest 都已核對。
• 有可驗證的 source-to-build attestation，把該 digest 綁到上方固定 commit 與建置流程。
• 操作人能核對 Home Assistant 將取得的 artifact 就是已核准 digest；不能只看名稱或版本文字。

條件式介面導覽

以下只是版本容錯的地標、預期可觀察狀態與停止點。只有日後受控紀錄補齊所有閘門時，管理者才可依當時的 Home Assistant 官方文件人工執行。

1. 加入 repository。核准紀錄與 artifact/image digest 證明都有效時，從 Home Assistant 的設定區找到 Add-on 管理地標，再依官方文件進入 repository 管理。加入後只接受清單顯示核准 repository 身分；若項目不同、來源無法辨認或介面要求猜測，停止。本站目前缺少 digest，所以不要執行。
2. 人工安裝。核准紀錄與 artifact/image digest 證明都有效時，從 Add-on 商店找到已核准來源的 KNXD 詳細頁。安裝完成後，預期頁面能分辨「已安裝」狀態與生命週期控制區；不要用商店版本推論 commit。若自動啟動或要求真實 KNX 值，立即停止。本站目前缺少 digest，所以不要執行。
3. 人工啟動。核准紀錄與 artifact/image digest 證明都仍有效時，由在場管理者使用詳細頁的啟動控制一次。預期只觀察到 Add-on 程序狀態由停止類狀態轉為 running 類狀態；文字依版本而異。這不證明 bus。本站目前缺少 digest，所以不要執行。
4. 人工重新啟動一次。核准紀錄與 artifact/image digest 證明都仍有效，且前一步狀態可解釋時，才使用詳細頁的重新啟動生命週期控制一次。預期只看到短暫轉換後回到 running 類狀態；反覆重試或狀態不明就停止。本站目前缺少 digest，所以不要執行。
5. 人工停止。受控核准範圍包含停止且前述證明仍有效時，使用詳細頁的停止控制。預期狀態不再是 running，而是 stopped 類狀態。畫面未改變時不反覆操作，保持隔離並前往停止與還原。本站目前沒有操作可停止。
6. 人工移除。只有受控核准範圍包含移除，且 Add-on 已停止時，才從詳細頁辨認移除／解除安裝的生命週期動作。預期已安裝狀態與該實例的生命週期控制消失，或頁面回到可安裝狀態；這不代表 Home Assistant 整體已還原。本站目前沒有安裝可移除。
7. 人工還原。只有備份涵蓋範圍與受控核准完全相符，才由管理者從 Home Assistant 備份管理地標選取事前核對的回復點，先檢視影響範圍再確認。預期只回到該備份涵蓋的狀態；還原後要重新核對 Add-on 與其他受影響項目。本站目前沒有生命週期變更需要還原。

完成檢查與證據判讀

目前正確完成結果是「因缺少核准 artifact provenance，在第一個變更前停止」。日後若證明補齊，日誌也只在 Home Assistant 畫面內短暫查看。依安全日誌條目完成去識別，只記時間範圍、元件與錯誤類別；移除主機、IP、位址、帳號、token、session、憑證、裝置名稱、路徑與序號，不發布完整日誌。

• 我知道固定 commit 只證明來源，商店版本不能代替 artifact/image digest 與 source-to-build attestation。
• 我已在加入 repository 與安裝前檢查六項隔離條件及完整核准紀錄；目前缺少 digest，所以沒有執行變更。
• 我能說明 installed、running、stopped、removed 與 restored 各自可觀察的範圍，不跨層推論。
• 我不連接介面或 bus；不傳送 telegram；不執行群組操作；不執行 ETS programming／download；也不執行實體控制。

下一步：保持所有 KNX 介面、裝置映射與 bus 斷開。需要判讀程序狀態時看Add-on 狀態；缺少 artifact provenance 時只保留「blocked」紀錄。

停止、移除與還原決策

1. 先縮小變更範圍。若日後問題只涉及這個 Add-on，先停止 Add-on，再移除 Add-on。完成後只確認程序未執行且 Add-on 實例已移除；不要把移除說成整個 Home Assistant 已還原。
2. 只有範圍相符才考慮整體還原。若已發生 Add-on 以外的變更，而且事前核准的備份確實涵蓋該範圍，管理者先核對備份時間、內容與其他可能被覆蓋的變更，再人工確認使用 Home Assistant 官方備份還原流程。介面與用詞依版本而定，本章不虛構按鈕。
3. 還原後再驗證。由管理者確認 Home Assistant 回到預期範圍、KNXD Add-on 為預期的停止或已移除狀態，且沒有非預期影響。任一結果不明就保持隔離並停止後續操作。

• 缺少 digest 或 attestation：保持 blocked，不加入其他 repository，也不安裝相似版本。
• 程序狀態不明：只記匿名錯誤類別後停止；不要填 bus 值、換 driver 或接上介面嘗試。
• 日誌含環境資料：停止分享並刪除副本；若秘密已揭露，交由管理者撤銷或輪替。

進階補充與常見問題

本章概覽

先說結論：這一章只做一張不含識別資料的候選分類表。你不會列出電腦目前看到的裝置，也不會找出適用硬體。完成表格，不等於硬體相容。

目的

用去識別特徵分類介面候選項，不猜測硬體是否適用。

準備

一張空白離線分類表，以及第 3、4 章的安全界線。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant；只建立不含真實裝置路徑與序號的離線介面分類表。

預期結果

能用去識別特徵分類介面候選項，並把硬體可用性保持為未證實。

停止條件

• 不得抄錄或公開真實裝置路徑、USB 序號或主機識別。
• 步驟要求連接介面、KNX bus 或存取實體設備。

範圍與安全界線

你只整理「資料應怎麼分類」。不要執行裝置列舉。不要查看真實裝置路徑。不得抄錄真實序號。不得發布真實主機名稱、IP、端點、憑證或時間線索。若既有資料含這些內容，停止轉交，再依安全日誌指引處理。

本章不加入 repository、不安裝、不啟動。這些動作只有在完整隔離、書面核准，以及核准的 immutable artifact/image provenance 全部成立後，才可能另行評估。本站目前缺少核准的 artifact/image digest，所以不得執行。

也不要連接介面或 KNX bus。禁止群組讀取、群組寫入、telegram 傳送、ETS programming／download 與實體控制。

核心概念

分類表只放三種判斷：來源文件已說明、尚待人工複核、超出本章。看到候選存在，最多只能說「有一筆待分類資料」。不要寫成「已找到介面」或「可以使用」。

準備與前置條件

準備一張空白表。只建立下列欄位，不填任何環境實值：

• 候選代號：使用「候選 A」這類無意義標籤。
• 資料類別：文件事實、待複核問題或禁止公開資料。
• 欄位角色：這筆資料是否可能屬於介面輸入。
• 目前結論：一律從「硬體適用性未證實」開始。
• 停止原因：記錄缺少核准、資料可能識別環境或來源版本不符。

不要準備終端機指令、裝置清單或截圖。本章沒有 live enumeration 程序。

分段步驟

以下全是離線紙上分類。你不需要接觸執行中環境。

1. 先寫共同結論。在表頭寫「本表只做候選分類；硬體相容、驅動運作與 bus 狀態都未證實」。
2. 建立中性代號。需要區分既有的去識別紀錄時，依序寫候選 A、候選 B。不要由路徑、序號、型號或位置產生代號。
3. 分類資料角色。把每筆內容放入「文件事實」「待人工複核」或「不得公開」。沒有足夠內容時就標示未知。
4. 寫下未證實事項。每個候選都註明硬體身分、驅動家族、適用性與 KNX bus 狀態未證實。
5. 套用停止條件。若分類需要回看真實路徑、序號、主機或 live 裝置清單，就停止。不要用逐項啟動來找答案。
6. 交給另一人複核。只交付去識別分類表。請複核者確認沒有環境識別資料，也沒有相容性宣稱。

驗證與證據

正確成果是一張分類表，不是一個裝置答案。用下面清單確認文字沒有越界。

• 我的表格只有候選代號，沒有真實路徑、序號、主機、IP 或端點。
• 我沒有執行 live enumeration，也沒有提供相關程序。
• 每個候選都保留「硬體適用性未證實」。
• 我沒有安裝、啟動、連接 bus、操作群組、ETS 或實體設備。

下一步：前往第 6 章。你只會從固定文件選出一個驅動家族供日後人工複核，不會試啟動。

故障排除

• 不知道候選來自哪裡：標示「來源未知」並停止。不要回到 live 系統找答案。
• 候選代號暗示型號或位置：重新改成無意義的字母代號，刪除舊副本。
• 同事要求真實路徑：不提供。把需求轉成「需要複核哪一種欄位角色」。
• 表格看起來像相容清單：在每列補上「硬體適用性未證實」，並移除推薦或肯定字眼。
• 有人提議逐個啟動：停止。這不是本章的分類工作，也不能繞過隔離、核准與 artifact provenance。

常見問題

本章概覽

先說結論：你只會選出一個「固定文件有說明的驅動家族」，交給日後人工複核。這不是安裝建議，也不是硬體相容證明。文件不足就不選。

目的

依固定文件列出一個可供人工複核的 driver 家族候選。

準備

第 5 章的去識別分類結果，以及固定版本的文件對照。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant；只依固定文件離線比較 driver 家族。

預期結果

能列出供人工複核的 driver 家族候選，不把名稱對應寫成硬體相容或可用證明。

停止條件

• 有人要求從產品名稱直接推論 driver 或硬體相容性。
• 步驟要求載入 driver、啟動服務或接觸實體介面。

範圍與安全界線

本章只讀固定文件。不要從產品名稱、外觀、插頭、候選代號或網路文章猜驅動。也不要輪流啟動驅動來試。若沒有同版本的明確文件，答案就是「不選，待補證據」。

本章不加入 repository、不安裝、不啟動。任何這類動作都必須先完成完整隔離、書面核准，以及核准的 immutable artifact/image provenance。本站目前缺少核准的 artifact/image digest，因此仍被封鎖。

不要連接介面或 KNX bus。禁止群組讀取、群組寫入、telegram 傳送、ETS programming／download 與實體控制。不要記錄任何環境識別資料。

核心概念

選擇時只問兩題：Add-on 固定版本是否接受這個名稱？鎖定的 upstream 文件是否明確說明同名家族？兩題都是「是」，才可列為日後人工複核候選。

準備與前置條件

建立一張離線決策卡。不要放產品名稱、裝置路徑、序號、主機、IP 或端點。卡片只需要：

• 需求類別：只寫「裝置型輸入」或「端點型輸入」等角色。
• Add-on 名稱證據：有、沒有或未知。
• upstream 文件說明：有、沒有或未知。
• 人工複核狀態：待複核或停止。
• 非結論：本機硬體相容、驅動啟動與 bus 狀態都未證實。

版本不符時，先看版本與相容性。不要拿其他版本補答案。

分段步驟

1. 先寫需求角色。只寫需要處理哪一類輸入。不要寫品牌、型號或真實值。
2. 核對 Add-on 名稱。確認候選名稱在 Add-on 0.6.1 的固定列舉中。沒有就停止，不自行改名。
3. 核對 upstream 說明。確認 upstream 0.14.72 固定文件明確描述同名驅動家族。只有名稱相似不算。
4. 最多保留一個候選。兩邊文件都明確時，寫成「文件候選，待人工複核」。若有多個或沒有明確答案，就不選。
5. 補上非結論。寫明「未證明硬體相容、未載入驅動、未啟動服務、未接觸 bus」。
6. 在文件層停止。把決策卡交給核准流程。不要試啟動，也不要用正向日誌替候選加分。

驗證與證據

完成結果只能是「文件候選」或「證據不足」。不能寫成「驅動適用」。

• 候選同時有 Add-on 0.6.1 名稱證據與 upstream 0.14.72 明確文件。
• 決策卡沒有產品、路徑、序號、主機、IP、端點或憑證。
• 我把硬體相容、載入、啟動、listener 與 bus 狀態都保留為未證實。
• 我沒有輪流試驅動，也沒有安裝、啟動或連接實體介面。

下一步：前往第 7 章，只辨認設定欄位、占位文字、門牌號碼與暴露責任。

故障排除

• 只有 Add-on 名稱，沒有 upstream 說明：標示證據不足，不建立家族對應。
• 名稱很像但不完全相同：視為不同。不要從字首、字尾或產品描述猜。
• 有兩個文件候選：兩個都不選。列出文件缺口，交給人工複核。
• 有人把預設值當推薦：移除推薦語句。來源預設只是一個 schema 事實。
• 有人要求啟動看看：停止。試啟動不是文件選擇，也不能證明硬體相容。

常見問題

本章概覽

先說結論：設定欄位、占位文字、連接埠與網路暴露不是同一件事。你只會做一張責任表。你不會填真實值、不會開放連接埠，也不會改網路。

目的

分清設定欄位、文件占位值、連接埠與網路暴露責任。

準備

一張空白責任表；不需要 ETS 專案、主機資料或網路設定。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant 或網路；只用占位資料整理位址欄位、連接埠與暴露面。

預期結果

能區分設定欄位、占位值與網路暴露責任，且未填入任何現場識別資料。

停止條件

• 不得填入或公開真實主機、端點、個體位址或群組位址。
• 步驟要求開放 listener、防火牆或建立現場連線。

範圍與安全界線

本章只有文件分類。不得填入真實個體位址或群組位址。不得發布真實用戶端範圍、主機、IP、連接埠、URL、介面、裝置路徑、序號或憑證。文件占位文字也不能貼進設定。

不要開啟 listener、修改防火牆、路由或網路介面，也不要做連線測試。本章不加入 repository、不安裝、不啟動。任何變更仍需完整隔離、書面核准，以及核准的 immutable artifact/image provenance；本站目前缺少核准 digest。

禁止群組讀取、群組寫入、telegram 傳送、ETS programming／download 與實體控制。欄位格式正確也不能證明 KNX bus、ETS、整合或設備成果。

核心概念

個體位址與群組位址也不同。這一章不配置任何一種位址，更不開啟 ETS 專案。

準備與前置條件

建立四欄責任表。每一列只放概念，不放數字或環境值：

• 表格空格：設定欄位的名稱與資料角色。
• 文件提示：使用語意占位文字，並標示「不可套用」。
• 門牌角色：只說這是 port 類資料，不寫任何數字。
• 誰能進門：列出 listener、綁定、防火牆、路由與網路範圍分屬不同審查責任。

若資料來自日誌或截圖，先依安全日誌指引停止分享。不要為了完成表格去讀 live 環境。

分段步驟

1. 先標示欄位角色。把位址類、範圍類、端點主機類與 port 類分開。只寫類別。
2. 改用占位文字。公開表格只寫「個體位址占位」「用戶端範圍占位」「端點主機占位」「端點 port 占位」，並註明不可套用。
3. 分開 port 與 listener。port 是門牌角色；listener 是服務等待工作的角色。不要把兩者寫成同一個狀態。
4. 列出暴露責任。把綁定範圍、防火牆、路由與可接近網路視為獨立審查項。全部標示未評估。
5. 補上非結論。寫明未配置位址、未開放 port、未建立 listener、未驗證端點，也未證明 bus。
6. 搜尋並移除實值。若表格出現任何數字位址、port、主機、URL 或環境名稱，刪除後再交付。

驗證與證據

完成標準是責任分開，而且沒有真實值。不是設定可以使用。

• 我能說明欄位是空格、占位文字是提示、port 是門牌角色、暴露是誰能到門前。
• 所有占位文字都清楚標示「僅供文件分類、不可套用」。
• 表格沒有位址、範圍、主機、IP、port 數字、URL 或其他環境識別資料。
• 我沒有修改 Home Assistant、listener、防火牆、路由或網路，也沒有操作 ETS 或 bus。

下一步：前往第 8 章，用「接待櫃檯」理解 listener 與 KNXnet/IP 的責任界線。

故障排除

• 讀者想看格式範例：只用語意占位文字。不要提供看起來可直接套用的數字。
• 占位文字被當成設定值：在每個占位旁加上「不可套用」，並移除可複製的設定片段。
• 有人說有 port 就代表已監聽：把結論退回門牌角色。listener 狀態需要另一層證據。
• 有人說已監聽就代表對外開放：列出綁定、防火牆、路由與網路範圍仍未評估。
• 有人要求開 port 驗證：停止。本章不做 live 網路變更或探測。

常見問題

本章概覽

先說結論：listener 只是一個等待接收工作的角色。看到設定中有這個角色，不能證明端點可達、連線或 tunnel 成立，也不能證明 KNX bus 狀態。

目的

分清 listener、網路介面、KNXnet/IP 與 KNX bus 的責任。

準備

第 7 章的欄位責任表；不需要端點、網路工具或 ETS。

時間

約 15 分鐘。

系統變更

不修改 Home Assistant 或網路；只閱讀 listener 與 KNXnet/IP 的責任邊界。

預期結果

能說明 listener、網路介面與 KNX bus 的不同責任，不宣稱端點可達或連線成功。

停止條件

• 需要提供、探測或連線真實網路端點。
• 不得宣稱 KNX bus 或介面成功；listener 狀態不能證明它。

範圍與安全界線

本章只讀固定範本。不要提供或探測端點。不要執行連線、tunnel、socket 或 reachability 程序。不要抄錄主機、IP、port、URL、網路介面、憑證或任何環境識別資料。

本章不加入 repository、不安裝、不啟動。任何變更仍必須先有完整隔離、書面核准，以及核准的 immutable artifact/image provenance。本站目前缺少核准的 artifact/image digest，因此所有執行動作都被封鎖。

不要連接 KNX 介面或 bus。禁止群組讀取。禁止群組寫入。禁止 telegram 傳送。禁止 ETS programming／download。禁止實體控制。listener 或網路訊息都不能替這些結果作證。

核心概念

請保持四層分開：範本宣告、程序／listener 狀態、端點 reachability、KNX bus 結果。前一層永遠不能自動證明下一層。

準備與前置條件

畫四個空框，不填端點或數值：

1. 範本角色：固定文件是否提到 server 或 listener。
2. 程序角色：是否有獨立的程序／listener 證據。
3. 網路角色：端點是否可達；本章一律寫「不探測、未建立」。
4. bus 角色：KNX bus 是否有成果；本章一律寫「未證實」。

這張圖只用來限制說法。它不是網路拓撲，也不能拿來建立連線。

分段步驟

1. 先寫文件結論。只寫「固定範本包含 listener／server 設定角色」。不要寫「已監聽」。
2. 放進第一個框。把這句話放在範本層。其餘三框保持未建立或未證實。
3. 分開網路介面。註明介面只負責網路資料進出；它不等於 listener，也不能代表 bus。
4. 封住 reachability 推論。在網路框寫「沒有端點、沒有探測、沒有連線或 tunnel 程序」。
5. 封住 bus 推論。在 bus 框分別寫「沒有 telegram 證據」「沒有群組操作證據」「未執行 ETS programming／download」「沒有實體控制證據」。
6. 逐句降低結論。若看到端點、連線、tunnel 或 bus 的肯定成果，移除並退回固定範本能支持的說法。

驗證與證據

完成成果是一張四層責任圖。唯一有直接來源的是範本角色。其他層都要保持未證實。

• 我能說明 listener 像等待來電的接待櫃檯，不等於外線可達。
• 我把範本、程序／listener、reachability 與 KNX bus 分成四層。
• 我的圖沒有主機、IP、port、URL、介面名稱、憑證或其他環境識別資料。
• 我沒有提供探測、連線或 tunnel 程序。bus、ETS、整合與實體控制成果都維持未證實。

下一步：繼續前往第 9 章，分類 INI 區段、選項與受管範本的責任。

故障排除

• 範本看起來已有完整設定：仍只記為範本角色。它不證明已產生、已套用或已監聽。
• 日誌出現 listener 字樣：只屬程序／listener 層。依狀態判讀把 reachability 與 bus 保持未證實。
• 有人要求提供端點：不提供。公開教材不包含可連線值。
• 有人想探測是否可達：停止。本章沒有 reachability、連線或 tunnel 程序。
• 有人把 KNXnet/IP 當成 bus 成果：退回四層圖。網路側術語不能證明 KNX bus。

常見問題

本章概覽

先說結論：你只會畫一張離線責任圖。把設定內容分進有標籤的抽屜。你不會填值、寫檔或套用設定。

目的

用有標籤的抽屜分清 INI 區段、選項與產生責任。

準備

一張空白紙與第 7–8 章的責任分類；不需要設定檔或執行中資料。

時間

約 20 分鐘。

系統變更

不修改 INI 或啟停 Add-on；只離線閱讀固定版本的受管範本。

預期結果

能把 INI 區段、選項與產生責任對應起來，不把範本視為可直接套用的現場設定。

停止條件

• 需要填入真實環境值或把範本直接寫入系統。
• 步驟要求套用設定、安裝或重新啟動 Add-on。

範圍與安全界線

本章只在紙上分類。不要貼入主機、位址、連接埠、裝置、序號、秘密或正式設定。不要讀取本機結果，也不要把範本當成目前設定。

本章不加入 repository、不安裝、不啟動。本站缺少核准的 immutable artifact／image digest 與來源到建置的證明，所以所有執行動作都被封鎖。

不要連接介面或 KNX bus。禁止群組讀取、群組寫入、telegram 傳送、ETS programming／download 與實體控制。紙上對照不能證明 daemon、listener、整合或 bus 成果。

核心概念

你的圖只需要四個抽屜：「主要責任」「服務責任」「記錄責任」「介面責任」。若一項資料無法只靠固定來源歸類，就放進「待補證據」。

準備與前置條件

拿一張紙，畫出五個空框。前四框是四個責任抽屜。第五框是「待補證據」。每個框只放分類字樣。

• 在紙張上方寫「離線責任圖」。
• 寫明「不含實值」。
• 寫明「未產生、未套用、未讀取執行結果」。
• 把版本差異留給版本與相容性處理，不混用其他版本。

如果手邊資料帶有環境識別內容，不要抄寫。只記「需要授權人員在受控位置確認」。

分段步驟

1. 先放主要責任。把整體串接與共同設定的角色放進主要抽屜。不要填任何值。
2. 再放服務責任。把等待其他軟體交接的角色放進服務抽屜。不要推論服務已存在。
3. 分開記錄責任。把訊息層級與記錄類別放進記錄抽屜。不要抄本機日誌。
4. 分開介面責任。把裝置型、篩選型或網路型輸入只寫成類別。不要放路徑或端點。
5. 標出來源邊界。每張分類卡註明它來自輸入規則或受管範本。不要把兩種來源寫成同一件事。
6. 封閉結論。最後只寫「離線責任已對照」或「仍有缺口」。不要寫成已部署或可使用。

驗證與證據

完成品只能是一張不含實值的責任圖。它說明資料應由哪一類抽屜承接，不說明系統現在做了什麼。

• 我有主要、服務、記錄、介面與待補證據五個抽屜。
• 我分開標示輸入規則與受管範本。
• 我的圖沒有主機、位址、連接埠、路徑、序號、秘密或正式設定。
• 我沒有寫檔、套用、安裝、啟停或讀取執行結果，也沒有宣稱任何 bus 或整合成果。

下一步：前往第 10 章，用交接檢查點分清 driver、介面與 bus 的證據層。

故障排除

• 不知道放哪個抽屜：放進待補證據。不要靠名稱猜。
• 有人貼入正式值：停止分享並移除內容。責任圖只保留分類。
• 範本看起來很完整：仍標成來源材料。完整外觀不代表已產生或已套用。
• 輸入規則與範本對不上：分開記錄兩個來源，再標示缺口。不要自行補關係。
• 有人要求立即套用：停止。本章沒有寫檔、安裝或啟停程序。

常見問題

本章概覽

先說結論：你只會畫一張交接檢查表。每個檢查點只代表一種文件分類。它不是本機觀察，也不是 KNX bus 成果。

目的

用交接檢查點分清程序、driver、介面與 bus 的證據層。

準備

第 9 章的離線責任圖與一張空白分類表；不需要硬體或日誌。

時間

約 20 分鐘。

系統變更

不修改 Home Assistant；只用固定文件建立離線鏈路層與 driver 診斷模型。

預期結果

能區分程序、driver、介面與 bus 證據層級，不把啟動訊息當成匯流排成果。

停止條件

• 步驟要求啟動診斷模式、存取硬體或重啟服務。
• 不得傳送 telegram，也不得執行實體控制來驗證 driver。

範圍與安全界線

本章只整理固定文件中的責任。不要開啟診斷模式，不要讀取本機日誌，不要存取硬體，也不要重新啟動服務。表上的狀態都是分類名稱，不是本地觀察。

本章不加入 repository、不安裝、不啟動。本站缺少核准的 immutable artifact／image digest 與來源到建置的證明，所以所有執行動作都被封鎖。

不要連接介面或 bus。禁止群組讀取。禁止群組寫入。禁止 telegram 傳送。禁止 ETS programming／download。禁止實體控制。任何程序或 driver 類別都不能證明 bus、整合或設備成果。

核心概念

你可使用三種紙上標籤：「文件可對照」「文件描述失敗邊界」「證據不足」。這些字樣只分類來源內容。它們不是觀察到啟動、停止、重試或硬體反應。

準備與前置條件

畫四個交接框：程序、driver、介面、bus。每個框再分成「固定文件說明」與「仍不能推論」兩欄。

• 來源只用鎖定版本的固定 INI 文件。
• 狀態只用分類字樣，不使用「本機看到」或「現場發生」。
• 不放路徑、端點、位址、硬體名稱、序號或日誌片段。
• bus 欄固定保持「沒有本章證據」。

如果資料來自執行中環境，就不要放進這張表。依安全日誌另行處理，且不能把它改寫成本章的來源主張。

分段步驟

1. 先畫四站。依序寫程序、driver、介面與 bus。只寫責任名稱。
2. 分類文件關係。把固定文件中的引用責任放在文件可對照欄。不要宣稱設定已載入。
3. 分類啟動語意。把固定文件對 driver 設定與失敗的描述放在文件邊界欄。不要寫成本機曾啟動或失敗。
4. 封住介面推論。註明 driver 家族名稱不能證明介面存在、相容或可用。
5. 封住 bus 推論。註明程序與 driver 類別都不能證明 telegram、群組操作或 bus 成果。
6. 完成交接表。結論只寫「來源分類已完成」或「證據不足」。不要加入本地診斷結論。

驗證與證據

完成品是一張文件分類表。它把責任分站，也把可說與不可說的範圍分開。

• 我把程序、driver、介面與 bus 分成四個交接點。
• 我的診斷狀態都是來源分類，不是本機觀察。
• 我沒有放入日誌、裝置、位址、路徑、端點、序號或正式值。
• 我沒有把啟動或失敗語意升格為 driver、硬體、介面、bus 或整合成果。

下一步：前往第 11 章，只用分類建立 ETS 離線預檢表。

故障排除

• 把文件語意寫成本機事件：改回「固定文件描述」。移除時間、主機與觀察結果。
• driver 名稱看似吻合：只保留文件家族分類。不要宣稱硬體相容。
• 有人提供正向日誌：不要放進表內。正向訊息也不能證明下一個交接點。
• 有人提供錯誤日誌：不要判定根因。依安全日誌流程另行處理。
• 有人要求重啟確認：停止。本章只做離線分類。
• 有人要求用 bus 驗證：停止。禁止用 telegram、群組操作或實體控制來驗證。

常見問題

本章概覽

先說結論：你只會完成一張離線審閱表。表內只有分類，不放工程資料。你不會開啟 ETS 專案，也不會進行任何 KNX 動作。

目的

用分類完成 ETS 責任、核准與禁止事項的離線預檢。

準備

一張空白審閱表與指定責任人；不需要 ETS、專案檔或現場資料。

時間

約 15 分鐘。

系統變更

不修改 ETS、Home Assistant 或 KNX；只建立去識別的離線前置檢查表。

預期結果

能完成 ETS 責任與核准項目分類，並保持 programming、download 與群組操作為禁止自動化。

停止條件

• 需要開啟真實 ETS 專案或抄錄個體位址、群組位址。
• 不得執行 ETS programming、download 或群組讀寫。

範圍與安全界線

本章只做紙上分類。不要開啟 ETS，不要查看真實專案，也不要抄錄個體位址、群組位址、專案名稱、設備名稱、主機、端點、憑證或其他識別資料。

永不自動化：禁止 ETS programming／download。禁止群組讀取。禁止群組寫入。禁止 telegram 傳送。禁止實體控制。測試用途不構成例外。

本章不加入 repository、不安裝、不啟動。本站缺少核准的 immutable artifact／image digest 與來源到建置的證明。任何執行動作都被封鎖，也不能用 daemon、listener 或整合訊息代替 ETS 或 bus 證據。

核心概念

整張表只使用四種結果：「分類完成」「待授權確認」「不適用」「STOP」。它們描述審閱狀態，不描述 ETS、網路、介面或 bus 狀態。

準備與前置條件

建立一張不含實值的工作表。只放下列欄位：

• 責任類別：ETS 工程、Add-on 設定、核准、證據去識別。
• 負責角色：只寫角色，不寫人名或帳號。
• 來源狀態：固定來源、待授權確認或不適用。
• 安全分類：離線可審閱或 STOP。
• 禁止事項：programming、download、群組操作與 telegram。禁止實體控制。

不要附專案檔、畫面、匯出資料或日誌。需要權威值時，只由授權角色在受控位置核對；公開表格仍只留下分類。

分段步驟

1. 寫下審閱目的。只寫「離線責任與核准分類」。不要寫任何執行目標。
2. 分配四種責任。把 ETS 工程、Add-on 設定、核准與去識別審閱分欄。只填角色。
3. 標記來源狀態。每列只選固定來源、待授權確認或不適用。不要抄錄工程值。
4. 加入禁止分類。把 programming、download、群組讀寫與 telegram 逐項標成 STOP。禁止實體控制。
5. 檢查識別資料。確認沒有位址、名稱、端點、裝置、序號、秘密或專案內容。
6. 封閉文件結論。結果只選分類完成、待授權確認、不適用或 STOP。不要宣稱 ETS、介面或 bus 已準備完成。

驗證與證據

完成品是一張分類審閱表。另一位審閱者應能只靠分類看出責任、缺口與停止點。

• 我只用了分類完成、待授權確認、不適用與 STOP。
• 我分開 ETS 工程、Add-on 設定、核准與證據責任。
• 表內沒有個體位址、群組位址、名稱、端點、裝置、序號、秘密或專案內容。
• programming、download、群組操作與 telegram 都維持永不自動化。實體控制禁止自動化。

下一步：前往第 12 章，只在紙上整理 ETS 與 KNXnet/IP 的概念圖。

故障排除

• 不知道該填哪個值：不要找值。改填「待授權確認」。
• 有人傳來專案畫面：停止散布。公開審閱表不保留畫面或識別資料。
• 兩位負責人說法不同：標成待授權確認。不要在公開表格比較實值。
• 有人要求開啟 ETS 確認：標成 STOP。本章沒有 ETS 操作。
• 有人要求做一次讀取：標成 STOP。群組讀取仍屬永不自動化。
• 分類完成被寫成系統就緒：降級為「離線分類完成」。所有執行結果保持未證實。

常見問題

本章概覽

先說結論：你只會在紙上畫一張概念圖。它用來分清 ETS、KNXnet/IP、listener 與介面的責任。它不是設定圖，也不會帶你執行任何操作。

目的

在紙上分清 ETS、KNXnet/IP、listener 與介面的責任。

準備

第 11 章的離線審閱表與一張空白紙；不需要 ETS 或網路資料。

時間

約 15 分鐘。

系統變更

不修改 ETS、Home Assistant 或網路；只整理 KNXnet/IP 概念交接與人工審批點。

預期結果

能分清 ETS、KNXnet/IP、listener 與介面的責任，不宣稱端點可達或 ETS 成功。

停止條件

• 不得連線、探測或公開真實 KNXnet/IP 端點。
• 不得執行 ETS programming、download 或現場網路操作。

範圍與安全界線

本章只畫概念卡與責任線。不要填主機、IP、連接埠、位址、介面名稱、憑證、專案名稱或其他環境資料。不要開啟 ETS，也不要接觸網路或執行中服務。

本章不加入 repository、不安裝、不啟動。本站缺少核准的 immutable artifact／image digest 與來源到建置的證明，所以所有執行動作都被封鎖。

禁止 ETS programming／download。禁止群組讀取。禁止群組寫入。禁止 telegram 傳送。禁止實體控制。概念圖不能證明 daemon、listener、介面、網路、ETS、整合或 KNX bus 成果。

核心概念

四張卡都要加上同一句：「只有概念責任，沒有執行證據」。KNX bus 另外放在圖外，標成「本章沒有成果證據」。

準備與前置條件

準備一張紙與四張空白小卡。卡片只寫 ETS、KNXnet/IP、listener、介面。不要加入數值、名稱或設定格式。

• 紙張標題寫「紙上概念圖」。
• 每張卡加上「責任」與「不能證明」兩欄。
• 責任線只表示概念交接，不表示工作已發生。
• 在圖外寫 STOP：任何 ETS、網路、服務或 KNX 動作都停止。
• 指定另一位審閱者檢查沒有操作資訊與環境資料。

如果你真正需要的是現場資料，這張圖不能繼續。只保留需求分類，交回獨立核准流程。

分段步驟

1. 放下 ETS 卡。責任只寫「工程資料由授權角色管理」。不能證明欄寫「沒有本章操作證據」。
2. 放下 KNXnet/IP 卡。責任只寫「固定範本中的網路側語彙」。不能證明欄寫「沒有執行狀態」。
3. 放下 listener 卡。責任只寫「等待其他軟體交接的服務角色」。不要寫成目前正在工作。
4. 放下介面卡。責任只寫「資料交接邊界」。不要加入硬體、名稱或設定。
5. 畫責任線。線旁只寫「概念交接」。不要加入方向、參數或操作動詞。
6. 封閉整張圖。在下方寫「紙上概念已分類；所有執行層與 KNX bus 成果未證實」。

驗證與證據

完成品是一張只有四張卡的紙上概念圖。它說明責任詞彙，不說明任何現場狀態。

• 我有 ETS、KNXnet/IP、listener 與介面四張責任卡。
• 每張卡都分開責任與不能證明的內容。
• 圖上沒有主機、IP、連接埠、位址、介面名稱、憑證、專案或正式環境資料。
• 我沒有提供 ETS、網路、服務或 KNX 操作，也沒有宣稱 bus、整合或設備成果。

下一步：繼續前往第 13 章，對照 Home Assistant 整合與 KNXD 端的責任分工。

故障排除

• 責任線看起來像操作流程：把線旁文字改成「概念交接」，移除順序與動作。
• 有人想加入網路資料：停止。圖上不放主機、IP、連接埠或任何現場值。
• listener 被寫成正在工作：改回「固定範本中的服務角色」。執行狀態保持未知。
• ETS 卡出現畫面說明：移除。固定來源沒有支持 ETS 畫面或操作。
• 介面卡被當成硬體成果：改回資料交接責任。硬體與 bus 都維持未證實。
• 有人要求用現場動作確認：標成 STOP，不補替代方法。

常見問題

本章概覽

先說結論：你只會在紙上畫本教學的候選責任圖。圖中把 Home Assistant KNX 整合內的 xknx 邏輯、獨立的 KNXD daemon、連接介面與 KNX bus 分成五張桌子；這不是通用架構或已證實的現場路徑，也不會加入整合。

目的

用本教學的五張候選責任卡，分清各角色而不把它們畫成已證實路徑。

準備

一張空白紙與五張空白小卡；不需要 Home Assistant 或現場資料。

時間

約 15 分鐘。

系統變更

不加入或設定 Home Assistant KNX 整合；只閱讀固定來源的架構責任。

預期結果

能分清 Home Assistant KNX 整合內的 xknx 邏輯、獨立 KNXD daemon 與 KNX 側責任，並把候選拓撲及現場成果維持未證實。

停止條件

• 步驟要求加入整合、填入端點或重新載入 Home Assistant。
• 不得把版本或元件存在稱為整合已成功。

範圍與安全界線

本章只准用紙和空白小卡。不要開啟 Home Assistant、KNXD 或 ETS，不要連線、探測、重新載入或填任何環境資料。五桌圖只是一種候選責任拓撲，不是設定指示、通用分層規則或現場路徑證據。

不加入 repository、不安裝、不啟動。這些動作只有在實體隔離、書面核准，以及核准的 immutable artifact／image digest 與 source-to-build attestation 全部具備時才可另案評估；本章不提供這些條件。

不得自動化群組讀取。不得群組寫入。不得傳送 telegram。不得執行 ETS programming／download。不得實體控制。紙上圖不能證明 KNXD、介面、KNX bus、ETS 或 Home Assistant 整合有任何成果。

核心概念

五張桌子都要寫「狀態彼此獨立；排列不是通用路徑」。文件或元件存在，只能支持名稱與責任，不能支持載入、連線、傳輸或控制結果。

準備與前置條件

你只要準備一張無實值工作紙。畫五個空框，另留「來源支持」與「不能證明」兩欄。

• 五張卡只寫角色名稱，不寫主機、位址、連接埠、秘密、專案或裝置資料。
• 每張卡都先填「狀態未知」。
• 候選關係線只寫「概念責任」，不畫方向、不寫參數，也不暗示整合必須經過 KNXD。
• 指定另一位審閱者檢查沒有設定步驟與成果暗示。
• 若有人要求現場資訊，立即停止紙上流程並移交核准程序。

分段步驟

完成後只會得到一張紙上架構圖。

1. 放下整合桌。寫「管理 Home Assistant 內的整合責任」，並補上「沒有加入或載入證據」。
2. 放下邏輯桌。寫「xknx library／KNX 邏輯位於 Home Assistant KNX 整合邊界內」，並補上「宣告相依不等於已運作」。
3. 放下 KNXD 桌。寫「獨立 KNXD daemon；不是 Home Assistant KNX 整合固有層」，不要把 daemon 或 listener 狀態帶入圖中。
4. 放下介面桌。寫「守住交接邊界」，不要加入介面種類、名稱或現場狀態。
5. 放下 bus 桌。寫「現場網路責任；本章沒有成果證據」。
6. 標記候選關係。不用方向箭頭；每條線只標「本教學候選責任」，最後寫「不是通用或已證實路徑；沒有設定、連線或成果主張」。

驗證與證據

合格成果是五張責任卡，不是系統圖的實作證明。你應能指出每張卡負責什麼，也能說出它不能替哪一張卡作證。

• 我有五張分開的責任卡，且每張卡的狀態都是未知。
• 我能說明 xknx library／邏輯位於 Home Assistant KNX 整合邊界內。
• 我把獨立 KNXD daemon 與 Home Assistant KNX 整合分開，且沒有把 KNXD 畫成固有層。
• 我把介面與 KNX bus 分開，也把五桌標成非通用、未證實的候選責任拓撲。
• 圖上沒有任何環境資料、設定形狀、操作步驟或成果主張。
• 我沒有執行 ETS 或 Home Assistant 整合操作。我不得執行群組動作，不得傳送 telegram，也不得實體控制。

下一步：前往第 14 章，把設定需求整理成離線占位工作表。

故障排除

• xknx 與 KNXD 看起來是同一件事：把前者改寫成「整合邊界內使用的 library／邏輯」，後者改寫成「獨立 daemon，不是整合固有層」。
• 箭頭看起來像執行流程：移除方向與動詞，只保留「本教學候選責任；非通用或已證實路徑」。
• 元件存在被寫成已運作：退回「固定來源有此角色；執行狀態未知」。
• 有人想加入連線資料：停止。紙上圖不收環境資料。
• 有人要求加入整合確認：停止。本章沒有設定或測試授權。
• 有人想用 bus 動作驗證：拒絕。不得自動化群組動作，不得傳送 telegram，也不得實體控制。

常見問題

本章概覽

先說結論：你只會做一張離線設定工作表。表內只有占位文字、資料分類與審閱狀態，不會出現可套用的設定、真實值或連線位置。

目的

建立只有占位符與分類的 Home Assistant KNX 離線設定工作表。

準備

一張空白工作表與第 13 章的紙上責任圖；不需要開啟 Home Assistant。

時間

約 20 分鐘。

系統變更

不儲存 Home Assistant KNX 設定；只用占位資料建立離線設定檢核表。

預期結果

能辨認設定責任與變更前閘門，不填入真實端點，並把連線與整合成果維持未證實。

停止條件

• 需要輸入真實主機、端點、位址、秘密或裝置資料。
• 步驟要求儲存設定、重新載入整合或測試連線。

範圍與安全界線

工作表不能拿去執行。不要開啟執行中的 Home Assistant，不要提供 YAML、API、可貼上的欄位形狀、連線位置或任何實際值。

不加入 repository、不安裝、不啟動。只有實體隔離、書面核准，以及核准的 immutable artifact／image digest 與 source-to-build attestation 都齊全時，才能在本章之外另案評估；本章不提供授權。

禁止自動化群組讀取、群組寫入、telegram 傳送、ETS programming／download 與實體控制。離線工作表不證明 KNXD、KNX bus、ETS 或 Home Assistant 整合有任何成果。

核心概念

工作表的結論上限是「欄位責任可供人工審閱」。它不表示 Home Assistant 能接受任何設定，也不表示連線、整合或 bus 有結果。

準備與前置條件

先畫表頭，不填內容值。表頭只使用下列治理分類。

• 需求名稱：只寫一般用途，不寫環境名稱。
• 責任角色：記錄由哪種角色提供或審閱，不寫個人資料。
• 語意占位符：固定寫「待授權角色補充」。
• 資料分類：從可公開、受控、秘密、未知中擇一。
• 來源邊界：分開記錄文件快照與 Core 版本中繼資料。
• 審閱狀態與停止理由：只記分類，不記執行結果。

只要某一格需要真實資料或可執行形狀，立即停止。不要從舊檔、畫面、記憶或網路文章補入。

分段步驟

每一步都只處理紙上分類。

1. 寫工作表標題。註明「離線占位工作表；不可匯入、不可貼入、不可執行」。
2. 建立需求列。只用連線責任、整合責任、資料模型責任與核准責任等一般分類，不模仿設定欄位。
3. 加入占位文字。每列只填「待授權角色補充」，不要加入格式提示、預設值或示範值。
4. 加入資料分類。標出可公開、受控、秘密或未知；受控、秘密與未知都不得補入公開工作表。
5. 分開來源欄。分別記下文件快照支持的概念與 Core 版本中繼資料支持的登錄邊界，不寫成相容保證。
6. 做離線複查。確認沒有 YAML、API 形狀、連線位置、實際值或操作句，最後交給另一位審閱者。

驗證與證據

完成標準是安全地留下空白，不是把表格填滿。你要能從每列看出責任、分類、來源與停止理由。

• 工作表明確標成離線且不可執行。
• 每列只有一般需求、責任角色、占位文字與分類。
• 文件快照與 Core 版本中繼資料分開記錄。
• 沒有 YAML、API 形狀、連線位置、主機、位址、秘密、裝置資料或實際值。
• 沒有儲存、重新載入、測試連線或成果主張。

下一步：前往第 15 章，用標籤卡整理實體模型。

故障排除

• 占位符看起來像真實值：全部改回「待授權角色補充」。
• 工作表像可貼上的設定：移除層級、語法、資料形狀與欄位順序，只保留治理分類。
• 來源被寫成同一版本：拆成兩列，分別說明支持範圍與不能證明的事項。
• 有人要求查看執行中設定：停止離線流程，移交明確核准的唯讀範圍評估。
• 有人要求測試連線：停止。本章不提供測試或執行授權。
• 空白被誤認為遺漏：補上停止理由，不要猜值。

常見問題

本章概覽

先說結論：你只會用標籤卡分清 Home Assistant entity、KNX 個體位址與群組位址的角色。每張卡只記欄位角色與分類，不放值、映射、payload、服務呼叫或控制例子。

目的

用檔案卡分清 entity、個體位址與群組位址的角色，不記值或映射。

準備

幾張空白卡與第 14 章的離線工作表；不需要 Home Assistant 或 KNX 資料。

時間

約 20 分鐘。

系統變更

不建立 Home Assistant 實體或群組設定；只離線整理實體模型。

預期結果

能說明實體、個體位址與群組位址不可互換，且本章只記欄位角色與分類，不記值或映射。

停止條件

• 需要提供或猜測真實個體位址、群組位址或家庭裝置資料。
• 不得建立實體；不得群組讀寫；不得傳送 telegram；不得實體控制。

範圍與安全界線

卡片只放概念標籤。不要放識別字串、位址值、對應值、映射、資料內容、payload、設定形狀、控制或服務呼叫，也不要舉任何實體設備的控制情境。

不加入 repository、不安裝、不啟動。只有實體隔離、書面核准，以及核准的 immutable artifact／image digest 與 source-to-build attestation 全部具備時，才能在本章之外另案評估；本章不提供授權。

不得自動化群組讀取。不得群組寫入。不得傳送 telegram。不得執行 ETS programming／download。不得實體控制。卡片不能證明 Home Assistant 實體、整合、KNX bus、ETS 或設備有任何成果。

核心概念

即使標籤文字很清楚，也不能由名稱猜出現場值、映射、資料方向、型別或狀態。缺少授權證據時，一律保留「待確認」。

準備與前置條件

每張空白卡只畫四格。不要模仿 Home Assistant 或 KNX 的設定畫面。

• 用途標籤：只寫一般軟體用途。
• 資料語意：只寫「待來源確認」。
• 欄位角色：只寫 entity、device 身分或共享通訊主題的分類；不記任何對照。
• 證據狀態：只用待確認、固定來源支持或不適用。
• 卡片頁尾：寫「不可匯入、不可呼叫、不可控制」。

如果一般用途也會透露家庭、房間、人員或裝置資訊，就換成更抽象的標籤。你不需要為了讓卡片看起來完整而增加例子。

分段步驟

完成品是離線分類卡，不是實體清單。

1. 建立用途卡。每張卡只放一個一般用途，避免家庭、房間、設備或人員名稱。
2. 加入資料語意格。寫這個模型需要哪一類意義；固定來源沒有支持時就寫「待來源確認」。
3. 加入欄位角色格。只分類為 entity、device 身分或共享通訊主題角色，不寫任何值、映射、方向、內容或格式。
4. 加入證據狀態格。把文件概念與 Core 版本中繼資料分開標示，不把兩者寫成執行證據。
5. 做去識別檢查。移除識別字串、家庭情境、payload、呼叫、設定形狀與任何控制暗示。
6. 封存卡片。在整疊卡上寫「僅供紙上審閱；實體、整合與 bus 狀態未知」。

驗證與證據

一眼能分清 entity、device 身分、共享通訊主題與證據，就算完成。任何需要猜測的格子都應維持待確認。

• 我能說明 entity 是面向使用者的檔案卡／語意物件、個體位址是一個 KNX device 的身分、群組位址是 KNX 設計使用的共享通訊主題。
• 我知道三者不可互換，每張卡只記用途、資料語意、欄位角色與證據狀態。
• 所有用途都是去識別的一般標籤。
• 卡片沒有位址值、映射、識別字串、payload、服務呼叫、設定形狀或控制例子。
• 名稱沒有被當成資料方向、型別或現場狀態證據。
• 我沒有建立實體。我不得執行群組操作，不得傳送 telegram，也不得控制設備。

下一步：前往第 16 章，在任何動作發生前先做安全分類。

故障排除

• 標籤像現場名稱：改成一般用途，移除家庭、空間、設備與人員線索。
• 有人想從名稱猜資料意義：改寫為「待來源確認」。名稱不是型別證據。
• 欄位角色格出現值、映射或方向：立即移除，只保留 entity、device 身分或共享通訊主題的分類。
• 卡片看起來可匯入：移除設定形狀與順序，補上不可執行標示。
• 有人要求服務呼叫或控制例子：拒絕。本章只處理離線模型。
• 畫面狀態被當成 bus 證據：退回軟體觀察；本章沒有任何現場成果。

常見問題

本章概覽

先說結論：任何事情都先分類，這一章不執行測試。你會把提案分成安全、隔離測試、需核准、永不自動化四類；閘門不完整就停在紙上。

目的

在任何動作發生前，用四類矩陣判斷提案能否繼續。

準備

一張空白分類票與提案的無實值文字描述；不需要測試環境。

時間

約 20 分鐘。

系統變更

不執行現場測試；只把測試案例離線分成證據與安全類別。

預期結果

能分辨安全、隔離測試、需核准與永不自動化四類，並把所有環境成果保持為未證實。

停止條件

• 不得連接 KNX bus；不得傳送 telegram；不得群組讀寫；不得實體控制。
• 隔離、書面核准、停損或回復證據不完整。

範圍與安全界線

分類票不是執行許可。本章不連線、不啟動、不重新載入、不變更，也不收集現場結果。提案含多個動作時，必須拆開，並採其中最嚴格的類別。

• 安全：只限離線唯讀固定來源，或完全不存取執行環境的占位工作；不得啟動 daemon、接觸端點或裝置，也不得傳送 KNX telegram。
• 隔離測試：只可在另案已有明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫時評估。實體隔離測試 bus 僅限另行核准且確實需要它的演練；只做生命週期演練時，所有 KNX 介面、USB／裝置映射、實體 bus、正式 KNX 網路、ETS 專案與實體負載都必須斷開。缺一項就不能進入。
• 需核准：任何查看或變更執行中環境的提案，都要先有明確書面核准、限定維護範圍與資料去識別。即使只對 live／running 環境做唯讀查看，也屬需核准，不會自動成為安全；此類不得傳送 KNX telegram，不得執行 ETS 動作，也不得實體控制。
• 永不自動化：教材或自動化在任何情況下都不得群組讀取，不得群組寫入，不得傳送 telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，不得收集或發布環境識別資料，也不得實體控制；測試 bus 也不例外。沒有任何閘門可改變此分類。

加入 repository、安裝或啟動還必須同時具備隔離測試全部閘門，以及核准的 immutable artifact／image digest 與 source-to-build attestation。條件不完整就停止；本章不執行這些動作。

核心概念

證據也有上限。文件只證明文件內容；核准只證明範圍獲准；隔離計畫只證明準備條件。它們都不證明 daemon、listener、KNX bus、ETS 或 Home Assistant 整合有成果。

準備與前置條件

先做一張完全離線的分類票。任何欄位不明，就寫「未知並停止」。

• 目的與非目標：用一句話寫要回答什麼，以及明確不碰哪些系統。
• 原子動作：每列只能有一個離線閱讀、live／running 環境查看、變更或傳送類動作；不可把兩種閱讀混為安全。
• 環境邊界：寫離線、隔離候選或執行中環境，不填識別資料。
• 核准證據：寫核准角色、範圍與期限；口頭同意不算。
• 隔離證據：寫實體隔離、非正式設備、無實體負載與正式環境斷開。
• 停損與還原：先寫觸發條件、基準、責任角色與升級方式。
• 證據上限：先寫完成後最多能說什麼，以及一定不能說什麼。

分段步驟

走完流程仍然不會執行任何動作。

1. 寫下最小問題。移除預設現場成果的句子，只留下要審閱的問題。
2. 拆成原子動作。把閱讀、查看、變更、啟動與傳送分列；沒有拆清楚就停止。
3. 先抓永不自動化。不得群組讀寫，不得傳送 telegram，不得執行 ETS programming／download，也不得實體控制；任何一項出現時，都標記永不自動化並移除。
4. 判斷需核准。凡是查看或變更 live／running 環境，都標成需核准；唯讀查看也不例外。缺少明確書面核准、限定範圍或去識別計畫就停止。
5. 檢查隔離測試閘門。逐項核對明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫。只做生命週期演練時，所有 KNX 介面、裝置映射、實體 bus、正式網路、ETS 專案與實體負載均列為保持斷開；加入、安裝或啟動另需核准的 immutable provenance。
6. 確認安全類。只有離線唯讀固定來源，或完全不存取執行環境且沒有副作用的占位工作，才可標成安全。
7. 封存分類票。記下停止理由、證據上限與未決項目，並標明「尚未執行」。

驗證與證據

合格的分類票能在執行前阻止錯誤動作。它不包含命令、測試程序或執行結果。

• 每個原子動作只有一個四類標籤，衝突時採更嚴格類別。
• 安全類全部是離線唯讀固定來源，或完全不存取執行環境且無副作用的占位工作。
• 隔離測試的明確核准、非正式環境、管理員、有限網路暴露、斷開條件、停損與還原閘門逐項可見。
• 需核准類有明確書面核准、限定範圍與去識別要求；live／running 環境的唯讀查看也列在此類。
• 永不自動化事項已移除，沒有指令或替代測試方法。
• 所有環境、bus、ETS 與 Home Assistant 整合成果都維持未證實。

下一步：前往第 17 章，整理備份與還原的紙上治理界線。

故障排除

• 一列同時像兩種類別：拆成更小動作，並先套用較嚴格類別。
• 只有口頭同意：視為沒有核准，保持停止。
• 只有邏輯隔離：不能算隔離測試；必須符合 canonical 隔離閘門。只做生命週期演練時，所有 KNX 介面、裝置映射、實體 bus、正式網路、ETS 專案與負載都要斷開。
• 沒有還原基準：不得進入任何變更候選，先補紙上計畫。
• 加入或安裝缺少 provenance：停止，不加入 repository、不安裝、不啟動。
• 有人想把禁止動作改成手動腳本：拒絕。換工具不會改變永不自動化分類。
• 分類票開始出現測試結果：移除結果。本章只做執行前分類。

常見問題

本章概覽

先說結論：你先在紙上定義要保存的資料類別、還原負責角色與安全證據索引。你不會在本章建立備份，也不會按下任何備份或還原按鈕。

目的

定義備份範圍、還原責任與不含環境實值的證據索引。

準備

一張空白工作表與固定來源；不需要開啟專案或執行環境。

時間

約 20 分鐘。

系統變更

不建立或還原真實環境備份；只整理去識別的離線備份與還原演練清單。

預期結果

能定義備份範圍、保管責任、檢查與還原閘門，不把備份存在視為可還原證明。

停止條件

• 備份或紀錄含秘密、環境識別資料或未核准內容。
• 步驟要求在真實環境執行備份還原或覆寫狀態。

範圍與安全界線

本章只有離線紙上工作。你只讀固定來源，並用「資料類別」與「責任角色」填表。任何執行中環境的唯讀查看都是 approval-required 需核准，不會因為沒有變更就成為 safe 安全。

• safe 安全：只限離線唯讀固定來源，或完全不存取執行環境的占位分類。
• isolated-test 隔離測試：只有另案具備明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫，才可評估；本章不進入此類。
• approval-required 需核准：查看或變更 live／running 環境都屬此類；唯讀也一樣。本章不提供這類程序。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還必須先有完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺一項就停止；本章不執行這些動作。

核心概念

備份負責角色管理保存與期限。還原負責角色決定何時可進入另案演練。獨立覆核角色檢查範圍、證據上限與隱私。三項責任不能用「有人負責」帶過。

準備與前置條件

先準備一張不含實值的空白索引。每個欄位只填類別、角色或狀態。

• 目的欄：只寫保存、稽核或復原規劃，不預設已能還原。
• 範圍欄：列資料類別、排除類別與保留政策，不列專案名稱或內容。
• 責任欄：列建立、保管、還原決策、獨立覆核與例外核准角色。
• 證據欄：列來源版本、建立紀錄類別、完整性狀態、覆核狀態與證據缺口。
• 隱私欄：確認沒有秘密、帳號、端點、主機、網路、路徑、序號、位址、範圍或環境名稱。

時間資料規則：不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。

固定來源沒有精確的 ETS 專案備份或還原程序。因此，程序、格式、相容性與還原結果都要標為未驗證。

分段步驟

以下六步只整理紙上治理資料。你不會開啟正式專案，也不會建立、匯入或覆寫任何內容。

1. 寫下保存目的。用一句話說明為何需要備份治理，並寫明本章不執行備份或還原。
2. 圈出備份範圍。只列需要保存與必須排除的資料類別。不要填任何真實值。
3. 分配責任。分別指定保管、還原決策、獨立覆核與例外核准角色。再寫保留政策與交接條件。
4. 建立安全索引。為每個保存類別記錄狀態、來源版本、保留政策與證據上限。以「已遮蔽」或「待驗證」代替內容實值。
5. 標記證據上限。把「副本存在」「離線完整性紀錄」與「可回復能力」分列。前兩項不能替最後一項背書。
6. 交給獨立覆核。確認索引沒有識別資料，也沒有把待驗證事項寫成成果。缺一項就退回修正。

填寫期限時：不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。

驗證與證據

完成標準是索引可安全審查，不是環境已可還原。

• 保存目的、包含類別與排除類別都清楚，而且沒有環境實值。
• 保管、還原決策、獨立覆核與例外核准各有責任角色。
• 證據索引只含類別、狀態、保留政策與來源版本。
• 不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。
• 治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。
• 副本存在與離線完整性沒有被寫成還原成功。
• 精確備份程序、相容性與還原結果仍標為未驗證。
• 所有環境、KNX bus、ETS 與整合成果都維持未證實。

下一步：前往第 18 章，用離線工作表檢查最小暴露。

故障排除

• 範圍寫得像內容清單：改成資料類別，移除名稱、位置與值。
• 找不到還原負責角色：保持未指派並停止。不要把保管角色自動當成還原決策角色。
• 副本存在被寫成可回復：把結論降回「存在紀錄」，並把解析、相容與回復標成未驗證。
• 索引含敏感資訊：停止分享並撤回副本。重新最小化後交給不同角色覆核。
• 有人要求操作畫面：拒絕。本章沒有 live 備份或還原點擊程序。
• 有人要求加入或啟動工具：停止。缺少核准的 immutable provenance 閘門時，不加入、不安裝、不啟動。

常見問題

本章概覽

先說結論：你只用離線工作表檢查秘密、權限、網路暴露與核准紀錄。你不會修改防火牆、憑證、帳號、網路或執行中系統。

目的

找出最小暴露治理中的四類缺口，並為每項缺口指定責任與停止狀態。

準備

一張四欄空白工作表與固定來源；不要收集正式環境值。

時間

約 15 分鐘。

系統變更

不修改權限、秘密或網路；只完成離線最小暴露檢核。

預期結果

能找出權限、秘密、網路暴露與核准流程的缺口，不公開現場資料。

停止條件

• 需要揭露憑證、token、端點、帳號或網路拓撲。
• 步驟要求放寬權限、開放網路或停用安全控制。

範圍與安全界線

工作表不是變更許可。safe 安全只限離線唯讀固定來源，或完全不存取執行環境的占位分類。任何 live／running 環境的唯讀查看都是 approval-required 需核准。

• safe 安全：只整理欄位類別、責任角色與缺口狀態，不讀取現場內容。
• isolated-test 隔離測試：必須另案具備明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫；本章不進入。
• approval-required 需核准：任何查看或變更執行中環境的提案都屬此類，即使只做唯讀查看也一樣。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還需要完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺少任一證據就停止。

核心概念

秘密可以直接授權存取。環境識別資料則會暴露資產關係。兩者都不能進入公開教材、截圖、日誌片段、工單或提交紀錄。

準備與前置條件

先畫四欄，不要先收集資料。欄名是秘密、權限、網路暴露與核准紀錄。

• 每欄都有需求、擁有角色、核准狀態、期限政策、撤銷方式與證據上限。
• 秘密欄只寫「存在」「未進入紀錄」「待受控覆核」，不抄錄任何值。
• 權限欄只寫讀取、變更、核准或覆核等能力類別，不填帳號或人名。
• 網路欄只寫信任邊界類別、需求與期限政策，不填主機、位址、端點或拓撲。
• 核准欄只寫核准角色、受控紀錄參照、範圍與抽象到期狀態，不放簽章或私人證明。

時間資料規則：不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。

出現秘密、環境識別、來源不明、要求擴權或要求修改安全控制時，立即停止工作表流程。

分段步驟

這份審查只會產生缺口清單。它不會產生設定、命令或現場結果。

1. 先寫必要目的。每一列只回答一個需求。無法說明目的的項目標為待移除風險。
2. 檢查秘密欄。確認公開紀錄只顯示秘密處理狀態。任何秘密值出現都停止分享。
3. 檢查權限欄。把讀取、變更、核准與覆核分開。沒有期限政策、撤銷方式或擁有角色的能力都列為缺口。
4. 檢查網路暴露欄。用信任邊界類別描述必要接觸面。沒有目的、擁有角色或期限政策的暴露都列為缺口。
5. 檢查核准紀錄欄。確認每項例外都有範圍、核准角色、期限政策、撤銷條件與受控紀錄參照。
6. 做獨立覆核。由不同角色檢查四欄與資料最小化。結論只寫「完整」「有缺口」或「因資料不足停止」。

填寫期限時：不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。

驗證與證據

合格結果是一張去識別的治理清單。它不表示正式環境已套用任何限制。

• 秘密欄沒有憑證、token、session、密碼、cookie 或可還原連線資訊。
• 權限欄把讀取、變更、核准與覆核分開，並記錄期限政策與撤銷責任。
• 網路暴露欄只含需求、信任邊界類別、擁有角色與期限政策。
• 每項例外都有核准角色、範圍、抽象到期狀態與撤銷條件。
• 紀錄沒有主機、端點、帳號、路徑、序號、位址、拓撲或環境名稱。
• 不得填環境／事件時間戳、日誌時間戳、備份建立時間、執行時間，或任何可關聯家庭活動／系統事件的時間。
• 治理確有需要，而且資料不是從 live 事件衍生、不能識別環境時，才可使用經覆核的正規化政策截止日或抽象到期狀態；不需要精確日期時，優先使用「未到期」「待續核」「已到期」等相對／狀態分類。
• 所有現場控制、執行環境、bus、ETS 與整合成果都維持未證實。

下一步：前往第 19 章，把文件中的鏈路症狀放進離線分流表。

故障排除

• 欄位需要真實值才能填：改記資料類別與「需受控覆核」。不要把值帶進工作表。
• 權限找不到擁有角色：標為治理缺口並停止新增權限。
• 網路暴露沒有期限政策：標為不完整。不要用永久開放替代缺少的決策。
• 只有口頭核准：視為沒有核准，保持停止。
• 有人要求修改防火牆或憑證：拒絕。本章是 offline worksheet，不提供 firewall、credential 或 live system change procedure。
• 遮蔽後仍可辨認環境：移除更多上下文，或改用純文字類別摘要。

常見問題

本章概覽

先說結論：你只把固定文件中的症狀概念放進離線分流表。你不會重啟服務、試換 driver、探測 endpoint、連接 bus 或發布任何先前內部錯誤。

目的

依鎖定文件把鏈路症狀分層，並限制每一類證據能支持的結論。

準備

一張空白症狀分流表與兩份固定來源；不需要日誌或執行環境。

時間

約 20 分鐘。

系統變更

不重啟服務或連接 bus；只用去識別證據離線分類鏈路失敗。

預期結果

能按程序、listener、driver、介面與 bus 層級分類症狀，不把診斷嘗試寫成成功。

停止條件

• 步驟要求重新啟動 driver、服務、介面或 KNX 連線。
• 日誌仍含主機、端點、裝置路徑、序號或秘密。

範圍與安全界線

本章只分類文件，不分類現場。safe 安全只限離線唯讀固定來源，或完全不存取執行環境的占位分類。任何 live／running 環境的唯讀查看都是 approval-required 需核准。

• safe 安全：只閱讀鎖定的 Add-on 與 upstream 文件，並抄錄抽象症狀類別。
• isolated-test 隔離測試：另案必須先有明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫；本章不進入。
• approval-required 需核准：查看或變更執行中環境都屬此類；即使唯讀也不是安全。本章不提供觀測程序。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還必須先有完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺少任何一項就停止。

核心概念

程序層詞彙只能說明程序概念。listener 層詞彙只能說明監聽責任。driver 家族與文件化啟動失敗只能界定驅動文件範圍。介面與 bus 結果都不在本章證據內。

準備與前置條件

只準備兩份鎖定文件與一張空白表。不要帶入內部日誌、截圖或記憶中的錯誤。

• 來源欄只記固定來源識別與版本邊界，不記本機資料。
• 層級欄使用程序、listener、driver、介面與 bus 五類。
• 症狀欄只寫文件中的抽象狀態概念，不寫曾在某環境看到什麼。
• 證據上限欄先寫「只能支持文件分類，不能支持本地結果」。
• 停止欄寫來源不明、跨層推論、要求現場動作或出現識別資料。

早期內部鏈路錯誤不是本章公開結果。即使文字已遮蔽，也不能把它改寫成本站曾觀測、曾重現或曾驗證。

分段步驟

以下流程只做文件分類。每一步都停在紙上。

1. 鎖定來源。確認症狀概念來自本章列出的固定版本。來源不明就停止。
2. 選一個層級。依文件責任把概念放進程序、listener、driver、介面或 bus 欄。資訊不足就標成未分類。
3. 寫下證據上限。程序詞彙不能證明 listener；listener 詞彙不能證明 endpoint；driver 詞彙不能證明介面或 bus。
4. 列出未知項目。把相容性、硬體、接線、端點可達與 bus 狀態保持為未知，不選一個看起來合理的根因。
5. 排除內部結果。刪除任何「曾看到」「曾重現」「本機顯示」或類似敘述，只保留文件支撐的抽象分類。
6. 交給獨立覆核。確認每列都有來源、層級、證據上限與未知項目，而且沒有現場動作提示。

驗證與證據

完成結果只能是文件症狀分類表。本站沒有本地觀測來源，也沒有本地鏈路結果。

• 每個症狀概念都能對應固定來源與單一主要層級。
• 程序、listener、driver、介面與 bus 沒有被混成一個成功或失敗結論。
• 每列都清楚寫出能支持什麼，以及不能支持什麼。
• 硬體、接線、相容性、endpoint 可達與 bus 狀態都保持未知。
• 早期內部錯誤沒有被發布成觀測、重現或驗證結果。
• 表內沒有主機、端點、路徑、序號、帳號、秘密、位址、範圍或時間。

下一步：前往第 20 章，繼續整理 USB 與序列介面的離線故障分類。

故障排除

• 一個症狀像兩層：分成兩列，或標成未分類。不要用猜測選根因。
• 只有一般錯誤字樣：保留為未分類，等待精確文件證據。
• 有人貼入內部錯誤：移出公開表格，停止分享，並回到受控內部流程。
• 有人要求重新啟動：拒絕。本章沒有 restart procedure。
• 有人要求切換 driver 或探測 endpoint：拒絕。本章沒有 driver trial 或 endpoint probe procedure。
• 有人要求連接或測試 bus：拒絕。本章沒有 bus procedure，也不得以 telegram 或實體控制驗證。
• 分類文字洩漏環境：移除該列，改用來源中的抽象概念重新建立。

常見問題

本章概覽

先說結論：你只用不含現場值的三類症狀卡，離線判斷證據是「缺少候選項目」「候選路徑類別改變」或「driver 類別線索」。你不會查看裝置清單、抄錄路徑或序號，也不會試 driver、重啟或碰觸 bus。

目的

用三類匿名症狀完成 USB／序列介面的離線決策樹。

準備

一張空白三分支工作表與固定來源；不需要 USB 裝置、日誌或執行環境。

時間

約 20 分鐘。

系統變更

不存取或重啟 USB／序列介面；只整理去識別的離線故障分類。

預期結果

能區分裝置缺失、路徑變動與 driver 失敗證據，不宣稱介面或硬體可用。

停止條件

• 不得抄錄真實裝置路徑、USB 序號或主機資料。
• 步驟要求插拔硬體、載入 driver、重啟服務或連接 bus。

範圍與安全界線

本章只整理匿名症狀卡。safe 安全只限離線唯讀固定來源，或完全不存取執行環境的占位分類。任何 live／running 環境的唯讀查看都是 approval-required 需核准，本章不提供查看方式。

• safe 安全：閱讀鎖定來源，建立「缺少候選項目」「候選路徑類別改變」「driver 類別線索」三種空白卡。
• isolated-test 隔離測試：另案必須先有明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫；本章不進入。
• approval-required 需核准：查看或變更任何執行中環境都屬此類；核准唯讀不等於核准嘗試或修正。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還必須先有完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺少任何一項就停止。

核心概念

Add-on 0.6.1 的初始化來源可說明需要裝置的介面、USB 值轉換與設定準備責任；upstream 0.14.72 文件可說明 driver 家族與文件化診斷概念。兩份來源都不能提供某台主機的候選項目、路徑、序號或結果。

準備與前置條件

先畫決策樹，不要先找裝置。根節點只問「現有的去識別敘述屬於哪種症狀」，三個分支之外一律標為「資訊不足」。

• 缺少候選項目卡：只寫「預期類別未形成候選」；不寫候選內容、枚舉結果或出現位置。
• 候選路徑類別改變卡：只寫「參照類別與原紀錄不同」；不寫舊值、新值或裝置關係。
• driver 類別線索卡：只寫固定文件中的責任類別；不列試用順序、相容型號或載入方法。
• 未知卡：資訊混合、來源不明或需要現場值時，停止分類並保留未知。

工作表不得包含裝置路徑、USB 序號、主機、端點、位址、帳號、秘密、環境名稱或可關聯現場的時間。若手邊材料含這些內容，不要複製；交回受控隱私流程處理。

分段步驟

每一步都只處理離線文字。你不需要讓系統回答任何問題。

1. 確認來源邊界。只接受鎖定版本所描述的初始化責任與 driver 文件概念。沒有來源就標成資訊不足。
2. 移除現場成分。只保留「缺少」「參照類別不同」或「driver 責任類別」等抽象敘述；材料仍可識別環境就停止。
3. 走第一個分支。若敘述只說預期類別未成為候選，放入缺少候選項目卡；不要補猜硬體、權限或原因。
4. 走第二個分支。若敘述只說參照類別前後不同，放入候選路徑類別改變卡；不要記任何舊值、新值或列舉方式。
5. 走第三個分支。若敘述只能對應文件中的 driver 責任或失敗概念，放入 driver 類別線索卡；不要產生試用建議。
6. 限制結論。每張卡都寫「只支持文件分類；所有現場可用性均未證實」。
7. 獨立覆核。由另一位讀者確認分支單一、來源固定、沒有識別值，也沒有命令、枚舉、試換、重啟或 bus 動作。

驗證與證據

完成品是一張匿名離線決策樹。它不是診斷結果，也不表示任何裝置曾被查看、偵測或驗證。

• 根節點只接受固定來源支持的去識別症狀敘述。
• 三個分支恰為缺少候選項目、候選路徑類別改變與 driver 類別線索。
• 每張卡都有來源類別、症狀類別、證據上限、未知事項與負責角色。
• 沒有裝置路徑、USB 序號、主機、端點、位址、環境名稱或可關聯時間。
• 沒有命令、裝置枚舉、driver 試用、硬體插拔、服務重啟或 bus 動作。
• USB、序列介面、driver、KNX bus、ETS、整合、群組與實體控制結果都維持未證實。

下一步：前往第 21 章，把離線來源審閱、核准界線與證據註記排成受控維運節奏。

故障排除

• 敘述同時像缺少與改變：標為資訊不足，不替它選根因。
• 只有「USB 壞了」：這是結論，不是可分類症狀；退回要求匿名症狀類別。
• 有人提供真實路徑或序號：停止複製與分享，交回受控隱私流程。
• 有人要求列出裝置：拒絕。本章沒有 enumeration 或現場查看程序。
• 有人建議輪流試 driver：拒絕。driver 家族名稱不是試用清單。
• 有人建議插拔或重啟：拒絕。本章不觸發硬體或服務動作。
• 有人想用 bus 證明分類：拒絕。本章不得連接、讀寫或傳送任何 bus 資料。

常見問題

本章概覽

先說結論：你只建立一張離線變更紀錄，依序寫來源審閱、核准、觀察界線、停止、還原決策與證據註記。這張紀錄不會提供命令，不會繞過核准，也不會讓你操作執行中系統。

目的

用六格離線紀錄建立可停、可交接、不可繞過核准的維運節奏。

準備

一張六格空白變更紀錄與固定來源；不要帶入執行環境資料。

時間

約 20 分鐘。

系統變更

不套用設定或啟停服務；只建立離線變更紀錄與人工閘門。

預期結果

能記錄核准、觀察、停損、回復與證據層級，不把維護窗口視為操作授權。

停止條件

• 完整隔離、書面核准、immutable artifact/image digest 或 source-to-build attestation 任一缺少。
• 不得接受要求群組操作、telegram、ETS 動作或實體控制的步驟。

範圍與安全界線

紀錄節奏不是操作許可。safe 安全只限離線唯讀固定來源，或完全不存取執行環境的占位紀錄。任何 live／running 環境的唯讀查看都是 approval-required 需核准；有核准也只能停在核准的資料類別與範圍。

• safe 安全：審閱鎖定來源、設計空白欄位、標記證據層級與責任角色。
• isolated-test 隔離測試：另案必須先有明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫；本章不進入。
• approval-required 需核准：查看或變更 live／running 環境都屬此類；唯讀核准不包含修改、提升權限或擴大資料範圍。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還必須先有完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺少任何一項就停止。

核心概念

Add-on 0.6.1 的受管 INI 範本、初始化腳本與服務腳本，只能說明來源結構、設定準備與 daemon 叫用責任。它們不是部署紀錄，也不能證明 listener、KNX bus、ETS、Home Assistant 或硬體狀態。

準備與前置條件

先建立六個空格，全部預設為停止。欄位沒有合格內容時，不得以維護窗口、慣例、口頭同意或管理權限補足。

• 來源審閱：記固定來源、版本邊界與來源最多能支持的結論。
• 核准：記核准角色、目的、資料類別、期限政策與受控紀錄參照，不記姓名或環境識別。
• 觀察界線：只列允許與不允許的資料類別；live 唯讀仍必須另有明確核准。
• 停止：列出範圍不明、需要變更、識別資料出現或核准失效等停止狀態。
• 還原決策：只記決策角色、獨立核准需求、停損前提與受控計畫參照。
• 證據註記：分開來源事實、核准後觀察、推論與未知，不貼原始內容。

不得填環境或事件時間、日誌時間、裝置路徑、主機、端點、位址、序號、帳號、秘密或現場名稱。治理若需要期限，使用經覆核的抽象狀態，例如「有效」「待續核」或「已失效」。

分段步驟

六格只能依序離線填寫。任何一格不完整，就在該格停止並交回負責角色。

1. 完成來源審閱。把受管範本、初始化責任與 daemon 叫用責任分開記錄；不把來源內容當成現場設定。
2. 檢查核准狀態。只確認是否有受控紀錄、負責角色、目的、資料類別與有效狀態。缺一項就標為未核准，不建立替代路徑。
3. 畫出觀察界線。以抽象資料類別說明允許範圍與明確排除項。若提案涉及 live 唯讀，仍標為 approval-required，且本章不提供讀取方式。
4. 套用停止規則。只要提案需要寫入、套用、啟停、提升權限、連線、硬體接觸或 ETS，就停止；不得進行 telegram、群組操作或實體控制，並記錄交接角色。
5. 記錄還原決策責任。寫明由哪個角色在獨立核准流程中判斷是否還原，以及決策前必須具備的證據；不列候選動作。
6. 加上證據註記。每列標成來源事實、核准後觀察、推論或未知，並寫出證據上限與遮蔽狀態。
7. 第二人覆核與結案。另一角色確認六格順序、核准未被繞過、沒有識別資料或操作內容，再標成「紀錄完整」「因缺證停止」或「交由另案決策」。

驗證與證據

合格結果是可追溯的六格離線紀錄。它只能證明文件欄位與人工閘門已被覆核，不能證明維護、變更或還原已在任何環境完成。

• 來源審閱只引用固定版本，並寫明不能推論部署結果。
• 核准格包含目的、資料類別、角色、有效狀態與受控參照；沒有口頭捷徑。
• 觀察界線明確標示 live 唯讀仍為 approval-required。
• 停止格涵蓋不得執行的變更、擴權、連線、硬體、ETS、telegram、群組與實體控制需求。
• 還原格只記獨立決策責任與前提，沒有執行指示。
• 證據註記分開來源事實、核准後觀察、推論與未知。
• 紀錄沒有命令、識別資料、環境時間或任何現場成功敘述。

下一步：前往第 22 章，把同一套停止、交接與證據界線放進離線事件手冊。

故障排除

• 核准只寫「例行維護」：目的與資料範圍不完整，維持停止。
• 有人說唯讀不必核准：拒絕。live／running 環境的唯讀查看仍是 approval-required。
• 來源與現場說法不同：只記版本或證據差距，不修改系統來求一致。
• 維護窗口已經開始：時間窗口不是操作授權；六格不完整仍必須停止。
• 還原決策人與執行人相同：仍要分欄留下獨立核准、停止條件與責任界線，不能省略。
• 有人要求提供快速命令：拒絕。本章沒有 operational command 或核准繞道。
• 證據無法安全摘要：不發布原始內容，只記「需受控覆核」與負責角色。

常見問題

本章概覽

先說結論：事件發生時，你先停止未核准動作並聯絡負責的人，再用離線表單完成症狀分類、控制擴大風險的決策、隱私安全證據、升級責任與復原責任交接。本章不會探測、重啟、改設定、傳送資料或修復任何 live system。

目的

用五格離線手冊把事件交給正確的人，而不觸發現場調查或修復。

準備

一張不含環境值的五格事件表與組織既有責任角色清單。

時間

約 15 分鐘。

系統變更

不重啟、還原或控制現場系統；只建立去識別的離線事件應變手冊。

預期結果

能依症狀、證據層級、停損與人工責任處理事件，不觸發現場動作。

停止條件

• 事件涉及非預期實體動作、安全風險或需要現場負責人立即接手。
• 不得接受要求未核准啟停、還原、telegram、群組操作或實體控制的步驟。

範圍與安全界線

「停止」是停止你擴大動作，不是停止正式服務。safe 安全只限離線唯讀固定來源、空白表單與匿名分類。任何 live／running 環境的唯讀查看都是 approval-required 需核准；本章不提供查看、探測或修復方式。

• safe 安全：填寫匿名症狀類別、人工責任角色、停止狀態與受控證據參照。
• isolated-test 隔離測試：另案必須先有明確書面核准、非正式測試環境、管理員在場、有限網路暴露與已驗證停損還原計畫；本章不進入。
• approval-required 需核准：查看或變更任何執行中環境都屬此類；事件急迫不會自動取消核准。
• never-automate 永不自動化：不得群組讀寫，不得傳送 KNX telegram，不得執行 ETS programming／download，不得連接 KNX 介面或 bus，也不得實體控制。測試 bus 也不例外。

加入 repository、安裝或啟動還必須先有完整隔離閘門、書面核准、核准的 immutable artifact／image digest 與 source-to-build attestation。缺少任何一項就停止。

若有人身、建物、門鎖、照明、空調、致動器或其他實體安全疑慮，停止使用本技術表單，立即依組織既有緊急程序聯絡現場負責人與安全專業人員。

核心概念

固定來源可協助你區分初始化責任、daemon 叫用責任與文件化 driver 診斷類別。它不能證明真實事件的根因、影響或復原結果；錯誤文字消失或程序層敘述也不能證明 KNX bus、ETS、整合或硬體狀態。

準備與前置條件

平時先備妥五格空白表與角色清單。事件時才蒐集大量資料容易洩漏隱私，也容易把時間相鄰誤寫成因果。

• 症狀分類：只記使用者可描述的功能類別、來源類別與未知事項，不記設備、位址或現場名稱。
• 控制擴大風險的決策：記「停止未核准試誤」「限制公開分享」「等待負責角色」等人員決策，不寫系統動作。
• 隱私安全證據：公開表只記證據類別、受控保管參照、遮蔽狀態與證據上限。
• 升級責任：用事件指揮、現場安全、隱私覆核、產品負責或外部專業等角色，不填姓名與聯絡資料。
• 復原責任：記誰有權在本章外的獨立核准流程做決定，以及接收結果時需要哪些限制聲明。

不得填環境／事件時間戳、日誌時間戳、執行時間、主機、端點、裝置路徑、序號、位址、帳號、秘密或可關聯家庭活動的細節。順序只用「最早已知症狀」「後續通報」「交接後狀態」等抽象標籤。

分段步驟

這份 runbook 只指揮人員停止、通報與交接。它不指揮 live system。

1. 先停下並找人。停止所有未核准試誤與公開貼文；若有實體安全疑慮，立即依既有緊急程序聯絡現場負責人與安全專業人員。
2. 填症狀分類格。只選「使用者可見功能類別」「初始化責任線索」「daemon 叫用責任線索」「driver 文件類別」或「資訊不足」，不指定根因。
3. 填控制擴大風險的決策格。由事件指揮角色決定哪些人員活動應停止、哪些公開資訊應限制、由誰接手；不寫啟停、設定、連線或硬體措施。
4. 填隱私安全證據格。只記受控證據參照、證據類別、遮蔽狀態、事實與推論界線。原始資料由已獲授權角色留在受控位置。
5. 填升級責任格。依安全、隱私、來源版本或責任不明等類別指定應接手的角色；缺少角色就保持停止並通報事件指揮。
6. 填復原責任格。指定有權啟動獨立核准決策的人，以及回傳去識別結果的負責角色；不提出候選修復或驗證動作。
7. 覆核與交接。第二位覆核者確認五格完整、沒有識別值或 live procedure，再把表單交給事件指揮。狀態只寫「已交接」「因缺證停止」或「等待負責角色」。

驗證與證據

本章的完成標準是責任鏈清楚，不是系統恢復。即使獨立流程回傳某個狀態，本章也只接受經覆核、去識別且附證據上限的交接摘要。

• 症狀分類只描述功能或文件責任類別，沒有根因宣稱。
• 控制擴大風險的決策只限制人員的未核准活動與資訊擴散，沒有 live system 動作。
• 公開證據只有受控參照、類別、遮蔽狀態、未知事項與證據上限。
• 升級責任清楚指定事件指揮、現場安全、隱私覆核或其他負責角色。
• 復原責任由本章外的獨立核准流程擁有，本章沒有修復或驗證步驟。
• 沒有命令、probe、restart、configuration、telegram、ETS、group、physical 或 bus action。
• KNX bus、ETS、整合、群組操作與實體控制結果都維持未證實。

後續固定節奏：定期使用部署評估覆核停止與責任條件，並從幫助與下載取得去識別紀錄指引。這些資源仍不構成現場操作授權。

故障排除

• 通報只寫「系統壞了」：改記最小使用者可見症狀類別，根因保持未知。
• 有人已開始試誤：要求停止後續未核准動作，記錄責任交接，不用另一個動作抵消。
• 完整日誌已進入公開頻道：停止轉貼，依組織隱私程序限制擴散，由授權角色在受控位置處理。
• 有人要求探測端點：拒絕。本章沒有 command 或 probe。
• 有人建議重啟或改設定：拒絕。本章沒有 restart、configuration 或 remediation procedure。
• 有人要求 ETS、群組或 telegram 驗證：拒絕。這些動作不在事件表單內，也不得自動化。
• 事件指揮角色不明：保持停止，依組織既有通報鏈找負責人；不要自行接管 live system。

常見問題