NAS 掛了怎麼辦？HA 要怎麼設計才不會一起死

charles · 發表於 3 天前

這篇講的是依賴關係的設計，
一個很多人做到第二年才意識到的問題。

先畫出依賴圖

拿紙筆，寫下「誰需要誰才能運作」：

HA ──需要──> Zigbee 協調器（USB，本地）
HA ──需要──> MQTT Broker
HA ──需要──> 路由器（區域網路）
HA ──可選──> 網際網路（雲端整合）
HA ──可選──> NAS（備份、Frigate、InfluxDB）
Zigbee 裝置 ──需要──> MQTT（如果用 Z2M）
攝影機 ──需要──> NAS（Frigate）
歷史圖表 ──需要──> NAS（InfluxDB）

複製代碼

然後問：每一個掛掉的話，會失去什麼？

我自己畫完之後發現的問題

MQTT 跑在 NAS 上，而 NAS 每週會自動重開一次做維護。

那段時間：

所有 Zigbee 裝置在 HA 裡變成 unavailable
所有感應燈失效
所有依賴這些裝置的自動化全部停擺

而我完全沒把這兩件事聯想在一起。
只覺得「有時候家裡的燈就是怪怪的」。

依賴分級：三個等級

等級 1：關鍵路徑（不能掛）

掛了的話，基本的智能家居功能就停擺。

HA 主機本身
Zigbee 協調器
MQTT Broker（如果用 Z2M）
區域網路（路由器 / 交換器）

設計原則：這些東西要放在同一個「故障域」裡。

意思是：要嘛一起活，要嘛一起死，
不要出現「A 活著但 B 掛了」的半死狀態 —— 那是最難處理的。

所以 MQTT Broker 應該跟 HA 放同一台機器。

等級 2：增強功能（掛了會降級但還能用）

網際網路（雲端整合、遠端存取）
NAS（備份、影像辨識、長期數據）
語音助理

設計原則：自動化要能在這些東西掛掉時「優雅降級」。

等級 3：純粹的加分項

Grafana 圖表
天氣整合
行事曆

怎麼寫「會優雅降級」的自動化

壞的寫法：

actions:
- action: notify.mobile_app_charles # 需要網路
data:
message: >
外面 {{ states('sensor.outdoor_temp') }} 度 # 需要天氣整合
- action: light.turn_on
target: {entity_id: light.living_room}

複製代碼

如果網路掛了，第一步會失敗，整個自動化中止，燈不會開。

好的寫法：把「必要的」放前面

actions:
# 1. 最重要的先做
- action: light.turn_on
target: {entity_id: light.living_room}
# 2. 加分的放後面，而且加 continue_on_error
- action: notify.mobile_app_charles
continue_on_error: true
data:
message: >
外面 {{ states('sensor.outdoor_temp') | default('未知') }} 度

複製代碼

continue_on_error: true 讓那一步失敗也不會中止整個流程。

這個參數很多人不知道，但它是寫韌性自動化的關鍵。

另一個技巧：先判斷依賴還活著嗎

actions:
- choose:
- conditions:
- condition: state
entity_id: binary_sensor.外網連線
state: "on"
sequence:
- action: notify.mobile_app_charles
data: {message: "..."}
default:
# 沒網路的話改用本地的方式提醒
- action: light.turn_on
target: {entity_id: light.玄關}
data: {flash: short}

複製代碼

範本一定要給預設值

# 壞：感測器不可用就整個報錯
{{ states('sensor.outdoor_temp') | float > 28 }}
# 好
{{ states('sensor.outdoor_temp') | float(99) > 28 }}

複製代碼

預設值要選對方向：
上面給 99 是因為「抓不到室外溫度的話，寧可當成很熱讓冷氣開」。

給 0 的話，天氣整合掛掉就永遠不開冷氣了。

實際的架構建議

建議一：MQTT 跟 HA 同機

用 HA 的 Mosquitto 附加元件，或者在同一台主機跑容器。

代價：HA 重啟時 MQTT 也會重啟。
但這比「NAS 重開造成 HA 半死」好處理多了。

建議二：Zigbee 協調器直接插在 HA 主機上

不要用網路版的（Zigbee over IP / SLZB 之類的），
除非你有特殊需求。

多一層網路就多一個故障點。

（網路版的優點是可以放在訊號好的位置，這是真實的取捨。
如果你真的需要，記得用有線網路而不是 Wi-Fi。）

建議三：本地控制優先

裝置選擇上：

優先選 Zigbee / Z-Wave / Matter over Thread（本地）
避免只有雲端 API 的裝置
Wi-Fi 裝置優先選能刷 ESPHome 或 Tasmota 的

建議四：保留實體操作方式

這個前面講過很多次：

燈 → 牆上開關要能用
冷氣 → 遙控器要能用
門鎖 → 實體鑰匙

建議五：關鍵裝置接 UPS

路由器
HA 主機
網路交換器

一台小 UPS 大概兩三千，
但它讓「停電十分鐘」從「全屋失控」變成「沒感覺」。

而且 UPS 通常可以接進 HA（透過 NUT 或 USB），
做「停電時發通知 + 進入省電模式」的自動化。

建議六：做一個「系統健康」儀表板

把所有依賴的狀態放在一頁：

type: entities
title: 系統健康
entities:
- entity: binary_sensor.外網連線
- entity: binary_sensor.mqtt_broker
- entity: binary_sensor.nas_可達
- entity: sensor.zigbee_裝置數
- entity: sensor.不可用的實體
- entity: sensor.ha_運行時間
- entity: sensor.資料庫大小

複製代碼

出問題的時候看這一頁，三十秒知道是哪一層。

測試你的設計

這是最重要的一段，而且幾乎沒人做。

找一個週末下午，故意把東西關掉：

拔掉網路線 —— 感應燈還會動嗎？
關掉 NAS —— 哪些東西失效了？
重啟 MQTT —— 多久恢復？裝置會全部回來嗎？
拔掉 Zigbee 棒再插回去 —— HA 會自動恢復嗎？

每一項記錄下來：失去什麼、多久恢復、要不要人工介入。

我第一次做這個測試的時候發現：

拔網路線：感應燈正常（Zigbee 是本地的）✓
關 NAS：所有 Zigbee 裝置消失 ✗（那時候 MQTT 在 NAS 上）
重啟 MQTT：裝置要等五分鐘才回來 ✗
拔 Zigbee 棒再插：HA 沒有自動恢復，要重啟 ✗

三個問題，都是測試才發現的。

最後一個原則

「智能家居壞掉的時候，家要退化成一個正常的家，不是一個壞掉的家。」

差別在哪：

正常的家：燈用開關開、冷氣用遙控器、門用鑰匙。不方便但一切正常
壞掉的家：燈不會亮、冷氣關不掉、門打不開

每次加一個新東西，都要問一次：它壞掉的時候，會變成哪一種？

---

我自己後來的調整：

MQTT 從 NAS 搬到 HA 主機
HA 主機和路由器接同一台 UPS
所有燈都保留實體開關
做了一頁系統健康儀表板
每季做一次「故意弄壞」的測試

最後一項最有價值，因為它會逼你發現你以為沒問題的地方。

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

NAS 掛了怎麼辦？HA 要怎麼設計才不會一起死

瀏覽過的版塊