Home assistant проверить от чего сработал триггер

Введение

В Этой статье мы рассмотрим такую интересную вещь, как автоматизации в Home Assistant (далее HA). Возможности тут воистину просто безграничные по сравнению с приложением «Дом» от Apple, но и их составление не самая тривиальная задача. Для выполнения дальнейших действий в этой статье вам необходимо выполнить хотя бы три первых, которые вы можете найти в оглавлении. Итак, приступим.

Дано:

• Мохнатая собачья морда, любящая шариться по столам и тумбочкам на кухне
• Наличие Xiaomi Aqara Gateway 2
• Два датчика движения Xiaomi
• Home Assistant в виде Hass.io установленного на Raspberry Pi 3
• Настроенный и проверенный telegram_bot из предыдущей статьи
• Настроенный и проверенный Music Player Daemon (MPD)
• Колонки подключенные к Raspberry PI 3
• две кнопки Xiaomi размещенные в разных комнатах
• подключенный Amazon Polly TTS (но можно и штатным Google TTS)

Что необходимо сделать:

При двойном нажатии на одну из кнопок Xiaomi (или при включении автоматизации под названием Сигнализация в веб интерфейсе НА) происходит активация или дезактивация сигнализации

Что происходит: 

При наличии движения на одном из датчиков движения должно происходить следующее:

Home Assistant — это популярная система умного дома, которая автоматизирует привычные бытовые процессы и работает на YAML файлах. В этой статье я расскажу, как настроить Home Assistant (далее HA), и что конкретно я использую в повседневной жизни. Это поможет вам избежать ошибок и быстрее продвинуться в изучении HA.

На Хабре уже есть статьи о HA (раз, два, три), но здесь я хочу рассказать об установке и настройке системы от начала до конца. От первого запуска сервера до полноценно работающей системы, которую потом можно улучшать и дорабатывать для себя.

Основной единицей в HA является интеграция — логика, которая описывает взаимодействие с умным устройством или внешним сервисом. Большая часть полезной нагрузки HA ориентировано на связку: умное устройство + интеграция или внешнее API + интеграция.

Набор моих интеграций

Железо, участвующее в статье:

• Микроконтроллер Esp8266, а также датчик температуры и влажности DHT11;
• Лампа Xiaomi Desk Lamp;
• Raspberry Pi 4B в 2GB версии, как сервер для HA (в дальнейшем буду ее называть малинкой);
• Xiaomi Router 4A .

Сервисы, которые будем использовать:

• OpenWeatherMap для получения погоды, температуры, влажности на улице и других метеопараметров;
• Telegram для создания системы уведомлений;
• Google drive для создания бекапов;
• SpeedTest для замеров скорости;
• А также OpenUV для замеров ультрафиолетового излучения и др.

When automating your smart home with Home Assistant you will create a lot off automations. Monitoring and maintaining these Home Assistant automations can become a challenge. To overcome this it is possible to add cards to dashboards to provide an overview of triggered automations and disabled automations.

At this moment there are no cards available which will provide this functionality out of the box and some manual configuration is required. Luckily this is not complicated. I got the code from the Home Assistant community forum and adapted it a little bit to only show triggered automations from the last 24 hours and list the actual time instead of the hours/minutes past.

We will make use of the Mark Down card, which is by default available within the Home Assistant Lovelace UI dashboards and the code provided in this article.

We will implement 2 Home Assistant dashboard cards:

1. Triggered automations in the past 24 hours
2. Disabled automations

The required steps are provided in the next 2 sections.

3.1 Triggered automations in the last 24 hours

1. On the Home Assistant dashboard click on the button “Add card”displayed at the lower left of your screen and search for the Markdown card and select it.

   

2. Enter a title for the card

   

3. Delete the existing code from the content field by putting the cursor in the field, pressing the Ctrl-A (select all) and the Delete key.
4. Copy the following code and past it in the content field.
   

   

5. The theme part is not required. The preview will show the triggered automations.

   

6. Click on the Save button.

So use 3600 seconds for one hour, 43200 for 12 hours, etc.

3. 2 Triggered automations for an area

Change the highlighted in the area name you used for the automation. Check the name is exactly the same as used in the Area field for the automation (via information > settings for the specific automation).

3.3 Disabled automations

The final card will then look like the screen capture below.

<img decoding="async" src="https:/smarthome.familykruse.eu/data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTAwIiBoZWlnaHQ9IjUwMCIgdmlld0JveD0iMCAwIDUwMCA1MDAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CiAgICA8ZyBmaWxsPSJub25lIiBmaWxsLXJ1bGU9ImV2ZW5vZGQiPgogICAgICAgIDxwYXRoIGZpbGw9IiNFQkVCRUIiIGQ9Ik0wIDBoNTAwdjUwMEgweiIvPgogICAgICAgIDxyZWN0IGZpbGwtb3BhY2l0eT0iLjEiIGZpbGw9IiMwMDAiIHg9IjY4IiB5PSIzMDUiIHdpZHRoPSIzNjQiIGhlaWdodD0iNTY4IiByeD0iMTgyIi8+CiAgICAgICAgPGNpcmNsZSBmaWxsLW9wYWNpdHk9Ii4xIiBmaWxsPSIjMDAwIiBjeD0iMjQ5IiBjeT0iMTcyIiByPSIxMDAiLz4KICAgIDwvZz4KPC9zdmc+Cg==" alt="Article by Jan-Willem» data-old-src=»data:image/svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%200%200’%3E%3C/svg%3E»>

Writen by the website owner

Home Assistant – популярное приложение с открытым исходным кодом для организации умного дома. Первый опыт автора в работе с Home Assistant основывается на попытке интеграции в него ‘умной рисоварки‘. Автор постарается описать основные компоненты и возможности данного приложения, с которыми ему привелось пошагово познакомиться. Статья является в чем-то обзором, в чем-то руководством для желающих начать свое знакомство с Home Assistant.

Тем, у кого мало свободного времени, советую пропустить присказку – первую главу – и перейти сразу ко второй. Вам нужно знать только, что работать мы будем с умной китайской рисоваркой от Xiaomi.

Умная рисоварка

Рисоварка, очевидно, — это устройство для приготовления риса. Вики демонстрирует нам керамические рисовые пароварки из Британского музея, датирующиеся 1250 г. до н.э. В 1945 году корпорация Mitsubishi стала первой в Японии компанией, производящей домашнюю электрическую рисоварку. Наша модель — Rice Cooker от Xiaomi – может готовить не только рис. “Это великолепное устройство для приготовления не только риса, но других типов блюд. Оно может готовить и супы, и пирожные, и многое другое” — говорится в рекламе. Но самое главное — это наличие wi-fi модуля, ПО с возможностями автоматизации и 200+ программно установленных рецептов. “Путь к умному дому через желудок – это правильно”, подумал автор, и решился.

Xiaomi Rice Cooker, как и подобает цифровому устройству, внешне очень привлекательна, радует округлостью форм и общим минимализмом. Для её настройки и использования производитель предлагает приложение Mi Home. После регистрации Mi account, программа легко отыскивает новое устройство, и вы регистрируете его в вашей локальной сети. Интерфейс приложения не самый плохой, предоставляет базовые средства для автоматизации, может принимать уведомления от устройств. Однако, есть существенные недостатки. Не всех может порадовать отправление информации разработчику о каждом клике пользователя. И неприятное выражение находит часто упоминаемый нынче национальный калорит. Вместо 200+ рецептов на иностранные языки переведено и доступно всего лишь четыре. Остальное – исключительно для китайского народа. Когда ваша ‘умная’ рисоварка не способна выполнять все обещаные кулинарные обязанности, тут, согласитесь, становится грустно. Побродя некоторое время по интернетам, погрустневший автор наткнулся на следующий интересный проект (вечных благ автору). Который оказался посвящен разработке модуля для некоего Home Assistant.

