云控制与本地控制:家庭自动化该选哪个?

云可能更方便,但本地控制在您的 Home Assistant 生态系统中为您提供更多隐私和其他选项。
95 位读者喜欢这篇文章。
clouds in windows

Opensource.com。CC BY-SA 4.0

在投资家庭自动化生态系统时,有很多因素需要考虑。在本系列的第一篇文章中,我解释了 我为什么选择 Home Assistant,在本文中,我将解释家庭自动化中的一些基础性问题和技术,这些问题和技术可能会影响您如何处理和配置您的物联网 (IoT) 设备。

云连接

您今天可以购买的大多数设备都与某种类型的云服务绑定。虽然云带来了一定程度的便利,但也带来了一系列问题。首先,存在与公司访问您的个人习惯相关的隐私问题——您何时在家、您观看什么节目、您何时睡觉等等。尽管大多数人不像我那样关心这些问题,但隐私仍然应该是一个考虑因素,即使它只是一个小因素。

云访问还会产生依赖于您无法控制的事物的问题。2019 年,Sonos 因 远程使旧智能扬声器无法使用 而受到抨击。扬声器通常在保修期结束后仍能继续工作多年;事实上,它们通常会一直工作到物理损坏为止。还有一个 Automatic 的案例,该公司生产了一种基于云的汽车追踪器。当它在 2020 年 5 月宣布将 关闭 其服务时,它建议客户“请按照标准的电子产品回收程序丢弃您的适配器。”

依赖第三方提供商来提供关键功能可能会自食其果。IFTTT 是一项流行的服务,用于根据外部条件编程事件,它最近更改了其免费计划的 条款和条件,以严格限制您可以创建的事件数量——从无限数量减少到三个。即使 IFTTT 向设备制造商收取系统认证费用,这允许像 Meross 智能灯泡 这样的产品自豪地展示它们与 IFTTT 的兼容性。

其中一些决定纯粹是经济上的,但也有不少传闻案例表明,一家公司仅仅因为他们 不喜欢用户对他们的评价 就阻止某人访问他们购买的设备。这有多疯狂?

云连接的另一个考虑因素是设备的响应速度,如果其信号必须从您的家传输到云服务器(可能在地球的另一端),然后再返回到设备。这可能会导致任何操作延迟两秒(或更长时间)。对于某些人来说,这不是一个决定性因素。对于另一些人来说,这种延迟是无法忍受的。

最后,如果互联网中断会发生什么?虽然大多数现代家庭互联网连接都非常可靠,但它们确实会发生中断。一些大型、著名的云 服务提供商 今年都经历过中断。您是否愿意为了便利而冒着自动化系统崩溃并失去对智能设备控制一段时间的风险?

本地控制

您可以通过多种方式重新获得对智能设备的控制权。在商业上,您可以尝试像 Hubitat 这样的产品,这是一个强调本地控制的专有平台。我没有使用这些设备的经验,因为我不喜欢依赖中介。

在我的家中,我标准化了 WiFi(尽管我将来可能会扩展到 Zigbee)和 Home Assistant。使用 WiFi 意味着我需要根据设备与替代开源固件(例如 TasmotaESPHome)的兼容性来购买或制造我的设备。我承认,除非您从像 Shelly 这样的对社区非常友好的来源或像 CloudFree 这样的默认安装了 Tasmota 的来源购买设备,否则这些选项都不是“即插即用友好型”的。

(顺便提一句,我既刷过自己的设备,也从 CloudFree 购买过设备。DIY 方法有一些节省,但我为我父亲的房子购买了预刷设备的,因为这消除了很多麻烦。)

我不会详细介绍替代固件、如何刷固件等等。我只是想向您介绍一下存在本地控制选项的想法。

使用 MQTT 实现本地控制

本地控制设备可能使用直接的 API 调用(其中 Home Assistant 直接与设备对话)或消息队列遥测传输(MQTT)。

MQTT 是最广泛使用的本地 IoT 通信协议之一。我将分享一些基础知识,但如果您想了解更多信息,Hook Up 有一个 深入的视频 可以观看,HiveMQ 有一个关于 MQTT 基本原理的 完整系列

MQTT 使用三个组件进行通信。第一个组件是发送者,它是触发操作的组件。第二个组件是 代理,它有点像公告板,消息发布在上面。最后一个组件是设备,它将执行操作。此过程称为发布-订阅模型。

假设您在墙上有一个按钮,您想用它来打开投影仪、放下百叶窗并打开风扇。按钮(发送者)将消息 ON 发布到代理的特定部分,称为主题。主题可能是 /livingroom/POWER 之类的东西。风扇、投影仪和百叶窗订阅 此主题。当消息 ON 发布到该主题时,所有设备都会激活各自的功能,打开投影仪、放下百叶窗并启动风扇。

