От датчика до задания: собираем понятный обмен на MQTT

Датчик заметил изменение, камера прислала кадр, помощник составил текст. Как превратить это в понятное задание и увидеть, что произошло дальше? Разделим роли: кто наблюдает, кто предлагает, кто разрешает и кто проверяет результат. Координацией этого порядка займётся оркестратор.

В этой статье агентом называется отдельный программный компонент с ограниченной ролью. Ниже — проектная схема на MQTT, а не готовая программа для подключения реле. Она объединяет темы полива, вентиляции, анализа кадров, LLM и сводок. При соединении каждой части проверим её формат и поведение.

Раздаём программам небольшие роли

Наблюдатель передаёт измерения вместе с качеством. Анализатор снимка возвращает класс и оценку. Планировщик собирает предложение из правил или текста модели. Для первого опыта пусть предложением будет осмотр контрольной точки.

Оркестратор сверяет предложение с правилами и при необходимости обращается к человеку. Исполнитель принимает только разрешённое действие для конкретного устройства и следит за результатом. Разрешение хранится отдельным событием, которое можно проверить в журнале.

Даём каждой роли свои каналы и права

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

farm/teplica2/sensors/raw
farm/teplica2/alerts
farm/teplica2/vision/result
farm/teplica2/plan/propose
farm/teplica2/human/confirm
farm/teplica2/actuators/cmd
farm/teplica2/actuators/result
farm/teplica2/actuators/state
farm/teplica2/advice/llm

Разные названия тем не создают границ доступа. Нужны отдельные учётные данные и разрешения на чтение и публикацию; возможности ограничения тем описаны в документации Mosquitto. Наблюдатель, классификатор и LLM не должны иметь права публиковать команды или подтверждения от имени человека.

MQTT определяет доставку сообщений, а не проверку смысла команды или её физическое выполнение. Сохранённое сообщение с флагом RETAIN может попасть новому подписчику. Для команд однократного действия в этой схеме не используйте сохранённую публикацию; дополнительно проверяйте срок и повтор команды на стороне получателя.

Превращаем правила в проверяемую политику

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

1. Проверить источник сообщения, формат, время, свежесть данных и повторную доставку.
2. Убедиться, что устройство и действие есть в реестре, а параметры и единицы соответствуют его интерфейсу.
3. Определить по конфигурации, допустимо ли автоматическое исполнение при этих условиях или нужно подтверждение уполномоченного человека.
4. Перед отправкой снова проверить блокировки, текущие условия, ограничения и конфликт с другим действием.
5. Связать отправку и результат с неизменным планом и идентификатором команды.

Пометка critical во входном сообщении не разрешает обход этих проверок. Аварийные функции определяются отдельно, на нужном уровне контроллера или оборудования, по заранее проверенным условиям и источникам. Их независимость от модели и общего сервера необходимо испытать.

Выберите тайм-аут и режим отказа по конкретному процессу. Просроченный план оставьте без исполнения, а местные контуры — в предусмотренном для них режиме. Оцените последствия и остановки, и продолжения работы.

Сохраните три отдельные записи: проблема обнаружена, команда разрешена, результат подтверждён. По ним будет видно продвижение задания.

Пройдите следующую схему как план реализации. Для неё понадобятся хранилище состояний, проверка пользователя, MQTT и ответ устройства:

Получено предложение:
  проверить источник, формат, время и допустимость данных;
  сохранить plan_id, версию, устройство, действие, параметры и срок;
  по политике отклонить, запросить подтверждение или разрешить.

Получено подтверждение:
  установить пользователя из проверенного запроса, не из текста модели;
  проверить его права и точную версию ожидающего плана;
  проверить срок, отсутствие отмены и повторного исполнения;
  надёжно записать решение и автора подтверждения.

Перед командой:
  повторно проверить текущие условия, блокировки и ограничения;
  исключить конфликт действий над одним ресурсом;
  сохранить переход состояния и command_id;
  отправить ограниченную по сроку допустимую команду;
  получатель также проверяет допустимость, срок и повтор command_id.

После отправки:
  различать «отправлено», «принято» и «выполнено»;
  связать ответ устройства с command_id и фактическим состоянием;
  при неопределённом исходе не повторять действие вслепую;
  сохранить результат или необходимость проверки человеком.

Измените параметры уже предложенного плана и проверьте, что запрошено новое согласование. Затем повторите нажатие кнопки: физическое действие должно остаться однократным. Испытайте переходы между хранилищем, брокером и устройством при обрывах.

Первый опыт: из события получается задание на осмотр

Представим учебный сценарий. Наблюдатель передаёт значимое изменение со временем и качеством. Планировщик предлагает осмотр. Оркестратор записывает задание и уведомляет ответственного. Найдите в журнале все три шага по одному идентификатору.

Добавьте результат камеры с кадром, временем и версией модели. Он дополнит задание на осмотр. Права на опрыскиватель и дозирование удобрений этому результату не выдаются.

Для предложения полива подготовьте отдельную проверку устройства, параметров, фактического состояния и условий допуска. Автоматическое выполнение относится только к заранее испытанному сценарию; для остальных предусмотрите согласование.

Разбираем повтор и отказ по исходному событию

