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 на реальных событиях и обратная связь пользователя встроены в структуру.

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

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