内核开发人员玩转 Home Assistant:总体印象
我们这些一生都在玩电脑的人,自然会看到在家中部署电脑以实现数据采集和自动化的魅力。但是,我们中的许多人都关注着科技行业的发展,他们越来越不愿意将关键的家庭功能托付给云端服务器,因为这些公司可能并不把我们的利益放在心上。获得 Apache 授权的Home Assistant 项目提供了一个受欢迎的替代方案:使用免费软件实现本地控制自动化。本系列由两部分组成,涵盖了 Home Assistant 大约一年的使用情况,首先是对该项目的总体观察。
当然,这并不是 LWN 第一次关注这个项目;这篇评论简要介绍了 Home Assistant 五年前的情况,而这篇 2023 文章则很好地概述了项目的历史、管理和总体方向。在此,我将尽量避免重复这些材料。
项目健康状况
乍一看,“家庭助理 ”带有一些公司所有项目的特征。有关公司 Nabu Casa 就是围绕该项目成立的,并雇佣了一些主要的开发人员。该公司的盈利方式之一是提供每年 65 美元的订阅服务,让用户可以远程访问安装在防火墙住宅网络上的 Home Assistant 服务器。家庭助理支持该远程选项,但不支持其他选项。我们很想知道,如果拉取请求增加对 OpenThings Cloud 的支持,作为一种替代方案,会有什么结果。该请求的命运将在很大程度上说明项目的开放程度。
尽管如此,Home Assistant 并没有出现企业控制项目的大多数警示信号。项目的贡献者许可协议是内核开发者原产地证书的衍生;贡献者保留其作品的版权。自 2024.4 版本发布以来,Home Assistant 核心资源库已从 900 多位贡献者那里获得了 17000 多个变更集。虽然 Nabu Casa 的一些员工(在本页上列出)出现在前十位贡献者中,但他们并不占主导地位。
显然,“家庭助理 ”是一个拥有广泛开发人员基础的活跃项目。2024 年,该项目的总体责任移交给了新成立的 Open Home 基金会。这个项目很可能会一直存在下去,而且未来似乎也不太可能发生敌对的转变。对于一个处于家庭核心位置的系统来说,这些都是非常重要的特性。
安装和设置
Linux 用户往往有点被宠坏了;安装一个新的应用程序通常只需要一个软件包管理器命令。家庭助理并不适合这种模式。安装页面上的前三个选项涉及专用电脑,其中两个由 Nabu Casa 出售。对于想要在通用计算机上安装的用户,建议安装 Home Assistant 操作系统,这是一个定制的 Linux 发行版,可在 Docker 容器中运行 Home Assistant。还有一种基于容器的方法,可以在其他发行版上运行,但这种安装方式不支持附加功能。
换句话说,家庭助理并不是真正意义上的 Linux 系统上的另一个应用程序。不过,如果滚动到足够远的地方,就会发现安装到 “普通 ”Linux 系统上的说明,并适当地加上警告,说明这是一种 “高级 ”方法。当然,我就是这么做的,把软件安装到运行 Fedora 的现有系统上。后来,当发行版升级替换 Python 时,整个系统就崩溃了,但修复起来还是很容易的。总的来说,安装过程符合预期。
不过,开箱即用的新版家庭助理并没有什么作用。毕竟,它的工作是与整个房子的系统对接,而每个房子的情况都不尽相同。虽然家庭助理能自动找到一些系统(它能找到兄弟打印机,并尽职地告诉我该设备的青色碳粉不足),但它通常需要被告知房子里安装了什么设备。因此,用户很快就会进入 “集成 ”的世界–家庭助理的设备驱动程序。
对于家中每一个可远程访问的设备,希望至少有一个集成可以让家庭助理与之协同工作。许多集成都与系统本身打包在一起,可以通过家庭助理网络界面上的简单搜索屏幕找到。更多的集成是单独打包的,通常在家庭助理社区商店(Home Assistant Community Store)或 HACS 中;可以说,大多数用户最终至少会从这个来源获得一些集成。设置 HACS 需要几个步骤,不幸的是,用户需要有一个 GitHub 账户才能完全集成。没有 GitHub 账户也可以安装 HACS 集成,但这需要手动操作,而且会失去对更新跟踪等功能的支持。
大多数集成在安装时会发现网络上的任何相应设备,当然前提是这些设备支持这种发现。通常情况下,使用集成需要登录相关设备供应商提供的云账户的凭证。在可能的情况下,集成大多会努力做到完全在本地运行;有些集成仅在初始设备发现时使用云连接。在别无选择的情况下,集成会保持登录云账户的状态,并以这种方式与设备进行交互;这种模式可能会也可能不会得到供应商的支持(或认可)。当然,也有一些厂商积极反对与家庭助理集成。
不出所料,集成的质量参差不齐。我尝试过的大多数集成都运行良好。相反,OpenSprinkler(2023 年曾在此进行过评测)集成却彻底破坏了设备配置,让我羞愧地发现自己的草坪并不完美;但它很快就被移除了。当设备附带由供应商提供的家庭助理支持时,会给人带来特别大的惊喜,但这种情况还是比较少见。家庭助理现在的处境类似于 25 年前的 Linux;许多设备都得到了支持,但往往是在供应商不支持的情况下,人们必须谨慎选择组件。
安全性
家庭助理(Home Assistant)位于家庭网络的核心位置;它可以访问传感器,而这些传感器可以揭示家庭居住者的许多信息,它还可以在单一位置收集数据。如果主人需要远程访问,安装的设备就会暴露在互联网上。这显然有可能造成安全灾难。
该项目公布了一项安全政策,阐述了项目的立场;该政策要求在 90 天内禁止报告任何安全问题。我们鼓励撰写有关项目安全问题文章的作者将其作品提交给项目,“这样我们就能确保所有声明都是正确的”。安全策略明确排除了有关第三方集成的报告(毕竟核心项目无法解决这些问题)。该项目还对登录家庭助理的用户的任何权限升级不感兴趣,认为任何拥有账户的人都是完全可信的。
自 2024 年初以来,该项目只发布过一条安全公告。2023 年发布过几次,主要是 GitHub 进行安全审计的结果。
第三方集成没有经过全面审核,归根结底只是更多的 Python 代码。因此,加载未知集成与从 PyPI 导入未知模块类似;它可能会正常工作,但也存在潜在的麻烦。该项目偶尔会报告第三方集成的安全问题,但这种报告很少见。我找不到任何关于恶意集成的报告,但似乎迟早会出现。
使用家庭助理实际操作
对于新安装了家庭助理的用户来说,第一步自然是为家中安装的设备寻找集成。在成功安装和初始化后,集成系统将为系统添加一个或多个 “设备”,每个设备都有一定数量的 “传感器 ”来报告数据,并可能有 “控制器 ”来改变其运行状态。例如,一个热泵头可能有当前温度和湿度的传感器,以及操作模式、风扇速度、叶片方向等的控制器。
值得注意的是,这些实体的设置有时似乎有点不确定。我的太阳能系统有 22 块带逆变器的电池板,每块电池板都会报告近十个参数(电压、电流、频率、温度等)。没有简单的方法来确定哪个面板报告了 sensor_amps_12,尤其是 sensor_frequency_12 几乎肯定对应于不同的面板。我的经验是,家庭助理是为那些愿意花大量时间摆弄东西使其达到工作状态的人设计的系统。处理这些传感器就是这方面的早期入门;我们花了一些时间来弄清名称与屋顶位置之间的映射关系,然后将每个传感器重新命名为更有用的名称。
下一步就是设置仪表盘。家庭助理在向用户提供信息和控制方面具有很大的灵活性;可以设置以能源生产或气候控制为重点的屏幕。令人欣慰的是,通过编写 YAML 代码段进行配置的时代已经成为过去;偶尔还是需要使用 YAML,但并不常见。虽然界面并不总是那么直观,但它相当流畅、具有交互性和功能性。
家庭助理的另一个我还没怎么用过的部分是自动操作和场景。自动操作是一种简单的规则触发程序,可对某些控制进行更改。它们可以执行 “天黑时打开前灯 ”或 “如果有人按门铃而家里没人,就播放恐怖音乐 ”等操作。场景是一组预制的设备配置。例如,可以创建一个名为 “姻亲来访 ”的场景,播放嘈杂的朋克音乐,将温度设定在略高于冰点的水平,禁用所有语音控制,并将所有灯泡调至 6000K。
好消息是,除非摆弄本身就是重点(也可能是一个好重点),否则总有一天一切都能正常运行,摆弄也就可以停止了。一个配置良好的家庭助理实例可以向任何可以访问并登录的网络浏览器提供有关家庭状态的详细信息,并在设备允许的情况下进行控制。有一些(开源)应用程序可以将这种支持带到移动设备上,其工作方式与网络界面几乎没有区别。
综上所述,我们可以清楚地看到 Home Assistant 为何拥有越来越多的拥趸。它是一个开放的平台,能为行业带来控制权,而这个行业正竭尽全力牢牢掌控着我们的家庭和它们所创造的数据。家庭助理 “表明,没有这些脆弱、不可互操作、易被拉扯的云系统,我们也能做得很好。正如 Linux 证明我们可以控制电脑一样,家庭助理也证明我们不必放弃对家庭的控制。
这篇文章已经很长了,但关于家庭助理实际能做的有趣事情却少得可怜。在这方面还有一些有趣的故事要讲,它们将很快出现在本系列的第二部分,也就是最后一部分。
本文文字及图片出自 A kernel developer plays with Home Assistant: general impressions
你也许感兴趣的:
- Stack overflow 几乎已死
- Redis 再次开源。但是否为时已晚?
- 麻省理工:来自美国Nasa的编程之道
- java 字符串变得更快了
- 你真的了解 SQL 吗?数据库工程师究竟建议你做什么?
- 自去年年初以来,Google Play 的应用程序数量下降了 47%
- 四大网络浏览器即将损失 80% 的资金
- 使用 margin-trim,布局更简便
- 使用 PHP 8.4 新 DOM Selector 解析 HTML
- Office 太慢,微软让它在 Windows 启动时加载
请注意,本系列由两部分组成。第二部分可在此处阅读:
https://lwn.net/SubscriberLink/1017945/93d12d28178b372e/
在本文提交后不久,有人将该 URL 作为一个单独的提交内容发布,但我们没有将讨论分割开来,而是将评论合并到了这里,以便将所有内容作为一个主题进行讨论。
我是创始人家庭助理。我想说的是,我一直很喜欢看到这样的文章,看到人们通过家庭助理取得的伟大成就。
也许不是每个人都知道,但去年我们在瑞士成立了非营利性组织 Open Home Foundation,我将 Home Assistant 捐赠给了它[1]。它的资金全部来自用户。没有投资者参与其中。
我们全心全意致力于打造一个注重本地控制和隐私的智能家居。是的,我们的工作还很粗糙,但我们正在积极地公开工作,每个月都会发布进展情况。
~Paulus, Home Assistant 创始人兼开放家庭基金会主席 https://github.com/balloob
[1]: https://www.openhomefoundation.org/blog/announcing-the-open-…
> 我向它捐赠了 Home Assistant[1]。它的资金全部来自用户。没有投资者参与其中。
我对此感激不尽。两年前采用家庭助理来处理所有事情有点冒险,但你们的这一举动确实让我对最终不得不用其他东西取代它感到不那么害怕了。
我订阅了家庭助理云(通过 Nabu Casa),尽管我并不使用它,只是因为这似乎是为数不多的可以在经济上支持你们的方式之一,有什么办法可以一次性捐赠给基金会本身吗?
我们不想依赖捐款,也不想在应用程序中显示维基百科式的乞讨横幅(我本人也不愿意看到这种情况)。
因此,在资源有限的情况下,我们目前只考虑价值 1 万美元或以上的大额捐赠。到目前为止,我们已经收到了来自 DuckDuckGo 和 Espressif 的捐款。
我在使用 Blender 的过程中并没有乞讨的感觉,虽然这已经是几年前的事了。我记得他们的重点是为特定功能和展示作品(如电影)捐款。
作为一个非常快乐的 “家庭助手 ”用户,希望你也能做一些类似的事情,这样你就有足够的钱来维持生计,继续做好你的工作。
也许你们可以让人们为 Nabu Casa 付更多的钱?
乞讨横幅或宣传活动。
我从来没有遇到过这样的问题。
根据他们的 “支持我们 ”页面,这似乎是唯一的办法。
https://www.openhomefoundation.org/organization/#support-our…
你们打算修复 https://github.com/home-assistant/frontend/issues/18549 吗?
是否可以通过某种订阅方式向你们的基金会捐款?
我有一个 Nabu Casa 订阅,但我不是很需要它。
> 我有一个 Nabu Casa 订阅,但我不是很需要它。
可惜没办法捐赠。
我的意思是,如果您支付了订阅费,但从未使用过,这实际上就是一种捐赠,对吗?
OP 在另一条评论中解释了他们不接受小额捐赠的动机:
https://news.ycombinator.com/item?id=44014822
我想 baby_souffle 可能是指把订阅捐给别人的方法。
几乎每个用户都在使用低质量的硬件,或者没有部署网状接入点来连接设备。
用户一旦意识到智能设备不够智能,就会想方设法摆脱 “智能 ”的束缚。
无休止的 “更新”、寻租、破坏性更改、账户设置–这一切都不值得。
你应该去看看 Home Assistant 和它集成的大量生态系统!有很多无线电标准和制造商都考虑到了你所描述的问题,令人眼花缭乱。
如果你愿意,你可以(据我所知很多人已经这样做了)在没有任何 WiFi 的情况下运行整个智能家居。
Home Assistant 是免费开源的,而且我从他上面的评论中了解到,他们的创始人慷慨地将项目捐赠给了一个非营利基金会,以便在未来以这种方式维持下去。
对于你所担心的寻租动机,这一点非常令人放心。
你不必使用 WiFi,这整个论点都是无效的。用 Zigbee 代替吧。
只有我的 “智能 ”热水器通过无线网络进行通信。其余的都使用 Z-wave 或 Zigbee。我知道,至少 Z-wave 从一开始就能让设备在没有控制器的情况下编程运行。
因此,如果控制器掉了或你没有控制器,你仍然可以用按钮来切换灯光等。不管有没有控制器,在没有 WIFI 的情况下都能正常工作。
有 WiFi 替代品。
谁在 “随便 ”更换 Wifi SSID?
就像我父母的 Wifi SSID 是我上高中时设置的,20 年后还是一样。
但如果真的改变了,所有设备只需设置一个临时接入点,然后等待通知新的接入点和密码(临时接入点也受密码保护)。
你上次抱怨 Torvalds 寻租是什么时候?
在我看来,ESPHome 才是真正的神奇之处。事实上,你可以业余地将一些从网上买来的价值 2 美元的传感器焊接在一起,而且除了在网上找到的一些 yaml 之外,无需编码就能在 HA 中正常工作,这简直太疯狂了。
>我们不妨看看,如果拉取请求添加对 OpenThings Cloud 的支持,作为一种替代方案,会有什么结果。该请求的命运将决定项目的开放程度。
我有点希望不要有人尝试。到目前为止,他们在货币化方面的尝试还算友好和温和,如果有什么让他们感到不安,情况可能会发生变化。
是啊,ESPHome 太神奇了。我只花了焊接设置的成本和大约 0 美元的元件费,就建立了一个完整的家庭湿度监控设置。没有订阅费,没有专有接口,有的只是我想要的设置,而且制作起来既有趣又简单!
ESPHome 确实很酷,但据我上次检查,它仍然缺少电源管理功能,这也是我现在不用它的主要原因。
我不知道为什么启用自动灯光休眠不是 Arduino 的第一要务,但我猜可能存在一些微妙的问题,可能会破坏某些草图什么的。
因为实际上所使用的硬件都无法正确支持深度睡眠,而且使用高静态电流 LDO 调节器、上拉、LED 和 vBat 分频器会耗尽电池。此外,重新接入网络、等待哈希服务器连接(在 esphome 协议中,设备是服务器,而不是客户端)并重新进入休眠状态的延迟和能耗成本,只适用于一些不关心延迟或轮询率的奇怪边缘场景。
我使用的是与服务器模型完全相同的 ESP,但使用的是 Websockets,而这一切都能正常工作。
我想在 ESPHome 中甚至有一些关于自动灯光休眠的 PR,但还没有合并。
一样。我订购了几块额外的 ESP 板,其中只需要一块、一块额外的面包板和湿度/温度传感器,于是决定最终测量一下温室里的温度。在 R pi 上运行的 grafana dash 中拥有这一切真是太神奇了。
您(或任何人!)知道如何开始使用家庭自动化的好教程/系列/博客吗?
我会建议你安装家庭助理,并购买一个能运行 ESPhome 的设备,这样你就可以对它进行调整。遗憾的是,我没有比这更具体的东西,但我同意 ESPhome 非常棒。你只需焊接一些东西,在配置中定义引脚,一切就都能正常工作了。
> 我有点希望没人尝试。到目前为止,他们在货币化方面的尝试还算友好和温和,如果有什么事情吓到了他们,情况可能会发生变化。
公平地说,他们最近一直在大力增加备份支持。他们的 Nabu Casa 订阅内置了对备份的支持,这也是我购买该订阅的一个主要卖点(我已经有了用于远程访问的 Wireguard)。
在为自己的订阅提供一流支持的同时,他们还为其他集成添加了钩子,以提供相同级别的备份支持。现在,你可以像使用 Nabu Casa 一样轻松地选择使用 Google Drive、S3、BackBlaze 和其他软件。从某种程度上说,这 “更好”,因为 Nabu Casa 只支持单一的最新备份。
由此看来,他们非常友好,对锁定不太感兴趣。
不幸的是,他们的新备份支持强制加密;这对基于云的备份有意义,但对本地(NAS 等)备份没有意义。如果要求加密,只会得到用老方法手动备份的回复。
可以选择不加密备份。
为什么这很不幸?一般来说,加密备份是一种很好的最佳做法。
如果你想在目标备份中进行重复数据删除和加密,那就太不幸了。
因为这意味着我需要管理加密密钥(这是一个文件,而不是密码)。这增加了还原的难度,因为我需要找出密钥。
在家庭助理安装中,我没有任何需要加密的东西;如果你有访问权限,你就已经进入了网络,与实际运行的设备一样。
ESPHome 蓝牙代理太神奇了–无需在 Linux 系统上处理蓝牙问题(Linux 系统上的蓝牙问题依然很糟糕)!
尽管 ESPHome 有警告说同时使用 WiFi 和蓝牙代理不稳定,但我发现它在稳定性和性能方面比连接到我的家庭助理系统的英特尔蓝牙适配器要好得多。BlueZ 可能更复杂、更不成熟。
ESPhome 现在基本上可以运行我的整个房子。
这是我一直想要的家庭影院系统,也是我唯一想做的事情:所有东西都使用普通 IP,有一个网络接口,生活在一个隔离的 Wi-Fi 网络上。
很明显,他没有看引擎盖下面…… 我看了。一些技术决定……值得商榷。但禁止在论坛上询问原因。HA 可以好好清理一下它的社区,因为它的社区可能特别有毒,尤其是对高级用户,并开始接受批评者。当用户不想遵循 “简化版本,按我们说的做 ”的安装程序时,他们所面临的敌意确实令人不快。
这里没有禁止。哪些技术决定值得商榷?
家庭助理主管不太友好。它的设计使其必须保持更新,并处理自己的自动更新功能。如果对它进行一些重大修改,它也无法在 docker 容器中很好地运行。这意味着,如果你想安装一个完整的家庭助理,唯一的部署选择就是使用他们的 “家庭助理操作系统 ”或特定的 debian 版本。
总的来说,感觉他们在尽可能地增加部署难度,比如检查 supervisor 是否在 docker 容器中运行,如果运行则不工作。
这大概是用户在错误部署时产生的挫败感所致,但基于 supervisor 的 HA 安装确实没有理由不在 docker 容器中运行。我有一些私人黑客就是这么做的,但我不愿意公开发布,以防他们找到破解方法。
我不知道他们为何如此执着于不让完整的家庭助理安装在容器中运行,但这很奇怪。是想增加更多的摩擦,从而卖出更多的专用硬件?他们的硬件很好,而且可以独立运行,我不用它的唯一原因是我想在一台老式触摸屏 Chromebook 上运行,这样能耗很低。
多年来,我一直在 docker 中运行 home assistant。只需要 `homeassistant/home-assistant` 镜像。不需要其他东西了。据我所知,主管是为那些只想在盒子里设置一个可管理的家庭助理的人准备的,在这一点上,软件接管系统是公平的。
对于一些相当重要的附加组件来说,或多或少都需要监管者。
我在容器中安装 HA 有好几年了,不知道什么是 “关键附加组件”。有些很有用,但独立运行也很容易。
比如?我唯一想到的是 ESPHome,我可以单独运行它。
NodeRED 在监督员之外的设置非常麻烦。它需要在两端都进行扩展,而且通过验证的方式也很奇怪。
我在各自的 docker 容器中运行 NodeRED 和 ESPHome,它们与 home assistant 集成,运行得很好。从未使用过监督员。我设置它们已经有好几年了,所以不记得细节了,但这也意味着没什么值得注意的。之后就一直很稳定。
你是否将它嵌入了家庭助理用户界面,并使用了 HA 用户凭据?
我本想讨厌它的这一方面,但因为我喜欢 Debian,并将它作为我在许多系统上的日常驱动程序,所以我无法产生足够的愤怒来抱怨。
Debian 正在打包 HA 软件:
https://wiki.debian.org/Python/HomeAssistant https://wiki.debian.org/HomeAssistant
举个例子,他们(核心贡献者和创始人)过去和现在都对如何安装他们的软件非常严格: https://news.ycombinator.com/item?id=27505277
哇,真是令人讨厌。
我本打算为我的家庭实验室购买一个 Home Assistant Yellow,很高兴知道我需要在扣动扳机之前尽量减少与该项目的互动。
我也一定会把这件事告诉其他使用这个项目的人,他们应该知道依赖一个核心贡献者如此敌对的项目是有风险的。
名副其实的 “开源”(OSINO?)
是的,它被禁止了,我发布了一些对他的技术评论的更正(一个正面,一个负面),它被降权了,这个大概也会被降权….
我不会认为被降权就意味着禁止发表文章。过去我是这么认为的,因为这是我限制自己降权的原因,但不管出于什么原因,人们就是会给他们不喜欢的东西降权。你能做的就是不让它影响到你。
“prohihited “意味着社区组织者执行的官方规则。而 “降权 ”则是社区成员表达意见的一种方式。
我的 HA 已运行多年(在 Docker 中),非常可靠。
它几乎集成了我使用的所有设备或应用程序,对 DSMR(智能电表)的支持也是一流的。
我将电缆插入电表,然后将 USB 端插入服务器,它就能正常工作了。
不过,它的学习曲线确实很陡峭。看来它真的是 “由 IT 人员为 IT 人员服务”。
我把它装在 docker 中,使用监管模式(似乎不鼓励这样做,但我也希望我的机器能有其他用途)。我最头疼的问题是更新,我担心一旦更新就会崩溃。有什么办法可以完全快照容器状态和磁盘状态,以便在出错时 100% 还原?因为这个原因,我还在运行 2020 年的 HA。
我不太喜欢的另一个原因是它的模板语言,至少可以说很笨拙,但总的来说,它是一个非常棒且灵活的系统。
出于同样的原因,我使用 docker compose 运行它,它从未出现过更新失败的情况,只是偶尔需要调整一下配置。大部分情况下,都是编译拉取、编译升级,几周后再查看点版本。
从那么远的地方更新可能会有风险,但你不需要备份所有内容,只需备份配置目录即可。光是自动备份到 Google drive 就值得升级了。
在最近几个版本中,他们完善了内置的备份和还原功能,现在可以在设置菜单中使用。
https://www.home-assistant.io/integrations/backup/
所有持久存储都在映射到容器的主机目录路径中。只需备份映射到容器中的目录即可。不要尝试保存容器状态。
我只备份文件夹(卷),仅此而已。
如果我需要回滚,我可以把 Docker 镜像标签从 “最新 ”改成一个特定的标签。
我从来没这么做过,但我知道人们有时会抱怨更新会破坏东西。
可以在虚拟机中运行。
> 是否有办法完全快照容器状态及其磁盘状态?
docker commit` 应该能帮上忙,制作一份容器副本
有些文件系统支持目录快照。你的软件不一定要与之 “兼容”,只要能用就行。
使用 BTRFS,你甚至可以同时挂载/处理同一目录的多个快照。
重复数据删除可以节省空间。
我觉得它的学习曲线很陡峭。有一次,我手动编写了很长一段复杂的配置,包括所有设备、集成、自动操作等,后来逐渐被在 gui 中的简单点击所取代。另一方面,这也意味着在过去的几年里,当我不得不用新的方式重新配置我的员工时,会有很多破坏性的改动
最近版本的 HA 让我很不爽,因为它不再能很好地使用 yaml 文件配置。你大多被迫通过界面进行配置,这样做还可以,但当你有几个设置稍微复杂一点的设备时,这样做可能会很烦人、很痛苦。
例如,我想用另一个具有不同 Mac 地址的灯泡替换另一个灯泡。以前,只需在配置文件中更改 Mac 即可。现在则复杂多了。
此外,查看和备份配置文件也非常容易。现在就不那么明显了。
我的朋友使用自托管开源软件来监控他所有的家庭物联网设备[1],并将重要信息复制到云端。我使用 StarFive VisionFive 2 托管用于监控的数据库,但也有一份芯片 hetzner arm vps 的数据副本,同时在两个不同的云上托管备份。我知道一些用户多年来一直在使用[2]来监控太阳能电池板、草坪浇水和菜园浇水。
我的问题是:如果数据随时都有可能丢失,现在只使用 SaaS 真的方便吗?我指的是文章中描述的案例。
[1]: https://vrutkovs.eu/posts/home-infra/ [2]: https://github.com/VictoriaMetrics-Community/homeassistant-a…
PS: 我在VictoriaMetrics公司工作
在最近的播客节目中,贵公司的创始人 ( https://www.youtube.com/watch? v=8xkCykuJwKs , От стартапа до международного бизнеса: 他明确描述了VictoriaMetrics的发展历程,其中早期的一个步骤是尝试销售SaaS,而相当多的用户/客户都希望拥有此类工具的预置/自有设置。
因此,请回答你的问题: > 我的问题是:现在只使用 SaaS 真的方便吗?
不,不方便
总有一天,会有公司开始制造可黑客攻击的本地连接设备(云计算可选),并发布 API,以更高的价格出售。
至少,我喜欢这样告诉自己。
> 可黑客攻击的本地连接设备(云计算可选),并发布应用程序接口,然后高价出售
这种商业模式行不通。
很多人都有过这种想法。他们都遇到了同样的问题:可破解家庭自动化设备的目标受众不喜欢为他们认为可以 DIY 的东西支付高价。
如果你有一个价值 70 美元、设计精美、有据可查的物联网传感器,但 DIY 家庭自动化人员却认为他们可以在 10 美元的亚马逊设备上安装 ESPHome,并实现几乎相同的功能,那么他们会买哪一个呢?
如果你浏览论坛,你已经可以发现一些半高级设备,它们的结构更好一些,功能也更齐全。在这些评论之后,总会有人推荐更便宜的选择。
> 如果你有一个价值 70 美元、设计精良、有据可查的物联网传感器,但 DIY 家庭自动化人员认为他们可以将 ESPHome 放在 10 美元的亚马逊设备上,就能实现几乎相同的功能,那么他们会买哪个呢?
我同意你的观点,针对开发人员/购买/构建意识不强的人是行不通的!
我希望那些有钱/稍有成就但没时间捣鼓东西的开发者会选择它。
虽然有点跳跃,但我认为这是 FirefoxOS 等产品的一个重大战略失误–瞄准那些有钱、买得起 600 美元的 I-support-foss-and-mozilla 信号设备的开发者,而这些设备又恰好是他们可以黑客攻击的手机,这可能比瞄准 60 美元的功能手机更有效。
> 如果你浏览论坛,你已经可以发现一些半高级设备,它们的结构更好一些,功能也更齐全。在这些设备之后,总会有人推荐更便宜的选择。
我认为这没有问题!这类似于 HN dropbox 效应。在我看来,你其实是想让这些人找到更便宜的选择,对于一个高端品牌来说,这些都是不好的客户。
但产品必须比廉价产品更好、更稳定等。在我看来,有很大一部分书呆子其实并不想写 5 个文件和闪存操作系统来做智能家居的事情,他们想在应用层玩游戏。
NAS 行业就是一个很好的反例。
当然,这都是理论上的,所以…… 在这一点上,我们只是纸上谈兵。
这不正是 GL.inet 所做的事情吗?他们似乎很成功。
这样做的公司越来越多了。
雪莱公司成立较早,便宜的中国货很容易被黑,但他们最终转向了更便宜、更复杂的芯片,在这些芯片上,定制固件不存在或不那么成熟。不过,这种情况正在发生变化!我在阿里上看到的 ESP-32 驱动的 LED 灯控制器中,有一个 USB 端口用于重新编程/标有所有 GPIO……甚至有 HA/ESP-Home/WLED 徽标的数量比我过去几年看到的要多得多(少数总比零多,不是吗?)
买东西要当心–市场上有大量标榜 “开源 ”的产品,吸引了许多人的眼球,但其中许多产品的硬件质量很差。
对于任何在市电电压下工作的产品,我的启发式判断是:“如果我能在 Temu/Aliexpress 上找到与此相似的产品,我就不会买它”。它们很可能是白牌产品,来自同样的工厂,存在同样的质量问题。
根据我的经验,智能插头中的继电器通常都很粗糙。我买的或为他人设置的插头中,大约有一半会发出令人不安的噪音,让我担心电气连接不良和火灾风险。我只有两个 Shelly 插头,但它们没有这些问题。
我一直在努力寻找高质量、可开放/本地控制的 LED 灯,这些灯的电子元件和热量控制都足够强大,不会在几年内坏掉。遗憾的是,与开源/本地控制相比,结构质量的测试/记录更为薄弱。
更不幸的是,价格本身并不是一个非常可靠的指标。价格低通常是质量差的表现,但价格高并不是质量高的表现,更多的时候是想占不懂行的人的便宜。
图雅(Tuya)和它们的改头换面版本也属于这种情况。他们的电源开关很早就坏了,而且他们的固件实际上也从容易重新编程变成了敌对固件。他们有自己的云服务,你不能离开,只能获得一个访问代码,而且固件会阻止降级。可怕的公司。
Tuya 只是一个物联网平台,被许多廉价设备使用,但我同意,它成本低,基于云,这是一个糟糕的组合。我不会碰它。
买 ZigBee 版本的就行,它们与 HA 配合得很好
> 只要购买 ZigBee 版本,它们就能与 HA 美妙结合
802.15 确实有它的用武之地,但我们中的一些人更喜欢 802.11,除非电池要求使用低功耗的 PHY。Zigbee 也在贬值;如果可能,请寻找使用 Matter 的设备进行互操作。
> 但其中许多产品的硬件质量很差。
当然。便宜的硬件意味着偷工减料……不管软件有多开放。
Shelly 设备相当开放,做工精良,但价格却是其他 wifi 中继设备的 2 倍。贝尔金 WeMo 设备的价格与 Shelly 相近,做工也很好,但他们的软件却完全不尽如人意。
了解什么风险是可以接受的,以及如何识别某个特定组件是否按照可规避风险的规格制造,这可能永远是 DIY 场景的一部分。
有 Zigbee、Z-Wave 和 Matter。这些都是完全本地化的智能家居标准,即使公司倒闭了,设备也可以设置和使用。不过,您只能使用标准化的设备。
如果你想更进一步,可以寻找为 ESPHome 生产的设备或 Shelly 生产的设备。这两种设备都有本地应用程序接口,非常容易被黑客入侵。
(披露:我是开放家庭基金会的主席,ESPHome 是我们的项目之一,我还是 Z-Wave 联盟的董事会成员。)
> 有 Zigbee、Z-Wave 和 Matter。
我不是从业者,而是一个时常关注生态系统的人,并且已经等待了一段时间,因为我还没有看到我想要的堆栈+DX/UX。
Zigbee 从未达到临界质量,需要一个集线器。Z-wave 似乎也是如此。我认为未来的趋势是通过 Wifi 传输线程(不同的协议/传输方式都可以)。
在我看来,线程会胜出,路由器会支持线程,而我只需拥有一个支持线程的路由器,它可能还有其他功能。
我不想买一个物联网集线器。我想控制的许多物联网设备都足够强大,可以运行 Wifi,而且我想用一个标准的网络协议栈来控制它们,这个协议栈的采用率很高,工具也很熟悉。线程似乎最适合这种使用情况。
以上观点很不严谨,请随意批评指正。我很想知道我今天错得有多离谱!
> 如果你想更进一步,可以寻找为 ESPHome 生产的设备或 Shelly 生产的设备。这两种设备都有本地应用程序接口,非常容易破解。
感谢您的推荐!感谢您的披露,并对您在不知情的情况下发表了大量意见表示歉意。
还有一个附带的问题–为什么获得一个仅运行本地 Wifi(真的希望没有基站)并可为电池充电的简单物联网按钮如此困难?
显然可以用 ESP32 构建,但我只想买这个。
集线器的要求有那么重要吗?我的意思是,如果你想要真正的点对点,那么是的,但如果你已经在使用家庭助理,你可以将一个便宜的 ZigBee USB 加密狗插入其中。
那么我还缺的一点是:如何纯粹通过 WiFi 控制它们?你是否在手机上运行可以控制目标的软件?例如:应用程序通过网络直接与设备对话,而不是通过在 Pi 上运行的浏览器和家庭助理。我想不出有什么产品能在不支持云的情况下以这种方式工作(例如:有一个集线器,但你并不拥有它)。
> 集线器的要求有那么重要吗?我的意思是,如果你想要真正的点对点,那么是的,但如果你已经在使用家庭助理,你可以将一个便宜的 ZigBee USB 加密狗插入其中。
也许不是,但我并不想真正运行家庭助理,我只想黑进最基本的东西,真的。我想挑选一个最开放的东西,既能方便编程,又不依赖于使用家庭助理之类的东西(并不是说它不好或什么)。
> 那么,我所缺少的部分是:如何纯粹通过 WiFi 控制它们?你是否在手机上运行能控制目标的软件?例如:应用程序通过网络直接与设备对话,而不是通过在 Pi 上运行的浏览器和家庭助理。我想不出有什么产品能在不支持云的情况下以这种方式工作(例如:有一个集线器,但你并不拥有它)。
是的,这就是我的目标 — 基本上,我希望能通过任何联网设备控制这些设备(理想情况下,同一程序能在多个地方运行)。
我的想法是,如果 “只是”(著名的遗言)有线程/Wifi,我就可以在不支持云的情况下构建这个系统。
有了这个主题中的所有优秀反馈(感谢 HN!),现在看来,小型 SBC + Thread/Zigbee/BLE 加密狗[0]是未来的发展方向,然后通过 USB 将其连接到路由器,这样它就始终有电并跟随路由器移动(也许可以用魔术贴粘)。
SBC(或者更小的,但可能是 SBC),这样我就可以自己编程了。
[0]: https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbe…
> 是的,这就是我的目标 — 基本上,我希望能从任何联网的设备上控制这些设备(理想情况下,同一个程序能在多个地方运行)。
HomeAssistant 为所有与其连接的设备提供了 REST API。我甚至不使用它的自动化功能,我只是用它的 API 从其他设备控制我的 ZWave 设备。
https://developers.home-assistant.io/docs/api/rest/ (POST 至 /api/services/,进行远程控制)
(当然,如果这是你唯一想要的功能,那么它的功能就很强大了,不过,你想要的东西确实存在)
哦,是的,我知道,谢谢你指出来。我还可以使用 zigbee2mqtt 进行 API 优先交互。
至少在一开始设置 HA 似乎是个好主意,这样我就能找出最好的部分和最差的部分,并有一个基线
Zigbee 的基本原理不是家庭助理,而是类似 zigbee2mqtt 的 USB 加密狗,然后直接连接到 mqtt 代理。
对于我的自动化系统,我就是这样做的,我绕过了家庭助理,直接通过 mqtt 控制我的设备。效果非常好。
家庭助理完全可以拥有 Zigbee 协调器,而且效果也非常好(这是我几年来一直使用的 SkyConnect 加密狗)。
是的,我的意思是,如果你不愿意,就不必依赖家庭助理。
也许这并不是你想要的,但你可以看看 Shelly BLU Button1。这是一款电池寿命长的 BLE 按钮。
按下时会发出 BLE 数据包,家庭助理可通过蓝牙适配器或蓝牙代理接收这些数据包。您可以使用任何 ESP32 和 https://esphome.io/projects/?type=bluetooth 制作后者。
顺便说一下,我刚买了一堆 Shelly 的东西。看来这个项目可能会比我想象的更快实现!Shelly 1 看起来也是一个不错的选择:)
再次感谢您的推荐。
感谢您的推荐!这肯定会让事情变得更简单。BLE 电源模式 + BLE 唤醒 + wifi 也许可以方便使用!
听起来像是一个遥远的周末项目
> 我不想买物联网集线器。
期望不同。我不想让我的东西知道 Wifi 的存在。它能阻止供应商锁定,确保本地通信,即使网络瘫痪也能正常工作。这还能确保它们永远不会自动更新或加入 Mirai 僵尸网络。
我家里混合使用了 zwave(fibaro)、ZigBee(宜家)和 ble,我对此很满意。
我也是,我喜欢知道我的设备都无法访问网络,它们只能与 HomeAssistant 通信。
有了 Zigbee 绑定,即使 HomeAssistant 出现故障,我的大部分输入设备也能正常工作。
HomeAssistant 并没有出现过故障,但我可以想象它的固态硬盘或其他设备出现故障时的情景,在我更换新设备的几天时间里,我不会费心将它转移到其他电脑上。
是的,我想也是 — 我想至少我能控制我的路由器,所以我不必担心。虽然如此,但可能还是无法避免僵尸网络的情况。
另外,不幸的是,直到现在我都说错了–我指的是 “Matter over Thread ”和 “Matter over Wifi”。对我来说,Matter over Wifi 似乎更胜一筹,因为我可以直接使用它。
看来今后我将把一个小型 SBC 插入路由器的 USB(+ 以太网),然后连接一个 Zigbee + Thread 加密狗。这应该能满足我的大多数通信选择,然后就 “只是 ”软件问题了:)
在我看来,线和物质对消费者来说永远都不重要。为什么?它基本上是一个有围墙的花园。
想一想 HomeKit,但它更开放一点,开放的一点是,供应商可以允许它与其他供应商的设备通信。但他们不必这样做。
线程还需要更昂贵的 SOC,而 Zigbee 只需要一个几 MHz 时钟速度和几 KB RAM 的微型控制器。而 Thread 和 matter 则需要数百万字节的 RAM。
如今销售 HomeKit 设备的供应商可以将其 SOC 用于线程物质,从而使其价格比 Zigbee 供应商提供的具有相同功能的设备高出 3-4 倍。
> 在我看来,“线程 ”和 “物质 ”对消费者来说永远都不重要。为什么?这基本上就是一个有围墙的花园。
我想反驳的是,有围墙的花园非常受欢迎,尤其是对消费者而言。消费者不在乎大门是否上锁,他们在乎的是花园里的花是否漂亮,花园聚会上的茶是否好喝。
> 线程还需要更昂贵的 SOC,而使用 Zigbee 时,你只需要一个几 MHz 时钟速度和几 KB RAM 的微型控制器。而线程和物质则需要数百万字节的 RAM。
在我看来,SOC 的价格正在归零。ESP32 就是一个很好的例子。一旦 RISCV 得到更广泛的应用并具备更强的能力,一切都将加速发展。
> 现在销售 HomeKit 设备的供应商可以在线程方面重复使用他们的 SOC,从而保持比 Zigbee 供应商提供的具有相同功能的设备高出 3-4 倍的价格。
我想我们在这里达成了一致……?我认为更开放一点的 HomeKit 设备会胜出。但我认为,如果 HomeKit 设备只是一个路由器,那么它的采用速度会更快–我可以理解更新路由器来实现智能家居。我不希望在是否需要集线器、设备是否能协同工作等问题上出现混乱。
购买一个路由器作为集线器,再加上能 “扩展 ”信号的 Wifi “中继器”(我记得它们是这么叫的)(沿途给其他设备提供一个连接点),这对我这个消费者来说是非常合理的。我已经知道什么是 WiFi,我想要的是更好的覆盖,而不是更差的覆盖。智能家居只是我已经熟悉的技术中的一部分,效率才是最重要的。
Thread 是 WiFi 的替代品,设备通过 Thread 进行 IP 通信。
它与供应商控制的集线器之间有一个加密配对过程。该供应商可以允许或禁止其他供应商与该集线器通话。
以下是我们所掌握的情况: HomeKit:完全封闭,需要苹果认证。价格昂贵,功能有限。
Zigbee:完全开放,任何人都可以制造和销售 Zigbee 设备,不受任何限制。在全球以相同频率运行。设备超级便宜。作为供应商,您可以随意扩展协议。
Z-wave:完全封闭,多个频率不兼容,销售设备需要认证。
Thread and matter:半封闭,数据传输与 Zigbee 采用相同的 IEEE 标准。供应商可以让它与其他供应商的设备进行对话。需要认证。价格与 HomeKit 相同,也就是比 Zigbee 贵 3-4 倍。
它们都需要集线器。只有使用 Zigbee,才能保证在全球销售的所有供应商和所有设备之间实现互操作。多亏了家庭助理。如果有了线程,供应商就可以直接禁止您使用带有 HomeAssistant 的设备,这对我来说是无法接受的。
感谢您提供的所有背景/解释以及后续说明。自动范围扩展(即真正成为一个网状结构并转发信息)是一项出色的功能。
> 所有这些都需要集线器。只有使用 Zigbee,才能保证所有供应商和全球销售的所有设备之间的互操作性。多亏了家庭助理。有了线程,供应商可以直接禁止您使用带有 HomeAssistant 的设备,这对我来说是不可接受的。
我想反驳的是这一点–通过 Wifi 传输线程不需要特殊的集线器,对吗?结合本主题中的其他信息,很明显在现实世界中,要找到合适的硬件并不那么简单……但购买一个线程设备并通过普通的旧式无线网络使用是有可能的。
听起来 Zigbee 比 Thread 或 Thread/Wifi 更接近理想状态。
也许这就是某些人需要做的启动工作 — 将一些供电合理的设备连接到路由器/连接到支持 Thread 和 Zigbee 的路由器附近,进行完全本地化的管理,然后就可以了。这是否会让智能集线器变得过于复杂?不知道。
Thread 使用与 Zigbee 相同的协议,需要专门的硬件才能与之通信。如果想在 WiFi 网络上使用它们,就无法绕过集中式集线器。
Thread 只是在 Zigbee 上增加了一个 IP 层。Zigbee 与以太网或 WiFi 处于同一协议层。
> 线程只是在 Zigbee 上增加了一个 IP 层
澄清一下: Thread 并非建立在 Zigbee 之上,它们都是基于 802.15.4 独立构建的
正确,这使得一个芯片可以通过一根天线同时使用两种协议。
nabu casa 出售的 USB 棒就可以做到这一点。
技术上可行,但不足以超越 “实验性”
> 该实验固件自 2022 年 12 月起可用。通过大量测试,我们发现虽然它在某些情况下可以工作,但它存在技术限制,导致用户体验较差。现在,我们不建议使用该固件,在可预见的未来,它仍将是实验性的。相反,我们将专注于确保 Home Assistant Connect ZBT-1 的专用 Zigbee 和 Thread 固件为用户提供最佳体验。
https://www.home-assistant.io/connectzbt1/
> Thread 采用与 Zigbee 相同的协议,需要专用硬件才能与之通信。如果想在 WiFi 网络上使用它们,就无法绕过集中式集线器。> > Thread 只是在 Zigbee 上增加了一个 IP 层。Zigbee 与以太网或 WiFi 处于同一协议层。
啊,我才意识到我用错了术语。
我一直想说的是 “Matter over Thread ”与 “Matter over Wifi”!
Matter 似乎是一个不错的发展方向,它只能通过 Wifi 工作,这也是吸引我关注 Matter 的原因。我记得 Matter/Zigbee 并不是一个东西(虽然从技术上讲应该是可行的,但就 Matter 而言,Zigbee 只是一种传输方式,对吗?)
[编辑] 工作 -> 可以工作,线程/Zigbee -> 物质/Zigbee
但棘手的问题来了,当你购买 Zigbee 或 matter 设备时,每个供应商都会添加自己的扩展。
在 Zigbee 生态系统中,尽管 Zigbee 是一种可互操作的标准,但厂商们却拒绝与其他厂商的设备进行通信。
这就促成了 zigbee2mqtt 的诞生,它耗费了数百年的开发时间,目的是为现有的所有 Zigbee 设备提供全面的功能支持。
对于线程和物质设备,每个供应商都必须这样做。而这是不可能实现的,这将导致一个支离破碎的生态系统。
真是令人沮丧。
再次感谢你的阐述 — 我到处都能看到 zigbee2mqtt,这也解释了为什么有人会在其中加入 mqtt。听起来这又是一个需要在软件方面运行/管理才能稳健的东西。
这是一个疯狂的目标(谁知道我什么时候才能真正开始这个项目),但我想做的是一个 “能正常工作 ”的一体化系统。所以大致是这样的
1. 选择一个足够好的物理通讯堆栈来处理大多数事情
2. 2. 编写软件来填充其余部分
这将会很困难,但感觉所有这些工具的设置都很难,但如果你能确定硬件/安装说明,然后编写一个真正像样的软件层将其整合在一起,又不会让人们去做家庭实验室,那么设置就不难了。
话虽如此,但在达到目前的复杂程度之前,家庭助理开发人员可能也是这么想的。
我认为我的秘诀是 WebAssembly — 如果我能确定下面的硬件,通过 WebAssembly 构建/转换大量适配器,然后在此基础上构建一个令人信服/易于添加/安装/管理/配置的用户界面,我也许有一天能在 HN 上发布一些值得发布的东西。
在我看来,到 2030 年代,thread 和 matter 可能会像 homeassistant 和 zigbe2mqtt 一样成熟。目前,Zigbee 设备可以在没有任何集线器的情况下工作,只要你坚持使用一家供应商的产品。
我相信你只需要一个集线器来创建设备组,然后用一个开关就能控制这些设备。然后,你就可以拔掉集线器,继续使用它们,只需要一个集线器来实现以太网桥接和自动化。
> 我相信你只需要一个集线器来创建设备组,然后用一个交换机就能控制这些设备。然后,你就可以拔掉集线器,继续使用它们,只需要一个集线器来实现以太网桥接和自动化。
谢谢你指出这一点,我只需要一个 Zigbee 协调器(如果我目前对灯具的研究是正确的话)就可以使用了。
我想宜家的灯泡也会是我的未来。
Thread 和 Zigbee 执行相同的 IEEE 标准。
Matter 正确地说应该是线程的应用层协议,可以通过任何传输方式进行通信。如 HTTP
对了,Zigbee 标准的一部分就是自动范围扩展。每个带插头的设备都能扩展你的网络。
> 我不想购买物联网集线器。我想控制的许多物联网设备功能强大,足以运行 Wifi、
我在这方面拥有丰富的职业经验,因此我更倾向于让我的物联网设备远离我的 WiFi。
您不需要单独的 Zigbee 或 Z-Wave 集线器设备,只需将一个简单的 USB 适配器直接插入控制所有设备的设备即可。
让低带宽物联网设备远离主 WiFi 有很多好处。例如,当你无需重新连接家中的每个电灯开关就能完成所有操作时,更换 WiFi 密码也会容易得多。
感谢您在此分享经验 — 我同意最好避免喋喋不休,而且轮换 WiFi 密码确实是一个需要考虑的问题,那会相当麻烦。
集线器 “设备可以是一个 USB 记忆棒,连接到运行家庭助理的机器上。这就是我多年来一直在运行的设备,一个 Z-Wave USB 记忆棒,通过它连接到一个 ZwaveJS docker 容器(它也能与 HA 通信)。
因此,你并不需要一个大型的独立设备,它必须有自己的 Wifi 或以太网或类似的东西,它只是一个 USB 棒。
谢谢!这就是我最终的想法。虽然如此,我还是倾向于把 U 盘放在 Pi 或类似的东西里,它连接到路由器并由路由器供电!
我只想有一个设备,而且我认为这也许是最简单的方法,不用在路由器上运行东西。
基本上,它是一个集线器,但更像是路由器的附件。
> 为什么要弄一个只运行本地 Wifi(真的希望没有基站)并可为电池充电的简单物联网按钮这么难?
电池寿命太短,深度睡眠时的延迟也很严重。我从宜家买的 Zigbee 按钮用 nimh 电池供电已经好几年了,但只用了一半的电量。集线器是一个连接到家庭助理服务器的 USB 加密狗,没有任何问题。
> 电池寿命太短,深度睡眠时的延迟会很严重。我从宜家买的 Zigbee 按钮用的是尼姆电池,已经用了几年,但只用了一半的电量。集线器是一个连接到家庭助理服务器的 USB 加密狗,没有任何问题。
那么你认为电池寿命 “糟糕 ”到什么程度?我的容忍度很高,但问题是它们根本不存在。每个人似乎都会以 “不值得 ”为由搪塞过去。
> 我从宜家买了几个用 nimh 电池供电的 Zigbee 按钮,用了几年也只用了一半的电量。
这对我来说太紧张了,如果能把部署工作简化 10 倍,我对每 6 个月更换一次电池就已经很满意了。
> 集线器是一个连接到家庭助理服务器的 USB 加密狗,没有任何问题。
也许部署并不像我说的那么难!也就是说,没有什么比向一个 IP 地址发送一些数据包更简单的了。我想 Zigbee APK 应该很容易… 但举例来说,如果我在 crates.io (https://crates.io/search?q=zigbee)上搜索,我并没有看到任何明显的选择。
重述一下我的想法(希望听起来更合理一些),我希望能买一个智能灯泡,通过 BLE 配置它连接到 Wifi,然后在其余的使用时间里通过 Wifi 配置/更改它。如果能做到这一点,我可以每隔 1 到 6 个月更换一次电池!
> 也许部署并不像我说的那么难!也就是说,没有什么比向一个 IP 地址发送一些数据包更简单的了。
我想可能是这样的。买一个 USB zigbee 加密狗,花 1 个小时设置一下家庭助理,就差不多了。添加新设备只需点击 HA 中的一个按钮,允许设备加入,然后打开设备电源即可。它将发现网络并报告所提供的功能。
您可以通过 HA 的无线网络控制设备。此外,HA 还为您提供了一个应用程序接口(API),当您向网络中添加新的设备类别时,您无需维护和更新该应用程序接口。
重复更换 Wifi 设备电池所花费的时间远远多于配置一次 HA 所花费的时间。
编辑补充:有一件好事我忘了说,那就是在自制设备上使用 HA,可以为这些设备和商用设备保留一个统一的 API。您可以构建一个带有自定义传感器、显示器等的小型 ESP32 设备,并像使用现成产品一样控制这些设备。
是的,这些都是很好的观点,谢谢。
我真的需要弄清楚我想深入到什么程度 — HomeAssistant 显然是最好的现成选择。也许我会先建立 HA,然后再看看是否值得尝试建立更好的东西。
BLE 也应该可以工作,但您还需要一个加密狗,所以硬件上是一样的;理想情况下,您还需要几个网关(Shelly 设备开箱就可以做到这一点,新的 Shellies 将支持 Zigbee)。
您应该研究一下 Zigbee2mqtt。
是的,你说得没错 — 看起来 zigbee2mqtt 是一个巨大的解锁,没有它就很难构建,因为它支持的东西太多了!
对于现在必须同时使用 MQTT 代理并不感到兴奋,但是…… 运行大多数代理可能都很简单,而且很可能是单机即可完成。
有了 Thread+WiFi,设备能与互联网对话吗?我喜欢 Zigbee/Z-Wave 的一个重要原因就是它们不具备这种能力。
Wifi 可以。线程取决于线程边界路由器的设置。我们的默认设置是无法访问互联网。
我肯定我是在说给唱诗班听,但接入 Wifi != 接入互联网!
我之所以对通过 Wifi 连接线程感到兴奋,是因为我不需要任何额外的专用设备,而且一个设备就可以独立运行。
话虽如此,但要在没有网络的情况下购买可以访问 WiFi 的设备确实很难。制造商很容易在包装盒上写入网络要求,却不在包装盒上标明。使用其他协议则会使这种期望消失。
这一点很好,我到现在才考虑到。广告支持模式无法潜入。
现在我真的很想知道,为什么无线网络没有兴起。
ZWave 是目前最稳定的基于无线电的标准。它并不出色,扩展性也不强,但还算可以。有一种可黑客攻击的设备:https://z-uno.z-wave.me/technical/,但其 SDK 并不出色。
纯 ZigBee 则……很不稳定,因为没有认证要求。Matter 处于开发地狱,但正在慢慢好转。
与 ZWave/ZigBee/Thread 相比,WiFi 的问题在于能效(或缺乏能效)。
到目前为止,我已经尝试了大多数家用无线电标准。Lutron 是最可靠的,但它也是超级专有的。我的下一栋房子将只用低压电缆导管连接所有的电灯开关,这样我就可以使用 KNX 这样的标准,而不是基于无线电的标准。
这样的开发板太贵了…
这里有一个支持线程和 zigbee 的 esp32-h2,价格为 5-12 美元
https://a.aliexpress.com/_mMfZEsX
我认为对这种东西的支持可能比 70 多美元的开发板增加得更快。
> 与 ZWave/ZigBee/Thread 相比,WiFi 的问题在于能效(或能效不足)。
这是我很想用老办法解决的一个问题,我认为它阻碍了太多的建设。对我来说,能量密度、可充电性等问题就像 CPU 速度一样 — 最终会得到解决,我可以每个月更换一次设备或更换可充电电池(尤其是如果设备能告诉我电池电量不足)。
我真的认为最终会是内置线程天线的线程+无线路由器获胜(至少是我获胜)。
如果 ZWave 或 ZigBee 能够进入家用路由器领域,它们早就赢了。直到现在,它们还没能成功,可能有一些令人讨厌的原因。
> 到目前为止,我已经尝试了大多数家用无线电标准。路创是最可靠的,但它也是超级专有的。我的下一栋房子将只用低压电缆导管连接所有的电灯开关,这样我就可以使用 KNX 这样的产品,而不是基于无线电的产品。
谢谢你分享了这些和你的其他经验!
也感谢 KNX。
> 我真的认为最终会是内置线程天线的线程+Wifi 路由器获胜(至少是我获胜)。
事实上,这种情况已经存在了一段时间。很多 WiFi 路由器都内置了线程(ZigBee)无线电,但后来没人真正使用它们,制造商也就不再理会它们了。所以,现在几乎只有 Eero 接入点还有这种功能。
> 此外,还有 KNX。
我的梦想是拥有完全触觉反馈的_actuated_开关。这样,当远程开关时,桨叶就会物理翻转。
我委托一家工程公司对此进行了研究,但根据美国 NEC 和 UL 的要求,这显然是不可行的。唯一的办法是使用低压线路连接开关,然后用它们来控制线路电压继电器。这种系统在欧洲很流行,所以你还不如直接使用 KNX 这样的系统。
> 实际上,这种情况已经存在了一段时间。很多 WiFi 路由器都内置了 Thread (ZigBee) 无线电,但后来没人真正使用它们,制造商也就不再理会它们了。所以现在几乎只有 Eero 接入点还在使用。
谢谢你提供的背景信息–当我搜索时,我只找到了 “线程边界路由器”–我找不到一个知名品牌生产的路由器包含线程功能–似乎总是 “买一个路由器,再买一个线程边界路由器”。
我真的很惊讶自己错过了这个浪潮,不知道这是否是 “我们希望人们买两样东西”,而不是没有人真正使用它。也许我只需要等待它再次出现?
也许答案是一个 USB 供电设备,带有一个额外的 2.4Ghz 无线电(运行像……OpenThread 或我需要的任何东西)。OpenThread或任何我需要在可用天线上做的线程)连接到路由器上?
我不明白的是,为什么要使用现有路由器的 2.4Ghz 天线?老实说,空间的混乱程度和设备不能做多种事情的情况真的很烦人。我只能猜测,这种东西之所以不简单/不明显,是因为利益驱动(当然,除了设计良好标准的难度之外!)。
[编辑] 好吧,虽然频率相同,但天线并不相同–显然这是为了确保硬件层面的快速运行。
因此,如果我从贸泽公司购买一些零件,附加天线也许可以工作:
https://eu.mouser.com/c/passive-components/antennas/?protoco…
[EDIT2] 不,更糊涂了。多协议天线是存在的。为什么所有路由器都没有这种即插即用的功能?谁能告诉我这里面的政治/权力斗争或其他什么真正的原因。然后在我的路由器上连接+粘贴一些东西。
> 真的很惊讶,我竟然错过了这一波浪潮,不知道这是否是 “我们希望人们买两样东西”,而不是没有人真正使用它。也许我只能等待它再次出现?
更糟的是。市场上没有新的独立线程边界路由器。你可能会找到 GL.iNet 路由器的旧库存,我相信还有其他一些实验性设备。
如果你想要一个强大的 Matter 网络,最好的办法就是使用苹果或谷歌设备作为边界路由器。或者你也可以使用带有 HomeAssistant 的 USB ZigBee 棒。
> [编辑 2] 不,更糊涂了。多协议天线是存在的。为什么所有路由器都不提供这种即插即用的选项?
没有市场需求,所以路由器制造商就懒得做了。最初版本的 Matter 就是一团燃烧的垃圾。
谢谢你给我的颜色 — 虽然很难过,但我懂了。
听起来我们就快成功了,Zigbee/Thread 至少可以支持相同的硬件。我想我可以接受!
> 没有市场需求,所以路由器制造商就懒得去做。最初版本的 Matter 是一团燃烧的垃圾。
我记得我听说过这件事–他们最终修复/改进了它,但我想伤害已经造成了。
等等,我很好奇:为什么这种东西不能内置 Wifi/其他无线电?
UL 要求开关能够以一种无法远程启动的方式物理断开连接。因此开关需要额外的物理切断开关。这很有趣,但可行。
问题的关键在于功率耗散要求。螺线管既小巧又强大,足以驱动桨叶,但如果卡在 “开 ”的状态,就会耗散过多的功率。小型齿轮电机也不行,因为开关必须是双稳态的,不能卡在中间。
因此,如果使用集成设备,桨叶最终将只是一个输入设备,而不是一个实际的电流中断元件。如果不采用类似苹果公司的工程设计,开关内部就没有足够的空间容纳所有部件。
文章确实提到了 https://refoss.net/,引用如下:
很多 “智能 ”产品都带有 BK7231x 芯片,可以闪存到 esphome,没有人需要另一个自定义协议(即使是开放协议),因为 esphome 目前支持本地加密传输,比 99% 的中国(甚至西方)公司设计的本地通信都要好。
哦,大多数业余爱好者也不会为这些产品支付高价,除非这些产品预装了 esphome 并赞助了 hass 项目,即便如此,90% 的人还是会购买市场上最便宜的产品。)
这不正是 zigbee 和物质吗?
我只是想知道,既然已经有了可以完美虚拟运行的 hassOS,为什么还有人要费尽周折在 Linux 上安装家庭助手呢?
因为我们想在同一个操作系统上运行的不仅仅是家庭助理?因为传统上操作系统和应用层是分离的?因为在 LTS 和安全补丁方面,我们更信任成熟的 Linux 发行版?因为我们对 Debian/Ubuntu/Nix 等已经了如指掌?
完全正确。一旦你开始在家中运行应用程序,并对其质量有了一定的要求,你最终不得不在应用程序上附加各种东西(VPN、DNS、日志聚合等),而这些东西最好是包裹在应用程序中,而不是让它们在应用程序中运行。而 AppOS 通常会妨碍这些工作,而且正如 edejong 所说,你已经知道如何在典型的生产型操作系统上完成这些工作,而学习如何在每个 AppOS 上完成这些工作实在是太麻烦了。
Proxmox 只增加了很少的开销。我在运行 HAOS 的同时还在运行几十个应用程序。
操作系统是阻力最小的途径,维护成本低,却能带来最佳体验。
https://community-scripts.github.io/ProxmoxVE/scripts?id=hao…
> Proxmox 只增加了很少的开销。
它仍在运行第二个内核和整个用户空间栈。在我的世界里,这可不是 “很小的开销”。
ProxMox 支持虚拟机和 LXC 容器。你可以使用 LXC 容器来降低开销。没有第二个内核。
ProxMox 支持它,但这不是链接脚本所做的,也不是 HAOS 官方支持的。
是的!
我知道这里有一些取舍。具体到家庭助理,如果你想继续获得一流的支持,有两种选择。裸机运行或在虚拟机中运行。
选择不同的路径并不是一个糟糕的选择,甚至可以说是一个很大的降级。
6 年多前,我曾体验过运行家庭助理的各种不同方式,然后决定采用一种最省事、可长期使用的解决方案。我对自己的选择很满意,它带给我的正是我所期待的。
将 Proxmox 与 lxc 容器一起使用时,不需要第二个内核。它使用主机内核的本地 cgroups 和命名空间进行进程隔离。实际上,只使用系统和命名空间也能达到同样的效果。
话虽如此,但我认为如果你喜欢传统的发行版打包方式,那就绝对应该坚持这样做。
我在运行 HA 的同时也在运行几十个东西,而且我不需要使用 proxmox。
在不支持的模式下运行 HA 并不难。唯一真正的区别是,它会恼人地提醒你不支持。其他一切都能正常运行,包括插件/附加组件。
我曾以多种方式运行 HA。这其实并不重要。使用 HACS 来填补空白。
一键更新可以在仪表板上进行吗?我觉得不行。
当然,你不一定要走 proxmox 路线,但这是一条简单的路线。
我有一个 proxmox 集群,因此在机器间移动、高可用性和备份都轻而易举。几个月前,我的一个固态硬盘坏了,我就把那台机器上的所有东西转移到另一个节点上,直到新硬盘出现。这是一次愉快的经历。
有很多其他方法可以做到这一点,但这是我的选择,我很满意。它很简单,如果需要的话,我可以用手机管理一切。
附议。我的家庭服务器有很多功能,其中之一就是 homeassistant。
我曾经通过 Docker 使用家庭助理,但后来我改用了 Proxmox,在一个虚拟机中使用 HAOS,并用第二个 Debian 虚拟机处理其他事务。我这样做的主要原因是这似乎是更受支持的方案。例如,在语音助手刚问世时,只有 HAOS 附加组件才真正记录了设置。我设法让它在独立的 Docker 容器上运行,但要弄明白很麻烦。在我看来,使用 HAOS 确实更简单。
> 当涉及到 LTS 和安全补丁时,我们更信任成熟的 Linux 发行版
这一点。如果我不得不信任某个巨大的容器或定制操作系统,那么开源的好处又在哪里呢?
> 太棒了
这是很主观的看法。
如前所述,人们很少只为一个目的而运行专用物理服务器。家庭助理操作系统的概念正是如此。
此外,它基于 Debian。它使用速度较慢的 `apt` 软件包管理器。有些人可能更喜欢更快、更现代的东西,比如 `pacman` 或 `dnf`。
> 完美虚拟化运行
有道理。
但这显然需要在服务器上设置虚拟化。如果人们不在服务器上使用虚拟化,他们还不如直接设置家庭助理。
最后,我认为还有一个问题。
许多与家庭助理操作系统的集成都需要将物理硬件连接到服务器上。阅读器、接收器之类的东西。
但这些家庭服务器通常被放置在一些难以接近的地方,比如阁楼,在那里无法获得传感器的数据。在那里铺设电缆可能不太现实。而且无线设备可能离得太远,那里的接收器无法读取。
因此,人们需要想出一些变通办法,将数据传输到服务器。他们设置了各种信号代理和瘦客户机,在有传感器的地方接收来自传感器的数据,然后通过网络将数据发送到家庭助理服务器。
遗憾的是,根据我的经验,许多集成完全忽略了这种用例。它们很可能只专注于将所有设备本地连接到 “唯一 ”服务器上。只有这样,它们才会表现良好,开箱即用。但一旦您需要任何特殊步骤或行为,就必须深入挖掘并创建自定义层,以便将数据从设备传输到服务器。
家庭助理操作系统并没有简化这些工作。也许恰恰相反,它迫使你使用特定的基于 Debian 的发行版,这些发行版的软件包可能已经过时,你无法在不破坏 Home Assistant 的情况下轻松升级。
因此,在我看来,对于这类安装,使用它是毫无意义的。
> 此外,它基于 Debian。它使用的`apt`软件包管理器速度很慢。有些人可能更喜欢更快、更现代的东西,比如 `pacman` 或 `dnf`。
人们真的在乎解析一个软件包索引需要 5 秒还是 1 秒吗?我完全不明白这种说法。
我完全同意你的观点。这是我遇到过的最奇怪的反对理由之一。
你还没意识到这是基于虚构的:
> 家庭助理操作系统并非基于像 Ubuntu 这样的普通 Linux 发行版。
https://github.com/home-assistant/operating-system
HAOS 上没有 apt 或其他软件包管理器。
是的,你说得对。还有一个抽象层。
家庭助理操作系统使用 Buildroot,而 Buildroot 使用 Docker 来运行带有家庭助理主管的容器。只有该容器基于 Debian [0]。
[0] https://github.com/home-assistant/operating-system/blob/0c75…
这完全无关紧要,因为它是在一个永远不会使用 `apt` 的不可变容器中。
几周前,我给一台闲置了几个月的笔记本电脑供电。它安装了 Ubuntu 22.04。最初的 “apt-get update ”花了一些时间下载新的索引,之后又花了将近 3 分钟来处理所有索引,而我就在那里盯着屏幕,不知道自己为什么要盯着屏幕看那么久,因为只要我的任何一台机器关机超过几周,这种经历就会发生。apt 确实很慢。
我刚刚在 Debian 和 Alpine 上安装了 python3。它需要 16s 对 4s(我进行了三次测试,并保留了 Debian 最快的测量值和 Alpine 最慢的测量值)。
当然,一次性等待 12 秒并不会改变我的生活。但我不会只用一次 apt/apk,我会在每次安装时都使用它。当我的工作流程因为等待机器完成工作而被打断时,我很不爽,增加 300% 的等待时间也无济于事。
这对我来说不是决定性因素。但这并不能为基于 Debian 的方法加分。
> 人们真的在乎吗?
我想这取决于情况。我很在意,因为我通常需要定期做这个工作。而且快速完成也很不错。
那在 Kubernetes 中运行它的人呢?^^;;
我试着为妻子在带触摸屏的 raspi 4 上安装它。raspi 在 Debian 下运行正常,尤其是它的安装程序会要求提供 wifi 和 ssh 密钥,因此你可以轻松地连接到它。
而 homeassistant 安装程序则不然。没有 wifi 设置,也没有 ssh 访问。你真的需要用电缆连接,然后映射新的 IP,然后我就卡住了,因为网络服务器没有显示出来。连接键盘后,我进入了一个受限的 ha> 提示,在这里我无法修复任何问题。
到目前为止,情况糟透了
几个月前,我在测试家庭助理设置时也这么做了,但结果恰恰相反。我忘了具体是怎么做的了,但在安装之前,我编辑了一个包含 wifi 设置的文件,并将我的公开 ssh 密钥放到了 SD 卡上。
如果使用以太网,则无需编辑。网络界面会自动进入设置模式。
值得注意的是,ha cli[0] (ha>) 也有一个 “network ”命令来进行配置。
[0] https://github.com/home-assistant/cli
请注意,您不应该使用带有 SD 卡的 Pi 进行 HA。我不确定官方的立场是什么,但是: 在我的同行小组中,SD 卡故障是绝大多数问题的罪魁祸首。原因可能是大量日志记录和断电的混合;可能是电网的原因,也可能是用户在断电前没有关闭 Pi 的错误。
在我们家,我通过虚拟机(在一台强大的服务器上)运行 HAOS。我妻子在她的手机上使用该应用程序(我也是),我们还为客人准备了一台装有该应用程序的廉价平板电脑。在笔记本电脑/台式机上,我们也可以访问网页用户界面。
正如文章所指出的,手机的远程访问可以通过商业产品或 VPN(如我们的情况:OpnSense 上的 wireguard)完成。
完全是传闻,但我从 SD 在 Pi 上运行 HA 已经好几年了,没有任何问题。
这完全取决于你有多少东西。当自动备份变得很大(1G 以上)时,我的 Linux io 调度程序就开始出问题了,它会挂起并需要电源循环。
> 完全取决于你有多少东西
还要看你用的是什么 SD 卡,不同型号的 SD 卡耐用性差别很大。我的仪表盘摄像头使用的 SD 卡(闪迪 MAX ENDURANCE 卡)已经用了好几年了,而其他一些便宜的 SD 卡,如果你用它来写入大量文件,可能几个月后就不能正常工作了。
轶事同意,但我只用它来装灯(大约 20 个智能灯泡 + 5 个传感器 + 4 个遥控器),而且我从不修补它。至少 4 年后,那个小小的 Raspberry Pi 3 + ZigBee 加密狗 + sdcard 就有点被遗忘了。
有趣的是,我的 Raspberry Pi 3B+ + Zwave 加密狗 + SD 卡最终变得太慢(以至于 HAOS 更新失败)。我把它换成了一个旧的 ChromeBox,从那以后就再也没有出现过问题。
非常感谢 Home Assistant 让一切变得如此容易访问,但它本质上是一个复杂的项目。此外,它还必须努力做到面面俱到,因此很难在所有选项中找到最简单的设置路径。
有两种方法可以使用家庭助理:
1. 识别简单路径说明,购买完全匹配的设备,并严格按照说明操作。只使用集成度高的设备。必要时才升级。只要一切正常,就不做任何更改。
2. 愿意花大量时间修补和调试。在我所在的一个大型 Slacks 中,有一个很大的家庭助理频道,每个人最终都会遇到需要花几天或几周时间才能解决的问题。
许多公司都试图将家庭助理包装或用作即插即用物联网集线器的基础,但他们最终似乎都意识到,一旦你稍稍偏离了具有出色支持的设备列表,它就真的需要一个有能力且愿意参与其中的人。这甚至不完全是家庭助理的错: 这些设备大多不是为第三方控制而设计的。
如果在 ha> 提示符下输入 “login”(登录),就会得到一个 root shell。
这也是我不得不接受的 HA 问题。在我的案例中,它是在虚拟机中运行的,所以开箱即用,但安装后不能直接 ssh 到它,而且 ha> 提示也有点不同。到目前为止,虽然偶尔需要花些时间来了解如何操作,但它并不碍事。
不过它非常灵活,除了家里的设备,还有很多外部数据源可以使用,比如天气数据、太阳高度或垃圾回收日期。通过手机上的 HA 应用程序,您可以在一个流程中使用许多传感器。根据我的经验,花在这上面的时间通常会产生值得花的结果。
您不需要 nmap;请访问 http://homeassistant.local:8123
我建议你使用 docker 实例。设置非常简单。
没有 HAAS 对我做各种事情几乎没有影响,而 HACS 可以让你访问一大堆额外的东西,而且可以在 docker 中运行。
+1. 我知道父版本读起来像 “按我的方式做”,但在 docker 中运行确实更简单。
> Home Assistant 支持该远程选项,但不支持其他选项。
它只是一个反向代理。你可以随意设置。Wireguard、cloudflare 通道、带有安全插件的 caddy,选择无限。
我对 HA 试图让我在其发行版之外难以运行的做法感到恼火,于是安装了 openHAB。我发现这对我来说已经足够好了。
有趣的是,我的经历恰恰相反: 我对 OpenHab 的一切都感到非常沮丧,而对 Home Assistant 的多功能集成和简易设置感到非常高兴……
如果你按照他们的要求使用 OpenHab,那就更容易了。但是,如果你不想在专用电脑上使用它,就会变得更加困难。
很长时间以来,我一直在使用单个脚本运行家庭自动化,并对此感到满意。后来我发现自己在一个偏远的地方,那里的互联网服务供应商给了我一个低劣的调制解调器,当没有大量使用时就会挂起。
我不得不通过给智能插头[1] 上电来自动重启调制解调器,结果发现 Home Assistant 在这方面非常有用。官方 HW 集成和 Node-RED 非常直接地解决了我的问题。从那时起,我就开始通过 HA 管理和监控家中的各种硬件设备。
有趣的是,有些制造商不仅对 HA 没有意见,而且还与 HA 集成开发商合作,使他们的物联网产品能够离线使用,尽管他们的官方应用程序完全被屏蔽了。
如今,我在购买物联网设备前都会先检查一下 HA 兼容性。
[1] https://abishekmuthian.com/restart-modem-automatically-when-…
我不太懂 HA。对于大多数人的家庭自动化需求来说,它似乎过于庞大。也许我只是因为我的房子完全是 KNX 布线而感到厌倦,但我唯一需要的 “附加组件 ”是 NodeRed,用于一些仪表盘和 ESP 集成,这些只是为了额外的监控。它可以在一个单独的 docker 容器中正常运行,不需要一百万个依赖项。
话说回来,我也不明白为什么人们要购买所有基于 “智能”/云的设备,并试图将所有东西都粘合在一起–当硬件出现故障时,很可能供应商已经不存在或不再支持它了,然后你又要从头开始。
你的房子已经安装了替代设备,你就不能想象那些没有这种基础设施的人正在寻找一种实现智能自动化的方法吗?
我使用 HA 多年了,我很喜欢它,它能做我需要它做的事情,同时在后台安静地运行。我没有任何 “基于云 ”的设备,所以我不在乎供应商是否倒闭。
我的设备是 wifi、z-wave 和摄像头的混合体,摄像头通过以太网连接,但可以与 onvif 集成。
我的房子也建于 1958 年,我不可能在任何地方铺设 KNX 电缆,更不可能在所有地方都安装设备。
所以,这个评论可以归结为 “这个免费软件项目能力太强,而且存在依赖云服务器的硬件”。
> Home Assistant 支持该远程选项,但不支持其他选项。
openHAB 云连接器允许将本地 openHAB 运行时连接到远程 openHAB 云实例,例如 myopenHAB.org,它是 openHAB 基金会托管的 openHAB 云服务实例 (https://www.openhab.org/addons/integrations/openhabcloud/)
> 还有一种基于容器的方法可以在其他发行版上运行,但这种安装方式不支持附加组件功能。
您可以在容器化版本中使用附加组件。这已在其他地方讨论过。
我曾经尝试过 HA,为了让各种传感器和控制器集成并可靠运行,我被 YAML 所束缚。这些年来,我又重试了几次 HA,但那时我已经习惯了 Node-RED,没有强烈的理由去改变它。我知道 HA 现在可以通过前端图形用户界面进行更多配置,这很好。
我刚刚将办公室的不间断电源与 Node-RED 库存仪表板集成,以记录状态、电源电压和电池充电状态,这只花了 5 分钟,包括通过图形用户界面为 Node-RED 安装 UPS NUT 插件的时间。
我喜欢可视化、基于模块的配置,以及添加可编程功能块来处理和修改数据的功能。
Node-RED 中唯一不太好的地方是仪表盘的外观和感觉,以及仪表盘设置工具。
我刚开始使用家庭助理时,觉得它太笨拙,几年后再用,又觉得它太臃肿。
虽然有很多志愿者参与其中,但它缺乏整体协调,也没有一个简单一致的使用模式。这就是开放源代码的弊端之一:厨师太多,就会导致平庸,但当每个人都心怀善意时,就会出现意外。
我不得不对我要添加的设备进行大量研究,以至于我更愿意自己开发网关和云。现在,我控制的代码基数大大缩小,可以轻松调试问题。
也许 HA 可以重构成一套较小的模块,从一开始就不需要大量的资产?
谢谢!请访问 Lars 的频道,了解有关带有远程传感器的家庭助理的一些有趣见解:https://www.youtube.com/@LarsKlintTech/search?query=home%20a…
家庭助理非常棒,我已经能够推动它做一些我没想到它能允许的事情。只需在容器中运行 Python,就能与网络和传感器任意交互。我用它为自己的家庭网络应用提供后台支持。
我相信,很多对该产品不满的人都抱有完全不正确的期望。
是否有任何地方可以编译具有本地控制功能的智能家居设备数据库?我试着简单搜索了一下,发现有智能设备数据库,但似乎都没有作为过滤器。
家庭助理文档至少记录了如何通过 “物联网类 ”进行集成
https://www.home-assistant.io/blog/2016/02/12/classifying-th…
例如 Tado:云轮询
https://www.home-assistant.io/integrations/tado/
感觉就像在家里打造我自己的智能贾维斯–有点棘手,但超级有趣!
有一个很好的主题,有人就是这么做的,不过是周五。
https://community.home-assistant.io/t/fridays-party-creating…
数据所有权让我想起了菲尔博士的早期商业交易:
1. 向易受骗的公众出售健身房的长期会员资格,并提供长期订阅服务。
2. 2. 将订阅服务卖给第三方。
3. 关闭健身房。订阅合同仍然有效。
https://www.celebitchy.com/8971/dr_phil_ran_a_health_club_sc…
愤世嫉俗很容易。家庭助理属于非营利组织。虽然这本身并不是无懈可击的,但它确实走了很长的路。
说到自动化的可靠性,“家庭助理 ”只是个玩具。不过这是个不错的玩具。
我会坚持使用我的 domoticz,因为 “如果它没坏……”。
我从未遇到过 HA 本身故障。我已经安装了 10 年,唯一真正的故障是硬件(服务器、物联网设备)或我自己的配置错误。
如果你明智地选择硬件,它的可靠性会令人难以置信。我家里的大部分设备都是自动化的,而我在过去一年中所做的只是增加了一些设备。
我承认,如果你略懂一二,低维护(或零维护)是比较容易实现的。
我使用 HA 长达十年之久,从未出现过任何问题。
你凭什么认为它是个玩具?
期待有一天,我们的家用电器也能没有板载 cpu,而只是局域网 wifi 固件设备。像 HA 这样的东西可以让它们变得随心所欲,用户想怎么智能就怎么智能,而无需让制造商对用户体验进行任何控制。
这就是字面上的 Zigbee。
有没有一种方法可以在不创建账户或不持续的情况下为 LWN 做出贡献?没有人使用加密货币吗?
看起来他们不接受捐款,听起来接受捐款要难得多。
https://lwn.net/Articles/828428/ https://lwn.net/Articles/1019619/
如果你不想订阅,可以等两周左右文章就可以免费阅读了
我只想支持。我想他们有预付费订阅,我可以每年支付 X 个月的费用,我觉得这样很公平。我读得不多,但也想出一份力。
本系列第一篇文章的链接:
https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/
我们将网址从 https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/ 改为 https://news.ycombinator.com/item?id=44014505,以避免两个部分的讨论分裂。
它们是两篇不同的文章,我认为这样做不对。
为了说明情况的困难性,我在这里张贴了对您另一份评论的回复:
https://news.ycombinator.com/item?id=44020047
我也担心隐私问题,尤其是家庭助理集成到供应商云端的 “拨号回家 ”功能。您的数据并不隐私。请查看我的项目:https://merliot.io。