Перед обходом хочется быстро понять, что изменилось за ночь. Датчики уже передали множество строк через MQTT — соберём их в небольшую сводку. Локальная программа выберет нужный период и отметит пропуски, а языковая модель поможет оформить текст для просмотра человеком.
Это учебный план обмена: начнём с сохранения сводки и её ручной проверки, затем подготовим подключение модели. Возможности текстового помощника разобраны в статье о LLM, обработка изображений — в материале об ESP32-CAM и модели. Последовательность всей серии — в путеводителе по DIY.
Сначала выбираем вопрос, затем собираем данные
Сводка помогает оставить сведения для конкретного вопроса и проверить их перед отправкой. Посмотрите, что стало короче и какая информация сохранилась. Расход на запросы и состав передаваемых данных оценим отдельно.
Определите, что должно продолжать работать без облака: местный полив, аварийные защиты, журнал. Проверьте эту независимость отключением интернета. Подготовка текста будет отдельной частью, которую можно остановить без нарушения местных функций.
Для первого опыта составьте список изменений и неизвестных данных за ночь. Сравните его с просмотром исходного ряда: помогает ли быстрее выбрать вопросы для обхода? Запишите время и пропущенные сведения.
Разделяем сбор, проверку и отправку
- Сбор. Сохраняйте измерения и события в локальной истории вместе с источником, временем, единицами и качеством. Хранилищем может быть подходящая база или файл с продуманной записью и резервированием.
- Местные правила. Сигналы отказа и предусмотренные защиты не должны ждать LLM. Принципы проверки рядов рассмотрены в статье о прогнозах по датчикам, ограничения показаний — в материале о влажности почвы.
- Агрегатор. За определённый интервал он рассчитывает статистику, количество наблюдений, пропуски, события и доступное состояние оборудования.
- Проверка отправки. Приложение проверяет права, состав данных, свежесть, основание запроса и бюджет. Расписание и события задаются для своей задачи.
- Получение ответа. Текст связывается с идентификатором исходной сводки, сохраняется и передаётся уполномоченному пользователю для проверки.
Начните с прозрачных правил запуска: плановое время, ручной запрос и потеря данных. Сохраните причину каждой отправки. Так станет видно, когда сводка подготовлена по расписанию, а когда из-за сбоя.
Даём каждой цифре время, место и единицы
Укажите границы периода, часовой пояс, зону, источники и полноту. Минимум и максимум подпишите как крайние значения полученных допустимых измерений. Для среднего отметьте способ расчёта: по отсчётам или по времени. Это особенно полезно при пропусках.
Посчитаем на вымышленных данных. За час ждём четыре отсчёта через 15 минут. Пришли 10, 12 и 14 °C в 00:00, 00:15 и 00:45 UTC; в 00:30 запись пропущена. Полнота — 3/4, или 0,75, арифметическое среднее полученного — 12 °C. Найдите эти же числа в формате ниже:
{
"summary_id": "example-gh2-20260926-00",
"schema_version": 1,
"zone": "gh2",
"crop": "tomato",
"period": {
"start_utc": "2026-09-26T00:00:00Z",
"end_utc": "2026-09-26T01:00:00Z",
"end_exclusive": true
},
"temperature": {
"sensor_id": "air_a",
"unit": "degC",
"expected_samples": 4,
"valid_samples": 3,
"coverage_fraction": 0.75,
"missing_sample_times_utc": [
"2026-09-26T00:30:00Z"
],
"min": 10,
"max": 14,
"sample_arithmetic_mean": 12,
"last_measured_at": "2026-09-26T00:45:00Z"
},
"rh_pct": {
"status": "not_available"
},
"soil_vwc": {
"status": "not_available"
},
"irrigation": {
"command_count": 1,
"delivered_l": null,
"irrigated_area_m2": null,
"depth_mm": null,
"delivery_status": "unknown"
},
"ventilation": {
"last_command": "open",
"measured_open_pct": null,
"measurement_status": "unknown"
},
"camera": {
"status": "no_fresh_frame"
},
"alerts": [
{
"type": "missing_measurements",
"sensor_id": "air_a"
}
],
"notes": "Синтетический пример формата, не данные хозяйства.",
"question": "Составь черновик записи: факты, неизвестные данные и вопросы для проверки. Не прогнозируй будущую погоду по этой сводке."
}Правый конец интервала оставим следующему периоду: 01:00 сюда не входит. Неизвестное запишем как null с пояснением. Команду полива отделим от измеренной воды, команду открытия — от положения, а отсутствие свежего кадра отметим отдельно.
Свободные заметки тоже проверяйте перед отправкой: они могут содержать лишние сведения или инструкции, которым приложение не должно следовать. Задание для LLM должно требовать отделять факты от неизвестного, но одной формулировки недостаточно для гарантии правильного ответа. Используйте подход к проверке из статьи о текстовом помощнике.
Выбираем удобный момент для сводки
Попробуйте плановую сводку за ночь, отдельное событие сбоя и ручной запрос. Задайте часовой пояс и точные границы, затем проверьте переход суток и повторный запуск. Расписание подберите по работе сотрудников.
Вечером сводка может помочь оформить журнал. Сверьте её с исходными записями и оцените частоту по реальной нагрузке. Местные полив и вентиляция продолжают работать независимо по своим проверенным правилам.
Просматриваем то, что уйдёт наружу
Выберите разрешённые поля и прочитайте фактический запрос целиком. Даже условное имя зоны вместе с другими сведениями может раскрывать хозяйство. Изучите обработку и хранение у выбранного провайдера.
- Удаляйте ключи, пароли и сведения, не нужные для запроса.
- Проверяйте свободные заметки, имена файлов и другие поля, куда могут попасть персональные или закрытые данные.
- Для изображений учитывайте не только обрезку кадра, но и оставшийся фон и метаданные. Обрезка не является доказательством удаления всех лишних сведений.
- Учитывайте весь маршрут, включая мессенджер и журналирование, даже если сама модель запускается локально.
Сначала сохраняйте сводки локально. После просмотра состава решите, какие из них подходят для внешнего обмена. Если задача решается без него, можно оставить этот этап на своём сервере.
Одно событие — понятная история сообщений
Привяжите отправку к состоянию и причине. Повторы объединяйте с сохранением истории, а новое ухудшение, участок или потерю данных отмечайте отдельно. Пройдите правила на журнале и затем в текущих наблюдениях.
Если текст повторяется, проверьте номер сводки, свежесть, дубликаты и сохраняющееся состояние. Сначала найдите источник повтора. Изменение значимого порога испытайте отдельно вместе с возможными пропусками.
Запишите в журнале и причину отсутствия отправки. Тогда можно отличить обычную паузу от прекращения наблюдений.
Пробуем отключить сеть и запустить сервер снова
- Местные функции сохраняют предусмотренный режим, если он реализован и испытан независимо от внешнего API.
- Сводка записывается в устойчивую очередь с идентификатором, периодом, временем создания и состоянием обработки.
- Повторные попытки ограничиваются по числу и времени. Ошибка API не заменяется придуманным ответом.
- После восстановления связи приложение проверяет возраст и назначение каждой записи. Устаревшую сводку нельзя выдавать за текущую рекомендацию.
- Пользователь видит сбой или задержку, а история позволяет отличить подготовку запроса, ответ провайдера и доставку пользователю.
У запроса сохраняйте номер и историю попыток. При потерянном ответе провайдер уже мог обработать текст, поэтому правила повтора согласуйте с API. Испытайте заполнение очереди, перезапуск и полный диск — это покажет, как сохраняются незавершённые сводки.
Текстовый ответ не должен попадать в канал управления. Одних имён тем MQTT недостаточно: права и обработчики приложения должны поддерживать это разделение. Взаимодействие с агентами и исполнителями требует отдельной проверки.
Сравниваем расходы на одном периоде
Возьмите одинаковый период и сравните два варианта: объём входа и ответа, изображения, поиск и повторы. Примените действующий тариф в его единицах. Так появится проверяемый расчёт стоимости.
К запросам добавьте местное хранение, оборудование и сопровождение. Время сотрудников замерьте вместе с исправлениями отчёта. Сокращение входного текста будет одним из результатов сравнения.
Начинаем с одного источника
- Готовьте сводки локально и сверяйте с исходными рядами: время, единицы, пропуски, события и крайние значения.
- Проверьте ручную передачу выбранной сводки и качество ответа без управления оборудованием.
- Добавьте автоматическую отправку с правами доступа, ограничениями расходов и журналом состояний.
- Проверьте повторы, задержки, дубликаты, отсутствие связи и устаревание данных.
- Только после этого оценивайте необходимость дополнительных ролей и согласований в оркестраторе.
Камера, метеостанция и почвенный датчик могут остаться прежними. Выберите сначала один и сверьте реальные поля с форматом сводки. Затем добавляйте следующий источник, сохраняя его единицы и качество.
Собираем агрегатор шаг за шагом
Запускайте задание таймером или событием. Определите входящие в период записи, проверку качества и удаление повторов. При пересекающихся запусках защитите одну сводку от конфликтующей обработки.
Ниже план реализации агрегатора. Пройдите его на сохранённых записях, различая обычное решение оставить сводку локально и ошибку, которая требует проверки:
Прочитать историю за определённый период.
Проверить время, единицы, источники, дубликаты и качество.
Рассчитать статистику вместе с полнотой и свежестью данных.
Добавить подтверждённые события и отдельно неизвестные состояния.
Сохранить исходную сводку и причину дальнейшего решения.
Если есть сбой данных:
сообщить о сбое по предусмотренному каналу;
не записывать «всё в норме».
Если внешнее обращение не требуется или не разрешено:
сохранить причину и закончить.
Иначе:
проверить состав, возраст сводки и бюджет;
поставить её в очередь с идентификатором;
выполнить ограниченную попытку запроса;
связать ответ или ошибку с этой сводкой;
передать текст человеку, не исполнительному устройству.До подключения API проверьте режим сохранения на обычном периоде, пропусках, смене датчика и границе суток. Сверьте цифры с оригиналами. Затем отдельно испытайте ответ модели и доставку уведомления.
Сохраняем смысл климата, полива и снимка
Для климата добавьте время крайних значений, длительность нужных событий и полноту. У почвенного показателя сохраните шкалу: VWC с датчиком и калибровкой или относительный индекс. Тогда число останется понятным после сокращения ряда.
Для полива отличайте число команд от фактически измеренного объёма. Слой в миллиметрах можно рассчитать, если известны литры и соответствующая площадь в квадратных метрах: один литр на квадратный метр равен одному миллиметру. Без этих данных поле должно оставаться неизвестным; даже средний слой не описывает равномерность по участку.
У камеры укажите время, версию, класс и происхождение оценки. Старый кадр сохранит свой возраст. Если почва не отозвалась на полив, добавьте наблюдение и вопросы к подаче, прибору и условиям участка, оставляя причину для проверки.
Языковая модель получает эти сведения для подготовки текста. Она не должна превращать неизвестный расход, предположение камеры или ошибку связи в установленный факт. Ограничения ложных ответов и подмены инструкций описаны в материале OWASP о дезинформации и материале о внедрении инструкций.
Находим этап, на котором возникла ошибка
- Ответ не соответствует положению форточки. Проверьте, передана ли команда или измеренное положение, время этого сведения и сам ответ модели.
- Ответ игнорирует полив. Сверьте период, фактический объём и время события; добавление поля само по себе не гарантирует правильного вывода.
- Нет сообщения при проблеме. Проследите путь от измерения через правила и очередь до доставки. Причиной могут быть не только пороги.
- Растут расходы. Проверьте объём, частоту, повторные попытки и параллельные задания по журналу, затем примените обоснованные ограничения.
- После восстановления связи пришёл старый совет. Проверьте правила возраста сводок и маркировку задержанных ответов.
Сохраняйте номер сводки, этап ошибки и данные для повторения случая. Ключи исключите из журнала, а доступ и срок хранения выберите по его содержимому.
Сравниваем отчёт с реальным обходом
Отметьте пропущенные события, лишние выводы, повторы и время проверки. Разделите ошибку отбора данных и ошибку текста модели. По таким примерам легче выбрать, какую часть доработать.
Свяжите в журнале исходные данные, текст, решение и результат осмотра. Если дополнительный ответ пока мало помогает, упростите запрос или оставьте локальную сводку. Следующий опыт будет опираться на конкретное наблюдение.
Готовим следующий источник данных
Перед расширением сохраните формат, явные неизвестные значения, правила отправки и результаты опытов со сбоями. Доступ к управлению оборудованием оставьте отдельному проекту.
Первый результат — сводка, в которой можно объяснить каждое число и найти исходную запись. Получив её на своей системе, попробуйте текстовый ответ и оцените, стало ли удобнее готовиться к обходу.
