LLM смотрит на мой сад: как ИИ-зрение решает, звать ли меня накрыть мебель перед дождём

TL;DR

Я собрал в своём умном доме автоматизацию, которая:

1. следит за прогнозом осадков (в том числе за краткосрочным nowcast’ом на ближайшие пару часов);

2. когда дождь/снег на подходе — включает подсветку на уличной камере и делает снимок;

3. отправляет снимок в мультимодальную LLM с вопросом «садовая мебель накрыта чехлами?»;

4. если не накрыта — присылает мне в Telegram фото + анимированный радар осадков и две кнопки: «Накрыл» и «Отложить на 3 часа»;

5. пока я не среагировал/не отложил — не спамит; на сухую погоду LLM не дёргается вовсе.

ИИ здесь на двух уровнях. Первый — LLM как слой зрения и рассуждения: принимает кадр с камеры и возвращает ответ по строгой схеме (covered / reason), без парсинга свободного текста. Второй — саму автоматизацию собрал ИИ-агент по SSH и REST/WebSocket API реального сервера (включение сущностей, config-flow, отладка граблей); человек — постановка задачи и приёмка.

Всё — на штатных механизмах платформы, без собственного компонента/интеграции: автоматизации, хелперы, встроенная LLM-интеграция.

1. Зачем это вообще

Классическая сцена: через полчаса дождь, а уличная мебель — диван, кресла, подушки — стоит без чехлов. Платформа умного дома технически «знает» и прогноз, и картинку с камеры. Но связать одно с другим и сделать вывод «пойди накрой» она сама не умеет: нет слоя, который понимает содержимое кадра и сопоставляет его с погодой. Если прозевал дождь, то будешь экстренно заносить в дом подушки и сушить их долго по углам.

Этот слой закрывает LLM: превращает кадр в вывод «мебель открыта / накрыта» с коротким обоснованием.

Само действие — надеть чехлы — делает человек: привода для этого нет, автоматизировать тут физически нечего. Задача системы не «сделать», а вовремя и по делу подсказать. Отсюда два требования:

• Точность вместо спама. Не слать «накрой мебель» на каждый прогноз дождя. Сначала снимок и проверка через LLM — уведомление уходит, только если мебель действительно открыта.

• Экономия вызовов. LLM дёргаем не по расписанию, а когда осадки реально близко (nowcast), и не чаще разумного (cooldown, snooze).

Контекст модели недоступен («сегодня чехлы сняли специально, потому что красили»), поэтому последнее слово — за человеком, одним тапом.

2. Архитектура

Весь конвейер — из штатных примитивов платформы:

┌─────────────────────────────────────────────────────────┐ │ Триггеры автоматизации │ │ • каждые 30 минут │ │ • nowcast осадков (2ч) поднялся выше 0 │ │ • состояние погоды сменилось на «дождь» │ └───────────────────────────┬─────────────────────────────┘ │ ┌──────────────────▼────────────────────┐ │ Условия (дёшево, без обращения к LLM):│ │ • не в режиме «отложено» (snooze) │ │ • дождь реально близко (nowcast/ │ │ прогноз/текущее состояние) │ │ • прошло > 3ч с прошлой реальной │ │ проверки (cooldown) │ └──────────────────┬────────────────────┘ │ (иначе — стоп, LLM не вызывается) ┌──────────────────▼───────────────────┐ │ 1. Включить подсветку камеры │ │ 2. Снять кадр во временный каталог │ │ 3. Выключить подсветку │ └──────────────────┬───────────────────┘ │ ┌──────────────────▼────────────────────┐ │ LLM-зрение (AI Task): │ │ вход: кадр + вопрос │ │ выход (structured): {covered, reason}│ └──────────────────┬────────────────────┘ │ covered == false? ┌──────────────────▼───────────────────┐ │ Telegram: фото + радар + кнопки │ │ [✅ Накрыл] [😴 Отложить 3ч] │ └──────────────────┬───────────────────┘ │ callback от кнопки ┌──────────────────▼───────────────────┐ │ Вторая автоматизация: │ │ выставить snooze_until, ответить │ │ на callback, отписать в чат │ └──────────────────────────────────────┘

