LWN：Home Assistant，基于Python的IoT中心！

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

Home Assistant, the Python IoT Hub

By John Coggeshall
June 10, 2020
原文来自：https://lwn.net/Articles/822350/

IoT（物联网，Internet of Things）仍在迅猛发展，有数十万种互连设备已经进入消费者家中，小到灯泡，大到洗碗机都有。Home Assistant 是一个开源项目，希望能让绝大多数的设备都不需要跟第三方交换数据。

通常来说，IoT设备都需要互相配合才能发挥最大功效。虽然是可以把这些设备去中心化，但是能让这些设备全都协调配合起来成为一个智能家居（smart house）通常都需要一个中心服务器（或者称之为"smart hub"），Apple, Amazon, Google等公司都不会错过这个机会，他们都提供了相应的各种解决方案。

不过处于隐私和安全考虑，这些方案都是有问题的，因为他们会把私人信息发送给中心服务器做处理，哪怕只是想开个灯而已。这些方案都是闭源的黑盒，并不能解决人们的隐私担忧。Home Assistan 就是一个基于Apache协议的项目，希望能解决这个问题。它由Paulus Schoutsen创建，希望能提供一个私人的中心hub来协调管理家中各种IoT设备的通讯以及自动化功能。Schoutsen也是Nabu Casa, Inc.的创立者，这个公司会对此项目提供商业支持。这个平台非常流行，也很活跃，在GitHub上的 core 项目有接近2,000位贡献者，已经快要发布600个版本了，大家一起把Home Assistent同其他各种IoT平台集成起来，提供了1,600种components。

Meet Home Assistant

Home Assistant希望能成为一个用户友好的工具，近期的多个release里面着重投入资源来大大改进了易用性以及前端界面的功能。包括一些auto-discovery 自动检测许多IoT设备的功能，还有built-in configuration editors （内置的配置编辑器）, 还有一个界面编辑工具，名为Lovelace。Home Assistant的内核是基于Python 3代码写成的，经由各种YAML的配置文件来管理，这样人们可以使用自己喜欢的编辑器来进行修改。

从开发者的角度来看，Home Assistant的API和架构文档非常完善，提供了基于网页的管理界面来管理家庭设备，也有Android和iOS平台的移动应用程序可用。从架构上来说，它是一个事件驱动的平台，拥有状态机，其中各个实体Entity都是有系统统一管理的。其中的Entity都是"things"，也有各种形式。可以是真实的设备，比如某个灯泡，也可以是从互联网上获取的信息如一份天气预报，甚至是一个布尔变量来代表指定手机的MAC地址是否出现在了局域网中。

在Home Assistant中，各个部件（Components）都暴露出entity和相应的service。这里不要跟API web service混起来，Home Assistant service指的是每个部件自己能提供的功能、动作，这里可能都不一定有底层的API。这些部件也都是由Python写成的，它们是Home Assistant生态系统的核心。Component负责跟第三方的技术（比如智能灯泡提供商的API）集成起来，从而可以调用这些API来让设备能跟Home Assistant entity里的状态对应起来。Component也不局限于remote API或者设备，还有一些component会提供shell command的服务，或者支持一些独立运行的Python脚本，也包括跟本地PC之间的各种交互。

Component是由Home Assistant从Home Assistant项目中按需下载和安装的。如果没有现成的已经写好的component，那么可以用Python来为自己的需求写一个custom component 。

把entity和service绑定起来的就是automations，它是根据某个或某几个entity的状态变化而产生事件进行触发的。automation会接下来按顺序调用Home Assistant service提供的actions，从而完成例如打开灯泡这种任务的。同时也支持条件执行，比如说可以创建一个只在周末执行的automation。

Getting started

希望尝试Home Assistant的读者建议可以使用Raspberry Pi 4 Model B 来开始，可以下载到相应的SD卡映像文件。如果希望在自己已有的其他传统Linux设备上安装的话，可以利用Docker image 或者使用pip的安装步骤。

前面已经提到过，配置数据都是由YAML管理的。修改配置文件就可以使用附带的网页界面，也可以直接修改这个instance的 configuration.yaml 文件。还有一个单独的 secrets.yaml 存放了相应的认证信息等隐秘数据。由于所有配置都是各种YAML文件，这样就很容易加到Git仓库管理起来。

我们下面用ecobee component 来举例说明配置文件是如何生效的。这个component会把Ecobee thermostat的内部数据和API调用都集成到Home Assistant的entity和service里。首先在 configuration.yaml 里这样定义一下此模块:

ecobee:
    api_key !secret ecobee_api_key

其中 ecobee_api_key 是定义在 secrets.yaml 文件中的。添加 ecobee component并重启Home Assistant之后就会自动下载并安装相关的软件包，从而让这个component可以正常开始工作。

在打开这个component之后，可以创建一些sensor entity来从中获取指定的信息。比如说，下面的定义就代表了一个Ecobee控制的HVAC风扇：

sensor:
  - platform: template
    sensors:
      my_hvac_fan:
        value_template: "{{ states.climate.home.attributes.fan }}"

