八種很快就會被關掉的自動化，以及每一種該怎麼改寫

charles

這篇的內容（31 段）

1. 1-1 原本的寫法
2. 1-2 為什麼它在機制上就會失敗
3. 1-4 你會看到什麼
4. 2-1 原本的寫法
5. 2-2 為什麼它在機制上就會失敗
6. 2-3 改寫版：做成三個一鍵場景
7. 2-4 你會看到什麼
8. 3-1 原本的寫法
9. 3-2 為什麼它在機制上就會失敗
10. 3-3 改寫版：用 zone.home 的人數
11. 3-4 你會看到什麼
12. 4-1 原本的寫法
13. 4-2 為什麼它在機制上就會失敗
14. 4-3 改寫版 A：做成儀表板卡片
15. 4-4 改寫版 B：只有異常才推播
16. 4-5 你會看到什麼
17. 5-1 原本的寫法
18. 5-2 為什麼它在機制上就會失敗
19. 5-3 改寫版：兩段式
20. 5-4 你會看到什麼
21. 6-1 原本的寫法
22. 6-2 為什麼它在機制上就會失敗
23. 6-4 你會看到什麼
24. 7-1 原本的寫法
25. 7-2 為什麼它在機制上就會失敗
26. 方式 C：兩個都用（最保險）
27. 7-4 你會看到什麼
28. 8-1 原本的做法
29. 8-2 為什麼它在機制上就會失敗
30. 8-4 你會看到什麼
31. ━━ 這八項的共同形狀 ━━

加一條自動化很容易，砍掉比較難。而有一類自動化在設計上就注定會被關掉 —— 不是因為寫得不好，是因為它把一個「人各有不同、而且會隨當下改變」的判斷交給了感測器。

這篇列出八種最常見的，每一種都有三個部分：原本的寫法（完整 YAML，你可以對照看看自己家有沒有）、為什麼它在機制上就會失敗、改寫版（完整可貼，而且解決的是同一個需求）。



━━ 步驟 0：先把八條都找出來 ━━

在開始改之前，先確認你家有哪幾條。到 開發者工具 → 範本，貼上這一段：

1. {% set autos = states.automation | list %}
2. 自動化總數：{{ autos | count }}
4. --- 目前是關閉狀態的（你當初為什麼關掉它？）---
5. {% for a in autos if a.state == 'off' %}
6. {{ a.name }}
7. {% endfor %}
9. --- 三十天沒觸發過的 ---
10. {% for a in autos if a.state == 'on' %}
11. {%- set lt = a.attributes.last_triggered %}
12. {%- if lt is none %}
13. [從未觸發] {{ a.name }}
14. {%- elif (as_timestamp(now()) - as_timestamp(lt)) > 2592000 %}
15. [{{ time_since(lt) }} 前] {{ a.name }}
16. {%- endif %}
17. {% endfor %}

複製代碼

你會看到什麼：右欄列出三段清單。

• 「目前是關閉狀態」那一段，就是你已經實際關掉的。底下八項多半會出現在這裡
  
• 「從未觸發」 —— 這些比關掉的更糟，因為它們看起來是啟用的。多半是實體 ID 打錯了
  
• 「三十天前」以上 —— 如果不是季節性的，它應該也已經壞了
  

2592000 是三十天的秒數（30 乘 24 乘 60 乘 60）。直接寫算好的常數，不要寫成算式，這樣讀起來一眼就知道門檻在哪。

━━ 步驟 1：進門自動播放音樂 → 改成「準備好但不播」 ━━

1-1 原本的寫法

1. - alias: "進門播音樂"
2.   mode: single
3.   triggers:
4.     - trigger: state
5.       entity_id: binary_sensor.da_men
6.       to: "on"
7.   actions:
8.     - action: media_player.play_media
9.       target:
10.         entity_id: media_player.ke_ting_yin_xiang
11.       data:
12.         media_content_id: "spotify:playlist:xxxxx"
13.         media_content_type: playlist

複製代碼

1-2 為什麼它在機制上就會失敗

大門開啟這個事件，對應到的實際情境有非常多種：正在講電話回家、雙手抱著東西、家人在午睡、送貨員按門鈴、倒垃圾回來、開門通風。

門磁只能告訴你「門開了」，它分辨不出上面哪一種。而播音樂這個動作在其中大約八成的情境裡是不合時宜的 —— 你得衝過去關掉。

關鍵在於誤判的成本不對稱：猜對的時候效益是「省下按一次播放鍵」；猜錯的時候成本是「立刻停下手邊的事去關掉它」。後者高得多。

1-3 改寫版：把「播放」換成「準備好」

1. - alias: "回家 - 準備好音樂但不播"
2.   id: arrive_prepare_music
3.   mode: single
4.   triggers:
5.     - trigger: zone
6.       entity_id: person.zhu_ren
7.       zone: zone.home
8.       event: enter
9.   conditions:
10.     - condition: time
11.       after: "17:00:00"
12.       before: "22:00:00"
13.   actions:
14.     # 只開音箱電源並設定好音量，不播放
15.     - action: media_player.turn_on
16.       target:
17.         entity_id: media_player.ke_ting_yin_xiang
18.     - action: media_player.volume_set
19.       target:
20.         entity_id: media_player.ke_ting_yin_xiang
21.       data:
22.         volume_level: 0.3
23.     # 把「要播什麼」存起來，等人決定
24.     - action: input_text.set_value
25.       target:
26.         entity_id: input_text.dai_bo_qing_dan
27.       data:
28.         value: "晚間放鬆"

複製代碼

配一個儀表板按鈕（設定 → 儀表板 → 編輯 → 新增卡片 → 按鈕），點下去才真的播。

設計的改變：自動化負責把準備工作做完（音箱開機要幾秒、音量要調），人只需要做那個「現在到底要不要」的判斷 —— 而那正是感測器做不到的部分。

1-4 你會看到什麼

• 回到家時，音箱的狀態從 off 變成 idle（到 開發者工具 → 狀態 搜尋那個 media_player 確認）
  
• 沒有任何聲音
  
• 儀表板上的按鈕點下去，音樂立刻開始 —— 而且不用等音箱開機那三秒
  

音箱狀態沒變 → 有些音箱沒有 turn_on 這個動作（它們是常時待機的）。那就把 media_player.turn_on 那段拿掉，只留音量設定。

以下還有約 82% 的內容
登入後即可閱讀完整教學

登入繼續閱讀使用 Google 登入