Компоненты:

• Хост. Старенький Raspberry Pi 3 (4 ядра ARM, ~1 ГБ RAM), платформа умного дома Home Assistant (HA) работает в Docker-контейнере. Каталог конфигурации примонтирован с хоста. Ресурсов в обрез — что позже и аукнется (см. раздел 8.7).

• Камера. Уличная IP-камера с управляемой подсветкой/ИК. Важно: её функции (снимок, свет) проброшены в платформу как обычные сущности camera.* и light.* — поэтому автоматизация не завязана на конкретного вендора.

• Погода. Интеграция, дающая не только прогноз, но и краткосрочный nowcast осадков (мм за ближайшие ~2 часа) и картинку-радар. Именно nowcast — лучший сигнал «дождь вот-вот».

• LLM. Мультимодальная модель, подключённая к платформе через штатную интеграцию AI Task (об этом ниже).

• Мессенджер. Telegram-бот в приватной группе, с inline-кнопками и обработкой callback’ов.

3. Почему без собственного компонента

Соблазн — написать свою интеграцию (и я даже начал, но потом решил, что нужно будет выложить в Open Source, а потом нести ответственность за проект — НЕТ). Но всё уже есть в платформе:

Свой код дал бы разве что более удобный UI настройки; функционально — ничего. Меньше кода — меньше поверхности для поддержки.

4. Ключевой кирпич: LLM-зрение через AI Task

Современные платформы умного дома (HA, например) умеют подключать LLM-провайдера (облачного или локального) как «AI Task»-сущность. Дальше в автоматизации доступен сервис, который принимает инструкцию + вложения (картинки) и возвращает структурированный ответ по заданной схеме.

Вызов (сокращённо, в терминах HA):

— service: ai_task.generate_data continue_on_error: true # деградируем мягко, если LLM недоступна data: entity_id: ai_task.<провайдер> task_name: garden_furniture_check instructions: >- Ты смотришь на снимок уличной террасы/сада. Скоро осадки. Определи, накрыта ли садовая мебель (диван, кресла, подушки) защитными чехлами. Если что-то открыто — covered=false. Если слишком темно или обзор закрыт — covered=false и объясни в reason. structure: # схема ответа = гарантированный формат covered: selector: boolean: {} description: true, если мебель защищена чехлами required: true reason: selector: text: {} description: одно короткое предложение с описанием required: true attachments: — media_content_id: media-source://media_source/local/weatherwatch_ai.jpg media_content_type: image/jpeg response_variable: result

Два важных момента:

1. Structured output. Мы не парсим свободный текст модели, а сразу получаем result.data.covered (bool) и result.data.reason (строка). Это резко упрощает логику ниже: covered != true — и всё.

2. Вложение — только через media-source. Поле attachments принимает не путь к файлу, а идентификатор медиа-источника вида media-source://media_source/local/<файл>. А это значит, что снимок надо класть в каталог, который платформа считает медиа-источником (у меня — контейнерный /media), а не просто куда-то на диск.

Ответ на реальном кадре выглядел так:

{ «covered»: false, «reason»: «Часть мебели открыта и не накрыта чехлами.» }

5. Полная автоматизация проверки

Ниже — основная автоматизация целиком (идентификаторы сущностей обобщены, chat_id заменён плейсхолдером).

