智能家居系列（一）：我為什麼開始用 Home Assistant

我原本主要使用 Aqara App 控制家裡的智能設備。

因為手邊的手機、平板和電腦都是 Apple 系列，我也曾經拜訪過幾家智能家居規劃的店家。當時得到的建議很一致：如果平常就在 Apple 生態系裡，使用 Apple Home 會是相對穩定、也比較容易讓家人一起使用的選擇。

這個方向本身沒有錯。把燈光、開關和環境感測器接進去之後，確實可以在同一個介面查看與控制，也能透過手機或語音操作。對剛開始接觸智能家居的人來說，這樣已經比每個設備各自打開一個 App 方便很多。

但隨著家裡的設備增加，我慢慢碰到一個問題：燈光、開關和感測器可以待在同一套系統裡，空氣清淨機、除濕機和其他家電卻不一定能順利加入。

每一台設備單獨看都算「智能」，放在一起時卻還是各做各的。我可以在手機上看到環境濕度，也可以用另一個 App 打開空氣清淨機，但兩件事之間沒有真正連起來。

這也是我後來買下 Home Assistant Green 的原因。

智能設備很多，不等於智能家居

現在要買到可以連網的家電並不難。燈泡、開關、感測器、空氣清淨機、除濕機和電視，幾乎都有各自的 App。

但如果每次操作都還是要拿出手機，先想起這台設備是哪個品牌，再找到正確的 App，那只是把牆上的開關搬進手機裡而已。

我真正想要的是讓設備根據生活情境互相配合：

• 環境濕度超過設定值時，自動開啟指定設備；
• 準備做飯時，按一下料理模式就開啟小米電視並播放 YouTube 音樂清單；
• 離家時，系統主動確認不需要運作的設備已經關閉。

這些需求的共同點，是觸發條件和執行動作可能來自不同品牌。單一品牌的 App 很擅長控制自己的產品，但當我想把整個家當成一套系統時，就需要一個站在所有設備上方的中控平台。

Home Assistant 是什麼

Home Assistant 是一套開源的智能家居平台。它的工作不是取代每一台家電，而是把不同品牌、不同協定的設備整合到同一個系統裡，再用統一的方式讀取狀態和執行動作。

設備接進 Home Assistant 之後，會以一個或多個「實體」（entity）呈現。例如燈可能是 light、環境感測器可能是 sensor、電視遙控器可能是 remote。自動化不必一直思考設備原本屬於哪一個 App，而是讀取這些實體的狀態，再呼叫相對應的服務。

這個差異很重要。

以前是我看到濕度太高，再自己打開另一個 App 操作家電；接進 Home Assistant 之後，濕度感測器的讀數可以直接成為另一台設備的觸發條件。原本彼此不認識的產品，開始可以參與同一段流程。

Home Assistant 官方表示，目前平台提供超過一千種內建整合，可以連接大量智能設備與線上服務。它也能和既有的 Apple HomeKit、Google Home、Samsung SmartThings 與 Amazon Alexa 環境並存，因此不必一天之內把原本使用的系統全部換掉。

對我來說，Home Assistant 不是另一個比較大的遙控器，而是讓不同設備彼此溝通的翻譯與協調者。

我為什麼買 Home Assistant Green

決定使用 Home Assistant 之後，下一個問題是要把它安裝在哪裡。

Home Assistant 可以裝在 Raspberry Pi、迷你電腦、虛擬機或其他環境裡，也有人會使用 Docker 自己架設。這些方式有很大的彈性，但也代表我要先處理硬體、作業系統、儲存空間、網路和後續維護。

最後我選擇直接購買 Home Assistant Green。它是官方推出的 Home Assistant 主機，Home Assistant 已經預先安裝完成。接上電源與網路線後，就可以透過手機或網頁跟著引導完成設定。

硬體本身是一台小型、低功耗的專用主機，採用 1.8 GHz 四核心 ARM 處理器、4 GB 記憶體和 32 GB eMMC 儲存空間，並提供 Gigabit Ethernet 與兩個 USB 連接埠。對我而言，最重要的不是規格有多高，而是它把安裝環境先整理好了。

我想把時間花在自動化，而不是安裝

理論上，我也可以找一台現有設備，自己研究 Home Assistant OS 或 Docker 的安裝方式。現在有 AI 可以協助，遇到錯誤時也比以前更容易找到方向。

但「有 AI」不代表安裝和維護就不需要成本。

