Агрофирма: датчики в полях шлют данные в облако вендора — забираем поток себе

MAATRIX

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

Как это устроено у большинства агрофирм

Типичная схема почти всегда одна и та же. Датчик в поле — это не отдельное устройство с собственным выходом в интернет, а маленький узел радиосети (чаще всего LoRaWAN или похожий низкоскоростной протокол на несколько километров, реже — NB-IoT прямо в сотовую сеть). Узлы объединяются вокруг шлюза — базовой станции, которая стоит где-то на возвышенности или на крыше склада и ловит сигнал со всего массива. Именно шлюз имеет полноценное подключение к интернету — обычно через 4G-модем, потому что стационарного провайдера в поле, как правило, нет.

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

Проблема в том, что удобство куплено ценой полной зависимости от чужой инфраструктуры. Ваш собственный агрономический архив — история влажности и температуры по каждому полю за несколько сезонов — физически лежит на серверах вендора, а не у вас. Что при этом получает агрофирма напрямую? Чаще всего только доступ через веб-интерфейс и мобильное приложение, иногда — ограниченный экспорт в CSV за короткий период. Прямого потока сырых данных в реальном времени на свою инфраструктуру у вас, как правило, нет — если только вы отдельно не настроите его сами.

Что вы теряете, пока поток идёт напрямую вендору

Это не абстрактный риск «а вдруг облако упадёт» — это набор вполне конкретных ограничений, с которыми агрофирмы сталкиваются на практике.

Зависимость от продолжения работы конкретной компании. Рынок агротеха состоит из десятков небольших производителей датчиков, часть из которых не переживает и пяти лет: закрываются, объединяются, продают направление, меняют модель монетизации. Если облако вендора закрывается или он решает свернуть бесплатную часть сервиса — вы не просто теряете удобный дашборд, вы теряете доступ к истории данных по собственным полям, которую собирали годами.

Ограничения API и экспорта. Даже у живых и стабильных вендоров API часто урезан: лимит запросов в минуту, экспорт данных только за последние 30-90 дней, отсутствие доступа к «сырым» показаниям без агрегации. Если вы захотите построить собственную аналитику — сопоставить влажность почвы с урожайностью за три года — может оказаться, что нужных вам данных за такой период у вас просто нет в доступной форме.

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

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

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

Архитектура: сервер как собственная точка приёма телеметрии

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

Датчики в поле (влажность, температура, погода)
        │  LoRaWAN / радиоканал
        ▼
Шлюз на краю поля (4G-модем, VPN-туннель наружу)
        │  MQTT или HTTP, зашифрованный канал
        ▼
Ваш сервер: MQTT-брокер → база временных рядов → дашборд/алерты

Ключевая точка — это шлюз. Именно он решает, куда отправлять данные: в облако производителя или туда, куда скажете вы. У многих промышленных LoRaWAN-шлюзов и части «умных» контроллеров полива есть настройка конечной точки — можно прописать собственный MQTT-брокер или HTTP-эндпоинт вместо (или вместе с) адресом вендора. Это не универсально: часть дешёвого потребительского оборудования жёстко зашита под облако производителя без возможности переопределить адрес — об этом варианте разговор отдельно, ниже.

Как только данные добрались до вашего сервера, дальше это уже полностью ваша территория: вы решаете, сколько хранить историю, кто имеет доступ, как строить отчёты и с чем сопоставлять данные — хоть с бухгалтерией по расходу воды, хоть с картами урожайности за прошлые годы.

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

Стек на сервере: брокер, база временных рядов, дашборд

Для приёма телеметрии с полевых датчиков не нужен сложный энтерпрайз — достаточно проверенного открытого стека, который прекрасно живёт на одном сервере среднего размера. Базовый набор:

• MQTT-брокер (например, Mosquitto) — принимает сообщения от шлюзов в поле, это стандартный лёгкий протокол для IoT-телеметрии.
• База данных временных рядов — InfluxDB хорошо подходит именно под показания датчиков: время + значение, эффективное хранение больших рядов, встроенная агрегация по периодам.
• Обработка потока — Node-RED удобен, чтобы разбирать входящие сообщения, приводить разные форматы данных от разных производителей к единой структуре и писать в базу.
• Дашборд и алерты — Grafana поверх InfluxDB даёт графики по каждому полю и датчику, а также правила оповещений (например, «влажность ниже порога» или «датчик не отвечает больше часа»).

Минимальный docker-compose для старта:

