LWN：作为内核开发者来尝试 Home Assistant 的总体印象！

关注了就能看到更多这么棒的文章哦～

A kernel developer plays with Home Assistant: general impressions

By Jonathan Corbet
May 9, 2025
Gemini-1.5-flash translation
https://lwn.net/Articles/1017720/

那些终生与计算机为伍的人，自然能看到将它们部署到家中用于数据采集和自动化所带来的吸引力。但我们中的许多人，在见证了技术产业（technology industry）的演变后，越来越不愿意将关键的家庭功能委托给由那些可能并非为我们最大利益着想的公司运营的云服务器。Apache 许可的 Home Assistant 项目提供了一个可喜的替代方案：通过自由软件实现本地控制的自动化。本系列文章共分两部分，涵盖了大约一年的 Home Assistant 使用体验，首先将对其进行一番总体性的观察。

当然，这不是 LWN 第一次关注这个项目了；这篇评论文章 展现了五年 Home Assistant 的面貌，而 这篇 2023 年的文章 则对项目的历史、治理以及总体方向提供了很好的概览。我将努力避免在此重复这些内容。

项目健康

初看之下，Home Assistant 带有背靠着公司的项目的一些特征。涉及的公司 Nabu Casa 是围绕该项目成立的，并雇用了其许多关键开发者。该公司盈利的方式之一是提供每年 65 美元的订阅服务，为安装在防火墙后的住宅网络中的 Home Assistant 服务器提供远程访问。Home Assistant 支持这种远程选项，但没有其他选项。如果有人提交一个添加支持例如 OpenThings Cloud 作为替代方案的 pull request（拉取请求），看看会发生什么将会很有趣。该请求的命运将在很大程度上说明这个项目到底有多开放。

（顺便说一下，我购买了 Nabu Casa 的订阅，而不是像使用 WireGuard 那样在可访问的系统上开放端口；这是一种轻松解决问题并支持软件开发的方式）。

话虽如此，一个由公司控制的项目通常伴随的大多数让人警示的信号并未出现在 Home Assistant 中。该项目的 贡献者许可协议 是 kernel（Linux 内核）的 developer certificate of origin（开发者来源证明）的衍生版本；贡献者保留其对其作品的 copyright（版权）。自 2024.4 版本 发布以来，Home Assistant 的 core（核心） repository（代码仓库）已经从 900 多名贡献者那里获得了超过 17,000 个 changeset（变更集）。尽管 Nabu Casa 的一些员工（此页面 上有列出）出现在贡献者前十名中，但他们并未在这个列表中占据主导地位。

Home Assistant 显然是一个活跃的项目，拥有广泛的开发者基础。2024 年，该项目的总体责任转移给了 新成立的 Open Home Foundation。这个项目很可能将会持续存在，并且未来似乎不太可能出现转变成恶意方向的情况。对于一个处于家庭核心位置的系统来说，这些都是重要的特征。

安装与设置

Linux 用户通常会被宠坏；安装一个新的 application（应用程序）通常只需要一个 package-manager（包管理器）命令。Home Assistant 并不完全符合这种模式。安装页面上的前三个选项涉及专用计算机——其中两款由 Nabu Casa 销售。对于那些希望将其安装在通用计算机上的人来说，推荐的方法是安装 Home Assistant Operating System，这是一个定制的 Linux distribution（发行版），它在 Docker（容器）中运行 Home Assistant。还有一种基于 container（容器）的方法可以在其他发行版上运行，但这种安装方式不支持 附加组件（add-ons）功能。

换句话说，Home Assistant 并非被设计成 Linux 系统上的另一个普通 application（应用程序）。然而，如果往下翻够远，就会找到在“普通”Linux 系统上安装的说明，并配有警告，说明这是一种“高级”方法。当然，我就是这样做的，将软件安装在一个运行 Fedora 的现有系统上。随后，当 distribution（发行版）升级替换了 Python 时，整个系统崩溃了，但这很容易修复。总的来说，安装工作如预期般顺利。

然而，刚安装好的 Home Assistant 默认情况下并不会做太多事情。毕竟，它的工作是与家中的各种系统对接，而每个家庭都不同。虽然 Home Assistant 可以自动发现一些系统（它找到了我的 Brother 打印机，并尽职地告诉我设备中的青色墨盒不可避免地快用完了），但通常需要告知它家中安装了什么设备。因此，用户很快就会深入到“integration（集成）”的世界——Home Assistant 的设备驱动程序。

对于家中每一个可远程访问的设备，如果幸运的话，会有至少一个可用的 integration（集成）可以让 Home Assistant 与之协作。许多 integration（集成）是与系统本身打包在一起的，可以通过 Home Assistant web interface（网页界面）中的简单搜索屏幕找到。更大的一套则单独打包，通常在 Home Assistant Community Store 或 HACS 中；可以说，大多数用户最终会从这个来源获取至少一些 integration（集成）。设置 HACS 需要一些步骤，而且不幸的是，为了完全集成，需要用户拥有一个 GitHub 账户。虽然 可以 在没有该账户的情况下安装 HACS integration（集成），但这是一个手动过程，并且会失去对诸如更新跟踪等功能的支持。

大多数 integration（集成）在设置时会发现网络上的任何兼容设备——当然，如果这些设备支持这种发现功能的话。通常，使用一个 integration（集成）需要登录设备 vendor（供应商）提供的 cloud（云）账户的 credential（凭据）。只要可能，integration（集成）大多努力完全在本地运行；有些只在初始设备发现时使用 cloud（云）连接。然而，如果别无选择，integration（集成）将保持登录 cloud（云）账户，并以此方式与设备交互；这种模式 vendor（供应商）可能支持也可能不支持（或默许）。当然，有些 vendor（供应商）积极反对 与 Home Assistant 集成。