Home Assistant

Сперва, немного общей информации. Как нам говорят на домашней странице HA, ”Это ПО с открытым кодом для автоматизации умного дома, ориентирующееся на локальное управление и конфиденциальность. Развиваемый трудом открытого сообщества энтузиастов, он отлично подходит для работы на Raspberry Pi или локальном сервере.” Проекту более пяти лет, он использует python и лицензию Apache 2.0. Версия релиза на момент написания этих строк – 0.99.3.

Для управления устройствами HA использует отдельные модули (integrations, или components). Создать такой довольно просто. На сайте можно найти каталог основных (одобренных и поддерживаемых сообществом) модулей. Среди общего их количества (1485 штук) попадаются совершенно разнообразные, в каталоге значятся имена amazon, google, xiaomi, и даже один раз yandex.
Попробуем установить HA в виртуальное окружение на линукс десктопе. Нам понадобится python3 и менеджер пакетов pip.

python3 -m venv homeassistant # Создаем виртуальное окружение
cd homeassistant
source bin/activate # Активируем виртуальное окружение
python3 -m pip install homeassistant # Устанавливаем Home Assistant
hass --open-ui # Запускаем Home Assistant

Все необходимые пользователю данные HA хранит, в случае линукс, в папке настроек “~/.homeassistant”. Файлы настройки записаны в формате YAML, и основной из них – это “configuration.yaml”. Он объединяет данные модулей, автоматизаций, etc. Возможность импорта позволяет разбить настройки на отдельные логически организованные файлы. Модули же хранятся в подпапках “components” (встроенные) и “custom_components”.

Этих знаний для установки нового модуля нам должно быть достаточно. Копируем с репозитория папку “xiaomi_cooker” в нашу “~/.homeassistant/custom_components”. Согласно описанию, добавляем настройки модуля в файл “configuration.yaml”:

xiaomi_cooker: # Имя модуля name: 'Akari' # Имя устройства host: 192.168.1.10 # IP адрес устройства token: '4921def609273302248d040a24243a25' # Замуты протокола Xiaomi model: chunmi.cooker.normal2 # Модель устройства

Любой модуль представляет собой некоторый набор объектов (entities) и сервисов (services, по сути — функции). Объекты хранят различные принимаемые от устройств данные. Например, sensor.xiaomi_cooker_temperature – температуру рисоварки, sun.sun – положение солнца. Данные объекта выражаются одним основным значением — статусом (state), и произвольным набором дополнительных аттрибутов (attributes). Сервисы используются для передачи команд и значений устройствам. Например, xiaomi_cooker.start – команда начала работы рисоварки, или homeassistant.check_config – инициализация поиска ошибок в файлах настроек HA. В списке Developer Tools веб-интерфейса находится раздел Services, где можно просмотреть доступный вам список сервисов и поиграться с их вызовами. Рядом есть раздел States, где, соответственно, можно просмотреть и поизменять значения объектов. Нужно заметить, что изменения значений объектов в разделе States имеют односторонний характер. Т.е. если, например, поменять здесь состояние объекта lights.state с off на on, на истинном состоянии устройства это не отразится, и при следующем же обновлении данных от устройства значение объекта будет перезаписано в реальное.

Automation

 - id: '1565889970818' # ID автоматизации alias: Umpiro decharging # Имя trigger: # Условия срабатывания - platform: time_pattern # Тип условия - временной minutes: /15 # Задание условия (в нашем случае – условие выполняется каждые 15 минут) condition: [] # Дополнительные условия срабатывания action: # Выполняемые автоматизацией действия - data: # Аргументы, передаваемые при вызове сервиса entity_id: sensor.umpiro_charge # Аргумент (ключ: значение) service: homeassistant.update_entity # Имя вызываемого сервиса

Нужно заметить, что пока еще не все доступные автоматизации (например, приведенную выше) можно сконфигурировать без редактирования yaml-кода, через графический интерфейс, но разработчики говорят об активной работе над устранением этого недостатка.

Templating

После автоматизаций будет самое время рассказать о шаблонах (templating). Различные элементы настроек в yaml-файлах позволяют использовать вставки на скриптовом языке jinja2. Многие из этих элементов объединены общим названием ‘Templates’, как то service_template или trigger_template. Используя шаблоны, мы получаем доступ к значениям объектов в HA и возможность использовать эти данные в комплексных математических и логических выражениях, что значительно расширяет наш потенциал. В качестве примера, приведем записанный в “configuration.yaml” чуть подусложненный код упомянутого ранее sensor.umpiro_charge. Это template_sensor, i.e. “сенсор, формирующий данные на основании значений других объектов”. Наш сенсор будет представлять собой некоторый аналог постепенно разряжающейся батарейки:

sensor: # Название модуля platform: template # Тип модуля - шаблон sensors: # Список объектов # Название объекта – sensor.umpiro_charge umpiro_charge: # Задает форму отображения объекта в UI (опционально) unit_of_measurement: '%' # Шаблон, задающий значение объекта value_template: >- # Получение значения объекта – конвертация фильтром ‘int’ # + проверка на соответствие типа {% if states('sensor.umpiro_charge')|int('unknown') is number %} # запись в переменную нового значения объекта # на основе текущего значения и времени последнего обновления {% set value = (states('sensor.umpiro_charge')|int - (as_timestamp(now()) - as_timestamp(states.sensor.umpiro_charge.last_updated))/60/15)|round %} # Тонкая работа фильтрами для ограничения плюсанутости {{ [[0, value]|max, 100]|min }} {% else %} # Значение, используемое HA по умолчанию # для не определенных состояний объектов {{ 'unknown' }} {% endif %} # ID стороннего объекта, при изменение значения которого # будет обновляться значение данного объекта entity_id: [] friendly_name: 'Charge' # Имя объекта # Задает форму отображения объекта в UI (опционально) device_class: battery

entity_id мы оставили пустым, поскольку уже добавили автоматизацию, которая будет самостоятельно вызывать обновление данных объекта.

Python Scripts

В свою очередь, для создания новых сервисов простым инструментом являются пайтон-скрипты (python scripts). После добавления в “configuration.yaml” строчки: “python script:”, все файлы с расширением “.py”, которые мы поместим в папку “~/.homeassistant/python_scripts”, станут доступны в качестве сервисов с именами “python_scripts.<file_name>”. Их код выполняется в заранее заданном окружении, где переменные data и hass дают нам доступ к аргументам вызова сервиса, а также объектам и сервисам HA. В качестве примера приведем код файла “charge_set.py” для сервиса “python_scripts.charge_set”. Его функцией будет установка заряда нашей батарейки:

# Получение первого аргумента вызова
name = data.get('name', 'sensor.umpiro_charge')
# Получение второго аргумента вызова
new_state = data.get('charge', '100')
# Получение данных объекта
attributes = hass.states.get(name).attributes
# Изменение данных объекта
hass.states.set(name, new_state, attributes)

