40 команд от Яндекс Smart Home за 3 секунды: как мы узнавали, кто их послал, и не узнали

Ворота открылись сами в 17:26. Кто отдал команду — выяснить невозможно

TL;DR. У частного клиента дважды за месяц зафиксированы неавторизованные команды через Yandex Smart Home API: в одном случае это привело к тому, что въездные и гаражные ворота стояли открытыми почти 13 часов в отсутствие хозяев. Источник команд установить средствами Home Assistant нельзя — context_user_id у таких событий всегда null. В поддержке Яндекса тикет создан больше месяца назад, был один звонок от менеджера, дальше — шаблонные «мы скоро вернёмся», по тону похожие на автоответы LLM. Пока ждём — собрали свой мониторинг массовых команд. Данные, по которым можно установить источник, есть только у Яндекса. И эта сторона пока молчит.

---

Контекст

Я настраиваю и поддерживаю Home Assistant у частных заказчиков. У одного из них — загородный дом, автоматизация на HA, голосовое управление через Яндекс Алису (интеграция Yandex Smart Home, подключение через Yaha Cloud / HACS-компонент yandex_smart_home). В числе устройств — въездные и гаражные ворота, климат, DMX-освещение, выключатели, увлажнители.

За последние шесть недель через этот канал дважды приходили команды, которые никто из жильцов сознательно не отдавал. В одном из случаев это имело последствия в физическом мире.

---

Инцидент 1 — 9 марта 2026, ворота

Что увидел владелец

Вечером на почту пришло уведомление от камеры: движение во дворе. На записи — распахнутые настежь ворота. Владелец был в отъезде, в доме никого.

Хронология:

Что увидел я в логах HA

В 17:26:23–17:26:26 через шину HA пришла волна из ~40 событий типа yandex_smart_home_device_action. Все события — с одним и тем же context_id. По смыслу — команда «выключить» на группу устройств: климат, увлажнители, часть выключателей, два cover’а (ворота). Свет команда не затронула — это была не команда «всё выключить», а целевая, на конкретный набор.

Климатические устройства команду отбили с ошибкой ServiceNotSupported — они не поддерживают on_off как capability. Их состояние в итоге не поменялось. А вот ворота команду приняли.

Почему команда «выключить» открыла ворота

Привод ворот у клиента — с классическим импульсным управлением: один импульс = toggle. Один импульс открывает, следующий закрывает, состояние хранится у контроллера. В конфигурации HA команды open_cover и close_cover слали один и тот же GPIO-импульс.

В 17:26 ворота были закрыты. Яндекс прислал команду «выключить», HA транслировал её как close_cover, отправил импульс. Привод воспринял импульс как toggle — и открыл закрытые ворота.

Защитные автоматизации, которые должны были перехватить эту ситуацию (напоминание о незакрытых воротах, автозакрытие в 23:00, Telegram-уведомление об открытии) на тот момент были отключены — по причинам, к Яндексу отношения не имеющим.

Ключевая деталь

Владелец не отдавал такой команды. В доме в этот момент никого не было — колонки не могли услышать случайный голос с улицы, ТВ не работал. Команда пришла извне, через API.

---

Инцидент 2 — 8–10 апреля 2026, DMX-освещение

Спустя ровно месяц — та же картина, на других устройствах. В течение трёх дней через yandex_smart_home_device_action несколько раз приходили команды на включение и выключение DMX-освещения, в том числе ночью. Владелец этих команд не отдавал.

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

---

Что удаётся увидеть самому — и чего не хватает

Интеграция Yandex Smart Home (yandex_smart_home) для каждой входящей команды публикует в шине HA событие yandex_smart_home_device_action. Recorder пишет его в SQLite (home-assistant_v2.db, таблицы events и event_data). Выглядит это так (реальный формат, идентификаторы обфусцированы):

{  "entity_id": "light.dmx_zone_1_example",  "capability": {    "type": "devices.capabilities.on_off",    "state": {      "instance": "on",      "value": true    }  }}

Дополнительно у каждой записи в events есть:

• time_fired_ts — момент события

• context_id — общий для всех событий, порождённых одним запросом. По нему и видно, что 9 марта на ~40 устройств пришла одна команда, а не сорок подряд.

• context_user_id — для всех событий yandex_smart_home_device_action равен NULL

Вот здесь и начинается проблема. context_user_id = NULL означает, что команда пришла через внешнюю интеграцию, от неавторизованного с точки зрения HA субъекта. Для штатных команд из UI или автоматизаций HA это поле заполнено — видно, кто нажал на кнопку или какая автоматизация сработала. Для Алисы — всегда пусто.

То есть из логов HA в принципе нельзя вытащить:

• с какого устройства пришёл запрос (колонка? приложение «Дом с Алисой»? веб? внешний сервис, интегрированный с аккаунтом?)

• какой пользователь аккаунта Яндекс его отдал (если в аккаунте несколько членов семьи)

• был ли это голосовой запрос — и если да, что конкретно распознал голосовой движок

• был ли это пользовательский клик в интерфейсе, или срабатывание пользовательского сценария, или активность со стороны самого Яндекса (например, переиндексация / миграция устройств)

