Home Assistant: немного о шаблонах – Simple HA

Home assistant trigger

Use this platform to trigger when Home Assistant starts up and shuts down.

Hours, minutes, seconds

Триггеру обязательно нужно указать либо hours, либо minutes, либо seconds.
Если ничего из этого не указать, то будет ошибка:

Можно одноврменно указать любой набор параметров, например два:

Или сразу все 3:

Mqtt trigger

Triggers when a specific message is received on given topic. Optionally can match on the payload being sent over the topic.

Multiple triggers

When your want your automation rule to have multiple triggers, just prefix the first line of each trigger with a dash (-) and indent the next lines accordingly. Whenever one of the triggers fires, your rule is executed.

Numeric state trigger

On state change of a specified entity, attempts to parse the state as a number and triggers if value is above and/or below a threshold.

Listing above and below together means the numeric_state has to be between the two values.
In the example above, a numeric_state that is 17.1-24.9 would fire this trigger.

Session_replication_role

Читаем

На механизм срабатывания триггеров также влияет конфигурационная переменная session_replication_role. Включённые без дополнительных указаний (по умолчанию) триггеры будут срабатывать, когда роль репликации — «origin» (по умолчанию) или «local». Триггеры, включённые указанием ENABLE REPLICA, будут срабатывать, только если текущий режим сеанса — «replica», а триггеры, включённые указанием ENABLE ALWAYS, будут срабатывать независимо от текущего режима репликации.

Особо подчеркну, что настройка относится к не ко всем-всем сразу, как

ALTER TABLE

, а только к нашему отдельному спец-коннекту. Итого, чтобы не срабатывали никакие прикладные триггеры:

SET session_replication_role = replica; -- выключили триггеры
UPDATE ...;
SET session_replication_role = DEFAULT; -- вернули в исходное состояние

State trigger

Triggers when the state of tracked entities change. If only entity_id given will match all state changes, even if only state attributes change.

Use quotes around your values for from and to to avoid the YAML parser interpreting values as booleans.

Sun trigger

Trigger when the sun is setting or rising. An optional time offset can be given to have it trigger for example 45 minutes before sunset, when dusk is setting in.

Sometimes you may want more granular control over an automation based on the elevation of the sun. This can be used to layer automations to occur as the sun lowers on the horizon or even after it is below the horizon. This is also useful when the “sunset” event is not dark enough outside and you would like the automation to run later at a precise solar angle instead of the time offset such as turning on exterior lighting.

The US Naval Observatory has a tool that will help you estimate what the solar angle will be at any specific time.

Switches

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

Time trigger

Time can be triggered in many ways. The most common is to specify at and trigger at a specific point in time each day. Alternatively, you can also match if the hour, minute or second of the current time has a specific value.

Zone trigger

Zone triggers can trigger when an entity is entering or leaving the zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the OwnTracks platform as well as the iCloud platform.

Давайте просто отключим триггеры!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

Собственно, тут и все —

все уже висит

Потому что ALTER TABLE накладывает AccessExclusive-блокировку, под которой никто параллельно выполняющийся, даже простой SELECT, ничего из таблицы прочитать не сможет. То есть пока эта транзакция не закончится, все желающие даже «просто почитать» будут ждать. А мы помним, что UPDATE у нас до-о-олгий…

Давайте тогда быстро отключим, потом быстро включим!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
COMMIT;

UPDATE ...;

BEGIN;
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

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

Значения

В качестве значений параметров hours, либо minutes, либо seconds можно использовать одну из трех вещей:

Коротко про синтаксис

Обратите внимание на оформление, в шаблонах могут использоваться строки с разным обрамлением:

По умолчанию, каждая строка шаблона на выходе будет оканчиваться символом новой строки «n».Причем даже те строки, которые ничего не выводят (например, объявление переменной — {% set a = 123 %}).

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

Помимо этого, стоит уделить время ресурсу yaml-multiline.info, на котором можно наглядно разобраться с вопросом форматирования и переноса строк в YAML’е (символы |, > и т.д.), это бывает полезно при форматировании многострочных шаблонов.

Отдельно стоит упомянуть о том, какие операторы можно использовать в шаблонах.Полную информацию об этом стоит искать в документации на jinja, а вкратце это:

Помимо этого, в выражениях можно использовать фильтры jinja и HA, передавая значения в них через символ «|».Пример: ((states(‘sensor.0x158d0003230618_pressure’) | float) / 1.333) | round(2)

Важные моменты в документации, на которые стоит обратить особое внимание:

— ~ —

Отсутствие значений

В зависимости от того что указано по разному определяются отсутствущие значения.
Логика: “If larger units are specified, default the smaller units to zero”

Параметр attribute

Триггеру state можно указать необязательный параметр attribute.

В том случае если указан параметр attribute, то автоматизация запустится только при
изменении значения этого атрибута у сущности. Вот пример. Есть сенсор sensor.tv,
у него есть атрибут channel — канал который сейчас работает. Вот автоматизация
которая запустится при изменении канала:

