【新手必读】入门->精通：HA安装方式、基本概念及来龙去脉

XCray

从论坛发帖来看，很多新手稀里糊涂。很多所谓的教程贴甚至某些以HA为主题的网站，其内容早就陈旧不堪，很多新手受这些文章毒害颇深，以至于刚一上手就义无反顾地跳进自己根本不知道的大坑。

本着人道主义精神，花点时间整理了本贴。如果你不那么玻璃心、愿意承认自己是新手，建议仔细阅读。

0. HA介绍
来到本论坛，说明你已经对HA至少有所了解了。所以这一段就不写了，对了，HA是 home assistant 的缩写，经常也被写成ha，这里不分大小写。另外HASS、Hass、hass也经常被用作简称。

1. 看文档&安装
上手第一件事，必须先学会看文档！首选必须是官方文档：home-assistant.io，英语没学好的还可以趁机加强一下。

文档第一篇干货，就是安装方法：Installation - Home Assistant (home-assistant.io)，看文档的同时，就可以结合自己的硬件环境一边看一边动手安装了。

目前官方支持的安装方式有4种，按照逻辑上的递进顺序和功能由少到多，分别是 Core（核心）、Container（容器）、Supervised（监管的，不知道那个汉语词更妥帖）、OS（操作系统）。但从安装和维护难易程度上排序，最简单的是OS和Container，这也是官方推荐的两种方式；更难一些同时功能最简单的，是Core；最难的最不推荐的，是Supervised（老鸟随意）。

现在这4种方式的名称基本已固定下来，在发展过程中曾有过很多变化，这也是很多文章陈旧以致于产生误导作用的一个原因。

4种方式的简要介绍如下：

20220702：补充个图，可以看的更明白：

紫红色、整个的就是OS；黄色圈内的那部分就是supervised。

1.1 Core（核心）。核心这个词一度被赋予极其特殊的含义，在这里大家简单理解字面含义即可。简单地说，Core 就是 Home Assistant 本身，是一个用 Python 开发的项目，完成最基本最重要的智能家居的功能：
- Automations，自动化（小米的米家app里原来也叫过自动化，还叫过莫名其妙的“智能”，后来改成了明显错误的“场景”），这是智能家居的灵魂。HA的自动化非常非常强大！与之相比，小米搞的简直就是垃圾一样的存在，其他厂商搞的就更别提了。
- Lovelace，色鬼？到底是什么鬼？就把它当成HA的前端界面就行了，或者说其中的一种，通过浏览器或手机客户端访问HA所看到的，就像人的外貌。
- Intergrations，集成。把各种智能家居和服务接入到HA这个平台的方法和代码的专有名称。这是Core的核心。每个集成的代码，都是HA的一个“组件 Component”——注意这个词汇！
    在最新的2021.10版本中，官方已经内置了1856个集成——是的，1856个！
    虽然已经这么多，但总还有些智能硬件不能直接被HA使用，怎么办？
    于是很多懂开发的高手就自己开发组件，这种非官方的组件就被称作“Custom Component 定制组件”（相对于官方已经集成好了的组件）。很多优秀的定制组件慢慢被纳入了HA官方组件里，这也是HA不断发展强大的一个原因。
    Custom Component 这个词，有时也会被人不严谨地叫作“插件”，其实与“插件”更接近的英文单词应该是“plug-in”。由于很多人的不严谨，插件这个词被严重滥用了，产生了很多误导误解。
    HACS，就是一个非官方的定制组件商店（还有一些前端的东西）。其实所有的定制组件都可以不通过这个商店就可以安装。所以这个商店并不是那么必要的，我就一直没用过。
   补充：15楼朋友说的不错，官方文档里，integration 一词就是原来的 component 改过来的，在ha的世界，基本上这俩词是一个意思。

- Blueprints，蓝图。为了降低自动化编写难度而生造的一个失败的功能，用途是别人把自动化设计思路以蓝图的形式发表出来、你拿它直接套用。但这个功能很失败，连鸡肋都比不上。反正我是就当这个功能不存在。