Creating integration

Все что мы сделали с помощью шаблонов и пайтон-скриптов, возможно, было бы проще осуществить написанием отдельного модуля. Как уже говорилось, неофициальные модули хранятся в папке “custom_components”. В будущем нам понадобится объект, хранящий информацию о текущем рецепте для нашей рисоварки, и сервис, позволяющий изменять эти данные. На основе примера из документации создадим для этого новый модуль, “overmind”. Первый шаг – это файл custom_components/overmind/__init__.py:

# Домен для регистрации сервиса
DOMAIN = 'overmind'
# Значение по умолчанию для нашего объекта (рецепта)
DEFAULT_RECIPE = {
"title": "Habr post",
"description": "Post an article on habr.com", "profile": "471822"
}
# Функция настройки модуля
def setup(hass, config): # Установка значений объекта hass.states.set('overmind.current_recipe', 'on', DEFAULT_RECIPE) # Функция с описанием сервиса установки рецепта def handle_set(call): # Получение значения аргумента recipe = call.data.get(‘recipe’, DEFAULT_RECIPE) # Выполнение задачи - изменение значения объекта hass.states.set('overmind.current_recipe', 'set', recipe)
# Регистрация сервиса
hass.services.register(DOMAIN, 'recipe_set', handle_set)
return True

После этого сообщим о новом модуле файлу настроек “configuration.yaml”, добавив в него строчку с названием модуля: “overmind:”. Задача решена.

Lovelace UI

Так называется используемый HA фронтенд. Этот графический интерфейс, через который обычному пользователю предлагается управлять умным домом, является заглавной страницей веб-интерфейса HA. Интерфейс LUI формируется из карточек (сards) разнообразых типов, которые могут отражать значения объектов, служить для вызова функций и прочих задач. Карточки можно распределять по страницам (view), по аналогии с браузерными закладками. Настройка удобно организована через тот же графический интерфейс, но доступна и посредством yaml-кода, для чего там же присутствует встроенный текстовый редактор. Рекомендую заглянуть на страницу https://demo.home-assistant.io/, где приведено несколько различных примеров настройки LUI, и где их легко можно посмотреть, пощелкать и поизменять.

Пример настройки графического интерфейса

Говоря о недостатках интерфейса, к сожалению, разработчики сами признаются, что проект пытается усидеть одновременно на стульях десктопа и смартфона. LUI, по умолчанию, любит самостоятельно определять расположение и размеры карточек, что иногда может превращать нормально выглядящую на мониторе страницу в полную кашу на экране смартфона, и наоборот. Присутствуют некоторые простые инструменты для упорядочения интерфейса, но и они, по моему опыту, не всегда эффективны.

Думаю, не имеет большого смысла описывать создание интерфейса посредством графических инструментов, поэтому я приведу несколько примеров в виде использованного мной yaml-кода. Создав для нашей рисоварки отдельную страницу (view), мы постараемся заполнить её самыми необходимыми элементами так, чтобы это не вызывало отторжения при пользовании с экрана смартфона.

Тут же опробуем те самые простые инструменты упорядочения интерфеса, это – horizontal-stack и vertical-stack. Сперва, создадим vertical-stack из карточек типов entity-button и sensor. Первая будет служить для запуска нашей рисоварки, вторая – для отображения значения температуры:

cards: # Список карточек стека - type: entity-button # Тип первой карточки в стеке entity: sensor.xiaomi_cooker_state # Объект, связанный с данной карточкой icon: 'mdi:selection' # Иконка для данной кнопки icon_height: 100px # Размер иконки name: Offline # Имя под кнопкой show_icon: true # show_name: true # tap_action: # Действие при нажатии action: call-service # Действие – вызов сервиса service: script.turn_on # Сервис – вызов скрипта service_data: # Аргументы вызова сервиса entity_id: script.order_cooker_start # Аргумент – название скрипта hold_action: # Действие при удержании action: none # - type: sensor # Тип второй карточки в стеке entity: sensor.xiaomi_cooker_temperature # Объект, связанный с данной карточкой name: Temper # Имя карточки
type: vertical-stack # Тип карточки – вертикальный стек

Home Assistant включает в себя архив иконок Material Design Icons, которые, через соответствующие имена (например, mdi:selection), можно использовать в элементах настроек. Скрипт (в данном случае, не python-, а yaml-), который мы использовали для вызова сервиса, это еще один удобный инструмент HA.

Теперь объединим приведенный выше vertical-stack с карточкой портрета нашей в теперь уже horizontal-stack. Все будет так же просто:

сards: # Список карточек стека - type: picture # Тип карточки image: /local/akari_r.jpg # Адрес файла изображения - # Тут мы помещаем написанный выше код вертикального стека
type: horizontal-stack # Тип карточки – горизонтальный стек

Здесь нужно отметить строчку ‘image:’. Все файлы, которые мы помещаем в папку ‘~/.homeassistant/www’ становятся доступными по ссылке http://localhost/local/filename.

Следующим шагом мы немного поработаем над созданной нами кнопкой вызова сервиса. Для нас было бы удобно, если бы она работала как тумблер, т.е. на включение/выключение, а не так, как это сделано сейчас. Этого можно добиться через использование карточки типа conditional, отображение которой на экране можно регулировать через задание определенных условий. Ниже приведен код для карточки, которая является кнопкой выключения рисоварки и видна только при условии, если рисоварка находится в процессе приготовления блюда:

card: # Описание содержания карточки entity: sensor.xiaomi_cooker_state # icon: 'mdi:star-box-outline' # icon_height: 100px # name: Running # tap_action: # action: call-service # service: xiaomi_cooker.stop # type: entity-button # conditions: # Условия отображения # Объект, значение которого проверяется entity: sensor.xiaomi_cooker_mode # Значение объекта, необходимое для выполнения условия state: Running
type: conditional # Тип карточки

Переписав подобным образом ранее созданный код кнопки влючения, и объединив его с этим, мы получим одну кнопку, работающую одновременно на включение и выключение.

Дополним наш интерефейс еще одной карточкой — с отображением времени до окончания приготовления (аналогично карточке температуры), и еще одной – с деталями приготовляемого рецепта (custom:recipe-card). В итоге получим что-то такое:

Custom Cards

Home Assistant помимо богатства встроенного набора типов карточек, конечно же, предоставляет возможность создавать и свои. Такие карточки называются пользовательскими карточками (custom cards), и для их создания используется javascript. Здесь можно ознакомиться с двумя простыми примерами кода. В сети несложно найти готовые карточки, созданные различными энтузиастами, а если хочется поэкспериментировать самому, то полезно будет узнать, что существуют и специальные js-модули, созданные для упрощения работы над написанием новых. Мой опыт обращения с javascript продолжает желать меньшего, поэтому, в качестве примера, я приведу только небольшую часть кода карточки, используемой для выбора и отображения текущего рецепта.