与留言板不同,消息具有不同的服务质量 (QoS) 状态。HiveMQ 网站对 三个 QoS 级别 进行了很好的解释。简而言之

  • QoS 0: 消息以“即发即弃”的方式发送到代理。不尝试验证代理是否收到消息。

MQTTT QoS 0

(© 2015 HiveMQ,经许可重用)

  • QoS 1:消息发布后,代理会在收到消息后回复一次。可以在代理回复之前发送多条消息。例如,如果您尝试提高投影仪的亮度,则在代理告知发送者停止发布消息之前,可能会无意中调整多个亮度条。

MQTTT QoS 1

© 2015 HiveMQ,经许可重用

  • QoS 2: 这是最慢但最安全的级别。它保证消息只被接收一次。与 TCP 类似,如果消息丢失,发送者将重新发送消息。

MQTTT QoS 2

(© 2015 HiveMQ,经许可重用)

此外,MQTT 还有一个 retain 标志,可以在消息上启用,但默认情况下未设置。回到公告板类比,这就像有人在公告板上发布消息,但另一个人走到公告板前,取下消息,阅读它,然后扔掉。如果第三个人五分钟后查看公告板,他们将不知道该消息。但是,如果 retain 标志设置为 true,则就像将消息钉在板上,直到收到新消息为止。这意味着无论人们何时来阅读消息,他们都将知道最新的消息。

在家庭自动化术语中,是否设置 retain 标志完全取决于用例。

在本系列中,我将使用 Home Assistant 的 Mosquitto MQTT 代理 插件。我的大多数设备都使用 MQTT;但是,我确实有几个非关键的 Tuya 设备需要云帐户。将来我可能会用本地可控的设备替换它们。

总结

Home Assistant 是一款大型、出色的软件。它在某些领域很复杂,当您需要对设置进行故障排除和协调时,熟悉这些基本技术将对您有所帮助。

在下一篇文章中,我将讨论您可能在智能设备中遇到的“三大”无线协议:Zigbee、Z-Wave 和 WiFi。别担心——我几乎完成了底层理论,很快我将开始安装 Home Assistant。

接下来阅读什么
User profile image.
Steve 是一位敬业的 IT 专业人士和 Linux 倡导者。在加入红帽之前,他曾在金融、汽车和电影行业工作多年。Steve 目前在红帽的解决方案和技术实践部门担任架构师。他拥有从 RHCA(DevOps 领域)到 Ansible,再到容器化应用程序等各种认证。

2 条评论

哦,我可以就此滔滔不绝。

我的旧房子 100% 基于 HomeKit,我有很多遗憾。我的家人也是如此,他们不得不与非常原始的家庭自动化系统共处一室。自动化有很多细微之处是想要的,但在这种非常简陋的家庭自动化平台上是不可用的。

今年早些时候,我们都搬到了更大的房子。我一开始就决定投入额外的工作来构建更复杂、更本地化的控制系统。我最终选择了基于 Home Assistant 的系统。

有一些 WiFi 配件,但主要是用于与 MQTT 通信。还有一些 Z-Wave 和一些 Zigbee。我不确定您是否可以只选择其中一个选项就能取得很大进展。例如,虽然 Zigbee 有大量的廉价且优质的温湿度传感器,以及智能灯泡和开关……但如果您想要嵌入式门传感器,您可能只能选择 Z-wave。在许多其他利基领域也是如此。

事实证明,Home Assistant 非常有能力为我提供我一直想要的复杂、细致的自动化。但这确实需要付出代价。学习曲线很高。而且架构仍然……过时。单体式。情况正在好转。正在推动将 Z-wave 集成原生迁移到 MQTT 中,这将有所帮助。但就像每次进行配置更改一样,您都必须重新启动它。许多有用的配置更改仍然迫使您编辑 yaml 文件并处理其中非常固执己见的空格。

我认为在这个项目和周围的社区中,有很多空间可以创建 HA 与其集成之间更松散的耦合(MQTT 模型就是一个很好的例子)。在不“简化”HA 功能的情况下,有很多空间可以简化用户体验。试用一下,看看您的想法,但要为一定的学习曲线做好准备!

多么深思熟虑的回复。我想因为我没有任何先前的知识,所以我没有觉得学习曲线太陡峭。尤其是在我采用 NodeRED 之后。

我只是最近才获得了一个 Zigbee Home(一个刷了 Tasmota 的 Sonoff ZB Hub),所以我使用的 98% 的东西仍然是基于 WiFi 的,这对我们来说效果很好。我们在 19:00-21:00 的高峰时段遇到了一些 WiFi 干扰问题,因为我们住在公寓楼里。总的来说,我喜欢 HA 的发展方向

回复 ,作者:magnus919

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.