既然是用 Python 开发的项目，那么安装运行就需要先有 python 环境。
初期的做法是在有python的系统里直接安装core：
  为了避免对系统造成其它影响，强烈推荐采用 python 虚拟环境部署——如果 python 没学好的话赶紧去学。另外我刚才说过，这种安装方式对新手来说难度很大，仅次于最难的 Supervised，但功能又是最少的。所以真心不建议新手用这种方式安装。
后来有了容器的思路，把core做成容器、在docker上跑，就是container这种安装方式。

HA Core 诞生于2013年9月17日，现在的版本号采用“年+月+小版本”的形式，每个月大概会出6个左右的小版本（正式版本），一般每个月的大版本都会增加一些新的功能或集成或较大的改动，上旬更新会比较频繁、中旬基本达到稳定状态（小版本到5~6左右），下旬一般就不发布小版本了，开发大神们应该都去忙下个月的新的大版本了。

所以很多不愿意频繁更新的老鸟会选择在每个月的20号前后更新。

这里顺便说一句：建议每个月都至少升级一版、别掉队，顺便好好看看 Release Notes。因为每个月的大版本都会有较大变化，如果几个月不升级的话，很可能你乍一升级然后就启动失败，自己都不知道发生了什么。

1.2 Container（容器）
Docker 是一项非常了不起的技术，给软件部署带来了革命性的变化（不明白的赶紧去找些 Docker 基础教程看看）。HA 大概从2016年5月1日的0.14.2版本开始同步发布 Docker 镜像。

从我个人的角度，这是最佳安装方式——虽然和 Core 方式相比没有增加什么功能只是部署方式的变化，但升级和维护得到了极大地简化，灵活性足够、资源占用也达到了最优（几乎）。

1.3 Supervised（监管的）
先强调一下：没人监管你！这个监管指的是对 HA 相关 docker 容器的监管，这些容器除了最基础的几个之外，都有一个正式的名称：Add-on，官方现在翻译成“加载项”。而最基础的那几个，除了 Core 和Supervisor 之外，包括observer、dns、audio、cli、multicast 等，都被称作 plugin 插件——这才是官方话语里面“插件：的准确含义！
只不过这些插件都会随着 Supervised 或 OS 安装方式天然就有了，基本不需要使用者关注。

逻辑上讲，这种方式是在上一种的基础上，增加了几个辅助性的容器（这几个容器被叫做 plugin！）并统一加以监管，包括网络设置、安装、升级、备份、恢复、启动、状态监视等等。
完成监管功能的，是一个叫做 Supervisor 的容器。
老鸟们都很喜欢的 ESPHome、Node-Red 等等，也都以 Docker 容器的方式（Add-ons）被安装到系统里、接受 Supervisor 的统一监管。

很多半新不新的新手，对这种安装方式的最大感受，就是有一个 Add-ons Store，加载项商店，很多不严谨的人把它也叫做“插件商店”或“插件市场”，与前面说的 HACS 混为一谈。

HA 官方开发维护着二十几个 Add-ons，社区和自由开发者们也开发了大量的各种 Add-ons，有些还是非常实用非常优秀的。
Add-on 这个词，很多人也很不严谨的把它翻译成“插件”，甚至自己都没搞清楚的情况下，与前面所说的“Custom Component”混为一谈！
不过我也觉得比起“Custom Component”来说，“插件”用于指代“Add-on”更恰当一些。但是已经被用滥了（官方又赋予了明确含义），所以官方使用了“加载项”作为 Add-on 的中文翻译，也比较恰当，别的是不是还有哪个词更合适我也不知道。

所以看到插件这个词的时候，一定要记得再看看到底是哪个，是 python 语言写的定制组件？还是以 docker 容器/镜像形式存在的 Add-on（加载项）？

