statistics 與 derivative：把原始數據加工成有用的資訊

charles

感測器給你的是「現在幾度」。
但你真正想知道的常常是「過去一小時的平均」「變化有多快」
「今天最高幾度」。

這篇講三個內建的數據加工平台。



1. statistics：統計加工

1. sensor:
2.   - platform: statistics
3.     name: 客廳溫度一小時平均
4.     unique_id: living_temp_1h_mean
5.     entity_id: sensor.living_room_temperature
6.     state_characteristic: mean
7.     max_age:
8.       hours: 1
9.     sampling_size: 200

複製代碼

state_characteristic 可以選很多種：

• mean / median — 平均 / 中位數
  
• value_max / value_min — 期間最大 / 最小值
  
• change — 期間變化量（末 − 初）
  
• change_second — 每秒變化率
  
• count — 取樣筆數
  
• standard_deviation — 標準差
  
• total — 總和
  
• distance — 所有變化的絕對值總和
  

兩個參數的關係：

• max_age — 只看這段時間內的資料
  
• sampling_size — 最多保留幾筆（預設 20，太小的話會提早丟掉）
  

sampling_size 太小是常見錯誤。
感測器每 10 秒回報一次，一小時是 360 筆，
sampling_size 留預設 20 的話，你的「一小時平均」其實只算了最近 3 分鐘。

實用場景

用平均值做冷氣自動化，比用瞬時值穩定：

1. conditions:
2.   - condition: numeric_state
3.     entity_id: sensor.客廳溫度一小時平均
4.     above: 28

複製代碼

瞬時溫度會因為有人走過、開門而跳動，平均值不會。

用 value_max 記錄今日最高溫：

1.   - platform: statistics
2.     name: 今日最高溫
3.     entity_id: sensor.outdoor_temperature
4.     state_characteristic: value_max
5.     max_age:
6.       hours: 24
7.     sampling_size: 2000

複製代碼

2. derivative：變化速率

這個算「每單位時間變多少」，拿來偵測異常變化非常好用。

1. sensor:
2.   - platform: derivative
3.     name: 室溫變化率
4.     unique_id: temp_rate
5.     source: sensor.living_room_temperature
6.     unit_time: h              # 每小時
7.     time_window: "00:15:00"   # 用 15 分鐘的資料算斜率
8.     round: 2

複製代碼

結果是「每小時變幾度」。

實際用途一：偵測門窗忘記關

冷氣開著但溫度一直在上升 → 大概是門沒關。

1. alias: 冷氣效率異常
2. triggers:
3.   - trigger: numeric_state
4.     entity_id: sensor.室溫變化率
5.     above: 1.5
6.     for: "00:10:00"
7. conditions:
8.   - condition: state
9.     entity_id: climate.客廳
10.     state: cool
11. actions:
12.   - action: notify.mobile_app_charles
13.     data:
14.       title: 冷氣好像沒效
15.       message: >
16.         冷氣開著但室溫每小時上升
17.         {{ states('sensor.室溫變化率') }} 度，
18.         檢查一下門窗或濾網
19. mode: single

複製代碼

實際用途二：偵測漏水

有水表的話，深夜的用水速率應該接近零。
不是零就代表有地方在漏。

1.   - platform: derivative
2.     name: 用水速率
3.     source: sensor.water_meter_total
4.     unit_time: min
5.     time_window: "00:30:00"

複製代碼

1. alias: 可能漏水
2. triggers:
3.   - trigger: numeric_state
4.     entity_id: sensor.用水速率
5.     above: 0.5
6.     for: "01:00:00"
7. conditions:
8.   - condition: time
9.     after: "01:00:00"
10.     before: "05:00:00"
11.   - condition: state
12.     entity_id: binary_sensor.家裡真的有人
13.     state: "on"
14. actions: ...

複製代碼

time_window 要調

太短 → 雜訊很大，數字一直跳。
太長 → 反應慢，變化發生很久才看得出來。

我的經驗：溫度用 15-30 分鐘，用電用 5 分鐘，用水用 30 分鐘。

3. integration：反過來，把速率變累積

有些智能插座只給瞬時功率（W），不給累計用電（kWh）。
能源儀表板需要的是後者。

1. sensor:
2.   - platform: integration
3.     name: 除濕機累計用電
4.     unique_id: dehumidifier_energy
5.     source: sensor.dehumidifier_power
6.     unit_prefix: k          # W → kW
7.     unit_time: h            # 每小時 → kWh
8.     method: left            # 積分方法
9.     max_sub_interval:
10.       minutes: 5

複製代碼

method 三種：

• left — 用區間開始的值（建議用這個，對開關型負載最準）
  
• right — 用區間結束的值
  
• trapezoidal — 梯形法（預設，對連續變化的負載比較準）
  

為什麼開關型負載要用 left？

除濕機關掉的瞬間，功率從 300W 變 0W。
梯形法會算成「這段期間平均 150W」—— 但實際上它是一直 300W 然後突然停。
用 left 就會正確算成 300W。

max_sub_interval 很重要（新版功能）

沒有它的話，功率長時間不變（例如冰箱穩定運轉）就不會有新的資料點，
積分結果會卡住不動。設了之後，HA 會定期強制計算一次。

記得設 state_class

要進能源儀表板的話：

1.   - platform: integration
2.     ...
3.     # integration 平台會自動設成 total，通常不用手動指定
4.     # 但如果做出來的感測器沒出現在能源設定裡，去實體設定確認一下

複製代碼

三個平台的關係

• 原始感測器 — 現在幾度、現在幾瓦
  
• statistics — 統計：平均、最大、最小
  
• derivative — 微分：變化有多快
  
• integration — 積分：累積了多少
  

derivative 和 integration 是互逆的。
功率積分變成用電量，用電量微分變回功率。

共通注意事項

1. 這些都是「衍生實體」，重啟後要重新累積

statistics 和 derivative 在 HA 重啟後會從頭開始（integration 會保留累計值）。
所以重啟後幾分鐘內數字可能不準，自動化最好加個 for: 條件避開。

2. 會增加資料庫負擔

每個衍生感測器都是一個新實體，都會被 recorder 記錄。
做太多的話記得檢查資料庫大小。

3. 用 UI 建也可以

設定 → 裝置與服務 → 新增整合，搜尋
Statistics、Derivative、Integration - Riemann sum。

UI 建的好處是有說明和驗證，缺點是不方便批次複製。

---

我自己用最多的是 integration，因為家裡一半的智能插座只給瞬時功率。
把它們全部積分成 kWh 之後，能源儀表板才真的能用。

derivative 的漏水偵測是後來加的，還沒真的抓到漏水，
但心理上踏實很多。