现成的消费级家庭自动化已陷入一种相当标准的模式。您有一个智能设备（如灯泡或门锁），它与您网络上的某种集线器通信。它与设备 供应商拥有的云服务通信，您通过移动应用程序与该服务交互。这提供了简单易用的开箱即用体验，并允许供应商在云端和移动端迭代其服务；然而，这种模式有很多缺点，并且对其功能有极大的限制。
opensource.com
这种模式依赖于云来处理其部分逻辑，而您无需为云的维护付费，这意味着其经济性完全基于销售更多设备来维持这个云。这也意味着互联网中断现在会降低您的家庭功能。如果从您家到该云服务的任何路径中断，您可能会失去家中的功能。此外，您还从整个互联网接收入站命令，这些命令决定了您家的功能方式。虽然安全地执行此操作是可能的，但它会增加风险。当做得不好时，您最终会遇到像 Mirai 僵尸网络 这样的问题，该僵尸网络在去年秋天破坏了美国大部分互联网。
这种模式还依赖于移动应用程序，这意味着您对产品的选择 可能受您的移动设备选择的支配。您可以构建的自动化类型由供应商以及他们在移动应用程序中公开的内容决定。在不同平台之间进行任何真正的集成是不太可能的。例如，如果打开门触发灯打开会很好，但很可能您的联网门和联网灯 处于完全不同的生态系统中。
为什么不能实现无缝连接？
我们采用这种模式的主要原因之一是最后一英里网络和设备发现是分散的。这有实际原因。起初，我们认为无处不在的 Wi-Fi 可能是一个好主意，但 Wi-Fi 在拥挤的环境中非常糟糕。此外，安全的 Wi-Fi 假设有人能够将 Wi-Fi 密码输入到连接到网络的每个设备中。这对于手机或笔记本电脑来说效果很好，但对于灯泡来说效果很差。使之成为可能的各种解决方法包括让灯泡运行您可以连接到的 Wi-Fi 接入点。与其他技术选择相比，Wi-Fi 也非常耗电，因此不适合在 AA 电池上运行的传感器。此外，大多数家庭路由器配置为不超过 250 个设备，这在推出联网设备时成为一个真正的考虑因素。
opensource.com
替代方案包括 X10 RF、Zigbee、Z-Wave 甚至蓝牙。所有这些方案在安全性、可发现性、范围、功耗和网络方面都有不同的权衡。几乎所有都比 Wi-Fi 更好。有些会开箱即用地进行网状网络。有些具有消息的活动确认，这对于在其之上构建自动化系统非常重要。为了使所有这些东西都可供消费者使用，您需要一些将它们桥接回家庭网络的东西，因此您必须有一个集线器。
在这一点上，供应商的选择是将所有逻辑写入集线器，并希望消费者定期升级他们的集线器——但他们不会——或者将尽可能多的逻辑保留在异地，以便供应商可以继续迭代和改进平台。从供应商的角度来看，这一切都很有道理。但这极大地限制了 您可以使用这些设备做什么，坦率地说，这使得它们不太有吸引力。
引入 Home Assistant
这就是 Home Assistant 发挥作用的地方。Home Assistant 是一个开源家庭自动化中心，可以 安装在各种设备上——从完整的 Linux 系统到一些网络附加存储 (NAS) 环境，甚至 Raspberry Pi。该项目在早期做出了很好的决策，例如使用 Python 编写，这使得数百人可以轻松地为该平台添加设备支持。UI 基于 Polymer，即实现 Web Components 标准的 Google 库，因此它开箱即用，看起来干净且有吸引力。内部状态和事件模型清晰，这使得不同组件之间的自动化交互变得容易。
Home Assistant Polymer UI。请注意，Hue 灯泡图标与灯泡当前的颜色相匹配。
开箱即用，您可以获得与 700 多个不同组件的集成，范围从 Hue、Nest 和 Sonos 等极其流行的平台，到您以前从未听说过的众多平台。该项目尽可能尝试自动发现您网络上的设备并使用 UPnP 和其他发现协议集成它们。
我对该项目的第一个贡献是 Proliphix 恒温器的连接器。Proliphix 制造工业和商业联网 HVAC 系统，10 年前，它尝试通过以太网连接的家用恒温器进入消费领域，当时我购买了它。该公司多年前停止生产该产品，但它具有本地 Web 服务 API，因此该设备继续运行良好。大约用 100 行代码，我能够为其编写一个 Home Assistant 插件并将其贡献给上游，在那里它很快被接受。当时，这是一个 相当旧的平台，并且我可能是唯一的用户这一事实并不重要，因为 Home Assistant 项目希望与任何平台合作，无论多么晦涩难懂。那次贡献以及社区的友好性让我着迷，从那时起我就一直是开发社区的成员。
Home Assistant 中的自动化
要了解您可能在 Home Assistant 中拥有的 自动化 类型，请考虑以下情况。我有一个带纱窗的门廊，我们一年中有六个月将其用作餐厅。我在天花板上安装了 Hue 灯泡，有一个 Aeotec Z-Wave MultiSensor 6，并将我的 AV 接收器的区域 2 用于外面的户外扬声器。我希望灯在晚上有人进入门廊时打开，而不是在白天打开，因为那将是毫无意义的能源浪费。我也经常忘记关掉音响，所以我真的希望，当外面没有人时，区域 2 会关闭，以示对我们邻居的礼貌。
scene:
- name: Porch Lights On
entities:
script.porch_on:
state: on
switch.deck_lights_48:
state: on
- name: Porch Lights Off
entities:
light.porch_fan_1:
state: off
light.porch_fan_2:
state: off
light.porch_3:
state: off
light.porch_4:
state: off
switch.deck_lights_48:
state: off
media_player.living_room_stereo_zone_2:
state: off
script:
porch_on:
alias: "Turn On Porch Lights"
sequence:
- service: light.hue_activate_scene
data:
group_name: "Porch"
scene_name: "Porch Orange"
automation:
- alias: Turn on porch lights after dark
trigger:
platform: sun
event: sunset
offset: "-1:00:00"
condition:
condition: and
conditions:
- condition: state
entity_id: light.porch_fan_1
state: "off"
- condition: state
entity_id: binary_sensor.porch_ms6_1_129
state: "on"
action:
service: scene.turn_on
entity_id: scene.porch_lights_on
- alias: Turn on porch lights on motion
trigger:
platform: state
entity_id: binary_sensor.porch_ms6_1_129
to: "on"
condition:
condition: and
conditions:
- condition: state
entity_id: light.porch_fan_1
state: "off"
- condition: sun
after: sunset
after_offset: "-1:00:00"
action:
service: scene.turn_on
entity_id: scene.porch_lights_on
- alias: Turn off porch
trigger:
platform: state
entity_id: binary_sensor.porch_ms6_1_129
to: "off"
action:
service: scene.turn_on
entity_id: scene.porch_lights_off这种情况的复杂性肯定会稍微影响 YAML 模型，但请耐心等待，因为这个复杂的示例展示了很多东西。
自动化由事件触发，但在我的情况下，我有两个潜在的触发器：运动传感器被触发，以及时间足够晚可以打开灯。因此，我需要寻找任一事件，并检查另一个事件是否处于预期状态。我还必须检查灯当前是否熄灭，这样如果我手动打开它们，此自动化不会随机更改它们的颜色或亮度。
自动化调用一个场景，该场景打开甲板灯 （由 Z-Wave 开关控制），并调用一个脚本，该脚本使用嵌入在 Hue 控制器中的场景名称来打开灯。同一个 Hue 场景暴露给我的 Hue 的轻触开关和移动应用程序，因此 Home Assistant 在任何情况下都像轻触该场景一样。在关闭自动化规则中，您可以看到灯、开关和接收器的关闭。
请注意，此自动化集成了由五家不同制造商制造的设备——Philips Hue 灯泡/集线器、Z-Wave 集线器、Z-Wave 开关、Z-Wave 传感器和音频接收器——并通过三个不同的网络——Zigbee、Z-Wave 和以太网——进行通信，以获得一致的感觉。这一切都以我可以提交到 Git 存储库的格式完成，这样当我进行更改时，如果它破坏了我的房子，我可以轻松地恢复（这非常关键，因为家庭自动化错误是一些最难调试和诊断的事情）。
生态系统
Home Assistant 社区充满活力并且不断发展壮大。该项目每两周发布一个版本，并继续吸引贡献者。复杂自动化场景（如上面的场景）的一些挑战正在通过 App Daemon 等生态系统项目来解决，它允许您用 Python 编写自动化代码。由于 Home Assistant 守护程序将整个事件和状态结构作为 Web 服务公开，因此构建这些类型的自定义插件甚至您自己的环境专用 UI 非常容易。
如果您正在考虑涉足家庭自动化领域，请务必查看 Home Assistant 项目。将开源置于家庭自动化的核心将使您能够按照自己的节奏构建它，随着时间的推移进行调整，并确保您控制关键资源，例如您自己的家。
本文基于 Sean 在 OpenWest 的演讲，为什么我们不能拥有美好的物联网：家庭自动化入门。OpenWest 将于 2017 年 7 月 12 日至 15 日在犹他州盐湖城举行。
1 条评论