version: "3.8"
services:
  mosquitto:
    image: eclipse-mosquitto:2
    ports:
      - "8883:8883"   # MQTT поверх TLS
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data

  influxdb:
    image: influxdb:2
    ports:
      - "8086:8086"
    volumes:
      - influxdb-data:/var/lib/influxdb2
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=change_me
      - DOCKER_INFLUXDB_INIT_ORG=agrofirma
      - DOCKER_INFLUXDB_INIT_BUCKET=polya

  node-red:
    image: nodered/node-red:latest
    ports:
      - "1880:1880"
    volumes:
      - node-red-data:/data
    depends_on:
      - mosquitto
      - influxdb

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - influxdb

volumes:
  influxdb-data:
  node-red-data:
  grafana-data:

Готовый пример docker-compose под Node-RED с пояснениями по томам и переменным есть отдельно — см. Node-RED в docker compose, если хотите разобрать его подробнее перед разворачиванием.

В Mosquitto обязательно закройте порт паролем и TLS — шлюз в поле будет подключаться через интернет, а не по локальной сети:

# /mosquitto/config/mosquitto.conf
listener 8883
cafile /mosquitto/config/certs/ca.crt
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key
allow_anonymous false
password_file /mosquitto/config/passwd

По ресурсам сервера ориентируйтесь не на абстрактные цифры, а на простую прикидку: объём данных с датчиков влажности и температуры — это, как правило, компактные текстовые сообщения (десятки-сотни байт на показание), и даже сотня датчиков с опросом раз в несколько минут годами не создаст серьёзной нагрузки на диск — это далеко не видеопоток. Гораздо важнее не экономить на памяти для Grafana и InfluxDB, если планируете держать историю за несколько сезонов и строить по ней тяжёлые агрегирующие отчёты — здесь конкретные требования сильно зависят от числа датчиков и глубины хранимой истории, так что стоит закладывать запас и следить за ростом базы по факту, а не по прикидке заранее.

Связь между полем и сервером

Поле — это почти всегда зона без стационарного интернета. Штатное решение — 4G/LTE-модем на шлюзе, который отдаёт данные наружу. Особенности такого канала стоит учитывать заранее: сигнал сотовой сети в поле может быть неровным, IP чаще всего динамический или вовсе за NAT оператора, а значит открыть входящее соединение к шлюзу напрямую вы не сможете — только шлюз инициирует соединение к серверу, не наоборот. Разбор именно таких особенностей 4G-подключения — в статье про VPN через 4G-модем.

Разумная схема — поднять VPN-туннель (WireGuard достаточно лёгкий даже для слабого шлюза) от точки в поле до вашего сервера, и уже внутри туннеля пускать MQTT-трафик. Это закрывает сразу две проблемы: шифрует канал по сотовой сети, где вы не контролируете промежуточные узлы оператора, и даёт шлюзу стабильный внутренний адрес, к которому можно привязать правила брокера — независимо от того, какой внешний IP оператор выдал модему в этот раз.

Отдельно стоит продумать поведение при обрыве связи — а он на 4G в поле будет случаться регулярно, особенно в непогоду. Хороший шлюз или контроллер должен буферизовать показания локально (хотя бы последние несколько часов) и досылать их при восстановлении связи, а не терять данные за время обрыва. Если ваше оборудование такой буферизации не поддерживает — это стоит держать в голове как ограничение: часть точек в истории просто выпадет, и с этим придётся смириться либо доплачивать за более умный шлюз.

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

Если датчики жёстко зашиты под облако вендора

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

• Забирать данные через API вендора по расписанию. Если у производителя есть хотя бы читающий API (даже с ограничением по частоте запросов), можно поднять на своём сервере простой скрипт по cron, который раз в несколько минут опрашивает облако вендора и складывает полученные значения в свою базу временных рядов. Это не избавляет от зависимости от доступности облака вендора в моменте, но снимает главный риск — потерю истории данных при закрытии сервиса, потому что копия уже у вас.
• Искать модели с открытым протоколом при следующей закупке. При расширении парка датчиков осознанно выбирайте оборудование, которое поддерживает Modbus, MQTT или хотя бы настраиваемый HTTP-вебхук — это прямо влияет на то, будете ли вы владеть потоком данных или снова окажетесь привязаны к чужому облаку.
• Уточнять у вендора возможность локального шлюза. У части поставщиков промышленного уровня есть отдельный вариант поставки — локальный контроллер вместо облачного, иногда за дополнительную плату или по отдельному запросу. Это стоит спрашивать прямо при закупке, а не постфактум.
• Совмещать оба потока. Ничто не мешает оставить фирменное приложение вендора для оперативного взгляда агронома и параллельно вести собственную копию через API-скрипт — не обязательно выбирать что-то одно, если бюджет и время позволяют держать оба канала.

Полностью уйти от зависимости получится не с любым оборудованием сразу — но даже частичный контроль (регулярная выгрузка через API в свою базу) уже страхует от главного риска: полной потери истории при закрытии сервиса вендора.

Частые вопросы