import {
// Импорт из стороннего модуля lit-element LitElement, html, css
} from "https://unpkg.com/lit-element@latest/lit-element.js?module";
// Класс с описанием новой карточки
class RecipeCard extends LitElement { // Получение доступа к элементам HA static get properties() { return { hass: {}, config: {} }; } // Пример вызова сервиса callServiceEx() { this.hass.callService('persistent_notification', 'create', {message: 'example'}); } // Получение html-кода карточки render() { // Получение информации об объекте, связанном с данной карточкой const entityId = this.config.entity; // Получение состояния объекта const state = this.hass.states[entityId]; // Получение аттрибута объекта const titleStr = state ? state.attributes.title : 'unavailable'; const descrStr = state ? state.attributes.description : 'unavailable'; // Формирование кода карточки return html` <ha-card> <div class="flex" style="margin-top:16px;"> <div class="icon"> <ha-icon icon="mdi:bowl"></ha-icon> </div> <div class="header"> <span class="name">Recipe</span> </div> </div> <div class="flex info" style="margin-bottom:16px;"> <span class="recipe-title">${titleStr}</span> <span class="recipe-descr">${descrStr}</span> </div> </ha-card> `; }
// Задание имени новой карточки
customElements.define('recipe-card', RecipeCard);

Для использования новой карточки нужно будет добавить в начале файла настроек LUI следующий код:

resources: # Задание внешних ресурсов - type: module # Тип ресурса – модуль url: /local/recipe-card.js # Расположение ресурса

и среди списка карточек:

 - type: 'custom:recipe-card' # Тип карточки entity: overmind.current_recipe # Объект, связанный с данной карточкой

Notifications

Необходимой частью умного дома является отправка сообщений пользователю. В HA такие сообщения называются notifications (уведомления) и существует два базовых типа уведомлений. Первый – это внутренние уведомления (persistent notifications). Для их отправки используется встроенный сервис «persistent_notification.create». Список таких сообщений доступен через иконку колокольчика в графическом интерфейсе, они используют markdown разметку и по сути довольно просты.

Другим, более интересным, инструментом является встроенный модуль notify, который через установку дополнительных модулей позволяет передавать сообщения, используя сторонние платформы. В качестве примера рассмотрим модуль для telegram.

Для использования модуля нам, прежде всего, будет необходимо создать бота в самом telegram. При настройке нам понадобится chat_id нашего пользователя и API token бота. Как получить эти данные – детально рассказано по ссылке выше, будем считать, что они у нас готовы. Переходя непосредственно к установке модуля, сперва, как мы уже делали, скопируем его исходники в папку components, а затем добавим его настройки в файл “configuration.yaml”:

telegram_bot: # Настройки модуля telegram platform: polling # Тип модуля api_key: XXXXXXXXXXXXX # API Token вашего бота allowed_chat_ids: XXXXXXX # chat_id вашего пользователя proxy_url: socks5://XXXXXXXXXXXXX # Адрес нашего любимого прокси proxy_params: username: umpiro password: umpiro_password

плюс настройки модуля notify:

notify: # Настройка модуля notify name: notify_send # Название сервиса (в нашем случае – будет notify.notify_send) platform: telegram # Тип модуля chat_id: XXXXXXX # chat_id вашего пользователя

Модуль telegram позволяет нам отправлять сообщения, картинки, или видео. В качестве примера, создадим автоматизацию для отправки сообщения с картинкой, уведомляющее нас об окончании приготовления блюда.