正如预期的那样，integration（集成）的质量参差不齐。我尝试过的大多数 integration（集成）都运行得很好。但 OpenSprinkler（2023 年在此评测过）的 integration（集成）却彻底破坏了设备配置，让我蒙受了因草坪不够完美而被看到的羞辱；它很快就被移除了。当设备 vendor（供应商）自己提供 Home Assistant 支持时，这是一个尤其令人惊喜的事情，但这仍然相对罕见。Home Assistant 现在的情况类似于 25 年前的 Linux；许多设备得到支持，但常常是尽管有其 vendor（供应商），而且用户必须仔细选择组件。

安全

Home Assistant 位于家庭网络的 core（核心）；它可以访问能够揭示许多关于家庭居住者信息的 sensor（传感器），并且它在一个位置收集数据。如果所有者需要远程访问，安装就会暴露在 Internet（互联网）上。这显然存在发生安全灾难的潜力。

该项目发布了 一份安全策略，描述了项目的立场；它要求对任何安全问题的报告实行 90 天的 embargo（禁运）。鼓励撰写项目安全相关文章的作者在发表前与项目沟通，“以便我们确保所有说法都是正确的”。安全策略明确排除了关于第三方 integration（集成）的报告（毕竟 core（核心）项目无法修复这些问题）。该项目也对已登录 Home Assistant 的用户进行任何 privilege escalation（权限提升）不感兴趣，认为拥有账户的任何人都是完全可信的。

自 2024 年初以来，该项目仅发布了 一份安全 advisory（公告）。2023 年发布了几份，主要源于 GitHub 进行的 安全审计。

第三方 integration（集成）没有得到全面的 vetting（审查），它们终究只是更多的 Python code（代码）。因此，加载一个未知的 integration（集成）类似于从 PyPI（Python 包索引）导入一个未知的 module（模块）；它可能会工作，但潜在的麻烦是存在的。项目偶尔会 报告第三方 integration（集成）中的安全问题，但此类报告很少见。我尚未发现在实际环境中存在恶意 integration（集成）的报告，但迟早会有一个出现。

真正用 Home Assistant 做一些事情

一个新的 Home Assistant 安装的所有者，自然首先要寻找家中已安装设备的 integration（集成）。成功安装和初始化后，一个 integration（集成）会向系统添加一个或多个“device（设备）”，每个 device（设备）都有一些用于报告数据的“sensor（传感器）”，以及可能改变其运行状态的“control（控件）”。例如，一个 heat-pump head（热泵主机）可能有用于当前温度和湿度的 sensor（传感器），以及用于其运行模式、风扇速度、叶片方向等的 control（控件）。

值得注意的是，这些 entity（实体）的设置有时似乎有点 non-deterministic（非确定性）。我的 solar system（太阳能系统）有 22 块面板带 inverter（逆变器），每个都报告近十个 parameter（参数）（voltage（电压）、current（电流）、frequency（频率）、temperature（温度）等）。没有简单的方法确定哪个面板报告了例如 sensor_amps_12 ，尤其因为 sensor_frequency_12 几乎肯定对应于 不同 的面板。我的经验是，Home Assistant 是一个适合愿意花大量时间摆弄事物使其达到工作状态的人的系统。处理这些 sensor（传感器）是我早期接触这方面的一个例子；花了一些时间才弄清楚名称和屋顶位置之间的映射关系，然后将每个 sensor（传感器）重命名为更有帮助的名称。

下一个层级的摆弄是设置 dashboard（仪表板）。Home Assistant 在提供给用户的信息和 control（控件）方面提供了极大的灵活性；可以设置专注于例如能源生产或气候控制的屏幕。令人高兴的是，必须通过编写 YAML snippet（代码片段）来完成配置的时代已经基本过去；偶尔仍然需要深入到 YAML 中，但这并不经常发生。界面并不总是直观的，但它相当流畅、交互且功能强大。

Home Assistant 的另一部分我尚未多玩，那就是 automation（自动化）和 scene（场景）。Automation（自动化）是简单的由规则触发的程序，它们会改变一些 control（控件）。它们可以执行诸如“天黑时打开前灯”或“如果有人按门铃而家中无人，则播放吓人的音乐”之类的操作。Scene（场景）则是一系列预设的设备配置。例如，你可以创建一个名为“in-laws visiting（岳父母来访）”的 scene（场景），播放响亮的朋克音乐，将温度设定在刚好高于冰点，禁用所有语音控制，并将所有灯泡调整到 6000K 的色温。

好消息是，除非摆弄本身就是重点（这也可以是一个很好的重点），总会有那么一个时候，事情就是能够正常工作了，而摆弄也可以停止了。一个配置良好的 Home Assistant instance（实例）可以通过任何能够访问并登录的 web browser（网页浏览器），提供关于家居状态的详细信息——以及在设备允许的情况下提供控制。还有（开源的） application（应用程序）可以将这种支持带到 mobile device（移动设备）上，其体验几乎与 web interface（网页界面）无异。

总而言之，Home Assistant 拥有强大且日益壮大的追随者群体，原因显而易见。它是一个开放平台，为试图牢牢掌控我们家庭及其生成的数据的产业带来了控制权。Home Assistant 表明，我们完全可以摆脱那些脆弱、不互操作、随时可能“卷铺盖跑路”（rug-pull-susceptible）的 cloud system（云系统）。就像 Linux 证明了我们可以控制自己的 computer（计算机）一样，Home Assistant 表明我们不必放弃对家庭的控制权。

这篇文章已经写得很长了，但令人惊讶的是，关于真正可以使用 Home Assistant 做什么有趣的事情的内容却很少。这方面有一些有趣的故事可以讲；它们很快将在本系列 第二部分，也是结尾部分 中出现。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～