这里还涉及到历史上曾经存在过的几个叫法（没办法，官方也多次改来改去的）：HassIO、Hass.IO、Hass.io、Hassio、hassio，这些都是 Supervisor 的曾用名（也叫过 Hass.io supervisor）。这几种写法在不少不严谨的文章里也指代 Supervised 这种安装方式。

这种安装方式是最难的，要求使用者拥有雄厚的 Linux、网络、协议、Docker 等知识和技能，新手除了有自虐倾向，千万别尝试。不客气地说，国内很多推荐新手用这种安装方式的文章，非蠢即坏。明明自己没那个技术基础，上来就要折腾这种玩法的人，除了蠢就是笨，外加跟自己过不去！

补充：群晖DSM 6.x的时候有个大神做了一个套件（群晖用语），用于安装这个，我曾经用过几个月，后来作者本人也放弃了。


另外，其实我个人也觉得这种方式比较鸡肋：多了好几个容器，而且还都没啥大用或者很难用；想用哪个 Add-on，完全可以自己在 docker 里手动部署。

可能也就是一种场景适用这种方式：有一个现成的 Linux 系统，有其他不可少的用途，但又想在上面部署 HA 且还实在想用 Supervised 的其他可有可无的功能。

由于这种安装方式太不利于管控（使用者的安装环境千差万别），官方曾一度想废弃，后来讨论的结果是维持，但仅限于支持当前版本的 debian 这一种环境。其他环境，只能使用者自己折腾，官方一概不支持。

1.4 OS（操作系统）
鉴于上面那种部署方式很容易引起的混乱，官方从大约2018年4月18日开始，干脆自己在 Supervised 基础上集成了操作系统，制作成系统镜像文件（与 docker 镜像不可混淆），这个镜像是一个包含所有功能的大包、逐渐适配了常见的各种硬件，使用者直接下载使用即可。

这种安装方式的名称也有过变化，最初叫“Hass.io-OS”，后来改成了“HassOS”（我也觉得这个名称最恰当）。官方文档中，还曾经管这个操作系统综合体叫过“Home Assistant”——纯属官方制造混乱啊！

顺便说一下这个论坛的域名：hassbian，其实也是官方曾经用过的一个专有名词，特指供树莓派使用的 HassOS（和现在的概念不太一致）。熟悉树莓派的同学对这个拼写应该有很自然的亲切感。不过早在2019年10月，官方就废弃了这个叫法，所以不了解也无所谓。

从安装难度上来说，这个是最简单的、最适合新手的。坏处就是你的树莓派或主机（或虚拟机）就变成专用的了。

我自己在树莓派和群晖虚拟机中使用过较长时间，后来觉得没啥太大的必要，改成了1.2 Docker那种安装方式（我自己认为是最好的方式，尤其是在群晖上）。

2. 全球参考
根据官方最新统计，全球HA的使用者中，2/3用的是 OS 这种方式：

而硬件平台方面，最多的是树莓派4（超过1/3)，其次是虚拟机（接近1/3）。
总的来说，所有使用树莓派的占到了58.5%：

XCray

除了开发者们撸代码搞测试之外，绝大多数使用者应该是在这个环节花的时间最多。
安装完成后，接下来需要做的事情有：
1. 把各种设备和服务接入HA，利用的就是HA自带的各种集成（intergration）和非官方的各种定制组件（custome component），如果两个都没有现成的，要么等，要么自己写。
  设备容易理解，服务可能很多新手都犯迷糊——其实更简单，就是网上提供的各种数据服务，比如天气预报、电力公司的用电数据、股票信息之类的。

  每个集成的使用，最佳参考资料就是官方文档！
  Integrations - Home Assistant (home-assistant.io)
  不但更新及时，文字也非常准确、全面，甚至可能碰到的问题也都有成熟的答案。

  定制组件，最好的是作者的文档和帖子，其次才是网友们写的各种教程文章帖子之类的。

  另外，非常推荐大家（包括新手和半新手）仔细阅读这篇文章：Classifying the Internet of Things - Home Assistant (home-assistant.io)，对于提高理解、建立正确的逻辑思维能力非常有帮助。
  这篇文章的主要内容是把HA所有的集成分为5类（其实不仅仅适用于HA，所有的物联网组件都可以这么划分）：

  值得一提的是，有些定制组件明明针对的是本地的设备，也采用云端推送甚至云端轮询的方式，时延有时就难以接受了。

  这张表其实很重要，很多自以为是的“老手”都在这方面打过脸。

  虽然我说本地推送最好，其他几种也不是不该存在，也都有其适用的设备或场景，当然，有时候是不得已的做法。