 - id: '1571074941908' # ID автоматизации alias: EOC # Имя автоматизации trigger: # Условия срабатывания автоматизации # Объект, определяющий срабатывание - entity_id: sensor.xiaomi_cooker_mode from: Running # Исходное состояние объекта # Тип автоматизации – изменение состояния объекта platform: state to: Waiting # Конечное состояние объекта condition: [] # Дополнительные условия action: # Выполнияемые автоматизацией действия - service: notify.notify_send # Действие – вызов сервиса data: # Аргументы, передаваемые при вызове сервиса title: End of Cooking # Заголовок message: "EOC" # Сообщение data: # Дополнительные данные сообщения photo: # Тип данных - изображение # Файл изображения - file: /home/umpiro/.homeassistant/www/cat.jpg # Заголовок изображения caption: “EOC”

Послесловие

Home Assistant может заинтересовать тех, кто хочет попробовать организовать локальное управление умным домом. Это широкий, интересный, открыто и активно развивающийся за счет усилий коммьюнити проект. Разнообразие инструментов Home Assistant не может не радовать (некоторые важные я не успел упомянуть). В качестве минуса можно назвать относительную запутанность и неполноту документации.
P.S.
Недавно, 10 октября произошел, не знаю можно ли это назвать релизом, переход проекта от версии 0.99 к версии 0.100.
Цитата из Release Notes:

Welcome to the release notes of yet another wonderful release! No, we’re not going for 1.0, we’re doing 0.100! We feel like we’re not ready yet with our goals for 1.0, but we’re making progress every day. For a sneak peak of what we’re thinking about, check our blog Simple mode in Home Assistant 1.0.

Отслеживание устройств

Начнем с отслеживания устройств, с помощью которого мы можем фиксировать вход и выход носителей из дома.
Я предлагаю 2 способа отслеживания:

• с помощью роутера (у меня в наличии Xiaomi Router Mi4A),
• с помощью GPS.

В системе доступно много производителей роутеров. Для старых и не перечисленных в списке моделей можно использовать nmap (более подробно тут).
Если установить на телефон официальное приложение, HA по умолчанию создаст интеграцию, и в системе появится дополнительное устройство, которое можно отследить.

Немного оптимизации

По умолчанию в HA используется SQLite, и сброс данных на диск происходит часто (каждую секунду). Это может привести в скором времени к выходу из строя SD карточки на малинке (если сервер стоит на ней). Чтобы продлить срок службы карточки, скажем HA, что нужно записывать на диск раз в commit_interval и исключить некоторые сущности, которые мы не хотим отслеживать на длинном временном промежутке (или вообще не хотим отслеживать).

commit_interval: 1500
purge_keep_days: 7
exclude: domains: - updater - automation entity_globs: - sensor.miwifi_router* entities: - sensor.date - sensor.date_time - sensor.time - sensor.openweathermap_forecast_time

recorder: !include configs/recorder.yaml

Если мы хотим использовать СУБД, отличную от SQLite, то можно сделать один из следующих пунктов на выбор:

1. Установить соответствующий аддон для перехода на MariaDB.
2. Использовать существующую реляционную базу данных на удаленной машине, если указать строку для подключения в параметр db_url.

Более полный пример

Вообще автоматизации в основном имеют такой скелет:

• trigger как мы ранее говорили — действе которое запускает автоматизацию
• condition это условие, исполнение которого необходимо для автоматизации
• action ну и действие которое выполняется автоматизацией

- alias: Temperature heater 24 on morning trigger: platform: time at: '06:30:00' condition: condition: state entity_id: group.devices state: home action: - service: climate.set_temperature data_template: entity_id: climate.ariston temperature: "24"

Trigger. В данном примере тригером является определенное значение времени, а именно 6:30 утра. Именно во столько должна сработать автоматизацияCondition. Условием выполнения автоматизации является проверка значения группы devices. Оно может принимать значение home или not_home.Action. Ну и наконец действие — установка на термостате необходимой температуры в 24 градуса.

Пример посложнее

Вариантов, как использовать автоматизации очень и очень много и перечислить все в рамках этой статьи я не смогу, но покажу кое-что, что я использую. Вот более сложный пример:

# Включение света в ванной ночью и днем
- alias: Turn on bathroom light trigger: platform: state entity_id: binary_sensor.motion_sensor_158d0001b177e8 to: 'on' action: - service: light.turn_on data_template: entity_id: light.bathroom brightness_pct: > {% if is_state('sun.sun', 'below_horizon') and is_state('light.living_room', 'off') %} 1 {% else %} 100 {% endif %}

Это автоматизация с условием включения света в ванной на 1 процент ночью, если выключен ночник в зале (это обычно значит, что я сплю) и на 100 процентов в остальных случаях (всегда днем или вечером, если включен ночник). Разберем подробнее:

• platform: state это значит что в тригере мы будем отслеживать значение состояния нужного нам датчика
• entity_id: binary_sensor.motion_sensor_158d0001b177e8 это название датчика взятое из списка всех устройств на соответствующей странице, чуть ниже покажу, где его можно взять.
• to: ‘on’ задаем значение, при котором должен сработать тригер

Теперь о entity_id и где его можно посмотреть. В веб версии необходимо найти слева раздел «Инструменты разработчика» и нажать на кнопку «состояния»:

Справа вы увидите таблицу со всеми вашими устройствами и не только, в первой колонке которой и будет перечень entity_id:

Далее разберем секцию action: более подробно:

• service: light.turn_on указываем какое действие мы хотим сделать при срабатывании тригера
• data_template: тут мы говорим, что будем использовать далее компонент HA «шаблон», что это такое можно почитать в офф документации HA тут
• entity_id: light.bathroom поясняем каким именно устройством мы хотим управлять
• brightness_pct: > указываем, какой параметр у устройства мы хотим изменить (Внимание! В коде вместо «&gt;» надо писать именно знак >) в данном случае это яркость в процентах

Далее нам надо будет познать немного программирования.

Создание системы отслеживания через роутер

Трекинг через локальную сеть роутера требует настройки, в отличие от GPS отслеживания. Два вида трекинга можно комбинировать для повышения точности. Ниже можно заметить, что в моем случае отслеживание через роутер работает лучше, чем через GPS. Зеленая зона значит, что телефон внутри зоны, красная — вне зоны.

Результаты работы отслеживания (сверху — роутер, снизу — GPS)

Редактирование конфигурационных файлов через VSCode

Можно подключиться через плагин SSH в VS Code, но получить доступ к проводнику в данный момент мне было удобнее. Поэтому, добавим сетевое расположение.

Нажмем обзор, найдем каталог config (мы в основном будем редактировать его) и выберем его как сетевую папку.

Дальше мы можем перейти в созданную папку и открыть ее через редактор.

platform: xiaomi
host: 192.168.31.1
password: !secret xiaomi_router_password
configuration.yaml
device_tracker: !include configs/router_device_tracker.yaml

После перезагрузки HA мы можем увидеть, что у нас появился новый глобальный объект device_tracker и наши устройства в нем.

Трекинг устройств через роутер

Упомянутые кастомизации

Когда мы настраиваем автоматизации, они появляются на основном экране Home Assistant и вводят в заблуждение. По факту нам кроме основной кнопки включения/отключения сигнализации, на главном экране больше ничего и не нужно. 

Поэтому мы берем файл customize.yaml и вставляем туда параметры

# название автоматизации или элемента на основной странице системы automation.disable_sound_of_alarm: # то как мы хотим чтобы она называлась «по человечески» friendly_name: ‘Отключить сирену’ # а тут мы говорим хотим ли мы видеть этот элемент на основной странице # это на самом деле означает спрятать. # типа ответа на вопрос «хотим ли мы спрятать элемент ?» # ответ «true» означает «да, хотим спрятать» hidden: true automation.motion_detection: friendly_name: ‘Сигнализация на кухне’ automation.arm_disarm_alarm: friendly_name: ‘Отключить сигнализацию кнопкой’ hidden: true automation.alarm_status_sound: friendly_name: ‘Подзвучка включения/отключения сигнализации’ hidden: true script.alarm_sequence friendly_name: ‘Действия при сработке сигнализации’ hidden: true

где  hidden: true скрывает ненужные нам автоматизации и скрипты с главного экрана и все становится значительно удобней.

С помощью Xiaomi Router Mi4A

• Не требует никаких действий на устройстве, отслеживает всех в локальной сети.

• Если устройство не подключено к домашней сети, то устройство пропадает в пустоту, и на картах мы его не увидим.
• Иногда может сработать триггер выхода/входа из зоны, когда фактически девайс не покидает зону (можно попробовать решить расширением зоны).

Возникавшие сложности

• Добиться аналогичности действий при двойном нажатии на кнопку и при активации через веб интерфейс (если все звуки снятия и постановки на охрану прописать в автоматизации для кнопки, то при активации или деактивации сигнализации через веб интерфейс — все происходит в гробовой тишине)
• При сработке сигнализации, отрабатывалась часть автоматизации отвечающая за воспроизведение звуков при постановке/снятии на охрану так как использовался алгоритм is_state

Отслеживание системных параметров

Чтобы отслеживать остаток свободной памяти, загруженность процессора или скорость Интернет соединения, мы можем добавить мониторинг показателей системы.

- platform: systemmonitor resources: - type: disk_use_percent arg: / - type: memory_free - type: memory_use_percent - type: processor_use - type: processor_temperature - type: disk_free arg: /

При желании можем создать автоматизацию, которая при критических показателях будет отправлять уведомление о необходимости принятия мер.

Также мы можем посмотреть Uptime сервера.

- platform: uptime name: Time Online

sensor: !include_dir_merge_list sensors

Вариант представления на UI

Добавим blueprints

Теперь небольшое лирическое отступление в виде рассказа о написании blueprints на примере уведомлений.

В данном случае я бы перевел blueprints не как чертежи, а как шаблоны или заготовки. Их удобнее использовать, если нужно написать несколько похожих автоматизаций, а основную логику оставить нетронутой.

Например, можно упростить создание уведомлений о начинающихся осадках.

blueprint: name: Fallout start notification domain: automation input: # аргументы шаблона precipitation: name: Precipitation level selector: entity: domain: sensor # только для ui, поможет создать автоматизацию, предоставляя только сенсоры в выпадающем списке message_start: name: Telegram message default: "No message"
trigger: # условия срабатывания - platform: numeric_state entity_id: !input precipitation above: 0.9 for: minutes: "{{ states('input_number.minimum_time_for_stable_value')|int }}"
action: - service: telegram_bot.send_message data: message: !input message_start 

“for” — это время, в котором должен оставаться выбранный параметр, чтобы сработал триггер на превышение уровня осадков.

minimum_time_for_stable_value: name: Minimum time for stable value initial: 1 min: 0 max: 59 step: 1

Теперь, когда есть blueprint, мы можем написать автоматизацию с меньшим количеством логики.
Создадим уведомления о начале осадков.

- alias: 'Rainy is started' use_blueprint: path: homeassistant/fallout_start_notification.yaml input: precipitation: sensor.openweathermap_rain message_start: "Похоже, дождь начинается. Уже накапало {{states('sensor.openweathermap_rain')}}мм."
automation/snow_start.yaml
- alias: 'Snow is started' use_blueprint: path: homeassistant/fallout_start_notification.yaml input: precipitation: sensor.openweathermap_snow message_start: "Пошел снежок. Уже навалило {{states('sensor.openweathermap_snow')}}мм."

Мы смогли вынести часть функциональности в отдельный файл. В подобных случаях, когда со временем появляется похожий код, можно выносить часть логики в отдельный файл.

Для большей полезности можно изменить шаблон и поменять action на повышение яркости для света в доме или закрытие штор.

Вернемся немного в прошлое

Если вы читали статью 4 из оглавления в начале, то частично имеете представление об автоматизациях. Там мы рассматривали возможность отложенного запуска бриджа для интеграции в HomeKit. Рассмотрим этот пример еще раз и разберем для лучшего понимания:

- alias: 'HomeKit Delayed Start' trigger: - platform: homeassistant event: start action: - delay: 00:01 - service: homekit.start

• alias: это название автоматизации. Отсюда HA берет entity_id для нее, кириллицу лучше не использовать
• trigger: это условие, которое заставляет автоматизацию сработать. В данном примере это событие запуска HA
• action: это действие, которое будет совершено автоматизацией. Тут это отложенный запуск плагина HomeKit

Разберем конфигурацию

Для начала нам нужно понимать откуда нам брать названия сенсоров, кнопок, датчиков и автоматизаций чтобы их использовать в коде. Для этого мы идем в раздел «Элементы» из инструментов разработчика

а дальше уже из списка который у нас появился, мы выбираем названия элементов, которые нам нужны для работы:

Ну а дальше пошло самое веселье. Начинаем вставлять код в файл automations.yaml

# Основной модуль сигнализации, который отвечает за обнаружение движения и включение тревоги — alias: ‘Motion Detection’ # используется последовательное перечисление с указанием # платформ, так как простой список через запятую не заработал trigger: # Здесь перечисляются датчики, которые определяют момент # сработки сигнализации. Параметр «state» означает сработку # по состоянию (вкл/выкл) или (сработал/не сработал) — platform: state # Наименование кнопок или сенсоров если что берется из раздела # «состояние» или «state» в левом меню НА в инструментах разработчика со значком ‘&amp;amp;amp;amp;lt; &amp;amp;amp;amp;gt;’ entity_id: binary_sensor.motion_sensor_номер_сенсора1 to: ‘on’ — platform: state entity_id: binary_sensor.motion_sensor_номер_сенсора2 to: ‘on’ # Дальше начинается модуль действий action: # Уведомление через бот телеграма — service: notify.telegram data: # символ | указывает на возможность отправлять сообщения # из нескольких строк просто через перевод строки message: | !!! Эта мохнатая сволочь полезла на столы !!! # Запуск скрипта, который и выполняет роль сирены (описан ниже) # используется для скриптов. Означает просто состояние включенности # Home Assistant и потому что нужно указать какой то сервис в данном месте — service: homeassistant.turn_on #запуск скрипта alarm_sequence прописанного в scripts.yaml entity_id: script.alarm_sequence # Следующая автоматизация прекращает ор сирены если вдруг # сие случится когда я дома по нажатию одной из кнопок один раз — alias: ‘Disable Sound Of Alarm’ trigger: # триггером является момент начала или прерывания какого либо процесса — platform: event # это означает что мы совершаем действие (или что то совершает) event_type: click # описывается формат действия, в данном случае нажатие на кнопку event_data: #указывается какая именно кнопка имеется в виду entity_id: binary_sensor.switch_номер_кнопки_1 # указывается какое именно нажатие на кнопку используется # (в данном случае однократное, но у этой кнопки есть двукратное (описано ниже) и длительное) click_type: single — platform: event # по аналогии с предыдущей кнопкой event_type: click event_data: entity_id: binary_sensor.switch_номер_кнопки_2 click_type: single # А дальше по аналогии указывается действие которое должно произойти после нажатия кнопки action: # Мы выбираем что нам нужно действие с Xiaomi Gateway и даем команду остановить проигрывание рингтона — service: xiaomi_aqara.stop_ringtone data: gw_mac: МАК_АДРЕС_ШЛЮЗА # Автоматизация включения или отключения сигнализации — alias: ‘Arm/Disarm alarm’ trigger: # Все по аналогии с кнопками описанной выше — platform: event event_type: click event_data: entity_id: binary_sensor.switch_номер_кнопки_1 click_type: double # только клик двойной — platform: event event_type: click event_data: entity_id: binary_sensor.switch_номер_кнопки_2 click_type: double # Данной командой мы переключаем состояние автоматизации. # У нее есть состояние On и Off. Toggle переключает состояние между On и Off action: — service: automation.toggle # и указываем какую именно автоматизацию мы переключаем entity_id: automation.motion_detection # Маленький комментарий. Автоматизация срабатывает только во включенном состоянии. # Если она отключена, то все что в ней описано работать не будет пока мы ее не включим. # Самая «веселая автоматизация» которая отвечает за обозначение звуками и # уведомлениями процесса включения или отключения сигнализации # (кнопкой мы это делаем или через веб интерфейс — неважно) — alias: ‘Alarm Status Sound’ # Данным триггером мы отслеживаем состояние сигнализации # которая у нас описана в самой первой автоматизации trigger: platform: state entity_id: automation.motion_detection #данная настройка нужна для того, чтобы данная автоматизация # срабатывала только при изменении состоянии сигнализации # и не использовалась при срабатывании сигнализации condition: — condition: template # мы отслеживаем этой командой только изменение состояние сигнализации каким бы оно ни было value_template: «{{ trigger.to_state.state != trigger.from_state.state }}» action: # тут мы указываем что система голосом «кожаные мешки» должна через подключенные # напрямую в малину колонки нам сказать текст который мы хотим — service: tts.amazon_polly_say entity_id: media_player.mpd data_template: message: # тут мы выясняем в каком же состоянии находится сигнализация {% if trigger.to_state.state == ‘on’ %} # так как выше мы выяснили что она включена — то говорим что она работает Замри мешок с костями, а то ушибу # а тут рассматривается вариант что сигнализация отключена {% elif trigger.to_state.state == ‘off’ %} # и система сообщает что можно двигаться так как сработки не будет Можешь шевелиться кожаный мешок # а так как других условий у нас нет, то тут мы ничего и не указываем {% else %} {% endif %} # выше описано, что этот блок отправляет уведомление нам через нашего бота — service: notify.telegram data_template: message: # ну и дальше по аналогии с вышеописанным мы выбираем варианты # действий в соответствии с состоянием сигнализации {% if trigger.to_state.state == ‘on’ %} Замри мешок с костями, а то ушибу {% elif trigger.to_state.state == ‘off’ %} Можешь шевелиться кожаный мешок {% else %} {% endif %} # а тут у нас шлюз Xiaomi проигрывает кастомный рингтон постановки # на охрану записанный в него через MiHome — service: xiaomi_aqara.play_ringtone data_template: ringtone_id: &amp;amp;amp;amp;amp;amp;amp;amp;gt; {% if trigger.to_state.state == ‘on’ %} 10003 # Нумерация загруженных рингтонов через MiHome начинается с 10001 {% elif trigger.to_state.state == ‘off’ %} 10004 {% else %} {% endif %} gw_mac: МАК_АДРЕС_ШЛЮЗА ringtone_vol: 40 # громкость с которой будет воспроизводиться рингтон

Итак, зачем все так сложно ? 

Создавая это я столкнулся со следующими проблемами. Автоматизация Alarm Status Sound конфликтовала с автоматизацией Motion Detection когда использовалось штатное решение отработки по состоянию приведенное ниже: 

script: msg_who_is_home: sequence: — service: notify.notify data_template: message: &amp;amp;amp;amp;amp;amp;amp;amp;gt; # и вот эта вот гадина is_state отрабатывала при любом событии которое # происходило при любой автоматизации в системе # и брякало звуками и действиями {% if is_state(‘device_tracker.paulus’, ‘home’) %} Ha, Paulus is home! {% else %} Paulus is at {{ states(‘device_tracker.paulus’) }}. {% endif %}

и так как файл автоматизаций отрабатывает последовательно все что в нем написано, то в моем случае сначала начиналась сработка сирены по датчику движения, а потом система видела что статус сигнализации находится в режиме ‘On’ и начинала последовательность прописанную в автоматизации ‘Alarm Status Sound’ назначенную для сигнализации в режиме ‘On’ и сигнализация прекращала орать и проигрывала звук включения сигнализации…. ну вы понимаете….

Именно поэтому в данной конфигурации ‘Alarm Status Sound’ срабатывает только при изменении состояния автоматизации ‘Motion Detection’.

Ну а то, что происходит при срабатывании самой сигнализации прописано в файле scripts.yaml и довольно скучно на фоне написанного ранее:

alarm_sequence: alias: «Действия при сработке сигнализации» sequence: — service: tts.amazon_polly_say entity_id: media_player.mpd data: message: ‘Куда ты полез мохнатая наглая сука?!’ — delay: 00:00:03 — service: xiaomi_aqara.play_ringtone data: gw_mac: МАК_АДРЕС_ШЛЮЗА ringtone_id: 6 ringtone_vol: 8 — delay: 00:00:05 — service: xiaomi_aqara.play_ringtone data: gw_mac: МАК_АДРЕС_ШЛЮЗА ringtone_id: 5 ringtone_vol: 8

Зачем нужны задержки ? Потому что автоматизация не получает от перечисленных исполнительных устройств обратной связи о завершении проигрывания текста или звука. И запускает все одновременно. 

Без задержек получается что Текст проигрывается одновременно с последним указанным рингтоном шлюза, так как на шлюз пришли сразу две одинаковых команды и он выполняет последнюю. И получается каша.

Что если тогда?

Что за набор букв и символов, подумаете вы:

{% if is_state('sun.sun', 'below_horizon') and is_state('light.living_room', 'off') %} 1
{% else %} 100
{% endif %}

На самом деле тут все просто. 

• {% %} этими фигурными скобками мы обозначаем, что начинаем использовать шаблон
• if это, как можно понять с перевода на русский язык, использование логического «если»
• is_state(‘sun.sun’, ‘below_horizon’) тут мы проверяем состояние устройства sun.sun (да есть и такое!), а точнее что оно равно below_horizon то есть «за горизонтом»
• and а это у нас логическое «и», указывающее что должны выполняться первое условие и второе:
• is_state(‘light.living_room’, ‘off’) где мы проверяем, какое значение у устройства light.living_room и в нашем случае оно должно быть off или «выключено»

Ну ладно не просто, но и ничего сложного в этом нет.) 