В том случае если в описании триггера указан параметр attribute, то параметры from/to
означают не стейт сущности, а значение атрибута. Вот автоматизация которая зпускается
только когда значение атрибута bin у сущности робота пылесоса становисят full:

Параметр entity_id

Триггеру state нужно обзязательно указать entity_id. Значнеие — это либо строка в
которой указана одна сущность (в этом случае
автоматизация запускается при изменении стейта или атрибутов указанной сущности):

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

Так же можно перечислить несколько сущностей и другим способом — через запятую:

Параметр for

Триггеру state можно указать необязательный параметр for.

Значение этого параметра — это период времени. Вот пример.
Эта автоматизация запустится когда стейт сенсора будет в состоянии “ringing”
в течении 5 секунд. Т.е. значение становится “rining” и через 5 секунд стреляет
автоматизация. Если стейт стал “ringing”, но через 4 секунды поменяся на “off”,
то автоматизаци не запустится.

Период времени можно указать как в виде строк ‘HH:MM’, ‘HH:MM:SS’, ‘HH:MM:SS.F’, либо с помощью:

Можно использовать следующие параметры:

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

В том случае если указаны to и for, то автоматизация запустится если сущность будет
находится в указанном статусе указанное время.

Если указаны from и for, то автоматизация запустится если сущность изменила свой статус
с from на какой-то другой и за указанный период времени не было возвращения в статус from.

Ели не указан ни from, ни to, но указан for то автоматизация запустится через for
времени после любого изменения (изменение атрибутов так же запускает автомтаизацию).

Если указан параметр attribute, то все работат так же, но вместо стейта сущности
в логие участвет указанный атрибут.

Параметры from и to

Триггеру state можно указать необязательные параметры from и to.

Значения параметров from и to всегда стоит писать в кавычках.

Если указано значение для параметра to, то автоматизация будет запускаться только если
произошло изменения стейта и новое значение стейта стало такое как указано в to:

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

Значения параметров from и to может быть либо строка, либо список строк.
В том случае если значение — это список, то автоматизация запустится только
если состояние стейта до/после изменения такое как перечислено в списке.

Можно одновременно указать указать оба параметра from и to.
В этом случае автоматизация запустится если произошло изменение стейта и до изменения
значение сущности было такое как указано в from, а стало такое как указано в to.

Переменная trigger

После того как триггер сработал в блоках condition и action становится доступна специальная переменная
с именем trigger. Вот пример что может находится в этой переменной:

{
    'platform': 'numeric_state',
    'entity_id': 'input_number.n1',
    'below': 20.0,
    'above': 10.0,
    'from_state': <state input_number.n1=5.0; initial=None, editable=False, min=0.0, max=100.0, step=0.1, mode=box @ 2021-06-08T11:19:24.225065 00:00>,
    'to_state': <state input_number.n1=11.0; initial=None, editable=False, min=0.0, max=100.0, step=0.1, mode=box @ 2021-06-08T11:19:34.431623 00:00>,
    'for': None,
    'description': 'numeric state of input_number.n1',
    'id': '0'
}

Пример

Вот пример автоматизации:

Это автоматизация будет запускаться каждые 5 минут. В 00:00:00 (0 часов, 0 минут, 0 секунд), 00:05:00 (0 часов, 5 минут, 0 секунд), 00:10:00, 00:15:00 и т.д.

Вот еще один пример:

Эта автоматизация будет запускаться 1 раз час. Автоматизация будет запускаться всегда когда минуты — это ровно число 5,
т.е.: 00:05:00, 01:05:00, 02:05:00, и т.д.

Сенсоры и их атрибуты

С помощью шаблонов можно создавать как бинарные (onoff), так и обычные сенсоры:

Скрипты и автоматизации

Самое широкое применение шаблоны встречают в скриптах и автоматизациях.

Скрипт для запуска уборки роботом-пылесосом конкретной комнаты (в интерфейсе input_select.room_to_vacuum это выпадающий список с комнатами):

Управление переменными сессии

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

Условие внутри триггера

Но приведенный выше вариант работает для всех триггеров сразу (или надо «альтерить» заранее триггеры, которые не хочется отключать). А если нам надо

«выключить» один конкретный триггер

В этом нам поможет «пользовательская» переменная сессии:

Имена параметров расширений записываются следующим образом: имя расширения, точка и затем собственно имя параметра, подобно полным именам объектов в SQL. Например: plpgsql.variable_conflict.
Так как внесистемные параметры могут быть установлены в процессах, не загружающих соответствующий модуль расширения, PostgreSQL принимает значения для любых имён с двумя компонентами.

Сначала дорабатываем триггер, примерно так:

BEGIN
    -- процессу конвертации можно делать все
    IF current_setting('mycfg.my_table_convert_process') = 'TRUE' THEN
        IF TG_OP IN ('INSERT', 'UPDATE') THEN
            RETURN NEW;
        ELSE
            RETURN OLD;
        END IF;
    END IF;
...

Кстати, это можно сделать «наживую», без блокировок, через

CREATE OR REPLACE

для триггерной функции. А потом в спец-коннекте взводим «свою» переменную:

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- вернули в исходное состояние

Знаете другие способы? Поделитесь в комментариях.