2. 安装手机客户端。推荐iOS版本的官方app。除了刚开始需要梯子获取推送ID之外，其他时间都不需要梯子了。安卓的按说功能更强大（app可以获取更多的数据和权限），但据说因为国内特殊的环境很不好用（我没用过不知道细节）。

  手机客户端除了基本的查看、操作、配置等功能之外，还可以采集手机上的一些传感器数据，另外还有一个非常有价值的功能：可响应通知（可以参考我另一个帖子：稀奇玩法：HA问手机、手机回复文字，然后HA朗读手机的回复—在家在外都可以）。

3. 接下来最重要的就是远程访问了，就是你出门在外时也可以用手机连接家里的HA，查看和控制各种设备状态。

  这个依赖于具体安装环境和网络条件，比较简便可靠的就是ipv6，已经有很多帖子了，不明白的找来看就是了。

4. 自动化——物联网的灵魂，智能家居也是物联网的一个应用，自动化的重要程度同样怎么强调都不过分。

  配合强大的“模板 Templating”，HA的自动化几乎可以实现你的任何想法，没有做不到、只有想不到。只要你逻辑上想得明白，就可以用HA实现。（什么？非要HA给你变个美女出来？吃药了吗？）

5. 各种优化、美化和微调

  美化主要指的是前端，这方面我几乎从没有折腾过，顶多就是自带的仪表板（Dashboard）简单的调整调整。有很多这方面的工具和帖子，感兴趣的自己找吧。

XCray

注意！
有些老手可能是习惯问题吧，现在发帖可能还在使用已经不用、含义已经变化了的名称，闹不好就会导致误解。

翻了翻官方github，简单整理一下：

Core，全名 Home Assistant Core，曾用名小名：hass、ha、home assistant。
   最初版本0.0，2013.9.17诞生；2014.4.14正式发布时的版本号 0.7，之后（直到2020年12月份），版本号一直在小数点后面累加（注意，0.10是0.7的弟弟，0.100是0.99的弟弟），给人以一种一直不是正式版的感觉——官方也曾经在0.99之后发文说终于要出正式版了，当时很多人以为后面会按照1.xxx的形式，不料辣帮大神太谦虚，于是继续在小数点后折腾——0.100.x，一直到0.118.5；这种情况一直持续到去年年底，当时0.119测试版都出了好几个，又想着让0.119直接变身为1.0.0的正式版本号的样子。
  最后纠结来纠结去，确定了以“年+月+小版本”的形式编写版本号，第一个就是2020.12.0，一直沿用至今。

Supervisor，监工，supervised和hassos两种安装方式里的司令官，或者说总指挥。曾用名：HassIO、Hass.IO、Hass.io、Hassio、hassio、Hass.io supervisor。
显然，这些叫法和 对Supervised 这种安装方式的叫法经常混用，原因就是supervisor在supervised这种玩法里的地位和作用。
名称和版本号演进：

0.4，正式名称HassIO，2017.4.6
  0.36，名称加了个点Hass.IO，2017.6.5，后来IO又改成了小写io，有时候点被忽略
  0.102，2018.4.30
  103，版本号前面去掉了0.，2018.5.9
  194，改名为Hass.io supervisor，2020.1.8
  197，改名为Supervisor，2020.2.5
  249，2020.10.19
  2020.10.0，当月26号发布
  2021.10.0，本月7号发布

怀疑开发组里有国人大神，嫌弃250这个版本号，于是早在去年10月就率先改用了“年+月+小版本”的形式。

