LWN：作为内核开发者来尝试 Home Assistant：案例分析！

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

A kernel developer plays with Home Assistant: case studies

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

本系列的第一篇文章概述了 Home Assistant、其社区及其功能。然而，那篇文章特意减少了对 Home Assistant 可以完成的有趣事情的描述——也就是没有多介绍人们实际上会出于哪些原因来使用这个程序。在本篇作为结束时，我们将探讨 Home Assistant 是如何被用来解决一些实际问题的。

Solar panels

电气化是好事，但如果电力充足那就更好了；因此，几年前，我投入资金在屋顶安装了太阳能电池板（solar panels）。结果确实电力充足，发电量大约是我家和电动汽车（非特斯拉）实际用电量的两倍，这是件好事。但情况本可以更好。

这些电池板附带了一个名为 SunPower 公司的监控系统（monitoring system）；它收集电池板性能和电网使用量（grid usage）的数据，并将所有数据报告到云端某个系统。该公司提供了一个功能相当完善的应用（app），提供了关于当前和过去性能的信息，包括每块电池板的详细数据。当然，这个应用是获取这些数据的唯一途径，这一事实让我有点不安。依赖某个供应商提供的“免费”云服务（cloud service）通常不会有好结果。

果然，在 2024 年，SunPower 破产了。收购 SunPower 资产（其中包括我和我的数据）的公司名为 SunStrong。这家公司最近通知我，对我的数据的免费访问即将结束；如果不付费，应用将只提供基本的瞬时数据。换句话说，我拥有的太阳能电池板生成的数据，由我拥有的监控系统收集，并发送到我绝对不拥有的云系统，我的数据将被该系统扣为人质。

当然，这正是我使用自由软件（free software）旨在防止的情况。幸运的是，我早期的不安促使我寻找将数据收集并保存在本地的方法；这正是促使我安装 Home Assistant 的原因。事实证明，监控系统并不轻易地将其信息透露给那些自以为拥有它的人，但网络上有人 找到了一个方法，利用一个用于安装时诊断的网络端口（network port），并详细记录了下来。我能够以一种稍微简单的方式解决了这个问题（运行 Home Assistant 的机器有两个网络端口，所以我省去了中间的树莓派系统），从那以后，我便能完全访问太阳能系统的数据了。

经过一些不可避免的调整（详情请参阅第一篇文章），最终得到了一个比原来应用更好的太阳能相关信息界面。例如，这幅图片显示了一个电池板群的输出，即使在四月初，也清楚地显示了两块电池板部分阴影的影响。现在可以很容易地看到系统的各个部分运行得如何，而且如果有一天某个电池板或其逆变器出现问题，问题电池板会立刻显而易见。

这类数据不应该被某个公司挟持，这些公司觉得它们可以随时随意更改交易条款。在我看来，摆脱这种境地是使用 Home Assistant 这类工具最令人信服的原因之一。

Helpers

话虽如此，如前所述，Home Assistant 需要一些调整才能达到有用的程度。例如，考虑监控系统会报告电池板和电网的瞬时功率。它不报告房屋消耗的功率，而这通常是人们感兴趣的。当然，这个量很容易获得：它就是太阳能和电网功率流的总和。至少，一旦人们弄清楚被称为“helpers”的抽象概念（abstraction），这就很容易了。

如果进入 Home Assistant 界面的“Settings”（设置）界面，然后进入“Devices & services”（设备与服务），你会看到一个标记为“Helpers”的选项卡（tab）。实际上，helper 是一种实例化虚拟传感器（virtual sensor）的方法，该传感器定义为一个或多个现有传感器（sensors）的函数。这个界面有许多其他功能，包括可以用来创建“家庭用电量”的 helper，它是太阳能和电网功率传感器的总和。一旦它存在，就可以用于生成图表，作为其他 helpers 的输入，或作为自动化（automation）的一部分。

现在想象一下，如果能知道房屋在任何一天消耗了多少电力，那将是很好的。这里的“integral”helper（积分助手）就派上用场了；我们刚刚创建的房屋功率 helper 可以输入到这个新的 helper 中，它会随时间对其值进行积分，将千瓦（kilowatts）转换为千瓦时（kilowatt-hours）。这将产生一个持续增加的值，如果你想知道房屋的总使用量，这是不错的，但要了解当天的情况就不那么有用了。幸运的是，还有另一种类型的 helper 称为“utility meter”（效用仪表），可以配置在给定间隔（例如每天晚上午夜）重置为零。这个 helper 的输出将是当天的使用量。