我之前曾經用 Docker 安裝 OpenClaw，已經踩過不少環境與設定上的坑。容器能不能正常啟動只是第一步，後面還可能遇到權限、網路、儲存位置、更新和重新啟動後資料是否保留等問題。AI 可以幫忙解讀錯誤，實際環境仍然要自己理解和收拾。

所以這次我不想先花一段時間研究怎麼把 Home Assistant 裝起來。我買成品的目的很單純：縮短準備時間，先確認 Home Assistant 能不能解決家裡真正的問題。

Home Assistant Green 並不是唯一的選擇，也未必適合喜歡自己挑硬體、調整系統的人。但如果目標是盡快開始整合設備，而不是先完成一個安裝專案，它對我來說是一條比較直接的路。

第一個情境：用雙門檻控制臥室除濕機

系統開始運作後，我先把臥室的濕度感測器和除濕機接進同一套自動化。以前是我看到濕度太高，再打開另一個 App 操作；現在由 Home Assistant 接手判斷與控制。

我的設定只有三個主要規則：

• 高於 70% 持續 5 分鐘，才開啟除濕機；
• 低於 60% 持續 10 分鐘，才關閉除濕機；
• 開機後最多等待 30 秒確認設備回報 on，再把成功或逾時結果通知到手機。

開啟和關閉使用不同門檻，是為了避免濕度在 70% 附近波動時，讓除濕機頻繁開關。這裡的 5 分鐘與 10 分鐘也不是設備固定運轉時間，而是濕度必須連續符合條件的時間，可以排除短暫的感測變化。

我也讓這段自動化在 Home Assistant 啟動時重新判斷濕度。即使系統重啟時房間早已高於 70%，也能補上應該執行的動作。這個小情境讓我第一次感受到：不同品牌的設備不只可以放在同一個介面裡，還能真正接力完成一件事。

第二個情境：料理模式自動播放 YouTube 音樂

另一個我實際做的功能是料理模式，建立一個料理模式按鈕。按下後，Home Assistant 會先開啟電視相關設備，等待五秒讓小米電視完成啟動，再透過 Android TV Remote 要求電視播放指定的 YouTube 音樂清單。

為了不要每次都從同一支影片開始，程式會從預先設定的影片 ID 中隨機選一支，再帶著 playlist ID 開啟。最後送給電視的播放網址概念上會像這樣：

https://www.youtube.com/watch?v=<隨機影片>&list=<音樂清單>

這不是什麼大型系統，但它把原本需要好幾個步驟完成的事情，變成一個符合日常情境的按鈕。我不用先開電視、等開機、找到 YouTube，再選擇音樂；對系統來說，也不只是把幾個開關同時打開，而是按照設備真正需要的順序執行。

我開始在意的，不只是「能不能動」

做到這些自動化之後，我很快又遇到下一層問題。 如果濕度高於 70% 持續 5 分鐘後，除濕機仍然沒有開啟，我想知道是感測器沒有更新、自動化沒有被觸發，還是控制指令送出後設備沒有反應。料理模式沒有播放音樂時，我也需要分辨問題是在電源、五秒的等待時間、電視遙控器整合，還是 YouTube 播放網址。

自動化愈貼近日常生活，我就愈不希望它是一個只能祈禱成功的黑盒子。我開始在意狀態是否正確、每一步有沒有留下足夠的日誌、服務重新啟動後流程會怎麼處理，以及控制指令送出後能不能驗證結果。

Home Assistant 內建的 YAML automation 很適合從簡單流程開始，我最初也使用這種方式。但當自動化逐漸出現延遲、狀態管理、驗證、重試與取消排程等需求後，YAML 開始變得不容易閱讀和維護。

從控制設備，到建立自己的生活流程

回頭看，我開始使用 Home Assistant 的原因，不是對 Apple Home 或 Aqara 不滿意。它們在各自適合的範圍裡仍然很好用，我也不需要為了使用 Home Assistant 就把既有系統全部拆掉。

真正的轉折，是我希望智能家居不再被品牌邊界切成好幾塊。

Home Assistant Green 讓我跳過安裝作業系統的準備期，先把時間放在設備整合與生活情境上。用雙門檻自動控制臥室除濕機，以及用料理模式讓小米電視播放 YouTube 音樂，看起來都只是小功能，卻讓原本各自獨立的設備第一次真正合作。

當然，整合只是開始。流程變多之後，新的問題就從「怎麼讓設備連在一起」，變成「怎麼讓自動化保持清楚、可靠，而且方便修改」。

下一篇智能家居系列，我會從實際的自動化程式出發，整理我為什麼逐漸把較複雜的 YAML automation 改成 Python 腳本，以及 AppDaemon 在這個過程中替我解決了什麼問題。