Бэкапы

В бэкап попадает весь каталог /config, а также все установленные расширения. С любого бекапа можно восстановить состояние системы на момент его создания.

Можно настроить создание резервных копий в Google Drive:

1. Скопировать ссылку https://github.com/sabeechen/hassio-google-drive-backup и зайти в HA (также можно прочитать подробную инструкцию в ReadMe репозитория по ссылке)
2. Добавить ссылку как кастомный репозиторий в Supervisor’е через UI.

   

3. Открыть его (Open Web UI) и следовать инструкциям по аутентификации с Google Drive

После этих манипуляций мы получаем регулярное создание бекапов, важность которых сложно переоценить.

Проверка на вшивость

После всех правок файла с автоматизациями можно очень просто их проверить. Для начала заходим в веб морде HA в «Настройки» — «Общие» — «Проверить конфигурацию», и если ошибок в конфиге нет — жмем на кнопку «Перезагрузить автоматизации»: 

Далее идем на страничку с entity_id как мы делали немного выше, находим там нашу автоматизацию в списке и жмем на кнопку слева от нее, после чего жмем на кнопку «Запуск»:

Если все сделали правильно — автоматизация сработает и вы это увидите. Ура! У вас получилось!

Подключаем файл automations. yaml

Изначально все необходимые действия с настройками и добавлением устройств, автоматизаций, групп и прочего можно делать в стандартном файле конфигурации configuration.yaml, но для удобства, мы будем делать все действия с автоматизациями в файле automations.yaml. Для начала подключаемся к малине по ssh, идем в настройки HA:

