鏈路層與驅動診斷邊界

本章概覽

先說結論：你只會畫一張交接檢查表。每個檢查點只代表一種文件分類。它不是本機觀察，也不是 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、群組操作或實體控制來驗證。

常見問題