為什麼我把 Homebridge 換成了 Home Assistant

這個標題頗有 Geek 的風格，因為在網路上常常會遇到類似「為什麼我把 iPhone 換成了 Android 手機？」或是「為什麼我把 CentOS 換成了 Ubuntu？」諸如此類的文章。

在這個月初，我逐漸意識到 Apple 的系統穩定性大不如前，不論是 iOS 或 macOS。我知道 Apple 近幾年的商業發展還是一路高漲，特別是親近大陸市場之後。機緣巧合之下，前段時間我被迫用了 Ubuntu 和 Windows 10 兩個系統數月，令我欣慰的是 Windows 10 除了不合理的強制更新之外，一切都頗為穩定，至少在我 MacBook 宕機數次的這幾個星期，我的 PC 沒有讓我遇到要拔電源才能繼續的情況。

這讓我覺得，如果我再把自己綑綁在 Apple 的產品和服務身上，我可能會重蹈當年使用 Windows XP 的覆轍。因此我打消了五月份買 HomePod 的念頭，即使它的音質能令我滿意。研究了一下，Google Home 或者 Amazon Echo 也是不錯的選擇，況且我將要去日本了。

縱使 Apple 放開了 HomeKit 的部分限制，例如說不再強制要求通過 HomeKit 的認證，HomeKit 的生態也就是靠一群發燒友維持下去。這段時間我嘗試給兩個比較大的開源項目提交 PR，開發者也沒有理會的意思，再看看上一次 commit 已經是半年前了。我也想過自己 fork 一份另起爐灶，但我不是發燒友，也不喜歡重複造輪子，我只是希望它穩定運行就好。Homebridge 的 homebridge_yeelight 和 homebridge-mi-air-purifier 都仍存在 Bug，而且似乎也難在短期內修復。而反觀 Home Assistant 這邊，已經是官方支持 Yeelight 設備了，插件也更加豐富。

我嘗試過給 Homebridge 加一個 Web GUI 用於在 Mac 或者 PC 控制家電，以為這樣的需求早就會有人完成了，或者是在官方的 road map 中，發現並沒有。Home Assistant 相反，絕大部分的 GUI 都是基於 Web 的。

JavaScript 寫插件太痛苦，而 Home Assistant 可以用我最愛的 Python 語言。再加上 Home Assistant 的配置文件格式為 YAML，而 Homebridge 是 JSON。

基於上述種種原因，我嘗試把 Homebridge 換成了 Home Assistant，沒想到只用了一晚上的時間就部署好了。官方文檔寫得過於詳細了，中文文檔是一個不錯的入門手冊，建議先從中文文檔入手，後期遇到問題直接 Google 搜英文文檔。

已經接入的設備如下：

• Mac Server & Router 使用腳本定時提交設備當前溫度
• 雅虎天氣 API
• UniFi Controller 查看設備在線狀態
• 小米空調伴侶控制空調溫度和開關
• 小米空氣淨化器及其傳感器
• Yeelight 燈組
• WOL 控制 PC 開機
• 小米多功能網關及其自帶的燈與光照強度傳感器
• 小米無線開關
• 小米溫濕度傳感器

Home Assistant 對所有輸入設備的數據都抽象為一個一個的 event，然後通過監聽這些 event 去實現自動化，例如：

• 檢測到我的 iPhone 與 AP 斷開連接，判斷我已經出門，自動檢測空調，燈是否關閉。
• 入夜自動關閉空調和空氣淨化器的 LED 指示燈與提示音，將夜燈亮度調到最低。
• 設置為遊戲場景時，判斷室外溫度是否需要開空調，並將環境燈的色溫調暖，自動啟動遊戲 PC。

歷史記錄也方便查看過去一段時間的狀況，總的來說比 Homebridge 更開放，完成度也更高。