這幾種自動化寫法遲早會出事，附正確寫法

charles

都是很常見的寫法，看起來沒問題，但會在某個時間點咬你一口。




━━ 錯誤一：通知沒有時間條件 ━━

1. trigger:
2.   - platform: state
3.     entity_id: binary_sensor.後門
4.     to: "on"
5. action:
6.   - service: notify.mobile_app_手機
7.     data:
8.       message: 後門開了

複製代碼

看起來很合理對吧。直到某天凌晨四點，貓跳上窗台、或者風把門吹動了一下、或者感應器就只是單純地誤觸發。

然後你的手機大響。而且因為是「安全類」的通知，你還會嚇到彈起來。

正確做法——加時間條件，或者更好的做法是分級：白天只寫 Logbook，晚上才推播：

1. condition:
2.   - condition: time
3.     after: "07:00:00"
4.     before: "23:00:00"

複製代碼

如果這是安全性通知（真的想半夜也收到），那就改成「門開超過 30 秒」才通知，過濾掉瞬間誤觸。

━━ 錯誤二：用 delay 做延遲關燈 ━━

1. action:
2.   - service: light.turn_on
3.     target: {entity_id: light.浴室}
4.   - delay: "00:03:00"
5.   - service: light.turn_off
6.     target: {entity_id: light.浴室}

複製代碼

這個寫法的問題：你在浴室待了五分鐘，燈在第三分鐘暗掉了。

原因是自動化預設 mode: single，delay 期間再次觸發會被直接忽略，計時不會重算。

兩種改法：

最快的解法是加一行：

1. mode: restart

複製代碼

這樣每次偵測到人，自動化會重新開始，delay 也跟著重算。

比較乾淨的解法是用計時器（Timer）輔助元件：

• 偵測到人 → 開燈 + 啟動（或重啟）計時器
  
• 計時器結束 → 關燈
  

拆成兩個自動化，邏輯清楚，之後要改延遲時間也不用動程式。

━━ 錯誤三：忘記加 float ━━

1. condition:
2.   - condition: template
3.     value_template: "{{ states('sensor.溫度') > 28 }}"

複製代碼

這一行在比文字，不是比數字。

文字比大小是一個字一個字比的，所以 "9" 會被判定大於 "28"（因為 9 > 2）。結果就是冬天九度的時候，冷氣自己開了。

這個 bug 非常陰險，因為夏天完全正常，只有溫度掉到個位數才會發作。

正確寫法：

1. value_template: "{{ states('sensor.溫度') | float(0) > 28 }}"

複製代碼

float(0) 裡面那個 0 是預設值，感應器不可用（unavailable）的時候會用 0 代替，不會讓整個自動化報錯。這一點也很重要。

━━ 錯誤四：兩個自動化互相觸發 ━━

1. # 自動化 A：燈開了 → 把窗簾拉上
2. # 自動化 B：窗簾拉上了 → 把燈開起來

複製代碼

無窮迴圈。HA 會一直跑到你發現為止，日誌會被灌爆。

這種情況通常不是這麼明顯，而是繞了一圈才回來：A 觸發 B、B 觸發 C、C 又影響到 A。裝置一多就很難看出來。

解法是判斷「這是誰做的」。HA 的觸發資料裡有 context，可以分辨是人操作的還是自動化做的：

1. condition:
2.   - condition: template
3.     value_template: "{{ trigger.to_state.context.user_id is not none }}"

複製代碼

這樣就只有真人操作才會往下走，自動化造成的變化不會再觸發。

━━ 錯誤五：沒設 mode，觸發被吃掉 ━━

延續錯誤二講的：預設 mode: single 代表前一次還在跑的時候，新的觸發直接丟掉。

如果你的自動化裡有 delay、wait_for_trigger、或者動作很多需要跑幾秒，很可能遇到「明明觸發了卻沒反應」。

四種模式怎麼選：

1. mode: single      # 預設。同時只能有一個在跑
2. mode: restart     # 新觸發打斷舊的 ← 感應器類最常用
3. mode: queued      # 排隊依序執行 ← 需要每次都執行時用
4. mode: parallel    # 全部同時跑 ← 小心，容易打架

複製代碼

一個判斷原則：如果重複觸發應該「重新計時」，用 restart；如果每一次都必須被處理，用 queued。

━━ 錯誤六：直接對「裝置」而不是「實體」下手 ━━

用 UI 編輯器的時候，HA 會讓你選「裝置」。方便，但有個坑：

裝置一旦被刪除重加，裝置 ID 會變，你的自動化就默默失效了。而且不會報錯，你只會覺得「最近好像怪怪的」。

用實體 ID（entity_id）比較穩，因為那是你可以自己命名和控制的。切到 YAML 模式改成 entity_id 會安全很多。

---

大家還有踩過什麼？補充在下面，我整理到主帖上。