CH05 · PUBLIC READING
明明都是溫度計，為什麼換個牌子又要工程師改程式？
你的 IoT Server 為什麼不在意你用的是什麼牌子的溫度計
用 DCE 的行為分類觀念，說明裝置廠牌、資料解析與統計責任為什麼不該綁成同一支程式。
工廠鬼話
客戶原本用 A 牌溫度計，資料穩定跑了一段時間。半年後 A 牌缺貨，採購改買 B 牌。現場只覺得這還是溫度計，應該換上去就好；工程師打開封包規格後，才發現溫度值位置、倍率和狀態欄位都不一樣。
如果系統每次只認廠牌和型號，換一個硬體就可能變成一次程式修改。客戶會問：「明明都是溫度，為什麼又要工程師改程式？」
本章要回答的不是「如何支援所有裝置」，而是如何把資料行為、資料位置和身份對應拆開，讓同類資料不要每次都重寫一輪。
這章承接的是 CH1 的碎片化痛點：同樣叫溫度、電流或流量，底層封包可能完全不同。系統要有能力把可變的廠牌差異收進設定，把共用的資料行為留在架構裡。
課程地圖
圖解：本章在 LocalNest 架構中的位置
圖解：DCE 把廠牌差異收斂成行為核心
本章先說明 DCE 的基本概念：
新增或更換裝置時，導入人員要先判斷解析後的資料屬於哪一種行為核心，
例如平均型、累積型或邏輯型；
接著再把資料位置、單位、倍率與身份對應寫進設定。
這一章還不展開統計公式，
只先建立一件事：資料解析出來後，要帶著正確的行為分類進入 LocalNest 儲存流程。
等到 CH16 講歷史資料與統計週期時，
才會正式說明系統如何依照這些分類選擇平均、累積、布林或最大最小等計算方式。
5-1 現場痛點：為什麼換個牌子要改程式
有一個場景整合商一定碰過：
整合商幫客戶現場裝好了 10 台感測器，資料正常跑，
然後客戶說：「那個溫度計廠商斷貨了，我改買另一家的，可以協助替換嗎？」
一開始看起來只是換個硬體，實際上新廠牌的 BLE 封包格式完全不一樣，
溫度值放在不同的位元組（byte）位置，精度也不同。
最後還是得請韌體工程師修改封包解析器、測試、部署，最快一週。
客戶很困惑：「明明都是溫度計，為什麼換個牌子要這麼麻煩？」
這個問題的根本原因是：系統認識的是「裝置型號」，而不是「資料行為」。
如果每一種型號都寫死在程式碼裡，新增裝置就會變成新增一段程式碼；
換掉裝置，就可能要重新測整條資料流程。
DCE 要解決的就是這個耦合問題：不要讓每一個廠牌差異都變成一次程式碼修改。
5-2 什麼是 DCE
DCE 是 Device Core Extraction，這裡可以理解成「裝置行為核心萃取」。
它的工作不是自動辨識全世界所有裝置，也不是保證任何新裝置都完全不用改程式碼。
DCE 的重點是把新增裝置時最常變動的事情拆開：
| 類型 | 主要內容 | 優先處理方式 |
|---|---|---|
| 資料位置 | 數值在封包哪個位元組、長度是多少、倍率是多少 | 盡量放在設定檔 |
| 單位與換算 | 原始值要如何換成溫度、電量、流量或狀態 | 盡量放在設定檔 |
| 身份對應 | 這筆資料對應哪個 R_U_UUID、V_U_UUID、V_S_UUID | 盡量放在設定檔 |
| 行為核心 | 解析後的資料屬於平均、累積、最大值、最小值或邏輯狀態 | 由導入人員判斷，系統先記錄分類，後續統計層依分類執行 |
| 新行為 | 系統以前沒有定義過的統計方式或資料處理規則 | 可能需要擴充程式碼 |
也就是說，DCE 的理念是：人先判斷資料行為，
系統先用設定記錄分類；資料位置與身份對應盡量設定化，
讓新增不同種類裝置的彈性變大，並把修改程式碼的範圍壓到最低。
如果只是 A 牌溫度計換成 B 牌溫度計，兩者都屬於平均型數值，那通常應該改資料位置、倍率、單位與身份對應，而不是改整套資料流程。
可是如果現場出現系統從未定義過的行為，例如特殊事件序列、複雜狀態機、或全新的統計規則，那就不是單靠設定檔一定能解決，仍然可能需要擴充 DCE 的行為核心。
5-3 DCE 定義的常用行為核心
LocalNest 先把常見感測資料歸納成幾種常用行為核心：
| 行為核心 | 行為描述 | 典型裝置 |
|---|---|---|
| 平均型（Average） | 狀態值，後續統計通常看平均或趨勢 | 溫度、濕度、電流、亮度、CO2、VOC |
| 累積型（Cumulative） | 累積讀數，後續不能直接當狀態值平均 | 電表 kWh、脈衝計數、流量累積 |
| 邏輯 OR 型 | 任一觸發就算成立 | 漏液偵測、有任一區域異常 |
| 邏輯 AND 型 | 全部條件成立才算成立 | 全區域都達成才算成立的條件 |
| 峰值型（Max） | 需要保留最高狀態 | 振動峰值、溫度過熱保護 |
| 谷值型（Min） | 需要保留最低狀態 | 最低溫度追蹤、電壓最低點 |
溫度和濕度在物理意義上不同，但進入歷史統計時都常被歸在平均型。
漏液偵測和電燈開關在設備外觀上不同，但進入資料流程時都可能是邏輯狀態。
DCE 要抓的是這種「解析後的資料應該交給哪一類處理方式」的共同點。
這也是為什麼 DCE 不是廠牌分類表。
導入時不是只問「這是哪一家溫度計」，
而是要先問：「這筆數值解析出來以後，應該歸到哪一種行為核心？」
進階統計其實還有很多，例如標準差、中位數、百分位、變化率、持續時間、時間加權平均等。
這些不是不能做，而是通常比較客製化，會依產業、設備和報表目的才決定是否導入。
DCE 的設計重點不是一開始把所有統計方式塞滿，而是先把最常見的行為核心穩定下來；
未來真的需要進階統計時，再新增對應行為核心。
這也是 LocalNest 架構的價值。
因為資料身份、解析設定和行為分類已經拆開，未來導入新統計方式時，
不必像一般伺服器那樣到每個 APP、報表和資料流程裡各自補規則，複雜度會低很多。
5-4 DCE 在系統裡的位置
DCE 位在 DB / 歷史統計支線，不綁在 R_U_UUID 轉成 V_U_UUID 的過程：
R_U_UUID、V_U_UUID、V_S_UUID 管的是「這筆資料是誰、上層接到誰」。
DCE 管的是「解析後的核心數值要用哪一種統計行為處理」。
需要公式或多來源組合時，資料可以先形成 V_U_UUID；不需要組合的 R_U_UUID 或顯示用 V_S_UUID，也可以依各自的 USFID 設定進入相同的 DCE 行為。
所以身份分層和 DCE 的分工可以這樣記：
5-5 這個設計帶來的改變
換同功能裝置時：
- 舊系統：通知工程師 → 修改封包解析器 → 測試 → 部署 → 1 到 2 週
- LocalNest DCE：確認行為核心沒變 → 更新資料位置、倍率、單位與身份對應 → 測試資料正確性 → 完成
新增已支援行為的裝置時：
- 舊系統：每種新裝置都可能變成一次程式碼修改
- LocalNest DCE：行為核心已存在時，優先透過設定檔處理資料位置、倍率、單位與身份對應
遇到未定義行為時：
- 舊系統：直接在各處補例外邏輯，系統越補越亂
- LocalNest DCE：先判斷是否需要新增一種行為核心；如果真的需要改程式碼，修改範圍也應該集中在 DCE 行為定義，而不是散落在各個 APP 或報表裡
對整合商的意義不是「永遠不用工程師」，而是把大多數新增裝置的工作從程式碼修改降到設定檔調整；真的需要擴充程式碼時，也能知道應該改哪一層，不會到處補洞。
本章判斷重點
- 導入時有沒有先判斷資料行為？ 先判斷平均、累積、邏輯 OR / AND、最大值、最小值等原生已支援行為，再處理資料位置與身份對應。
- 系統是以「型號」分類，還是以「行為核心」分類？ 如果封包解析器裡有大量型號判斷，後面又把統計方式寫死在各處，代表系統仍然以型號為中心。
- 換同功能廠牌時，主要改設定檔還是改程式碼？ DCE 的目標是讓資料位置、倍率、單位與身份對應盡量設定化。
- 數值是否正確識別行為核心？ 把累積型 kWh 當平均型處理，報表數字會失真。
- 遇到新需求時，能不能分辨是設定問題還是新行為問題？ 已支援的行為核心應優先改設定；未定義的行為核心才考慮擴充程式碼。
- APP 和報表是否依賴底層硬體格式？ 如果上層使用端還要知道位元組位置、廠牌格式或解析細節，DCE 的隔離就沒有做好。
CONTINUE THE SYSTEM
這一章回答一個問題，完整課程負責把責任串起來
LocalNest 的完整內容會繼續處理裝置身份、解析、資料品質、歷史資料、離線補傳、APP、多站權限、設定面，以及可執行的 BETA 與 LAB。