— id: weatherwatch_garden_furniture alias: WeatherWatch — проверка садовой мебели перед дождём mode: single max_exceeded: silent trigger: — platform: time_pattern # каждые 30 минут minutes: «/30» — platform: numeric_state # nowcast осадков поднялся выше 0 entity_id: sensor.precipitation_forecast_total above: 0 — platform: state # состояние стало «дождь» entity_id: weather.local to: rainy condition: # не в режиме «отложено» (Human in the Loop, см. ниже) — condition: template value_template: >- {{ as_timestamp(now()) > (state_attr(‘input_datetime.weatherwatch_snooze_until’,’timestamp’) | float(0)) }} action: — service: weather.get_forecasts continue_on_error: true target: { entity_id: weather.local } data: { type: daily } response_variable: fc — variables: bad_conditions: [rainy, pouring, snowy, snowy-rainy, hail, lightning-rainy] rain_soon: >- {{ states(‘weather.local’) in bad_conditions or (states(‘sensor.precipitation_forecast_total’) | float(0) > 0) or (fc is defined and (fc.get(‘weather.local’, {}).get(‘forecast’, [])[:2] | selectattr(‘condition’,’in’, bad_conditions) | list | count > 0)) }} # осадки действительно близко? иначе — стоп, LLM не трогаем (экономия) — condition: template value_template: «{{ rain_soon }}» # cooldown: не запускать проверку чаще раза в 3 часа — condition: template value_template: >- {{ as_timestamp(now()) — (state_attr(‘input_datetime.weatherwatch_last_check’,’timestamp’) | float(0)) > 10800 }} — service: input_datetime.set_datetime # фиксируем «реальную» проверку target: { entity_id: input_datetime.weatherwatch_last_check } data: { timestamp: «{{ as_timestamp(now()) }}» } # подсветка -> кадр -> подсветка выкл — service: light.turn_on target: { entity_id: light.garden_floodlight } — delay: «00:00:03» # дать сенсору камеры «привыкнуть» — service: camera.snapshot target: { entity_id: camera.garden } data: { filename: «/media/weatherwatch_ai.jpg» } — service: light.turn_off target: { entity_id: light.garden_floodlight } # LLM-зрение — service: ai_task.generate_data continue_on_error: true data: entity_id: ai_task.provider task_name: garden_furniture_check instructions: >- Ты смотришь на снимок сада/террасы. Скоро осадки. Накрыта ли садовая мебель защитными чехлами? Если что-то открыто — covered=false. Если темно/обзор закрыт — covered=false и объясни в reason. structure: covered: { selector: { boolean: {} }, required: true, description: «true, если мебель накрыта чехлами» } reason: { selector: { text: {} }, required: true, description: «короткое описание того, что видно» } attachments: — media_content_id: media-source://media_source/local/weatherwatch_ai.jpg media_content_type: image/jpeg response_variable: result — variables: covered: >- {{ result.data.covered if (result is defined and result.data is defined) else none }} reason: >- {{ result.data.reason if (result is defined and result.data is defined) else ‘Ожидается дождь, а проверка ИИ не сработала — проверьте вручную.’ }} # уведомляем только если НЕ накрыто — condition: template value_template: «{{ covered != true }}» — service: camera.snapshot # снимок радара во временный каталог target: { entity_id: camera.rain_radar } data: { filename: «/media/weatherwatch_map.gif» } — service: telegram_bot.send_photo data: target: !secret tg_chat_id file: «/media/weatherwatch_ai.jpg» caption: «Накройте садовую мебель — ожидается дождь. {{ reason }}» inline_keyboard: — «✅ Накрыл:/ww_covered, 😴 Отложить 3ч:/ww_snooze3h» — service: telegram_bot.send_animation data: target: !secret tg_chat_id file: «/media/weatherwatch_map.gif» caption: «Радар осадков — nowcast на 2ч: {{ states(‘sensor.precipitation_forecast_total’) }} мм»

6. Обратная связь: кнопки «Накрыл» / «Отложить»

Раз финальное решение остаётся за человеком, ему нужна максимально простая точка управления — прямо в уведомлении. Реализуется тремя вещами.

(1) Inline-кнопки на уведомлении. В сервисе отправки фото есть поле inline_keyboard, где кнопка задаётся строкой Текст:/callback_data:

inline_keyboard: — «✅ Накрыл:/ww_covered, 😴 Отложить 3ч:/ww_snooze3h»