• request_id на стороне Yandex API, по которому можно было бы самому поискать в логах

Всё это данные, которые физически существуют — но только у Яндекса. У владельца аккаунта своего лога «кто и что запросил» на портале/в приложении нет. История Алисы в приложении показывает голосовые команды, но не показывает действия, пришедшие через API, и не показывает команды, которые выполнялись от других пользователей аккаунта или от сценариев.

---

Временные меры…

Раз Яндекс не отвечает и не даёт инструмента, пришлось сделать минимальный собственный мониторинг. Это не решение проблемы — это способ узнавать о следующем инциденте раньше, чем ворота простоят открытыми 13 часов.

Компоненты:

1. SQL-сенсор поверх recorder’а — раз в 30 секунд читает из home-assistant_v2.db последние 500 событий yandex_smart_home_device_action и кладёт их в атрибут items как JSON-массив. На ~100 команд в день это покрывает примерно 5 дней истории; предел — recorder.purge_keep_days.

2. Счётчик с окном 15 секунд на базе counter: и двух автоматизаций. На каждое событие yandex_smart_home_device_action инкрементируется, через 15 секунд без новых событий — сбрасывается. Простейшая детекция всплесков.

3. Автоматизация-алерт: если в окне N ≥ 5 событий — шлём Telegram с первыми 15 командами и общим context_id. Debounce 5 минут, чтобы один всплеск не превращался в спам.

4. Lovelace-карточка «Детали команд Алисы по волнам» — markdown + Jinja, группирует события по context_id, показывает сводку «за 14–19 апреля 2026 года (6 дн.): 43 волны, из них 34 массовых. Одиночных команд: 65. Всего событий: 500.» и каждый блок-волну с таблицей время / устройство / команда / значение

Ключевая эвристика — группировка по context_id. Если у тебя за секунду пришло 15 команд на 15 устройств, но у всех общий context_id — это одна команда от Алисы, не пятнадцать. По отдельным entity это видно плохо, по контексту — сразу.

Полный код пакета и дашборда. Там же — README с установкой и инструкциями по тестированию (симуляция массовой команды через Developer Tools → Events → Fire event).

Ещё раз: это костыль. Нормального ответа на вопрос «а кто это был-то» он не даёт и дать не может. Он только сообщает «опять пришло 15 команд за 3 секунды, смотрите лог».

---

Что я прошу у Яндекса

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

1. По переданным context_id и временным интервалам — данные о запросах к нашему аккаунту Smart Home:

   • тип действия и полный набор затронутых устройств

   • источник запроса: какое устройство (конкретная колонка / приложение / веб / внешний сервис)

   • user_id пользователя аккаунта, от которого пришёл запрос

   • request_id в логах Yandex API

   • если запрос голосовой — расшифровка распознанной фразы

2. Подтверждение или опровержение: был ли это пользовательский запрос (голос/ручной клик), пользовательский сценарий, либо активность со стороны инфраструктуры Яндекса.

3. В долгосрочной перспективе — дать владельцу аккаунта инструмент самообслуживания: лог «что, когда, откуда, кем» с возможностью фильтрации.

Без этих данных разобраться нельзя — ни нам, ни кому-либо ещё со стороны. Тем временем ворота продолжают быть в зоне досягаемости API, источник которого для владельца аккаунта — чёрный ящик.

---

Что это значит для других пользователей

Если у вас дома Smart Home на Алисе и в периметре есть устройства, у которых нежелательное срабатывание имеет последствия в физическом мире — ворота, электрозамки, подача воды, газовые клапаны, шлагбаумы, аварийное отключение питания — имеет смысл:

• Не добавлять такие устройства в Алису вообще. Yaha Cloud / yandex_smart_home позволяет фильтровать, что отдавать в облако. Снимите эти устройства из экспорта.

• Если всё-таки добавлены — поставить перед ними защитный слой в HA:

  • проверка текущего состояния перед импульсом (не слать close_cover, если уже closed)

  • отдельная автоматизация-напоминание, если cover открыт ночью

  • аварийный Telegram при критичных переходах состояния

  • детектор массовых команд (N действий за окно) — пример в github

• Положить свой мониторинг запросов от Алисы. Пока Яндекс не дал его сам — держать SQL-сенсор и алерт у себя. 30 строк конфига.

---

Оговорка

Источником команд может оказаться что угодно — и наша сторона в том числе:

• кривой сценарий в приложении, которого сам владелец уже не помнит

• колонка в доме, распознавшая фоновое аудио как голосовую команду (радио, ТВ, видеозвонок, разговор соседей)

• сторонний сервис, подключённый к аккаунту как навык/интеграция

• баг в облачной стороне Yandex Smart Home

• нечто, о чём мы пока не подумали

Все эти версии проверяемые — но только со стороны Яндекса, потому что данные есть только там. Проблема не в том, какая из версий окажется правдой. Проблема в том, что выяснять это должна единственная компетентная сторона — и по тикету 26040212533585258 от неё уже больше месяца идут автоответы.

Кирилл, если вдруг читаешь: очень ждём.