畫面有資料、有曲線、有報表，為什麼仍然不能直接相信？

工廠鬼話

客戶上週裝了一批新的 BLE 溫度感測器。

維護人員： 客戶反應，上週裝的溫度感測器幾乎都在斷線狀態。

RD： 先去現場用手機打開藍牙，看有沒有藍牙訊號。有的話，再去接收器那邊看有沒有收到該裝置的封包。

維護人員： 都有。手機看得到藍牙，接收器也有收到封包。但即時資訊偶爾上線一下，大部分時間都斷線。

RD： 見鬼了。

後來才發現，裝置確實有在廣播，接收器也確實有收到封包；問題是那些封包不一定都帶溫度資料。真正有溫度的封包偶爾出現，下一包不是目標資料的封包又把狀態蓋掉。從物理通訊看，裝置沒有完全消失；從系統資料看，溫度資料大部分時間就是沒進來。

這就是資料品質要拆開看的原因。有沒有藍牙訊號、有沒有收到封包、有沒有收到目標資料、即時組合值有沒有缺來源、統計時間裡樣本夠不夠，這些不是同一件事。如果系統只留一個模糊的品質分數，研發和維護人員還是要花時間猜問題方向。

課程地圖

12-0 先把問題接上來

前面幾章已經解決資料怎麼進來、怎麼被解析、怎麼被送進即時路徑與本地資料庫。這些都還不夠，因為資料進來不代表資料可信。

從這一章開始，課程進入資料品質線。重點不是只有沒有數值，而是要分清楚三個問題：

1. 這段時間有沒有收到帶目標資料的封包？
2. 這個即時組合值是不是缺了部分來源？
3. 這段統計時間裡有效資料是否足夠完整？

這三個問題分別對應三個資料品質指標：

它們一起構成 LocalNest 的資料可信特性。
這裡的「可信」不是抽象形容詞，而是讓維護人員可以判斷：
現在該查封包、查來源，還是查統計時間缺口。

先把本章定位講清楚：

圖解：本章在 LocalNest 架構中的位置

圖解：三個指標回答三種問題

12-1 有資料不等於資料正確

工廠裡一台馬達溫度計，每 60 秒回傳一筆溫度值，系統顯示 72°C。
畫面看起來很正常，報表也繼續把 72°C 算進平均，告警系統更不會叫人去看現場。

三天後才發現感測器的 BLE 連線在 Day 1 下午就斷了。
那個 72°C 不是新的量測值，而是系統沿用的舊值。
設備早就停轉，或現場溫度早就改變，但監控系統仍用舊數字讓大家以為狀態穩定。

這是 IoT 現場最普遍的陷阱：把有資料當成資料正確。

現場資料常常不是乾淨地分成「有值」和「沒值」。
BLE 裝置可能還在廣播，但這一分鐘送來的封包都不是目標資料；
Modbus 裝置可能有回應，但某幾個暫存器設定錯誤或讀值失敗；
電錶的 Pulse 計數可能偶爾凍結，畫面上仍然有數字，實際上數值已經不動。

這些狀況的共同點不是「在線或離線怎麼判斷」，
而是單看數值本身，看不出資料來源是否正確、組合來源是否完整、統計樣本是否足夠。
因此資料品質不能只靠 Value 欄位判斷，必須把封包、來源和時間樣本的背景一起帶上來。

每一筆 IoT 資料不能只留下量測值，還要一起留下三類背景資訊：

這些資訊要跟量測值一起被保存。原因不是資料表設計好不好看，
而是後面的報表、告警、歷史查詢都需要同時知道兩件事：數值是多少，以及這個數值有多可靠。

12-2 三個指標，不是同一個分數

封包有效率、空值比例、Rank 都在描述資料品質，但它們不是同一個分數，也不是同一層的判斷。

先把公式裡會用到的分母和分子說清楚：

封包有效率：封包裡有多少是真的目標資料

公式：

封包有效率 = 有效目標封包數 / 收到封包數