(2) Обработчик callback’а — отдельная автоматизация. При нажатии платформа генерирует событие telegram_callback, где полезная нагрузка лежит в trigger.event.data.data:

— id: weatherwatch_snooze_callback alias: WeatherWatch — кнопки Накрыл/Отложить mode: queued max: 5 trigger: — platform: event event_type: telegram_callback condition: — condition: template value_template: «{{ trigger.event.data.data in [‘/ww_covered’, ‘/ww_snooze3h’] }}» action: — variables: is_snooze: «{{ trigger.event.data.data == ‘/ww_snooze3h’ }}» secs: «{{ 10800 if trigger.event.data.data == ‘/ww_snooze3h’ else 64800 }}» — service: input_datetime.set_datetime target: { entity_id: input_datetime.weatherwatch_snooze_until } data: { timestamp: «{{ as_timestamp(now()) + (secs | int) }}» } — service: telegram_bot.answer_callback_query # убрать «часики» на кнопке continue_on_error: true data: callback_query_id: «{{ trigger.event.data.id }}» message: >- {{ ‘Отложено на 3 часа’ if is_snooze else ‘Принято — до вечера не беспокою’ }} — service: telegram_bot.send_message continue_on_error: true data: target: !secret tg_chat_id message: >- {{ ‘😴 Отложено 3ч: ‘ if is_snooze else ‘✅ Отмечено как накрыто: ‘ }}{{ trigger.event.data.from_first }}

(3) Хелпер-состояние. Нажатие выставляет input_datetime.weatherwatch_snooze_until в «сейчас + 3ч» (отложить) или «сейчас + 18ч» (накрыл — до вечера). Основная автоматизация в первом же условии проверяет: если now < snooze_until, она вообще не запускается.

Нажатие выставляет snooze_until, основная автоматизация его учитывает. Без нажатия ничего необратимого не происходит — максимум повторное уведомление, ограниченное cooldown’ом.

7. Контроль стоимости — by design

Мультимодальные вызовы стоят денег, поэтому «дешевизна» зашита в структуру, а не в добрые намерения:

1. Гейт по осадкам. Пока rain_soon ложно, автоматизация останавливается до снимка и LLM. В сухой день обращений к модели — ноль. Проверка каждые 30 минут — это всего лишь дешёвый рендер шаблона.

2. Правильный cooldown. Даже во время дождя реальная проверка запускается не чаще раза в 3 часа.

3. Snooze/ack. Ответ человека полностью выключает поток уведомлений на заданное время.

4. Дедупликация действий. Никаких «повторить на всякий случай»: одна ситуация — одно уведомление.

8. Грабли

8.1. Вложение для LLM — только из media-source

ai_task не принимает произвольный путь к файлу: нужен media-source://…. Каталог, отдаваемый как «локальный» веб-контент, media-источником не является. Решение — писать снимок в каталог, зарегистрированный как медиа-директория, и ссылаться на него как media-source://media_source/local/<файл>.

8.2. Telegram и редиректы

Радар осадков доступен по URL, но этот URL отдаёт 301-редирект на CDN с меняющимся адресом. Загрузчик Telegram-интеграции редиректы не проходит и падает с Failed to load URL: 301. Обычный curl -L редирект проходит — отсюда и расхождение. Решение: не отдавать URL, а снять кадр камеры-радара в локальный файл и отправить его.

8.3. Анимированный GIF ≠ фото

Радар — это анимированный GIF. send_photo анимированные GIF не принимает. Нужен send_animation (или send_document) — тогда в чат уезжает «живой» радар, что даже нагляднее.

8.4. Отключённые по умолчанию сущности

Многие полезные сущности интеграции (камера-радар, сенсоры nowcast) по умолчанию выключены в реестре. Включить их пачкой без перезапуска можно через WebSocket-API реестра сущностей:

