🏠 智慧家庭教學懶人包
這份智慧家庭教學帶你從零開始，打造完全自主可控的居家自動化系統，資料只經過你自己的伺服器，不受廠商綁定。
項目 重點說明 智慧家庭教學 整合 GCP VM + MQTT + 開發設備 的自主可控方案 自製 Google Home 裝置 透過 Cloud-to-cloud 整合實現語音控制 LINE 控制家電 Flex Message 互動介面，免安裝額外 App MQTT mTLS 教學 雙向憑證驗證，無需帳號密碼的企業級安全 Node.js IoT 實戰 常駐記憶體數十 MB 的輕量 API 伺服器 👇 詳細內容請往下閱讀 👇
為什麼要自建智慧家庭系統？商業方案的 3 大隱患
商業智慧家庭產品會將資料上傳到廠商雲端、綁定特定品牌生態系、且有月費訂閱成本。自建系統讓資料只存在你自己的 GCP VM，擁有完整控制權且零月費。
風險一：隱私資料流向廠商伺服器
自建系統的優勢在於資料只經過你自己控制的 GCP VM。你有 root 權限、可以查看所有 log、隨時刪除資料。雖然仍是「雲端」，但這是你自己的雲端，不是廠商的黑盒子。
小米、Tuya、Apple HomeKit 等商業方案，你的設備狀態、使用習慣都會上傳到廠商伺服器。根據 Mozilla Privacy Not Included 專案 評測，多數智慧家庭產品存在隱私疑慮。
風險二：品牌生態系綁定
買了小米就被鎖在米家生態系，想換 HomeKit 就要整組砍掉重練。商業產品的互通性極差，即使 Matter 協議正在推動，目前裝置支援度仍不完整。
本教學採用開放標準：MQTT 協議、REST API、OAuth 2.0。任何支援這些標準的平台都能整合，不會因為單一廠商策略改變而被迫換系統。
風險三：月費訂閱與服務終止
部分商業方案收取月費才能使用進階功能，或者廠商倒閉直接停止服務。智慧家庭品牌收攤導致既有設備失去雲端功能的案例不只一樁（Insteon 在 2022 年就發生過）。這正是「控制邏輯放在自己手上」的理由——雲端只該負責轉送指令，不該是設備能不能動的前提。
使用 GCP 的 Always Free 額度，只要留在方案規範內，每月支出可以是 0 元——額度內容以 Google Cloud Free Program 官方頁面為準，且需注意外部 IP 另計費。即使未來 GCP 政策改變，所有程式碼都在你手上，可以隨時遷移到其他 VPS 或甚至本地 Raspberry Pi。
自製 Google Home 裝置：語音控制整合實戰
自製 Google Home 裝置透過 Cloud-to-cloud 整合方式，讓你的 DIY 設備出現在 Google Home App 中，支援「Ok Google, 打開客廳燈」等語音指令。
這套方案不需要購買任何 Google 官方硬體。只要你有一支 Android 手機或 Google Nest 音箱，就能對自製的設備下達語音指令。從說出指令到燈泡亮起的延遲，取決於你的網路與雲端往返，實測多半落在一到兩秒。這段延遲主要花在語音辨識與雲端轉送，不是你的樹莓派慢。
Google Home Developer Console 設定流程
首先前往 Google Home Developer Console 建立專案。選擇「Cloud-to-cloud」整合類型，這代表你的設備透過自己的伺服器與 Google 通訊，而非直接連接 Google 雲端。
Google Home Developer Console 的 Cloud-to-cloud 整合設定頁面（AI 生成示意圖）
Account Linking 設定是關鍵步驟。你需要提供 OAuth 2.0 授權端點，讓 Google 能夠驗證使用者身份。我們的 Node.js 伺服器已內建 /oauth/authorize 與 /oauth/token 端點，只需將 URL 填入設定即可。
Fulfillment URL 與 Intent 處理
Google 會向你的 Fulfillment URL 發送三種主要 Intent：SYNC（同步設備清單）、QUERY（查詢設備狀態）、EXECUTE（執行控制指令）。每種 Intent 都有固定的 JSON 格式，你的伺服器必須正確回應。
SYNC Intent 回傳的設備資訊包含 type（設備類型）、traits（支援功能）、name（顯示名稱）。例如電燈設備使用 action.devices.types.LIGHT 類型搭配 action.devices.traits.OnOff 功能。
測試人員新增與權限設定
開發階段的 Google Home 整合只有專案成員能使用。若要讓家人一起測試，需要在 GCP IAM 中新增他們的 Gmail 帳號並授予「編輯者」角色。測試人員登入 Developer Console 後點擊「Test」按鈕，才能在 Google Home App 中找到 [test] 開頭的服務。
LINE 控制家電：免 App 即時操控方案
LINE 控制家電利用 Messaging API 與 Flex Message 技術，讓你直接在 LINE 對話中傳送指令或點擊按鈕，完全不需要安裝額外 App。
在台灣，LINE 幾乎是預設安裝的通訊軟體。拿它當控制介面的好處是不必再教任何人使用新 App——阿公阿嬤只要會傳訊息，就能操控家電。
這裡示範的是自家設備的個人專案。如果要接的是公司內部查單、簽核、告警這類跑在企業帳號下、需要權限與稽核的場景，做法規格更完整，見 LINE 企業應用開發。
LINE Developers Console 設定
前往 LINE Developers Console 建立 Messaging API Channel。記下 Channel Secret 與 Channel Access Token，這兩個憑證將用於驗證 Webhook 請求與發送回覆訊息。
Webhook URL 設定為 https://你的網域/webhook/line。記得關閉「Auto-reply messages」自動回覆功能，否則 LINE 官方回覆會與你的 Bot 回覆重疊。我們建議同時關閉「Greeting messages」歡迎訊息。
Flex Message 互動介面設計
按鈕的 action 設定為 message 類型，點擊後會自動發送預設文字如「開客廳燈」。這個文字觸發 Bot 的指令解析流程，形成完整的互動循環。
純文字回覆雖然簡單，但使用者體驗不佳。Flex Message 提供類似 App 的卡片式介面，支援按鈕、圖片、表格等豐富元素。我們設計的設備狀態卡片會顯示每個設備的名稱、目前狀態（開啟/關閉/離線），以及可點擊的控制按鈕。
中文指令解析器實作
中文自然語言處理是 LINE 控制家電的核心挑戰。我們建立了動作關鍵字表（開/關/切換）、房間別名表（客廳/臥室/廚房）、設備別名表（燈/風扇/冷氣），透過字串比對組合出完整指令。
例如「幫我把房間的電燈打開」會被解析為 room=bedroom, device=lamp, action=ON。系統容許模糊輸入，「開燈」「打開燈」「把燈開起來」都能正確識別。
MQTT mTLS 教學：企業級加密通訊架構
MQTT mTLS 教學的雙向憑證驗證架構（AI 生成示意圖）
MQTT mTLS 教學說明如何使用雙向 TLS 憑證驗證取代傳統帳號密碼，讓每個 IoT 設備擁有獨立身份憑證，封包加密傳輸且無法冒充合法設備發送指令。
傳統 MQTT 認證使用 username/password，一旦洩漏就會危及整個系統。mTLS（Mutual TLS）要求雙方都出示憑證，伺服器驗證客戶端、客戶端也驗證伺服器，達到零信任架構的安全標準。
憑證體系建立流程
憑證的 CN（Common Name）欄位非常重要。Mosquitto 設定 use_identity_as_username true 後，會將憑證 CN 作為使用者名稱記錄。我們為每個 ESP8266 設備簽發獨立憑證，CN 設為 esp-lamp-01、esp-fan-01 等，便於日誌追蹤。
整個 mTLS 架構需要三種憑證：CA 根憑證（簽發其他憑證的權威）、伺服器憑證（Mosquitto Broker 使用）、客戶端憑證（Node.js 與 終端IoT設備 各一份）。我們使用 OpenSSL 指令產生，CA 設定 10 年效期，其他憑證 5 年效期。
Mosquitto Broker 安全設定
內網連線使用 127.0.0.1 監聽，即使沒有開防火牆也無法從外部存取。外網的 8883 端口則需要在 GCP 防火牆與 VM 的 ufw 同時開放。
Mosquitto 設定檔中，require_certificate true 強制要求客戶端憑證，allow_anonymous true 代表不需要額外密碼驗證（因為憑證本身就是身份證明）。我們設定兩個監聽端口：1883 供內網的 Node.js 使用，8883 供外網的 終端IoT設備 使用。
憑證更新與撤銷策略
憑證過期前需要重新簽發。我們建議建立排程腳本，在到期前 30 天自動產生新憑證並透過 OTA（Over-the-Air）更新推送到 終端IoT設備。若設備遺失，可將該設備的憑證加入 CRL（Certificate Revocation List）撤銷清單。
Node.js IoT 實戰：API 伺服器完整建置
Node.js IoT 實戰的伺服器模組化設計（AI 生成示意圖）
Node.js IoT 實戰展示如何用 Express 框架建立輕量 API 伺服器，整合 MQTT 客戶端、LINE Webhook、Google Home Fulfillment 三大功能。
Node.js 的事件驅動非同步架構天生適合 IoT 場景。單一程序可同時處理數百個 MQTT 訊息與 HTTP 請求，常駐記憶體通常只有數十 MB（自己用 ps -o rss= -p $(pgrep -f node) 量一次就知道），在 GCP e2-micro 的 1GB RAM 下綽綽有餘。
專案架構與模組分離
我們採用路由分離架構：src/routes/line.js 處理 LINE Webhook、src/routes/google.js 處理 Google Home Intent、src/routes/oauth.js 處理 OAuth 授權流程。共用模組包含 src/mqtt.js（MQTT 連線管理）、src/devices.js（設備清單）、src/parser.js（指令解析器）。
這種架構讓程式碼易於維護。新增設備只需修改 devices.js，新增 LINE 指令只需修改 parser.js，不會影響其他模組。
設備狀態快取機制
QUERY Intent 直接讀取快取回傳，省掉一趟到設備的往返——差別在於「等設備回話」與「讀一次記憶體」，量級差距很明顯，實際數字請以自己的環境為準。快取的一致性由 MQTT 的 retain 機制保證：設備重新上線時會發布 retained 狀態訊息，確保快取與實際狀態同步。
每次 Google Home 查詢都會觸發 QUERY Intent，若即時向 ESP8266 詢問狀態會增加延遲。我們在 Node.js 中建立 deviceStates Map 物件，訂閱所有 home/+/+/state 主題，終端IoT設備 每次狀態變更都會更新快取。
systemd 服務與自動重啟
Node.js 程式需要設定為系統服務才能在 VM 重開機後自動啟動。我們建立 /etc/systemd/system/smarthome.service 設定檔，指定 Restart=on-failure 讓程式異常終止時自動重啟。RestartSec=5 避免快速重啟造成資源耗盡。
使用 journalctl -u smarthome -f 可即時查看服務日誌，方便除錯。
韌體開發：硬體端程式撰寫指南
使用 PlatformIO 開發 ESP 韌體並燒錄至開發板（AI 生成示意圖）
韌體開發使用 PlatformIO 環境與 Arduino 框架，透過 WiFiClientSecure 函式庫實現 mTLS 加密連線，支援實體按鈕、繼電器控制與 LWT 遺囑機制。
ESP系列 晶片內建 Wi-Fi 功能，開發板價格不到百元，是入門智慧家庭教學的最佳選擇。我們選用 NodeMCU 或 D1 Mini 開發板，GPIO 腳位充足且社群資源豐富。
PlatformIO 開發環境設定
Arduino IDE 雖然入門簡單，但缺乏專案管理功能。PlatformIO 是 VS Code 的擴充套件，提供程式庫管理、多板支援、Serial Monitor 整合。platformio.ini 檔案定義板型、框架與相依套件，一鍵即可編譯燒錄。
們使用的 knolleary/PubSubClient 是最廣泛使用的 Arduino MQTT 函式庫。搭配 終端IoT設備 原生的 BearSSL 加密引擎，可在有限的記憶體中實現完整 TLS 握手。
mTLS 憑證嵌入技巧
BearSSL::X509List 物件載入 CA 憑證，BearSSL::PrivateKey 載入客戶端私鑰。設定 wifiClient.setClientRSACert() 後，每次 TLS 連線都會自動出示憑證。
ESP8266 的 Flash 空間通常為 1-4MB（視模組型號），無法像桌面系統從檔案讀取憑證。我們將 PEM 格式的憑證內容直接寫在 certs.h 標頭檔中，使用 PROGMEM 關鍵字存放在 Flash 而非 RAM，節省寶貴的 80KB 可用記憶體。
LWT 遺囑與在線偵測
MQTT 的 LWT（Last Will and Testament）機制讓伺服器能偵測設備離線。我們在 mqtt.connect() 時指定 LWT 主題為 home/living/lamp/online，訊息為 "false"，retain 設為 true。
設備正常連線後會發布 "true" 到同一主題覆蓋遺囑。若設備斷線，Broker 會自動發布遺囑訊息。Node.js 訂閱這些主題，即時更新設備在線狀態供 Google Home 與 LINE 查詢。
系統完成後的進階擴充：Matter 整合與 AI 自動化
完成這套智慧家庭教學後，可朝 Matter 協議橋接、AI 場景自動化、更多設備類型三個方向擴充，現有 MQTT 架構能無縫銜接這些進階應用。
完成本教學後，你已具備獨立建置智慧家庭系統的能力。接下來可以探索更進階的應用場景，讓系統更加智能化。
Matter 協議橋接方案
Matter 是 Apple、Google、Amazon 聯合推動的智慧家庭統一標準。雖然目前裝置支援度仍在成長中，但 MQTT 與 Matter 並非互斥。你可以建立 Matter Bridge，將現有 ESP8266 設備橋接到 Matter 生態系。
根據連接標準聯盟（CSA）官網資料，已有超過 3,000 款 Matter 認證產品。我們建議持續關注 ESP32 的 Matter SDK 發展，未來新設備可直接採用原生 Matter 支援。
AI 場景自動化
目前的系統是「指令驅動」：你說開燈，燈才會開。下一步可以整合感測器資料與規則引擎，實現「場景驅動」自動化。例如結合人體感應器、光照感測器、時間排程，讓系統自動判斷是否需要開燈。
你可以在 Node.js 伺服器中加入規則引擎如 Node-RED，或串接 Home Assistant 等開源平台獲得更豐富的自動化功能。進階用戶甚至可以導入機器學習模型預測使用者習慣。
擴充更多設備類型
本教學以電燈為範例，但相同架構可擴展到風扇、冷氣、窗簾、門鎖等設備。差異僅在於 終端IoT設備 的 GPIO 接線與 Google Home 的 device type 設定。
進階用戶可以挑戰 PWM 調光、紅外線遙控（控制傳統冷氣）、RFID 門禁等應用。每新增一種設備，只需在 devices.js 註冊、parser.js 加入別名即可。
需要專業協助？克隆資訊智慧建築服務
如果你覺得自己建置太費時，或是需要更複雜的企業級整合方案，克隆資訊提供完整的IoT 與監控系統整合服務。從需求規劃、硬體採購、系統建置到後續維護，我們都能一手包辦。 無論是住宅智慧化、辦公室自動控制、或是整棟大樓的 IoT 整合，都歡迎與我們聯繫討論。
延伸閱讀
- 擔心雲端服務停止或隱私外洩：本地化智慧家庭完整指南：5 大理由拒絕雲端
- 想強化 LINE 端的 AI 對話能力：Gemini 串接 LINE Bot 教學：用 GAS 免伺服器做 AI 助理
💡 常見問題
Q1: 這套智慧家庭教學的硬體成本大約多少？
A: ESP 開發板約 50 元、繼電器模組約 30 元、杜邦線與麵包板約 50 元、電源模組約 40 元，單一設備總成本約 100-200 元。GCP VM 使用免費額度，伺服器端零成本。
Q2: 自製 Google Home 裝置可以讓家人一起使用嗎？
A: 可以。在 GCP IAM 新增家人的 Gmail 帳號並授予編輯者角色，他們登入 Developer Console 點擊 Test 後，即可在自己的 Google Home App 連結服務。
Q3: LINE 控制家電支援哪些指令格式？
A: 支援自然語言如「開客廳燈」「關臥室風扇」「查詢狀態」，也支援點擊 Flex Message 按鈕直接操作。系統會自動識別房間別名與設備別名。
