几张散图

世事难料。好久不来抱怨,随发两张图吧。

Great Blue Heron in Skagit River
Juvenile Bald Eagle
Franklin Falls
Advertisements
几张散图

搭建一个家庭自动化系统

有了一堆 sensor 和 smart things 之后其实最重要的是它们之间的信息融合,这意味着某个品牌的设备感知到的东西可以触发另一个品牌设备的某些功能,而这里需要有一个系统能够连接到足够多的设备上,并且让他们之间的信息流通起来。往往这些设备提供商会有一些匹配的 app 供大家使用,但是仅仅对自家的设备有效。

很自然,我们需要一个 hub 来完成这个联系。这大概就是为什么会有 Google Home 和 Amazon Alexa,似乎一切都可以交给他们,对多数人来说的确如此。但比较作的人知道,这些信息很显然不仅仅被 A 或者 G 知晓,也被他们用作其他的方面,比如时不时有人提出的 privacy violation 指控。而每个设备提供商本身也可能收集一些用户的数据被不为人知的使用。

Home Assistant 提供了一 hub 层面上的 open source 实现,而使用与其兼容的 firmware 来操纵设备,可以进一步避免自己的隐私数据被不必要的使用。在搭建一个家庭自动化系统的过程中,我们也会更多的了解各个技术实现的细节。不过力推 HA 这套系统的人往往会忽视 HA 系统存在的一些弊病:

  • 配置过程多样化,并不是所有的路径都可以正常工作,每种选择可能或多或少的存在一些优缺点,而这些取舍对于新手来说非常的 overwhelming,通常缺少一些比较 high-level 的比较帮助大家选择
  • 即便是有一定的 engineering background 的用户,在各种不同的实现路线上能走多远也存在一些困难,尽管很多问题可以 google 到答案,但是折腾一圈下来耗费的精力并不是 0,如果对于时间宝贵的人的话,应该是划不来的
  • 与商用系统的整合困难:通常每家智能设备的厂商与比较大的 hub 之间是有一些成熟的解决方案的,并且由于购买了他家设备已经“纳税”,因此整合费用(比如使用大厂家 API 需要的费用)就已经包含在产品的价格里了,而脱离这套系统意味着个人可能需要担负额外的整合费用,一个最简单的事情就是如果希望加入语音控制,不少产品标明的支持 Google Assistant 或者 Amazon Alexa 本质上都会存在一个远程的 server 与这些产品交互,比如之前看到的 plex 的 phlex 版,通常它们提供了一个 text 交互界面,而 text 的来源是这些语音助手,因此通常大厂的 API 需要一些手段(比如付费调用)限制这些访问。

当然我并不是说开源的解决方案一无是处,除了洁癖爱好者的种种 argument,我能想到的一些论据大概包括:

  • 小厂的设备便宜,但是我们并不知道他们什么时候会倒闭,而他们的倒闭其实意味着和其他产品的整合部分就会被完全抛弃(不继续付费 API 调用),软件支持也会被抛弃,这时唯一能够支持这些硬件提供一定的服务的只有开源社区,毕竟你甚至可以贡献自己的代码保证自己的设备还能运转
  • 相较于大厂对某些整合奇怪的 priority,开源社区提供某些整合还是比较有利于“小众需求”的,一个例子大约就是 caldav 的整合,G 家有自己的 calendar 产品,所以它不大理会其他用户要求 caldav 支持的需求,而比如不少 synology 产品用户可以方便架设自己的 caldav 服务

下面是一个 HA 的搭建方案,仅供参考:

  • 由于我已经购买了 Synology NAS 提供存储,所以我并不希望通过 Raspberry Pi 来提供相应的服务,而 Synology 本身的 package 是没有 HA 的支持的,因此我们求助于上面的 docker 实现来获得 HA 等相关的程序
  • 比较流行的 HA 安装是使用 HassIO,这个可以从更高的一个 level 上来管理相关的组件,因为选用了 docker 反而并不是很容易解决这个事情,那么手工就手工吧
  • 不少开源的固件选择支持 mqtt 协议,这就是一个 pubsub 协议,通过它可以减少设备之间的 coupling,因为每个设备可以通过 mqtt 广播自己的状态,形成自己的 feed stream,而同时也监听着一些 feed 来调整自己的状态。常见的实现有 mosquitto,HA 自己也内置了一个版本
  • 首先配置一个基于 docker 的 mosquitto:可以使用官方的 docker image:eclipse-mosquitto:latest,一般来说会使用 1883/9001 两个端口,这里懒得一次搞太多,比如口令什么的,简单的把 /mosquitto/data 和 /mosquitto/config/mosquitto.conf 映射出来就行
  • 然后配置一下 HA,这里也是使用的官方镜像,把 /config 映射进去就行,提供 8123 作为 web interface,最主要的大约是修改对应 configuration.yaml 文件,下面是一个简单例子
    mqtt:
      discovery: true
      broker: my-broker-ip
      port: 1883
      client_id: home-assistant
      protocol: 3.1
    
    switch:
      - platform: mqtt
        name: 'Dinning Room Speaker Switch'
        command_topic: 'cmnd/dinning_room_speaker_switch/power'
        state_topic: 'stat/dinning_room_speaker_switch/POWER'
        value_template: '{{ value_json.POWER }}'
        qos: 1
        payload_on: 'ON'
        payload_off: 'OFF'
        retain: true
    
  • 配置设备的 mqtt 端点,这主要是让每个设备连接到 mqtt broker 上(及 mosquitto),在 mqtt 上有个不同的 topic 以示区别

有了这些以后,基本的 HA 访问是通过 web 来解决的,在移动设备上也是如此,估计开源社区不乐意为在 app store 里面弄个 app 还要交钱吧。但是 iOS 上确实有个“伪 app”。

未完待续:

  • 配置访问权限
  • 整合 plex
  • 整合 G/A 的语音?或者别的实现
  • Yeti
搭建一个家庭自动化系统