OS，全名Home Assistant Operating System，注意官方文档里有时候也把这个叫成“Home Assistant”——怀疑是粗心的编辑人员弄的。

0.1，正式名称Hass.io-OS，2018.4.18，只支持虚拟机
   0.3，改名为HassOS，2018.6.5，加入树莓派2的支持
   0.4，2018.6.12，加入树莓派0、1和3的支持，并增加64位版本
   1.3，2018.7.7，正式发布
   2.8，2019.2.4
   3.7，2019.12.16
   4.7，2020.5.26
   5.8，2020.12.13
   6.0，2021.6.9
   6.4，2021.9.9

Container：
  大概从 Core 0.14.2 版本开始，官方制作docker镜像，2016.5.1
  一直到现在随核心同步升级（当然会比核心版本稍微慢一会儿，毕竟先有核心再有容器/镜像），没有也不需要自己的版本号。

上面基本上还是以安装方式的维度整的。其实还有两个重要模块：
frontend，前端，也有自己的版本号；
iOS和安卓版官方app，大名Companion，有自己独立的文档网站！

XCray

前面说的各种集成和定制组件，作用是把各种设备和服务接入到HA这个平台，但接入不是目的，接入后参与到各种自动化之后才能对得起“智能”这个词儿！
关于自动化，很多新手都会犯迷糊。其实也难怪，就连小米的米家app在这方面都很弱，近乎白痴一样的水平。

几个词汇必须明确区分：自动化、场景、状态、事件、条件。

小米的米家app里，关于自动化曾用过智能、自动化、场景等几个术语，第一个莫名其妙，最近的版本里又用了错误的场景一词，也就曾经用过的自动化是正确叫法，虽然很弱。

在HA里（以及任何不以反人类为目的的智能家居/物联网应用中），自动化都是由3个基本要素构成的：
- 触发要素，本质是事件
- 环境条件，本质是状态（这个要素在简单的自动化里可以不要）
- 动作，只有这些动作被正确执行，智能家居才能发挥为人类（可能也包括非人类哈）服务的作用。
  稍微复杂一些的自动化，在一系列动作中间还可以设置条件，这也是我们说HA的自动化能力远超米家app那种白痴水平的一个关键原因。

比如有人移动，这是一个事件，可作为自动化的触发要素；而太阳已经落山了，这是一个状态，可用作环境条件；开灯，显然是一个动作（而灯开着或关着，又是状态）。

小米等一众厂家卖的“人体传感器”，就曾经让很多小白觉得智商受到了侮辱，甚至到处骂娘。原因就是混淆了“事件”和“状态”。当然，厂家用这个名称用得也很不严谨很不负责，产生了误导。

准确的叫法，这些以热释电、红外线加菲涅尔透镜触发的这种被动式的传感器，应该叫“人体移动传感器”——它报告的就是发现“有人移动”这个事件，它没能力报告“有人”还是“没人”这两种状态！比如你蹲在传感器前面不动，它也只能过一定时间（一般2分钟）后报告“无人移动”。而最近几年逐渐被大家接受的“人体存在传感器”则是类似于雷达的一种主动式的器件，它报告的是“有人”和“没人”的状态值（当然也可以触发有人移动的事件，甚至还有移动方向，以此还可以实现计数的目的）。

~~~~~~~~~~~~~
HA的自动化能力也曾经有一个逐步加强的过程，现在已经基本达到了完美的程度。

很多玩家比较推崇Node-Red。不可否认，NR是一个了不起的软件，甚至可称之为平台。但我真心不推荐新手使用，甚至不推荐大多数HA玩家使用，原因有两个：
- NR的使用门槛还是挺高的，一般人真不一定玩得转；
- HA的自动化能力已经不需要NR来补充。
  早期确实有一些稍微复杂的自动化单靠HA自身很难实现，而NR可以。
  但现在么，如果真的要用到NR可以实现但HA实现不了的自动化，那一定早就不是新手了。

