自動化的 mode 四選一：single、restart、queued、parallel 差在哪

charles

這個設定藏在自動化編輯器右上角的三個點裡，很多人從來沒動過它，
但它是「自動化行為怪怪的」最常見的原因之一。

先講它在解決什麼問題：當自動化還在跑，又被觸發了一次，該怎麼辦？



single（預設）

還在跑就忽略新的觸發，而且會在日誌寫一行警告。

適合：不希望重複執行的動作。例如「每天早上六點澆花 30 秒」。

經典的踩雷：感應燈。

1. triggers:
2.   - trigger: state
3.     entity_id: binary_sensor.走道感應
4.     to: "on"
5. actions:
6.   - action: light.turn_on
7.     target: {entity_id: light.走道}
8.   - delay: "00:03:00"
9.   - action: light.turn_off
10.     target: {entity_id: light.走道}
11. mode: single

複製代碼

人走進去 → 燈亮 → 開始數三分鐘。第二分鐘人又經過 → 觸發被忽略 →
第三分鐘燈照樣關掉，人還在裡面。

restart

還在跑就砍掉重來，從頭開始執行。

上面那個感應燈，把 mode 改成 restart 就對了：每次有人經過，
三分鐘重新計時。這是最常見的正確答案。

幾乎所有「亮一段時間後關掉」的自動化都該用 restart。

queued

新的觸發排隊等，前一個跑完再跑下一個。可以設定佇列長度（預設 10）。

適合：每一次觸發都必須被處理，而且不能同時做的事。

我自己的用法是語音播報：

1. alias: 播報佇列
2. triggers:
3.   - trigger: event
4.     event_type: my_announce
5. actions:
6.   - action: tts.speak
7.     target: {entity_id: tts.piper}
8.     data:
9.       media_player_entity_id: media_player.客廳音箱
10.       message: "{{ trigger.event.data.text }}"
11. mode: queued
12. max: 10

複製代碼

如果用 parallel，三個通知會同時播，變成一團噪音。用 queued 就會一句一句講完。

parallel

同時跑，互不等待。一樣可以設上限。

適合：同一個自動化要服務多個對象，而且彼此無關。

例如「任何一個門窗開了超過五分鐘就提醒」，用一個自動化配 trigger id，
前門和後門同時開著也要各自計時 —— 這種就得 parallel。



怎麼選：兩個問題

問題一：重複觸發時，前一次的執行還有意義嗎？

• 沒意義（計時該重算）→ restart
  
• 有意義（每次都要完成）→ 繼續問第二題
  

問題二：這些執行可以同時進行嗎？

• 可以 → parallel
  
• 不行（會互相干擾）→ queued
  
• 根本不該重複執行 → single
  

一個容易忽略的細節

只有動作裡有「等待」的自動化才會受 mode 影響。

如果你的自動化就是「觸發 → 開燈」，一瞬間就跑完了，
根本不會有「還在跑又被觸發」的情況，mode 設什麼都一樣。

有 delay、wait_for_trigger、wait_template、repeat、或是很慢的動作，
mode 才有意義。

怎麼確認自己有沒有中招

到 設定 → 系統 → 日誌，搜尋 already running。

會看到類似這樣的警告：

1. Automation with alias '走道感應燈' is already running.
2. Maximum number of runs exceeded.

複製代碼

有這行就代表你的 mode 選錯了，而且已經在漏掉觸發了。

---

我自己的統計：家裡三十幾個自動化，大概有六個是 restart，
兩個 queued，一個 parallel，其他都留 single。

restart 的那六個全部都是感應燈或延遲關閉類型。這個比例應該滿有代表性的。