home assistant сценарии и скрипты

Script Syntax

Scripts are a sequence of actions that Home Assistant will execute. Scripts are available as an entity through the standalone Script component but can also be embedded in automations and Alexa/Amazon Echo configurations.

When the script is executed within an automation the trigger variable is available. See Available-Trigger-Data.

The script syntax basic structure is a list of key/value maps that contain actions. If a script contains only 1 action, the wrapping list can be omitted.

Call a Service

The most important one is the action to call a service. This can be done in various ways. For all the different possibilities, have a look at the service calls page.

Activate a Scene

Scripts may also use a shortcut syntax for activating scenes instead of calling the scene.turn_on service.

Variables

The variables action allows you to set/override variables that will be accessible by templates in actions after it. See also script variables for how to define variables accessible in the entire script.

Test a Condition

The condition action only stops executing the current sequence block. When it is used inside a repeat action, only the current iteration of the repeat loop will stop. When it is used inside a choose action, only the actions within that choose will stop.

Delay

Delays are useful for temporarily suspending your script and start it at a later moment. We support different syntaxes for a delay as shown below.

All forms accept templates.

These actions allow a script to wait for entities in the system to be in a certain state as specified by a template, or some event to happen as expressed by one or more triggers.

Wait Template

This action evaluates the template, and if true, the script will continue. If not, then it will wait until it is true.

The template is re-evaluated whenever an entity ID that it references changes state. If you use non-deterministic functions like now() in the template it will not be continuously re-evaluated, but only when an entity ID that is referenced is changed. If you need to periodically re-evaluate the template, reference a sensor from the Time and Date component that will update minutely or daily.

Wait for Trigger

This action can use the same triggers that are available in an automation’s trigger section. See Automation Trigger. The script will continue whenever any of the triggers fires. All previously defined trigger_variables, variables and script variables are passed to the trigger.

Wait Timeout

Wait Variable

After each time a wait completes, either because the condition was met, the event happened, or the timeout expired, the variable wait will be created/updated to indicate the result.

This can be used to take different actions based on whether or not the condition was met, or to use more than one wait sequentially while implementing a single timeout overall.

Fire an Event

This action allows you to fire an event. Events can be used for many things. It could trigger an automation or indicate to another integration that something is happening. For instance, in the below example it is used to create an entry in the logbook.

You can also use event_data to fire an event with custom data. This could be used to pass data to another script awaiting an event trigger.

The event_data accepts templates.

Raise and Consume Custom Events

The following automation example shows how to raise a custom event called event_light_state_changed with entity_id as the event data. The action part could be inside a script or an automation.

The following automation example shows how to capture the custom event event_light_state_changed with an Event Automation Trigger, and retrieve corresponding entity_id that was passed as the event trigger data, see Available-Trigger-Data for more details.

Repeat a Group of Actions

This action allows you to repeat a sequence of other actions. Nesting is fully supported. There are three ways to control how many times the sequence will be run.

Counted Repeat

This form accepts a count value. The value may be specified by a template, in which case the template is rendered when the repeat step is reached.

While Loop

This form accepts a list of conditions (see conditions page for available options) that are evaluated before each time the sequence is run. The sequence will be run as long as the condition(s) evaluate to true.

Repeat Until

This form accepts a list of conditions that are evaluated after each time the sequence is run. Therefore the sequence will always run at least once. The sequence will be run until the condition(s) evaluate to true.

Repeat Loop Variable

Choose a Group of Actions

This action allows you to select a sequence of other actions from a list of sequences. Nesting is fully supported.

Each sequence is paired with a list of conditions. (See the conditions page for available options and how multiple conditions are handled.) The first sequence whose conditions are all true will be run. An optional default sequence can be included which will be run only if none of the sequences from the list are run.

An optional alias can be added to each of the sequences, excluding the default sequence.

The choose action can be used like an “if” statement. The first conditions / sequence pair is like the “if/then”, and can be used just by itself. Or additional pairs can be added, each of which is like an “elif/then”. And lastly, a default can be added, which would be like the “else.”

More choose can be used together. This is the case of an IF-IF.

The following example shows how a single automation can control entities that aren’t related to each other but have in common the same trigger.

When the sun goes below the horizon, the porch and garden lights must turn on. If someone is watching the TV in the living room, there is a high chance that someone is in that room, therefore the living room lights have to turn on too. The same concept applies to the studio room.

Источник

Scripts

The script integration allows users to specify a sequence of actions to be executed by Home Assistant. These are run when you turn the script on. The script integration will create an entity for each script and allow them to be controlled via services.

Configuration

The sequence of actions is specified using the Home Assistant Script Syntax.

Configuration Variables

Friendly name for the script.

Icon for the script.

A description of the script that will be displayed in the Services tab under Developer Tools.

Variables that will be available inside your templates

The value of the variable. Any YAML is valid. Templates can also be used to pass a value to the variable.

Information about the script field parameters; see the Passing variables to scripts section below. Please note: In order for this description to be displayed in the Services tab of the Developer Tools, the script description must be defined as well.

A parameter field used by this script. All sub-options are only used for creating a representation of this script in the UI.

The name of this script parameter field.

A description of this of this script parameter.

Marks this field as an advanced parameter. This causes it only to be shown in the UI, when the user has advanced mode enabled.

Mark if this field is required. This is a UI only feature.

An example value. This will only be shown in table of options available in the Services tab of the Developer Tools.

The default value for this field, as shown in the UI.

The selector to use for this input. A selector defines how the input is displayed in the frontend UI.