При ошибке пройдите путь назад: команда, контекст, классификация, кадр или почвенный датчик. Посмотрите на исходные записи и определите этап. Изменение модели и её порога проверяйте отдельно от исправления связи или оборудования.

Объедините повторные предложения с записью причины, сохраняя заметными изменения и отказы. Лимиты действий задайте для выбранного устройства и механики. Тогда по журналу будет понятно, почему предложение отложено или принято.

Если сотрудник отклонил предложение, сохраните причину и разберите правило. Свяжите исходное событие, план, подтверждение, команду и результат. По этой истории решайте, что менять в следующем опыте.

Пробуем перезапуск каждой части

Компоненты можно оформить отдельными службами. systemd позволяет задать условия перезапуска процесса, но не восстанавливает за приложение смысл его состояния и незавершённых команд. Это нужно реализовать и проверить отдельно.

Составьте список общих ресурсов служб: питание, диск, сеть и брокер. Для важных функций предусмотрите местный режим при их отказе, затем испытайте его. Так станет понятна реальная независимость частей.

После перезапуска проверьте старые команды, отменённые планы и незавершённые результаты. Журнал должен сохранить их смысл. Отдельно посмотрите на датчик и исполнительный узел.

Считаем работу над одной цепочкой

В смету включите форматы сообщений, права, хранение, испытания и сопровождение. Для обратной связи и независимых защит может понадобиться оборудование. Начните с одного сценария, чтобы измерить объём работы на нём.

Языковую модель подключайте там, где полезен текст. Передайте проверенную сводку и измерьте расходы. Для простого планировщика можно оставить ясные правила.

Расширяем проект по проверенным шагам

1. Опишите роли, сообщения, права и состояния плана; определите предусмотренные режимы отказа.
2. Запустите сбор событий и предложения без публикации команд оборудованию.
3. Проверьте подтверждения и отказы на имитации, включая повторы и устаревшие данные.
4. Испытайте исполнителя на подходящем стенде с обратной связью и предусмотренной остановкой.
5. Подключайте конкретный проверенный сценарий по установленной процедуре, с возможностью вернуться к прежнему режиму.

Начните с достоверных измерений и понятного режима оборудования. После этого проверяйте по одному новому переходу. Начните с назначения инструмента и выбора подхода.

Описываем разрешение до конкретных параметров

Запишите устройство, действие, параметры, пределы, срок, обратную связь и режим отказа. Разделите автоматический допуск и подтверждение человеком. Такой набор можно испытать на подходящих и заведомо неподходящих сообщениях.

В первом запуске разрешите только запись задания и уведомление. Неизвестные устройства и команды должны отклоняться. Для будущих вентиляции и полива подготовьте отдельную проверку конкретной установки.

В предлагаемой архитектуре результат классификатора или совет LLM не разрешает автоматическое применение средств защиты растений, изменение доз удобрений или отключение защит. Такие полномочия не выдаются текстовому компоненту. Ограничения прав модели и необходимость проверки операций описаны в материале OWASP.

Сообщаем человеку, на каком этапе находится дело

Укажите факт, источник, время, текущее состояние и требуемое решение. Результат выполненного действия привяжите к обратной связи. Отказ и неизвестный исход оформите отдельными статусами — с ними проще продолжить проверку.

Сгруппируйте повторные сообщения и выберите время доставки для разных событий. Сохраните заметными ухудшение и потерю связи. При отложенном ответе заново проверьте срок и актуальность; «позже» оставляет действие ожидающим решения.

Испытываем логику до подключения нагрузки

1. Чужой пользователь, неверная роль и попытка модели выдать себя за подтверждающего не дают разрешения.
2. Изменённый, отменённый, просроченный или уже исполненный план не запускается по старому подтверждению.
3. Повторная доставка и перезапуск не приводят к повторному физическому действию.
4. Старые измерения, конфликт ресурса и активная блокировка учитываются непосредственно перед командой.
5. Потеря ответа устройства оставляет неопределённый исход для проверки, а не автоматически означает успех или разрешение повторить.
6. Отказ модели, брокера, общего сервера или связи проверяется отдельно от нормального запуска.

Сначала записывайте предполагаемую команду в журнал. Затем перейдите на подходящий стенд для механики, силовой части и остановки. Способ физического вмешательства выберите с учётом конкретного процесса.

Сравниваем поведение с заранее записанным сценарием

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

Подтверждение MQTT не является датчиком результата: например, PUBACK относится к обмену сообщениями, а не к поступлению воды. Статусы «отправлено», «принято устройством» и «действие подтверждено обратной связью» должны оставаться различимыми. Уровень QoS сам по себе не доказывает однократность физического действия через сбои всей системы.

Собираем части серии в свой проект

Камера, модель на Pi и обработка кадров дают наблюдения и оценки. Текстовый помощник готовит пояснения, агрегатор — контекст, а оркестратор управляет согласованием по собственной политике.

Соединяйте части по одной, сверяя формат, версию и результат каждого перехода. Общая последовательность собрана в путеводителе по DIY.

Первый результат: история одного задания

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

Начните с задания на осмотр одной точки и доведите его до записи результата. Затем попробуйте повтор, просрочку и перезапуск. Когда эти случаи читаются в журнале понятно, выбирайте следующую роль или устройство.