cd /home/homeassistant/.homeassistant/
sudo nano configuration.yaml

Ищем в конфиге следующую строчку, написана она должна быть именно так, без знака # перед ней:

automation: !include automations.yaml

Если строчки по какой-то причине нет — добавляем ее, но так может быть только, если вы ее зачем-то сами удалили. Сохраняем файл и выходим из редактора. После можно уже открыть файл с автоматизациями и приступить к ее наполнению:

sudo nano automations.yaml

sudo nano automations.yaml

ESP

Так как умного градусника у меня нет, а температуру измерять хочется, воспользуемся ESP8266.
Сначала установим интеграцию ESPHome из официального списка интеграций.

Для каждого микроконтроллера, используемого в системе, требуется создать файл с подобным содержанием.

esphome: name: home_params platform: ESP8266 board: nodemcuv2
logger:
api:
ota:

Подключимся к WiFi

wifi: ssid: !secret xiaomi_router_ssid password: !secret xiaomi_router_password

По умолчанию используются секреты только от ESPHome. А для того, чтобы подгрузить секреты из HA, можно создать отдельный файл, где мы заинклудим эти секреты.

Теперь подключим data pin (обычно это средняя нога) термометра к D2 порту, дадим на него питание и землю. Потом создаём сам термометр (DHT11) и две переменные, которые будем отслеживать в HA.

sensor: - platform: dht model: DHT11 pin: D2 temperature: name: "Living Room Temperature" humidity: name: "Living Room Humidity" update_interval: 60s

Если все заработало, то в Developer Tools мы увидим созданные переменные.

Освещение

Теперь, когда мы умеем отслеживать пользователя, мы можем включать и выключать определенные лампочки с учетом информации о его местоположении.

Для этого необходимо произвести действие по определенному событию. В этом нам помогут автоматизации.

- alias: Entering home trigger: platform: state to: home entity_id: device_tracker.mi9lite action: - service: light.turn_on data: entity_id: light.midesklamp1s_f86f brightness: 35 color_temp: 350
- alias: Leaving home trigger: platform: state to: not_home entity_id: device_tracker.mi9lite action: - service: light.turn_off entity_id: light.midesklamp1s_f86f

Теперь импортируем в наш основной файл весь каталог automation — так нам будет удобнее при написании следующих автоматизаций.

automation: !include_dir_merge_list automation

Для того, чтобы получить адаптивное освещение в зависимости от времени суток, нужно настроить цветовую температуру. Это удобно сделать внутри блока switch. Тут важно понимать, что пока данный switch включен, изменить параметры температуры будет невозможно (через interval минус время_с_прошлого_обновления лампа примет старые параметры).

Здесь вы найдете больше про динамическую цветовую температуру (flux в терминологии HA). А если вам интересна тема адаптивного освещения, на Хабре есть отличная статья по этому поводу.