Controls what happens when script is invoked while it is still running from one or more previous invocations. See Script Modes.

When max is exceeded (which is effectively 1 for single mode) a log message will be emitted to indicate this has happened. This option controls the severity level of that log message. See Log Levels for a list of valid options. Or silent may be specified to suppress the message from being emitted.

The sequence of actions to be performed in the script.

Script Modes

Full Configuration

Passing variables to scripts

As part of the service, variables can be passed along to a script so they become available within templates in that script.

There are two ways to achieve this. One way is using the generic script.turn_on service. To pass variables to the script with this service, call it with the desired variables:

The other way is calling the script as a service directly. In this case, all service data will be made available as variables. If we apply this approach on the script above, it would look like this:

Using the variables in the script requires the use of templates:

Script variables that may be used by templates include those provided from the configuration, those that are passed when started from a service and the this variable whose value is a dictionary of the current script’s state.

Waiting for Script to Complete

When calling a script “directly” (e.g., script.NAME ) the calling script will wait for the called script to finish. If any errors occur that cause the called script to abort, the calling script will be aborted as well.

When calling a script (or multiple scripts) via the script.turn_on service the calling script does not wait. It starts the scripts, in the order listed, and continues as soon as the last script is started. Any errors that occur in the called scripts that cause them to abort will not affect the calling script.

Источник

Home Assistant, статья 5 (автоматизации)

Введение

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

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

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

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

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

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

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

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

Trigger. В данном примере тригером является определенное значение времени, а именно 6:30 утра. Именно во столько должна сработать автоматизация

Condition. Условием выполнения автоматизации является проверка значения группы devices. Оно может принимать значение home или not_home.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как всегда великолепнейший материал 😉 твой верный подписчик очень доволен ))))

статья понравилась.Все доступно описано. Спасибо)

Спасибо! Отличный материал, мотивирует настроить ХА у себя 🙂

ОХОТНИК молодца! Своими статьями про Home Assistant мотивирует изучать УД с лёгким входом в тему!

Ну очень доходчиво объяснил, я аж уже захотел себе ХА поставить. Буду ждать дальнейших статей.

Спасибо за статью Александр! По прочтению у меня появился ряд вопросов:

Устройство сценариев понятно: триггер, условие и действие, оно довольно стандартно. Но мне не понятно, где я могу посмотреть все возможные «platform» для триггера, где посмотреть значения «to» у срабатываемых датчиков, там же может быть не «off/on» а например «true/false» или что либо еще? Вообще где можно посмотреть какие параметры есть у того или иного датчика, например, если взять ваш код, откуда вы взяли название параметра «brightness_pct»? Тот же вопрос про «- service: light.turn_on» и «- service: climate.set_temperature» откуда берутся эти обьекты? Автоматически прописываются при привязке того или иного устройства, или подобные категории устройств надо создавать самому? И где вообще посмотреть какие «service» доступны в моем HA?

Александр, здравствуйте, у меня есть кубик от сяоми, который определился как binary_sensor.cube, но его нет в выпадающем меню. На офф сайте ХА в разделе Integrations вообще нет поддержки сяоми. Объясните, пожалуйста, как с этим работать?

Особо не пинайте, я тут новенький во всем. Вопрос вот в чем, есть HA и выключатель aqara, могу ли я задать чтобы свет загорался только на «n» процентов и можно ли это сделать с обычными лампами или нужны какие то особые?

Светильник должен быть с диммированием(регулировкой).

На самом деле проблема в том, что датчик движения отваливается. После перезагрузки НА датчик срабатывает один-два раза и больше не меняет значение «off» на «on». Хотя в родном приложении сценарии отрабатывает. У кого нибудь отваливались датчики от НА? не могу понять, в чем проблема!

Не пойму зачем делать всё это в линуксе, когда в HA есть раздел автоматизации?

Источник

Первое знакомство с Home Assistant

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.

После этого на http://localhost:8123 станет доступнен графичекий интерфейс HA. При первом входе потребуется создать аккаунт пользователя. Веб-интерфейс HA довольно объемен. Пара важных элементов, о которых стоит упомянуть в самом начале, это закладка Configuration → General, где вы легко можете перезагрузить файлы конфигурации или сам сервер. А также страница Info в списке Developers tools, где можно посмотреть логи ошибок.

Все необходимые пользователю данные HA хранит, в случае линукс, в папке настроек “

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

Этих знаний для установки нового модуля нам должно быть достаточно. Копируем с репозитория папку “xiaomi_cooker” в нашу “

/.homeassistant/custom_components”. Согласно описанию, добавляем настройки модуля в файл “configuration.yaml”:

Готово. После перезагрузки HA в разделе General → Integrations веб-интерфейса появится запись о новом модуле.

Любой модуль представляет собой некоторый набор объектов (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

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

Templating

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

Python Scripts

/.homeassistant/python_scripts”, станут доступны в качестве сервисов с именами “python_scripts. ”. Их код выполняется в заранее заданном окружении, где переменные data и hass дают нам доступ к аргументам вызова сервиса, а также объектам и сервисам HA. В качестве примера приведем код файла “charge_set.py” для сервиса “python_scripts.charge_set”. Его функцией будет установка заряда нашей батарейки:

Creating integration

После этого сообщим о новом модуле файлу настроек “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. Первая будет служить для запуска нашей рисоварки, вторая – для отображения значения температуры:

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

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

/.homeassistant/www’ становятся доступными по ссылке http://localhost/local/filename.

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

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

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

Custom Cards

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

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

Notifications

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

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

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

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

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

Послесловие

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.

Источник