{ «type»: «config/entity_registry/update», «entity_id»: «sensor.precipitation_forecast_total», «disabled_by»: null }

После этого — «мягкий» reload соответствующей записи конфигурации, без рестарта всей платформы.

8.5. Config flow и subentries через API

Добавление интеграций и настройку «разрешённых чатов» бота можно делать целиком через REST-flow (/api/config/config_entries/flow) и flow вложенных записей (/api/config/config_entries/subentries/flow). Удобно для автоматизации «под ключ», без ручного клика по UI, Клодом.

8.6. Ошибка в cooldown, которую легко не заметить

Первая версия cooldown’а опиралась на «время последнего запуска автоматизации» (last_triggered). Проблема: этот таймстамп обновляется при каждом запуске, в том числе на «сухих» проверках, где осадков нет. В связке с проверкой каждые 30 минут это давало эффект:

• 00:00 — сухая проверка, last_triggered = 00:00;

• 00:30, 01:00, … — cooldown (>3ч) не прошёл, автоматизация даже не стартует;

• если дождь появился в 01:00 — проверка заблокирована до 03:00.

То есть «сухой» запуск глушил последующую реальную проверку. Решение — вынести состояние в отдельный хелпер input_datetime.weatherwatch_last_check, который обновляется только при реальной проверке (после гейта по осадкам). Теперь сухие срабатывания cooldown не сдвигают.

Мораль: «время последнего запуска» и «время последнего значимого события» — разные вещи. Легко перепутать и получить тихо-неправильную логику.

8.7. Как я уронил сервер в своп

HA у меня крутится на старом Raspberry Pi 3 (~1 ГБ RAM) — и именно поэтому история случилась. Чтобы «безопасно» проверить конфиг, я запустил внутри контейнера штатный скрипт проверки конфигурации. Он поднимает второй экземпляр платформы в памяти. Для гигабайта это перебор: система ушла в своп, перестали отвечать и веб-интерфейс, и SSH (буквально не завершался хендшейк — хосту не хватало ресурсов даже на это). В результате просто выключил из розетки и включил заново.

Выводы:

• на слабом железе не запускать тяжёлую проверку конфигурации «в бою» рядом с работающим инстансом;

• перезапуск контейнера/хоста — валидный и быстрый способ выйти из свопа, если конфиг лежит на диске и переживёт рестарт;

• reload через API валидирует изменения без поднятия второго инстанса — и в большинстве случаев его достаточно.

9. Что дальше

• Тихие часы — не будить уведомлением, скажем, с 22:00 до 07:00 (для «ночного» дождя копить и присылать заранее вечером).

• Больше «наблюдателей». Тот же примитив (камера + погодный триггер + вопрос на естественном языке + действие) переиспользуется: «закрыть окна», «занести бельё», «накрыть бассейн перед заморозком».

• Обратная связь как обучение. Кнопка «на самом деле накрыто» может со временем подстраивать порог/промпт и повышать доверие.

10. Выводы

• LLM-зрение — недостающий слой рассуждения между камерами и действиями. С нативной AI-Task-интеграцией его вплетаешь без единого своего компонента, а structured output превращает ответ модели в предсказуемые поля, а не в текст, который надо парсить.

• ИИ-агент сегодня не только пишет код, но и разворачивает систему целиком. Эту автоматизацию он собрал сам: заходил по SSH, ходил в REST/WebSocket API, включал отключённые сущности, проходил config-flow и вычищал грабли. Роль человека сместилась к постановке задачи и приёмке результата.

• Дешевизна и «не спамить» — это архитектура, а не намерение. Гейты по осадкам, cooldown на реальных событиях и обратная связь пользователя встроены в структуру.

• Финальное действие оставлено за человеком осознанно, а не по недоделке. Там, где ошибка необратима или нужен контекст, ИИ берёт наблюдение и суждение, решение — за человеком.

Подписывайтесь на канал ТехДир Подсекин, ставьте лайк, вам не сложно, мне — приятно.

Источник: habr.com