Покупка источника бесперебойного питания APC Back-UPS Pro Gaming BGM1500B была продиктована желанием защитить систему умного дома от кратковременных просадок напряжения. Сервер Home Assistant, работающий как виртуальная машина на базе Proxmox, вместе с сетевым оборудованием был подключен к ИБП для предотвращения повреждения данных. Однако практика показала, что бесперебойная работа самого «мозга» системы — это лишь часть проблемы, так как периферийные устройства, такие как розетки, лампы и хабы, остаются без электроснабжения при отключении сети.
Почему стандартные автоматизации перестают работать
Большинство пользователей настраивают автоматизации по принципу будильника: в заданное время или при наступлении определенного события система отправляет разовую команду. После этого Home Assistant считает задачу выполненной. Проблема возникает в тот момент, когда конечное устройство оказывается обесточенным или недоступным. ИБП не решает этот вопрос, так как Home Assistant не обладает встроенной памятью о действиях, которые должны были произойти во время отсутствия питания.
Временные триггеры, срок действия которых истек во время сбоя, не выполняются задним числом. Команды, отправленные на неработающее оборудование, завершаются с ошибкой без попыток повтора. Ситуация усугубляется перезагрузками сервера, так как стандартные параметры задержки и ожидания (delay и wait_for_trigger) не сохраняют состояние после перезапуска Home Assistant. Аналогично, облачные интеграции при отсутствии интернета могут уходить в бесконечный цикл попыток переподключения с интервалом до 10 минут, что требует ручного вмешательства.
Тестирование системы при имитации сбоя
Для анализа проблемы был проведен эксперимент с использованием лампы, подключенной через умную розетку Eve Energy с поддержкой протокола Matter. При отключении питания от розетки и последующем восстановлении выяснилось, что при стандартной настройке автоматизации (включение в 21:00) Home Assistant не предпринимает повторных попыток включения, если устройство в момент срабатывания было недоступно. Система «верит» в успешность выполнения команды до момента получения ошибки, после чего триггер считается отработанным.
Для повышения надежности необходимо пересмотреть подход к написанию сценариев. Вместо однократной команды автоматизация должна описывать желаемое состояние дома в текущий момент времени.
Как повысить отказоустойчивость автоматизаций
Главный урок заключается в создании гибких сценариев, которые проверяют актуальность действий после сбоя. В конфигурацию автоматизации следует добавить несколько триггеров: по расписанию, при запуске Home Assistant и при переходе устройства в статус доступности. При этом условия (conditions) должны ограничивать выполнение действия в заданном временном интервале.
Рекомендуемые шаги для повышения надежности:
- Использовать таймеры-помощники с параметром restore: true вместо долгих пауз.
- Настраивать поведение умных розеток при подаче питания (Power-on behavior) не на заводские значения, а осознанно.
- Подключать модемы, роутеры и коммутаторы к ИБП вместе с основным сервером для сохранения связности сети.
- Отдавать предпочтение локальным протоколам передачи данных, таким как Matter, Zigbee и ESPHome, чтобы минимизировать зависимость от облачных сервисов.
- Интегрировать Network UPS Tools для мониторинга состояния электросети и запуска процедур восстановления.
Хотя наличие ИБП критически важно для защиты сервера от сбоев, реальная устойчивость умного дома достигается за счет продуманной логики автоматизаций, способных самостоятельно проверять статус устройств после восстановления подачи электроэнергии.
Почему ИБП — это лишь начало
Важно понимать: даже имея 1500 ВА чистого синусоидального напряжения, вы защищаете только «мозг» системы. Сами по себе умные розетки и лампы, висящие на обычной настенной розетке, при отключении электричества теряют питание моментально. Проблема Home Assistant в том, что у него нет встроенной памяти о том, что именно он «планировал» сделать, пока устройства были недоступны. Даже если вы используете функции delay или wait_for_trigger, они не выживают после перезагрузки сервера или перезагрузки автоматизаций, что делает их крайне ненадежными в условиях нестабильного питания.
Разработчики Home Assistant официально подтверждают: параметр for: в триггерах не сохраняет свое состояние при перезапуске системы. Более того, в сообществе были прецеденты, когда ошибки в автоматизациях приводили к непредсказуемым последствиям — например, известна история с автоматизацией полива, которая из-за перезагрузки системы проработала два часа сверх нормы, затопив патио. Баг-репорт по этой проблеме был закрыт со статусом «not planned», поэтому единственный надежный путь — избегать написания автоматизаций, которые должны «помнить» что-то в течение долгого времени.
Особенности облачных интеграций
Облачные устройства добавляют еще один уровень уязвимости. Если ваш модем не защищен ИБП, то после подачи питания сервер Home Assistant может загрузиться быстрее, чем появится интернет. В таких случаях интеграции, которые связывают учетные записи через Home Assistant Cloud, могут начать аварийно завершаться. Они используют экспоненциальную систему повторных попыток (5 секунд, затем 10, 20 и так далее, до 10-минутного лимита). Без соответствующих патчей многие из этих 20+ облачных интеграций просто «зависают» в нерабочем состоянии до тех пор, пока вы не перезагрузите их вручную.
Детализация эксперимента: почему «забывчивость» критична
В ходе тестирования с лампой на Eve Energy (протокол Matter) выяснилось, что существует временной лаг, в течение которого Home Assistant считает устройство «доступным», хотя оно уже обесточено. В моем тесте это заняло около 4,5–5 минут. В этот период любая логика вида «подождать, пока устройство выйдет в онлайн» будет игнорироваться — система пропустит шаг, посчитав, что все в порядке. Если вы используете настройку розетки «previous state» (восстановление последнего состояния), вы можете даже не заметить сбоя, но при выборе опции «off» в качестве поведения при подаче питания (power-on behavior), автоматизация просто не сработает повторно, если триггер уже прошел.
Автоматизация типа «B» (в моем тесте), которая проверяет доступность устройства, сработала идеально только тогда, когда я явно добавил триггер на возвращение устройства из статуса unavailable. В этот же момент система проверила условие временного интервала и успешно включила свет спустя всего 0,22 секунды после того, как розетка снова появилась в сети.
Рекомендации по усилению логики
Чтобы автоматизации были устойчивы к сбоям, используйте следующий шаблон построения сценариев:
- Множественные триггеры: вместо одного события используйте комбинацию: конкретное время (time), событие запуска самого Home Assistant (homeassistant event: start) и изменение статуса устройства из unavailable.
- Условия как фильтры: используйте conditions для того, чтобы жестко ограничить временное окно выполнения действия (например, after: «21:00:00» и before: «23:00:00»).
- Режим работы: используйте mode: restart в автоматизациях, чтобы гарантировать актуальность выполнения последней команды.
- Отказ от задержек: замените длинные паузы на таймеры-помощники (Timer Helpers) с включенной функцией restore: true — это позволит им пережить перезагрузку системы.
- Локальный контроль: по возможности переходите на Matter, Zigbee и ESPHome. Каждый «прыжок» в облако — это дополнительная точка отказа, требующая времени на восстановление связи после того, как питание вернется в дом.
Использование интеграции Network UPS Tools (NUT) позволяет Home Assistant «понимать», когда питание восстановилось, и запускать процедуру проверки всех критически важных систем. В конечном счете, самый дешевый апгрейд — это не покупка более мощного аккумулятора, а пара дополнительных строк кода в ваших автоматизациях, которые заставляют систему проверять, в каком состоянии должен находиться дом «прямо сейчас», а не когда именно наступило время для команды.
