Home Assistant：三年之后

远程控制和看门狗电源切换

• 对于远程重启在其他地点的设备，许多人认为基于云的智能插座是可以接受的，因为网络中断会阻止任何解决方案。
• 建议的替代方案包括：TP-Link Kasa（简单的本地 TCP 协议）、刷入 ESPHome/Tasmota 的 Sonoff/Shelly 插座、SMS/GSM 控制的插座，以及专门的“看门狗”电源线（在 ping 失败时循环断电/上电，尽管有些人觉得太贵）。

采用模式和部署选择

• 有几位用户从其他平台（OpenHAB、Homebridge、X10、厂商应用）迁移过来，发现 HA 的能力明显更强，尤其适合复杂/离网场景。
• 常见部署方式包括：Docker 容器、VM，以及专用的 HAOS 设备；有些人为了增强韧性偏好 ZFS、Proxmox 或由 NFS 支持的存储。
• 像 HACS 这样的附加组件可以让 Docker 也具备类似 HAOS 的可扩展性，不过设置起来可能比较折腾。

自动化 vs 仪表盘与 UX 理念

• 很多人强烈认为，如果你经常用仪表盘来控制设备，说明自动化设计不够好；开关、传感器和 presence 应该处理大部分行为。
• 也有人重视仪表盘用于监控（例如能源、全屋状态）和批量控制（例如“关闭所有灯”）。
• 有些人运行非常“轻量”的自动化；另一些人则积极自动化照明、HVAC 和“模式”（在家/外出/访客）。

开关、场景，以及机械状态 vs 数字状态

• 对于希望物理开关始终反映灯光真实状态的需求，讨论集中在无状态/瞬时开关、电容式/LED 型调光器，以及基于按键和继电器的方案。
• 许多人认为，房间里的灯光才是相关指示；机械位置是否对称更多只是审美问题。

协议：Zigbee、Z-Wave、Matter，以及其他

• Zigbee 和 Z-Wave 被广泛使用；Z-Wave 被认为更贵、更耗电，但可靠，而且设备类型更少。
• 有些人比起 HA 的 ZHA 更偏好 Zigbee2MQTT，因为它支持更广泛的设备并更灵活，代价是复杂度更高。
• 对 Matter 的看法不一：一方面看好其本地控制和多生态支持；另一方面又对当前 Matter 设备经常暴露更少功能（例如缺少能耗指标）且显得不够成熟感到沮丧。

可靠性、更新和存储

• 使用体验从“多年稳定如磐石”到“每次更新都有可能破坏某些东西”不等，尤其是在 YAML 很重或较老的配置中。
• Raspberry Pi 上的 SD 卡被普遍认为不适合长期作为 HA 存储；建议使用 SSD、USB 启动、NAS，或带快照和备份的虚拟化宿主机。
• 有些用户每月更新并跟随发布说明；另一些则延迟更新，并接受跨多个版本时痛苦的补更过程。

专业安装商与长期可行性

• 多位发帖者认为存在一个缺口：拥有遗留或复杂系统的人希望得到专业的 HA 集成，但服务生态却很稀缺。
• 提到的原因包括：变化太快、更新会破坏兼容、第三方集成不受安装商控制、后端与前端紧密耦合，以及支持负担很高。
• 建议包括提供 LTS/稳定版发布通道，以及更清晰地区分“平台”和自定义 UI，不过这需要相当大的投入。

云端 vs 本地优先

• 讨论串中强烈偏好本地控制，以避免供应商锁定、故障、服务条款封禁和产品停运。
• 但也有人仍然为 HA 的云服务付费以便轻松远程访问，或依赖云端语音服务，理由是时间有限，而且其准确性比设备本地方案更好。
• 过去被厂商“砖掉”或性能劣化的经历，推动了很多人转向开放、可本地控制的硬件（通常通过 Zigbee + HA）。

安全、看门狗与故障模式

• 人们担心自动化去控制“绝对”状态，例如供暖设定值或电池充电，而没有独立保护措施。
• 推荐模式是：让 HA 选择模式或日程，但把独立恒温器/安全逻辑留在设备上。
• 对于关键系统，失去联系、温度过低或设备故障时的通知被视为必不可少。

UI、仪表盘与学习曲线

• HA 的能源仪表盘被称赞为打磨得很精致；而通用仪表盘的创建则被视为功能强大，但也令人望而生畏且耗时。
• 人们希望有更好的默认值、设置向导、基于平面图的 UI，甚至基于 LiDAR 的“数字孪生”映射，这反映出大家希望减少那种“逐块搭砖式”的配置方式。