构建本地优先的智能家居以避免对云端的依赖

如果一个智能家居设备需要云端连接才能执行基本任务——例如烤肉架控制器仅为了显示当前温度就需要Wi-Fi——这对于房主来说就是一个显著的故障点。为了降低这些风险，一些用户正在采用“本地优先”架构，在这种架构中，主要的逻辑和设备通信完全发生在家庭内部网络中。

云端依赖的风险

许多现代智能家居设备被设计为依靠制造商云服务器运行的“黑盒”。如果该服务器下线，或者公司倒闭并关闭其 API，硬件可能会变得毫无用处。例子包括由于应用程序错误而无法更改温度的智能冰箱，或者一旦支持公司停止运营就彻底停止工作的肉类温度计。

这张图片展示了文中提到的具体云端依赖设备示例，如智能冰箱和烤肉架控制器。

除了服务中断外，云端依赖还为用户的日常生活创造了一个单点故障。如果恒温器或智能锁需要活跃的互联网连接才能响应命令，简单的 ISP 断网就可能导致家庭基础设施失去响应。本地优先的方法将互联网视为远程访问的可选次要路径，而非基本运行的必要条件。

“没网络也没问题。核心功能必须能在拔掉网线的状态下工作。”

— Smart home devices should work without the internet — Do Code That Matters

本地优先系统的架构

稳健的本地优先设置依赖于解耦的通信模式，通常使用 MQTT 协议。在这种模型中，传感器将其数据发布到本地代理，任何授权设备（如仪表盘或手机）都可以订阅这些数据。这确保了传感器不需要知道谁在监听或数据如何被使用，使系统更加敏捷且易于修改。

基础架构通常涉及一个中央枢纽（例如 Raspberry Pi），通过 Node-RED 等工具运行自动化逻辑。设备通常由运行 Tasmota 固件的 ESP32 微控制器驱动，这允许它们被刷入纯本地功能。这种设置能够让复杂的流程完全在本地硬件上运行，例如只有当手机在场但汽车不在时才打开车库门。

图片展示了架构部分描述的 Node-RED 自动化逻辑和数据流。

权衡与实际实施

虽然本地优先系统提供了卓越的可靠性和隐私性，但它们需要更高水平的初始投入和技术配置。用户必须管理自己的硬件，这可能包括 3D 打印的外壳、自定义 PCB 布局以及手动刷写固件。这是与那些自带预配置应用程序的大众市场云端设备的“即插即用”便利之间的权衡。

此视觉效果支持对本地优先实施所需的硬件、固件（Tasmota）和自定义 PCB 布局的描述。

随着家庭从单用户环境演变为多用户环境，本地系统的复杂性会增加。它需要提供多种与房屋交互的方式，如物理钥匙、NFC 标签和墙挂式平板电脑，以确保每个人无论技术熟练程度如何都能操作房屋。目标是确保虽然底层系统非常精密，但用户体验依然简单且易于获取。