云控制 vs 本地控制:家庭自动化该如何选择

云端可能更方便,但本地控制在 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;但是,我确实有几个非关键的涂鸦设备需要云帐户。将来我可能会用本地可控的设备替换它们。

总结

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 模型就是一个很好的例子)。有很多空间可以简化 UX,而不会“降低”HA 的功能。试用一下,看看您怎么想,但要为一点学习曲线做好准备!

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

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

回复 ,作者 magnus919

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.