如果家中的智能开关必须依赖厂商服务器才能工作，那它就不该进入我的家门。这是我在十年家庭自动化实践中坚守的第一准则，其余原则皆由此衍生。
云端是薄弱环节
一次性购买的硬件不应因厂商策略变更而停摆，但现实往往相反：Google曾破坏Nest API导致集成失效；三星冰箱屏幕弹出TLS证书错误；Camp Chef烤炉控制器甚至需联网才能显示温度。
我仍使用Alexa和AWS等云服务，但仅作为补充。家庭运行的核心逻辑必须本地化：ESP板运行Tasmota固件，通过MQTT代理通信，由树莓派上的Node-RED处理逻辑。即使互联网中断，家中设备仍需正常运行。
核心规则演进
基于早期实践，我确立了以下基础规则：
- 断网无忧：核心功能必须在无网状态下正常工作。
- 新旧并存：引入新方案时保留旧机制，避免如“用胶带粘住墙壁开关”般的尴尬妥协。
- 保持敏捷：适应房间用途变化和人员流动，确保低成本调整。
- 审查自动化：定期检查流程，避免多个触发器冲突（如四个定时器同时控制同一水泵）。
- 例外需正当：打破规则的理由必须经得起时间考验。
随着家庭人口增加，我在入住第五年补充了新规则：
- 拒绝黑盒：云设备必须具备带日志的API，否则不予安装。
- 集中配置：统一管理配置信息，而非分散在多个厂商App中。
- 多元访问：支持App、语音、二维码或NFC等多种控制方式。
- 例行程序化：将重复动作序列转化为标准化“例行程序”。
- 解耦通信：设备间通过MQTT发布/订阅通信，避免点对点硬连接。
- 电池长效：除非续航超一年，否则不使用电池供电，避免关键时刻掉链子。
从单人到多人的架构升级
早期的自动化假设仅有一人居住。当家庭成员增加，物理钥匙管理、长时间离家带来的故障风险（如水浸）迫使系统升级。我从单用户修补转向多用户适配，引入了更严格的漏水和存在检测机制。
为解决“App碎片化”问题，我构建了一个集中式仪表盘，运行在壁挂平板电脑上。它整合了车库门控制、门锁状态、灯光调节及环境监测数据，取代了家中繁多的独立App。电视环境光也接入同一系统，提升了生活质量。
技术栈方面，Node-RED处理逻辑，Grafana提供可视化监控，Tasmota作为设备固件，Telegram发送通知。MQTT是关键解耦层：传感器发布数据，无需关心谁在监听；手机和后端均可订阅同一主题。
读者反馈与社区共识
在分享“断网无忧”原则后，大量用户分享了痛点：因App错误无法调温的冰箱、断网无法切换输入的电视、需联网才能使用的厨房排气扇等。这些案例印证了云端依赖的风险。
社区补充的关键建议包括：
- 离线优先：核心操作（开关、温控、安防）必须本地运行，互联网仅用于附加功能。
- 视第三方为风险：规划本地回退方案，核心功能不依赖云端API。
- 访客友好：访客应能在无App账户情况下使用基本功能，否则设计即失败。
- 清理遗留设备：移除废弃联网设备，防止成为安全漏洞。
在协议选择上，许多用户推荐Zigbee和Z-Wave优于Wi-Fi，因其更稳定且无需云端介入。对于远程访问，Tailscale和OpenVPN成为保持本地化的主流方案。此外，维修权运动被视为对抗厂商锁定的重要力量。
推荐硬件清单
以下是经长期验证的稳定组件：
灌溉控制系统
- 主控：HiLetgo ESP8266 NodeMCU（刷写Tasmota）
- 显示：SSD1306 OLED屏幕
- 执行：Inkbird SSR-40DA固态继电器（控制24 VAC阀门）
- 传感：BME280（温湿度气压）
灯光与电源
- 开关：Martin Jerry智能调光开关（预装Tasmota）
- 插座：Sonoff S31（支持电源监控）
- 工具：USB转串口适配器（用于固件刷写）
车库自动化
- 中枢：Raspberry Pi 3（运行Docker/Web API）
- 控制：SunFounder双通道5V继电器模块
- 兼容：LiftMaster有线控制面板（绕过防篡改布线）
全屋基础
- 网络：GL.iNet Flint 2路由器（运行OpenWrt及本地MQTT代理）
- 交互：廉价平板电脑（壁挂仪表盘）
- 清洁：Lefant扫地机器人