Home assistant не работает автоматизация

Автоматизации в Home Assistant

Home Assistant — это совершенно отличная штука чтобы делать «Умный дом». Можно подключить в HA разные устройства и создать удобный интерфейс для управления всеми этими устройствами.

Но кроме ручного управления устройствами Home Assistant позволяет создавать «Автоматизации» — действия выполняются автоматически при выполнении определенных условий.

Несколько примеров что можно сделать с помощью автоматизаций в Home Assistant:

  • Когда нет никого дома запускается робот пылесос
  • При открытии входной двери автоматически включается свет в коридоре
  • Ночник автоматически включается когда заходит солнце
  • В 7 утра по будням шторы автоматически открываются
  • Когда кто-то приезжает на дачу, а уже темно, то автоматически включается уличный свет

Но даже самое простое действие «нажали на кнопку — включили свет» в Home Assistant настраивается с помощью автоматизации.

Все устройства, которые подключены к Home Assistant могут выполнять свои действия по команде из автоматизаций.

Создание автоматизации

Существует два способа как можно создать или изменить автоматизацию:

  • использовать веб интерфейс http://IP:8123/config/automation
  • работать с текстовыми файлами конфигурации

Большинство людей, которых я знаю, пишут автоматизации в текстовых файлах и не используют веб интерфейс редактирования автоматизаций. Но вы сами смотрите, какой вариант работы с автоматизациями вам будет удобнее.

Редактирование файлов и использование графического интерфейса в итоге делает одно и то же. Главное понять идею — как работают автоматизации, а способ как настраивать автоматизации не очень важен.

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

В Home Assistant есть главный файл с настройками системы — файл /config/configuration.yaml Вполне возможно записывать все настройки HA только в этот файл и не использовать другие файлы. Но файл configuration.yaml который создается при первом запуске Home Assistant предлагает создавать автоматизации в отдельном файле. В файле /config/configuration.yaml есть вот такой фрагмент:

Этот кусок конфига говорит что автоматизации нужно брать из файла /config/automations.yaml

И для начала это прекрасное решение. В рамках этого текста мы будет редактировать только один файл — /config/automations.yaml

(Вообще есть несколько разных способов как удобно разбивать конфигурационный файл на разные файлы, но этот текст не об этом, а про автоматизации)

Включение «Advanced Mode»

Перед тем как продолжать, нужно выполнить одну настройку.

Нужно зайти на страницу http://IP:8123/profile и установить там галку «Advanced Mode»:

Эта галка влияет на то что отображается на странице http://IP:8123/config/server_control

Если галки нет (состояние по умолчанию), то на странице есть только кнопки перезапустить и остановить:

Но если поставить галку, то на странице появятся дополнительные действия, которые упростят и ускорят работу:

Первая автоматизация

Вот пример самый простой автоматизации. В файл /config/automations.yaml нужно записать:

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

Для этого нужно зайти на страницу http://IP:8123/config/server_control и нажать на кнопку «Check Configuration». Должен появиться текст «Configuration valid!»:

А после этого нужно нажать на кнопку «Reload automations»:

(если на этой странице вы не видите кнопок «Check Configuration» и «Reload automations», то нужно включить «Advanced Mode» как описано в предыдущем разделе)

Поздравляю! Вы создали свою первую автоматизацию. Это исключительно простая автоматизация. И она очень скучная: она ничего не делает, но это настоящая автоматизация в HA.

Каждый раз после изменения yaml файлов в которых описаны автоматизации нужно заходить на эту страницу и нажимать кнопки «Check Configuration» и «Reload automations».

Исследование автоматизации

То что добавили мы в конфиг создало автоматизацию «automation.first». Можно добавить ее в интерфейс:

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

Если кликнуть по названию, то становятся видно когда эта автоматизация последний раз запускалась (в нашем случае она еще ни разу не запускалась), плюс появляется кнопка Execute с помощью которой можно руками запустить эту автоматизацию (это бывает нужно достаточно редко):