上面我们使用 template platform定义了一个新的sensor，就是说这个数据会来自一个template。Home Assistant 中的Platforms 会把配置属性和相关的行为分组来管理。对于 template platform来说，它会告诉 Home Assistant要从 value_template 中提取传感器的数据。

注意， value_template 使用了Jinja2 template engine，这样sensor就可以把sensor数据归一化之后采用相同逻辑处理了。在这个例子中，我们会从ecobee component提供的状态属性中提取数据。还可以有非常复杂的template，比如我自己Home Assistant中的一个例子在这里： https://github.com/ThisSmartHouse/sarah/blob/master/configuration/binary-sensors/tanks/freshwater/temperature-status.yaml 

在定义好之后，sensor数据就可以通过 sensors.my_hvac_fan 这个entity ID来获取了。也可以把entity生成到web界面或者移动app界面中去，数据变化也都可以保存下来并随着时间来图形化展示出来，同时也能用作automation中的触发条件。Home Assistant大多数情况下已经为enttiy数据生成了缺省的展示方案，当然也可以让大家深度定制。

automation提供了一些规则和动作来把各个entity关联起来。每个automation都有3个主要组成部分：trigger（就是自动化的触发条件），condition（预置条件），action（条件满足之后采取的动作）。

下面是一个典型的automation：

automation:
  - alias: 'Light on in the evening'
    trigger:
      - platform: sun
        event: sunset
        offset: '-01:00:00'
      - platform: state
        entity_id: person.john
        to: 'home'
    condition:
      - condition: time
        after: '16:00:00'
        before: '23:00:00'
    action:
      service: homeassistant.turn_on
      entity_id: group.living_room

在这个例子中我们使用了内置的 sun entity来触发我们的automation，就是在日出前1小时（这里会自动根据时区和位置信息来判断）的时候采取行动，同时也使用了一个 person entity（我自己）。在Home Assistant里面的person entity其实就是代表一组device tracker，用来确定此人是否在附近。比如一个person entity的位置可以根据他的一个设备连入局域网而判断出来，也可以通过手机上的app来获取，或者其他跟这个person相关的数据来源。

在这个例子中，automation是由两个状态信息触发的：日出时间减去1小时，并且这个person在家中。当两个条件都满足的时候，就会自动触发automation并检查condition是否满足，从而决定是否执行action。这个例子里的action就是 homeassistant.turn_on service，这里还有个位置entity group.livin_room 需要打开。automation本身也是entity，可以用在别的automation配置中进行互相交互，从而极大丰富各种组合关系。有一个很常见的技巧就是根据某个automation的action结果来决定是否打开或关闭另一个automation。

Privacy and security

使用Home Assistant有个关键优势就是可以确保智能家居中的隐私。它给用户提供了在使用商业方案之外的一个选择。虽然Home Assistant提供了实现smart home hub的framework，完全不依赖公有云的服务，但是其实许多IoT设备完全不支持使用其他方案来控制它。有些产品做得比其他人可能在这方面会好一些，因此在选购打算使用的设备的时候一定要留意这一方面。

还有一个很重要的因素是安全，毕竟没有security的话也就没有privacy。Home Assistant项目提供了许多建议来确保用户的Home Assistant环境是安全的，这些建议包括要尽量使用新版本来跟上security fix的节奏。因为Home Assistant本身是个web application（也就是跟mobile aplication通过HTTP进行API通讯），所以通常关于这类application的通用安全措施也都是需要的。远程访问Home Assistant需要能有权限访问到这个host machine。在使用mobile application的时候，Home Assistant必须要暴露出一个公网IP地址，或者使用secure tunnel，否则无法访问到。

Home Assistant花了许多精力来确保这个平台是安全的。Security fix是各个发布版本中的常客（当然也不算异常的多），项目本身也有公告来告知大家如何汇报新的security vulnerability。

Home Assistant并不是独自就能支撑起一个完整的smart home stack的。通常还需要有Message broker比如MQTT server，以及数据库服务程序。确保他们的安全性也是同样重要的。最近有报道说大概有50,000个MQTT服务器暴露在了公网上，这也说明在IoT部署中，次要服务配置不正确也是一个主要让人担心的因素。

Learning more

如果Home Assistant在你看来也是一个智能家居领域很有希望的解决方案，那有许多资源可以让你开始入门。首先它有一个庞大的用户社区可供学习，还在新功能开发商有非常敏捷的发布周期。用户文档也深受好评，可以作为一个主要的参考资料。熟悉Python的用户如果想参与进来，可以从developer portal 入手，这里的信息足够你学会写新的component。此外还有一个很热闹的 Discord chat room 可以上去聊聊。

Home Assistant还是一个非常活跃的项目，值得期待能成为open-source IoT领域的领先选手。不过它还是需要许多技术背景才能搭建起来的，至少目前如此。不过随着此项目在不断投入来改善用户体验，这一局面会很有希望能改变。对于那些出于隐私担心而不愿意在家中部署自动化服务的读者来说，值得看一下这个项目。还有那些希望能控制自己的smart hub底层技术的读者也建议看一下。

全文完

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

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

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