Home Assistant：自建智能家居中枢，先想清楚「断网了还能不能开灯」
智能家居最关键的一条判断标准：网络断了，灯还能不能开、窗帘还能不能关。云方案通常不能；本地自动化可以。这就是自建中枢的意义。
一、三种安装形态，选错会返工
| 形态 | 适合 | 代价 |
|---|---|---|
| Home Assistant OS | 专用小主机（迷你主机、树莓派） | 整个系统被接管，不能装别的服务 |
| Supervised | 想同时跑别的容器 | 依赖 Debian 基础环境，升级偶发冲突 |
| Container（Docker） | 已有 NAS 或服务器 | 没有官方插件商店，需要自己起配套服务 |
大多数人的实际情况是「已经有一台 NAS 或服务器」，于是选 Container。但它有个隐性代价：很多便利功能（语音助手、ESPHome 编译、备份托管）依赖 Supervisor，容器版要自己找替代方案。
二、容器版最小部署
services:
homeassistant:
image: ghcr.io/home-assistant/home-assistant:stable
restart: unless-stopped
network_mode: host
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
environment:
- TZ=Asia/Shanghainetwork_mode: host 不是可选项而是必需的——它靠 mDNS/SSDP 自动发现局域网设备（音箱、电视、打印机），桥接网络下发现功能基本失灵。
三、接入设备的三条路
- Wi-Fi 设备：多数靠厂商云 API，本地化程度最低，断网就失效；
- Zigbee / Z-Wave：需要一个 USB 网关棒，设备直连本地，断网仍可控——这是最推荐的路线；
- 有线/局域网协议：部分品牌支持本地 API，需要逐台确认，通常要在路由器上做固定 IP。
如果从零开始布设备，优先买 Zigbee 系的传感器和开关。多花的那点钱，换的是「断网也能用」。
四、自动化的正确写法
新手最容易写出的自动化是「如果 A 发生，就做 B」，然后发现半夜灯乱亮。稳的写法要加三个约束：
- 条件：只在特定时段/在家状态执行；
- 冷却：同一自动化短时间内不重复触发；
- 手动优先：人手动改过状态后，一段时间内自动化不覆盖。
第三条最能提升体感。自动化把灯调暗，你又拧亮了，它立刻再调暗——这种「跟系统打架」的体验会让人很快关掉全部自动化。
五、暴露到公网的安全底线
它一旦开放在公网，就变成了一个能控制你家所有设备的入口。三条底线：
- 不要直接端口映射，走反向代理 + HTTPS；
- 开启双因素认证，并关闭默认管理员名；
- 更稳的方案是不暴露：用组网工具把手机和家里打通，只在虚拟局域网内访问。
组网方案见 WireGuard 自建 VPN 与 Headscale。
六、它的隐性成本
真正的成本不是服务器，是设备兼容性和持续折腾：一次版本升级可能让某个自定义卡片失效，某个品牌改了 API 就要重新适配。如果你的目标是「装上就不管」，成品方案反而更省心。
它适合的是「愿意花周末调自动化」的人——这类人会觉得它值，其他人会觉得它是个无底洞。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论