這個指標主要出現在原始封包整理成 60 秒資料、再往上統計的路徑。
它不是即時畫面拿來判斷單一封包好壞的欄位。

BLE 的重點在於：
裝置可能會送很多種封包，但只有其中幾種，甚至只有一種，真的帶有我們要的資料。
有些 BLE 裝置會輪流送不同類型的廣播封包，其中某一種放溫度、電流或其他目標數值，
其他封包可能只是狀態、廠商資訊或輔助資料。

所以一分鐘內收到 10 個封包，不代表 10 個封包都有量測值。
Parser 會把能解析出目標數值的封包算進有效封包；
解析結果是無效值、超出範圍，或這個封包類型根本沒有目標欄位，就不算有效封包。

這裡要把物理意義和系統資料意義分開：

Modbus 若設定一次讀多種數值，也可能遇到類似狀況：
通訊有回應，但目標欄位沒有被正確讀到。
差別是 BLE 常是裝置封包設計與廣播類型造成，
Modbus 比較常是人為設定、位址、長度或解析規則造成。

空值比例：即時組合值缺了多少來源

公式：

空值比例 = (預期來源總數 - 有效來源數) / 預期來源總數

空值比例回答的是即時組合值的可信度。
例如三相電要用 R / S / T 三個來源一起算總功率，其中一相沒有資料，
計算結果就不應該被當成完整資料。

三相預期來源 = 3
本輪有效來源 = 2
空值比例 = (3 - 2) / 3 = 0.33

這裡的 0.33 不是時間統計 Rank，也不是封包有效率。
它只表示「此刻這個組合值少了一部分來源」。
即時資訊要忠實呈現這個缺口，
現場才知道是整台設備離線、某一相沒進來，還是封包層沒有目標資料。

Rank：時間統計資料的完整度

公式：

Rank = 有效資料點數 / 預期資料點數

Rank 回答的是一段統計時間裡有效資料是否足夠完整。
15 分鐘、60 分鐘、一天、一週、一月，都屬於 Rank 會發揮作用的地方。

一小時資料應該由 60 筆一分鐘資料合成
實際只有 52 筆有效
Rank = 52 / 60 = 0.87

這裡的 0.87 是時間完整度，不是裝置數量比例。
它表示這一小時的統計值缺了一部分資料，
報表可以顯示數值，但應該知道這個數值不是滿資料量算出來的。

12-3 為什麼三個指標不能混用

三個指標最容易被混在一起，因為它們都在描述資料品質。但混用會讓排查方向錯掉。

封包有效率為 0 時，重點不是先判斷設備壞掉，而是問：

這段時間有沒有收到帶目標資料的封包？要查 BLE 封包類型、Parser 規則、目標欄位、數值範圍，或 Modbus 的讀值設定。

空值比例為 0.33 時，重點不是問這一小時少了多少資料，而是問：

這個即時組合值現在少了哪個來源？要查真實來源、相位、組合公式與來源缺失追查明細。

Rank 為 0.67 時，重點不是問少了幾個封包，而是問：

這段統計時間裡，有效資料點只達到預期的三分之二，缺口發生在哪些時間？要查近期資料庫、每日整理資料、最終歷史資料、補傳、融合與長期趨勢。

這也是資料品質設計的價值：不是多存幾個欄位，而是讓研發和維護人員少花時間猜問題方向。

12-4 Rank 的分母為什麼要從設定來

Rank 的分母是預期資料點數。
它代表這個時間段裡理論上應該有幾筆下層資料，通常來自統計週期或裝置設定。
例如一小時資料如果由 60 秒資料合成，理論上應該有 60 筆。

預期資料點數不能根據裝置過去行為動態推算。
原因很簡單：如果裝置慢慢變差，動態基準線也會跟著往下漂。
最後系統會把變差後的狀態當成正常狀態。

基準線必須跟裝置規格或統計週期一致，不能被現場實際狀況污染。
這樣 Rank 才能忠實反映資料完整度，而不是幫不穩定的裝置重新定義正常。