На странице Developer Tools -> States http://IP:8123/developer-tools/state можно посмотреть на внутреннее представление этой сущности:

Проблемы при создании автоматизации

Прямо сейчас у нас есть одна корректная автоматизаци. Давайте попробуем отредактировать эту автоматизацию, написать неправильно и посмотреть что будет. Удаляем все что есть в файле /config/automations.yaml и записываем в него только одну строчку:

Заходим на страницу http://IP:8123/config/server_control и нажимаем на кнопку «Check Configuration». Появляется ошибка:

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

Эта два элемента «trigger» и «action» являются обязательными. Их всегда нужно записывать в автоматизации. Но мы когда создали автоматизаци еще указывали «condition».

Возвращаем обратно правильный вариант автоматизации, нажимаем кнопки «Check Configuration» и «Reload automations».

Читайте также:  Погружной насос ручеек не работает

Структура автоматизации

Автоматизация состоит из трех элементов:

  • «trigger» — описывает условие когда автоматизация должна запуститься
  • «condition» — описывает дополнительные условия которые должны быть чтобы автоматизация выполнила свое действие
  • «action» — главное зачем создается автоматизация — выполнение действия

Очень часто автоматизация состоит из trigger и action. Происходит какое-то событие на которое настроен trigger и выполняется то что написано в action. Раздел «condition» тоже часто используется, но есть не всегда.

Редко, но бывают но бывают автоматизации которые состоят только из одного action (trigger и condition пустые). Автоматизация только из action бывает нужна чтобы сделать кнопку в интерфейсе по нажатию на которое выполняется все действия из автоматизации.

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

Action

То что описывается в разделе «action» — это самое главное зачем вообще создается автоматизация. В этом разделе записывается какое действие нужно выполнить.

Например, это может быть:

  • включить свет в туалете
  • запустить робот пылесос
  • выключать вентилятор в ванной
  • запустить таймер на 10 минут
  • отправить сообщение в мессенджер

Давайте создадим новые автоматизации, которые управляют светом.

У меня в Home Assistant заведена настолько лампа Xiaomi. В HA она называется light.lamp.

Добавляем в файл /config/automations.yaml

Добавляем автоматизации в интерфейс:

Заходим в автоматизацию automation.light_bright и нажимаем на кнопку Execute:

Результат — свет включился на полную яркость. Заходим в автоматизацию automation.light_dim, нажимаем кнопку Execute — яркость света стала минимальная.

В веб интерфейсе Home Assistant есть инструмент Developer Tools -> Services http://IP:8123/developer-tools/service.

Очень удобно сначала отработать то что хочется запустить сначала в этом инструменте, а потом перенести получившиеся настройки в конфигурационный файл с автоматизациями. То что выбрано в интерфейсе в ниспадающем списке Services нужно записать после «services:», а то что находится в «Service Data» нужно разместить после «data:». (то что записано в поле Entity никуда переносить не нужно, так как это же информация содержится в поле «Service Data»).

Иногда хочется выполнить несколько действий в одной автоматизации. Вот пример. При выполнении этой автоматизации сначала включается лампа light.lamp, а после нее тут же включается light.led:

Можно указать более чем два действия.

Иногда хочется сделать несколько действий, но с паузой между ними. Вот пример:

При выполнении этой автоматизации сначала включается light.lamp, а через 5 секунд включается light.led.

Строка «- delay: 00:00:05» говорит HA что нужно сделать паузу в 5 секунд. (Текст с рассказом про разные форматы времени в HA).

Значение action можно записывать в двух форматах. Полная форма, указывается service, а все данные указываются в data:

Но когда в data есть только entity_id, то удобнее использовать сокращенную форму. В этом случае data не нужна, entity_id указывается на том же уровне что и service:

И в том случае если в action выполняется только одно действие, можно записывать без использования массива:

Trigger

В разделе trigger описывается что должно произойти что чтобы запустилась автоматизация.

Несколько примеров что может являться триггером:

  • Зашло солнце
  • Нажали на кнопку
  • Влажность в ванной стала больше 50%
  • Сенсор движения зафиксировал движение
  • Таймер закончил работу
  • Наступило 7 часов вечера

Вот пример автоматизации которая включает свет по нажатии кнопку (свет включен — нажатие кнопки его выключит, свет выключен — включает):

А вот как включить вентилятор в ванной когда влажность стала больше 50%:

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

В trigger обязательно указывается platform. В зависимости от того какая платформа указана триггер запускает автоматизацию на разные действия. В предыдущих примерах мы использовали две разные platform:

  • state — происходит выполнение при изменении статуса сущности в Home Assistant
  • numeric_state — выполнение происходит для числовой сущности при достижении нужного значения

Есть еще много других platform, вот некоторые из них:

  • event — при возникновении события
  • time — запуск в точное время (например в 19:10:00)
  • time_pattern — регулярный запуск (например, каждые 5 минут)
  • template — возможность описать условие запуска автоматизации с помощью шаблонов
  • mqtt — при возникновении определенных записей в MQTT сервере
  • sun — в зависимости от положения солнца на небе
  • homeassistant — запускается при запуске или перезагрузке Home Assistant

Вот пример как можно автоматически включать свет когда зашло солнце:

В данной автоматизации в триггере используется платформа state. Свет включается когда статус сущности «sun.sun» стал «below_horizon». Можно сделать автоматизацию которая делает то же самое с помощью платформы «sun»:

А можно просто сказать Home Assistant чтобы он включал свет в 7 часов вечера:

Лучше привязывать включение света не к определенному времени, а к положению солнца, так как в разные дни темно становится в разное время. Платформе sun можно указать что нужно запускать автоматизацию за какое-то количество минут до заката. Вот как включать свет за 10 минут до заката:

Но еще лучше установить специальный датчик освещенности и включать свет по данным с него.

В разделе trigger можно указать несколько разных триггеров. Автоматизация запустится при выполнении любого из них. Вот автоматизация которая всегда включает вентилятор в ванной комнате ночью или если влажность в ванной комнате больше 50%:

condition

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

Читайте также:  Можно ли настроить принтер без компьютера

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

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

Эта автоматизация запускается когда кто-то приехал на дачу (сенсор binary_sensor.somebody_at_dacha переходит в статус ‘on’), плюс эта автоматизация запускается каждые 5 минут.

В condition проверяем что уличный свет выключен и что солнце низко. Только если оба эти условия совпадают, то включается уличный свет.

Источник

Сказ о том, как я Home Assistant настраивал

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 для замеров ультрафиолетового излучения и др.

Установка

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

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

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

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

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

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

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

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

С помощью Xiaomi Router Mi4A

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

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

С помощью GPS

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

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

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

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


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

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

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

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

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


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

    Освещение

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

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

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

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

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

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

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

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

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

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

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

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

    Добавим blueprints

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

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

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

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

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

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

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

    Бэкапы

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

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

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

  • Открыть его (Open Web UI) и следовать инструкциям по аутентификации с Google Drive
  • После этих манипуляций мы получаем регулярное создание бекапов, важность которых сложно переоценить.


    NodeMCU

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

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

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

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

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

    Дальше нужно скомпилировать прошивку и загрузить на контроллер. Если он подключен напрямую к Raspberry Pi, то мы увидим его на /dev/ttyUSB0 и сможем загрузить прошивку в первый раз. Все последующие обновления можно загружать по воздуху. А если в списке устройства не видно, то можно скачать прошивку и воспользоваться ESPHome-Flasher.

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

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

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

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

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

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

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

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

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


    Заключение

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

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

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


    Главный экран

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

    Источник

    Оцените статью