switch: - platform: flux lights: - light.midesklamp1s_f86f name: Fluxer start_time: '9:00' stop_time: '0:00' start_colortemp: 5000 sunset_colortemp: 3200 stop_colortemp: 2800 brightness: 25.5 disable_brightness_adjust: true # яркость будет константой mode: mired # для не rgb ламп transition: 30 interval: 30```
<!--</spoiler>-->
# Погода
По умолчанию в HA уже присутствует интеграция с погодным API от [Meteorologisk institutt](https://www.home-assistant.io/integrations/met/) (Норвежский метеорологический институт), но мы можем легко создать другую прямо через UI.
## Создание новой интеграции OpenWeatherMap
Переходим в config / Integration на UI , нажимаем на Add integration, и выбираем из списка OpenWeatherMap.
![](https://habrastorage.org/webt/wk/q5/gu/wkq5guripld3x0rlvuuvrh6us-8.png)
Вводим api_key, полученный на их сайте и нажимаем Submit. В итоге получим 19 сущностей, которые можем использовать для своих целей в автоматизациях.
![](https://habrastorage.org/webt/l1/dj/ps/l1djps20zhxaghdhbfrxzcm7tac.png)
*Сущности OWM (на скриншот попали не все 19)*
Таким же образом через UI можно создать интеграции к другим сервисам вроде SpeedTest, или OpenUV.
# Уведомления
Для настройки уведомлений можно использовать стандартные оповещения HA, отображаемые в боковом меню, уведомления на конкретных устройствах (нужно установленное приложение на девайсе), а также оповещения в сторонние сервисы.
![](https://habrastorage.org/webt/vw/lo/uk/vwloukneshhkvd6sklfjojnsvrc.png)
*persistent_notification*
Альтернативный способ уведомлений - это уведомления в сторонние сервисы, например Telegram. Для начала нужно создать бота, получить его api_key (при создании отправят ключ) и chat_id, который можно найти в ответе внутри `result.chat.id` после запроса на https://api.telegram.org/bot{api_key}/getUpdates .
<!--<spoiler title="Ответ с Telegram API приходит пустой">-->
Такое иногда случается по разным причинам.
В таких случаях подходит другой способ получения chat_id - написать @getmyid_bot боту и скопировать себе user ID.
<br>
![](https://habrastorage.org/webt/h_/em/a_/h_ema_sk04ldd4xsfkdzdthaml4.png)
<!--</spoiler>-->
Простейшая настройка Telegram бота:
<!--<spoiler title="notification/telegram_bot.yaml">-->

• platform: polling
  api_key: !secret telegram_api
  allowed_chat_ids:
  • !secret telegram_chat_id

Для того, чтобы не разглашать всем секретные данные, создадим еще secrets.yaml. Туда мы сложим все данные, которые не должны попасть в публичный доступ. Для использования переменных из этого файла используем !secret.

telegram_api: %api_key%
telegram_chat_id: %chat_id%

telegram_bot: !include notification/telegram_bot.yaml

В итоге у нас имеется Telegram бот, готовый к отправке сообщений.

Вместо послесловия

Мы в данной статье рассмотрели только крохотную толику разных типов автоматизаций и приводить все их мне просто не хочется, дабы не перегружать и без того сложноватую статью. Если будет интерес, я напишу отдельную, где поделюсь остальными своими примерами без такого подробного разжевывания и пояснения, но с комментариями. Спасибо всем за внимание!

С помощью GPS

• Точность работы сравнима с GPS трекером в телефоне.
• О телефоне можно узнать: процент заряда аккумулятора, заряжается устройство или нет, а также показатель состояния аккумулятора.

  

• Можно контролировать устройства (пользователей) не только на вход домой, но и на вход в любую из кастомных зон.

• Активно тратит заряд.
• Требует подключение Интернета.
• Для точного трекинга необходимо настроить SSL, чтобы телефон мог отправлять данные о местоположении из вне локальной сети.
• Требует дополнительных прав доступа к GPS, возможна утечка данных третьей стороне в будущем.
• На бюджетных телефонах, которые имеют свойство неожиданно менять местоположение GPS, возможны проблемы с выпадением из зоны.

Утренние (или нет) погодные оповещения

Теперь, когда у нас есть настроенный сервис уведомлений и погодная интеграция, мы можем сделать утренние оповещения о погоде.

Создаем новый файл автоматизации, и начинаем писать логику.

Пишем переменную, которая будет отвечать за срабатывание оповещений только по будням. Если он true — то в выходные оповещений не будет.

alarmweekday: name: Weekdays Only initial: off icon: mdi:calendar

И подключаем в основном конфиг файле.

input_boolean: !include input_boolean.yaml

- alias: 'Wake Me Up' trigger: platform: time at: input_datetime.weather_notification condition: condition: or conditions: - condition: and conditions: - condition: state entity_id: input_boolean.alarmweekday # оповещение в выходные state: 'on' - condition: time weekday: - mon - tue - wed - thu - fri - condition: and conditions: - condition: state entity_id: input_boolean.alarmweekday state: 'off' action: service: telegram_bot.send_message data: # тут message: "{% if now().strftime('%H')|int < 7 %} Доброй ночи, {% elif now().strftime('%H')|int < 12 %} Доброе утро, {% elif now().strftime('%H')|int < 18 %} Хорошего дня, {% else %} Хорошего вечера, {% endif %} сейчас на улице {{states('sensor.openweathermap_temperature')}}°C. "

Установка

Установка HA предельно проста:

1. Записать образ HA на SD карточку (подробная инструкция с ссылками на скачивание для разных версий Raspberry Pi тут).
2. Подключить питание и Ethernet к малинке
3. Подождать несколько минут, пока система развернется в локальной сети на <ip адрес малинки>:8123.

Также можно установить на уже имеющуюся систему с помощью Docker-compose:

version: '3'
services: homeassistant: container_name: homeassistant image: homeassistant/raspberrypi4-homeassistant:stable volumes: - /PATH_TO_YOUR_CONFIG:/config - /etc/localtime:/etc/localtime:ro restart: unless-stopped network_mode: host

А теперь разберем несколько сценариев использования.

Заключение

• Простая установка и настройка, не требующая знания программирования.
• Большое коммьюнити — вопросов на форуме много, ответов тоже хватает.
• Огромное количество готовых интеграций со сторонними сервисами — скорее всего не придется писать свою интеграцию руками.

• Достаточно сложно отлаживать систему. Если action можно запустить программно в обход триггера, то триггер тестировать уже сложнее.

В итоге мы создали несложную систему умного дома, которую каждый может расширить покупкой новых устройств или написанием своих продуманных и продвинутых автоматизаций. По этой ссылке можно найти полную версию моих автоматизаций дома.

Что дальше? Можно добавить HACS (сборник UI компонентов и даже целых интеграций от коммьюнити, пригодится при использовании Яндекс Станции) и установить несколько UI элементов. Можно интегрировать умную колонку или телевизор и включать их по определенному условию. Вариантов апгрейда бесконечное множество.

Успехов в автоматизации!

Выводы

Все это делалось не только для того, чтобы одна мохнатая морда получила предынфарктное состояние при попытке залезть на подоконник или стол. 

Данный пример показывает вариации автоматизаций с использованием различных совмещенных параметров отслеживания состояний различных автоматизаций и датчиков, и аккумулирует найденные мной примеры конфигурации в некий набор шаблонов, которые можно будет в дальнейшем использовать для автоматизации процессов в доме.

Итоговая реализация

Используются следующие элементы системы Home Assistant:

• Автоматизации
• Скрипты
• Кастомизация

Литература