所有这一切的最终结果是，helpers 可以利用 Home Assistant 收集的数据做很多有趣的事情，但这确实需要在界面中进行大量点击（或者对于有此偏好的人来说，编写 YAML）。这些工作可能会累积；如果要为 22 块电池板中的每一块生成每日产量总计，而无需手动为每一块创建 helper 链，我还没有找到方法。

另一种说法是，Home Assistant 确实需要一种更通用的查询语言来管理其数据。但是，作为一个一旦设置好就可以使用多年的系统，现有的功能已经运行得相当不错了。

关于数据，还有一点值得一提：Home Assistant 将收集来自提供源的高分辨率数据（high-resolution data），并且这些数据会被存储——但只存储一段时间。除非另有配置，超过十天的数据将被严重精简，似乎每小时只保留一个样本。由于许多人将 Home Assistant 运行在小型、资源受限系统（resource-constrained systems）上，采取一些措施减少所需的存储空间（storage space）是可以理解的。但是，对于拥有大硬盘并希望无限期保留全分辨率数据的用户来说，这种丢弃数据的情况可能会让他们感到意外。

Heat pumps

电力 surplus（盈余）怎么办？将其捐回电力公司（或类似效果）没什么吸引力。最好是找到这种电力的好用途，所以下一步是安装空气源热泵（heat pumps），不再用化石燃料（fossil fuels）加热房屋。在科罗拉多州这样做需要一点信念飞跃，因为今年冬天温度曾降至 -15°F (-26°C)，但这项技术已经取得了长足进步；房屋保持温暖。

购买前的研究清楚地表明，三菱（Mitsubishi）制造的热泵可以在这种气候（climate）下工作。人们普遍对该公司的硬件评价很高。在购买之前也很清楚，人们对三菱的软件及其“Kumo Cloud”应用评价较低。Kumo Cloud，顾名思义，是一个基于云的解决方案，需要 Internet 连接才能工作。这个应用就像评论中说的一样糟糕。三月份，三菱大肆宣传后，用一个新的应用“Comfort”取代了它；这个应用完全重写了，却比原来更差。

当然，Home Assistant 有一个三菱集成（integration）。它在初始化时需要访问云账户（cloud account）以获取每个热泵头的控制器（controllers）的 IP 地址，之后它就可以与控制器在本地互操作。这个集成收集硬件提供的数据（运行模式 operating mode、温度 temperature、设定点 set point、湿度 humidity），并可以用通常的方式提供这些数据。例如，应用（无论是哪个版本）都无法绘制房间一整天的温度曲线，但 Home Assistant 可以做到。

当然，它还可以通过一个简单的类似恒温器的部件来控制硬件，这个部件可以放在 dashboard（面板）上。可以在一个屏幕上看到整个房屋的气候控制配置。如果设置了远程访问（remote access），也可以在外出时更改配置，例如在回家路上调高暖气。

虽然我还没有这样做，但通过设置自动化（automations），可以做更多的事情。可以设置一个时间表（schedule）来在一天的不同时间改变设定温度。一个更复杂的设置可能会使用运动传感器（motion sensors）或蓝牙传感器（Bluetooth sensors）来确定哪些房间有人，并相应地调整气候控制设置。但即使只是作为在任何给定时间控制热泵设定的方式，Home Assistant 已经取代了使用厂商应用（vendor app）。在某个时候，我可能会完全切断这些控制器与 Internet 的连接。

Power monitoring

热泵在冬天很好地保持了房屋的温暖，但它们也导致了电力 surplus 的消失。这自然让我对房屋的用电量（power consumption）产生了更高程度的兴趣；SunPower 设备提供的简单数据已经不够了。如果能知道哪些具体的房间或电器（appliances）在消耗电力，那不是很好吗？事实证明，有很多公司销售电力监控器（power monitors），可以报告房屋中多个电路（circuits）的用电量；问题只是选择哪一个。

