怎麼判斷一則自動化該不該存在：五個檢驗與它們的實作

charles · 發表於 2026-9-21 14:15:50

這篇的內容（10 段）

步驟 3：把它寫進條件裡
步驟 4：做一個手動覆寫開關
7-2：不要設「初始值」
7-4：給一顆真正的按鈕
步驟 8：讓自動化留下痕跡
三個細節
四個細節上的建議
一、燈不要瞬間開關
三、半夜不要出聲
一個五分鐘的家庭測試

同樣的感應器和燈，有人做出全家都喜歡的系統，有人做出家人偷偷拔插頭的系統。差別不在技術，在幾個可以當場檢驗的設計判斷。

這一篇的每一節都是：一個可以問出答案的問題，加上一段可以直接貼進設定檔的實作。

檢驗一：這則自動化消除了哪一個動作？

問法：說出一句「以前我要做 X，現在不用了」。說不出來，它就只是「很酷」。

半夜起床走道燈微亮消除了：摸黑找開關
洗衣機洗好通知消除了：一直去陽台看
離家自動關全部消除了：出門前巡一輪
冷氣還開著的提醒消除了：在公司一直想這件事
要先開 App 才能開燈沒有消除任何動作，而且多了一個
要記得先切換模式多了一個要記住的事
燈會依心情變色很好看，但不是自動化該做的事

複製代碼

這個檢驗最有價值的用法是拿去看「已經做好的」那些，而不是還沒做的。

步驟 1：用資料找出該刪的自動化

Home Assistant 幫每一則自動化記了「上次觸發時間」。三個月沒觸發過的，多半就是答不出上面那個問題的那些。

到設定 → 工具 → 範本，把下面整段貼進左邊的編輯區：

{% set ns = namespace(rows = []) %}
{% for a in states.automation %}
{% set lt = a.attributes.get('last_triggered') %}
{% if lt is none %}
{% set ns.rows = ns.rows + [a.name ~ ' -- 從來沒有觸發過'] %}
{% elif (now() - lt).days > 90 %}
{% set ns.rows = ns.rows
+ [a.name ~ ' -- ' ~ (now() - lt).days ~ ' 天沒觸發'] %}
{% endif %}
{% endfor %}
共 {{ states.automation | list | count }} 則自動化，
其中 {{ ns.rows | count }} 則超過 90 天沒動作：
{{ ns.rows | join('\n') }}

複製代碼

你會看到右邊即時列出清單，像這樣：

共 47 則自動化，其中 6 則超過 90 天沒動作：
假期模式隨機開燈 -- 從來沒有觸發過
訪客模式 -- 從來沒有觸發過
下雨收衣服提醒 -- 173 天沒觸發

複製代碼

清單是空的，恭喜，你的自動化都還活著。

所有自動化都顯示「從來沒有觸發過」，代表你剛重新安裝過 —— last_triggered 在重啟後會還原，但重建系統之後就是空的，等一個月再看。

步驟 2：看完清單之後怎麼處理

從來沒觸發過 —— 多半是條件寫錯了，或者觸發條件根本不會成立。這是壞掉而不是沒用，先去追蹤頁面看一眼
很久沒觸發但條件是合理的（例如颱風才會用到的）—— 保留，但貼一個標籤歸類
很久沒觸發而且你想不起來它在做什麼 —— 停用它，不要直接刪。停用一個月沒有人抱怨再刪

為什麼要停用而不是直接刪：自動化壞掉的時候很安靜，沒有人會跑來跟你說「客廳的燈今天沒有自己亮」，他們只會自己去按開關。留一個月的緩衝可以接住這種情況。

檢驗二：如果這個判斷錯了，往哪一邊倒比較不痛？

問法：這則自動化有兩種錯法，哪一種你比較能接受？然後刻意往那一邊設計。

感應器壞了 → 燈一直亮可以接受（浪費電）
感應器壞了 → 燈永遠不亮不能接受（半夜摔倒）
判斷錯 → 冷氣多開十分鐘可以接受
判斷錯 → 半夜冷氣自己關掉不能接受（會熱醒）
通知誤報 → 多一則訊息可以接受
通知漏報 → 漏水沒人發現不能接受

複製代碼

步驟 3：把它寫進條件裡

Home Assistant 有一個內建函式 has_value()，判斷一個實體現在有沒有有效的數值（unknown 和 unavailable 都算沒有）。

不好的寫法：

conditions:
- condition: state
entity_id: binary_sensor.living_room_presence
state: "off"
actions:
- action: light.turn_off
target:
entity_id: light.living_room

複製代碼

感應器掉線時它的狀態是 unavailable，不等於 "off"，所以這則不會執行 —— 這次剛好安全。

但反過來的那一則就不安全了：

# 危險：感應器掉線時 states() 回傳 'unavailable'，
# 這個數字比較會直接出錯或用到預設值
conditions:
- condition: numeric_state
entity_id: sensor.living_room_temperature
above: 28
actions:
- action: climate.turn_on
target:
entity_id: climate.living_room

複製代碼

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

登入繼續閱讀使用 Google 登入

		自動登入	找回密碼
密碼			立即註冊

怎麼判斷一則自動化該不該存在：五個檢驗與它們的實作

延伸閱讀

瀏覽過的版塊