我自己也曾经用过几个月时间NR，但后来就不用了，就是因为发现用不着了，何必再多跑一个程序？

~~~~~~~~~~~~
用好（或者正确设计）自动化的前提，是自己先想明白，千万不要指望这些所谓的智能家居、智能设备真的智能！

你想想，连你自己都想不明白、说不清楚的逻辑，你能指望一个几百、几十、十几、甚至几块钱的东西会自己想明白？？？
真要是那样的话，你的智商还不如一个几块钱的电子产品，你还不得赶快去找块豆腐撞死去？！

XCray

这层楼不涉及HA的各种组件（components），不管是官方集成的还是定制的

除了HA（不管那种安装方式）外，最重要的就是手机端的app了，推荐iOS系统的官方版本，首次使用需要梯子获取push id。安卓版的我没用过，需要的自行了解吧。

Siri、快捷指令（捷径），功能都很强大，配合HA及app也很好玩。

对于OS安装方式来讲，个人认为最有用、最必要的是“加载项 add-on”—— Samba share，就是把配置文件夹共享出来、Windows系统可以在网络邻居中看到和操控，这对于编辑配置文件非常有帮助。SSH、File Editor用处不大或不大好用，不如 samba share。
mqtt broker（俗称mqtt服务器）对于大多数ha玩家来说都非常重要（与ha安装方式无关，下同），建议用独立安装的软件包（比如debian等系统里 sudo apt install mosquitto-nossl或ssl），比 docker 容器好，这种简单的软件没必要动用docker。如果你用不着就不装。

远程访问的话，nginx非常值得选择，不过你先得了解反向代理的概念，当然这已经不是新手可以考虑的问题了。你知道了就自然会用了。

喜欢用ESP8266/ESP32的，ESPHome是最佳选择，推荐docker安装。当然，用到这个的也早就不是新手了。

Node-Red，前面说过，JavaScript玩得不熟的话，建议还是先别用了，用也用不好。

想让ha发声（播放各种音频媒体）又没有合适的智能音箱的，mpd 是最佳选择。操作系统支持的话，首选独立安装软件包（apt install mpd），系统不支持的话就用docker部署。蓝牙、有线都可以支持。与mpd并列或差不多性质的方案还有很多，但都不如mpd最简洁高效。

数据库，替代默认的基于文件的SQLite，任何一个独立的数据库引擎都会更强大，首选MariaDB，当然，了解的也早就不是新手了。

其他的，也基本上都不是新手需要玩的，等你想到要用的时候，你肯定自己已经有能力去搞定了。

这都是个人观点，仅供参考，说错了概不负责哈

~~~~~~~~~~~~~~~~~~~~~
最后，plugin、add-on、integration、component，哪个叫插件合适？
一概不加以区分、统统都叫成插件？说的人有随便说的自由，听的人自求多福、自己想办法避免被误导？

bainiu

hass更新很快，虽然到处是坑，但是愿意折腾。静待楼主大作。写这种教程要花很多精力，但对我们这种新手来说非常受益，师傅领进门，修行看各人了。

poseidon

小白前来报道

wbdownn

也谈谈看法
我是core安装，最原始。容器等其他方式，还没学。以前core安装会出现ha挂掉的情况，一度想Docker方式安装或者搞个守护进程，现在ha比较稳定了，基本不会出现崩掉的情况。所以还是选择core方式，毕竟树莓派装的，效率应该最高。

HACS ，曾经我也看不上，因为不是官方的东西，要装组件自行下载不就可以了，但装了之后还挺香的，更新方便。

blueprints，近几个版本开始出现的东西，大概知道有点类似模板的意思，没用过。

我也提个问题，
自动化，是ha里面的自动化好呢，还是 nodered 好？
从效率（资源占用）、便捷角度、扩展性来分析。
虽然应该是nodered胜，但感觉它像是api。而不是ha原生的东西。

huyusong

非常nice,感谢分享！

sctale

感谢分享