这个问题最终很容易回答。有一款 Refoss 制造的设备，价格实惠，能够监控房屋中十六个独立的电路。（注意：该产品页面可能并非在所有地区都可用。主站点 在此。）读者无疑会惊讶地发现，这个设备被设计成向云服务器（cloud server）报告数据，然后通过应用提供数据。然而，这里有一个关键区别：Refoss 设备的 Home Assistant 集成（Home-Assistant integration），直接与监控器接口，不需要云连接（cloud connectivity），是由 Refoss 自己编写和提供的。Home Assistant 兼容性是上面链接的产品页面上的第一个要点。

没有多少公司会认为支持其产品的 Home Assistant 集成是合适的；可能更多公司对此是积极抵触的。因此，当一家公司支持这种集成时，它立刻就排在了我的候选名单的首位；这里就是这种情况。在房屋主配电盘（service panel）内部进行几个小时紧张的工作，以及更多时间花在调整所有传感器（sensors）的名称后，监控器按设计安装并开始向 Home Assistant 报告数据了。

监控器返回的数据立即证明是有用的。右侧的图显示了安装的两台外部热泵设备的用电量，一台用于楼下，一台用于楼上。蓝色曲线（楼下）显示了这些系统应有的运行方式；它们应该很少循环，一旦启动就稳定运行一段时间。黄线（楼上）则显示了一个名为“short cycling”（短时循环）的问题；这会导致用电量增加并增加设备的磨损。短时循环可能由多种问题引起，包括配置错误（configuration mistakes）或硬件问题（hardware problems）。

在这种情况下，原因似乎是硬件问题，但这花了些时间才得出诊断。然而，通过向维修技术人员（repair technicians）展示这样一张图，很容易就能向他们演示问题所在。如果没有详细的用电量信息，与技术人员的对话可能会长得多。拥有对关键系统（比如你的房屋）运行情况的可见性（visibility）是有价值的。

拥有电力信息还有助于其他方面。看到我的显示器在“power save mode”（节能模式）下消耗多少电流，我便养成了晚上关闭它们的习惯。现在更容易知道在电费高峰时段是什么在使用电力，并将这些用电转移到其他时间。了解一次完整的 kernel build（内核编译）大约耗电 20Wh 也是很有趣的。总的来说，了解房屋运行情况的可见性既有趣又有用。

To close

认识到这些信息能揭示房屋内正在发生多少事情（有多少人在场，他们在哪个房间，他们在这些房间做什么等等）也令人警醒。认为没有人试图获取（和利用）这些数据，这往好里说也是天真的。然而，我们却欣然允许这些数据导出并存储在别人的服务器（server）上，却不知道我们将拥有多久的访问权限，那个服务器保护得有多好，甚至不知道它在哪里。这就是我们为自己建造的世界，但这不是我们许多人所设想的世界。

Home Assistant 这样的工具提供了一种不同的世界愿景——我们本应从一开始就建造的世界。自由软件（free software）不仅仅适用于操作系统（operating systems）；它适用于触及我们生活的所有系统。它是真正为我们服务的软件，而不是为卖给我们它的人服务。

Home Assistant 是一个非常成功的项目，拥有大量用户，但大多数人仍然从未听说过它。无疑还有许多人被系统的繁琐性质和集成原本并非设计为协同工作的设备所带来的挑战吓退。要持续成功，还需要付出更多努力才能让事情变得“Just Work”（开箱即用）。在这个领域几乎肯定存在商机，只待具备必要精力与技能的人将其变为现实。同时，对于那些愿意付出努力的人来说，一个多功能且有用的工具已经可用。

对 Home Assistant 的探索就此结束。这至多只是一个部分探索；如前所述，我还没有太多时间去尝试自动化（automations）和场景（scenes）等功能。正在开发中的语音控制（voice control），以及用于媒体流（media streaming）的 Music Assistant。我的房子也没有运动传感器（motion sensors）、遥控灯泡、视频门铃、自动百叶窗、联网厨具、App 控制的宠物喂食器、“智能音箱（smart speakers）”以及其他各种 IoT（物联网）设备，所有这些如果存在，都可以连接到 Home Assistant。所以我无法测试这些集成。最终，每一次部署（deployment）都会像每一个家一样不同——但所有都将是自由的，并处于所有者控制（owner's control）之下。

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

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

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