Как мы организовали передачу телеметрии в ЕЦПП при нестабильном интернете: роль MQTT
Задача: данные с удаленных объектов, где связь пропадает
Единая цифровая платформа пчеловодства (ЕЦПП) объединяет аппаратные модули разных производителей: датчики температуры, влажности, массы улья, уровня CO₂, GPS и другие сенсоры. Все они установлены на пасеках — в полях, лесах, на крышах. Интернет там мобильный и нестабильный: связь может пропасть на часы.
Задача звучит просто: телеметрия должна доходить до платформы. Но на практике это означает, что система обязана работать, когда сеть недоступна, не терять данные при обрыве и одинаково принимать устройства от разных поставщиков. Для решения мы выбрали протокол MQTT — и ниже объясняем, почему именно его и как он встроен в архитектуру ЕЦПП.
Почему MQTT, а не привычный HTTP
HTTP — протокол, на котором работает обычный веб. Каждое сообщение требует заново установить соединение, передать служебные заголовки, получить ответ и закрыть канал. Это удобно для загрузки страниц, но расточительно для маленьких пакетов телеметрии.
MQTT устроен иначе. Устройство один раз подключается к промежуточному серверу (его называют «брокер») и дальше обменивается данными по постоянному каналу. Служебный overhead каждого сообщения — всего 2 байта вместо сотен в HTTP.
Что это даёт на практике:
Трафик. При передаче показаний датчика HTTP-сообщение весит около 1 300 байт, аналогичное MQTT-сообщение — порядка 60 байт. Разница в 20 раз. Для парка в тысячи датчиков это тысячи рублей экономии на сотовых тарифах ежемесячно.
Энергия. Батарейный датчик с HTTP разряжается за две недели; с MQTT тот же модуль работает около десяти месяцев. Для удалённых точек, где выезд на замену батареи дороже самого датчика, это критично.
Обратная связь. HTTP не умеет сам «постучаться» в устройство — приходится постоянно опрашивать сервер. В MQTT устройство подписывается на канал команд и получает их мгновенно, без опроса.
Как MQTT встроен в архитектуру ЕЦПП
Мы построили двухуровневую систему.
Локальный уровень — на пасеке. На одноплатном компьютере разворачиваются пять сервисов: база данных, бэкенд, сервис сбора данных (Collector), шлюз (Gateway) и MQTT-брокер. Датчики публикуют показания в брокер, Collector забирает их и кладёт в базу. Пасека становится самостоятельным узлом платформы.
Облачный уровень. В штатном режиме данные из локального брокера дублируются в облако в реальном времени. Заказчик видит телеметрию в централизованной системе.
Режим офлайн. Если интернет пропал, пасека продолжает работать автономно: данные копятся локально, мобильное приложение подключается к одноплатному компьютеру напрямую по Wi-Fi. Когда связь восстанавливается, накопленная телеметрия автоматически синхронизируется с облаком. Потеря интернета не означает потерю данных.
Единый стандарт для устройств разных производителей
Чтобы подключение нового оборудования не превращалось в отдельный интеграционный проект, мы зафиксировали единый формат адресации сообщений:
bsd_id / sensor_type / sensor_id
Идентификатор блока сбора данных, тип датчика и номер сенсора разделены. Любой производитель, соблюдающий этот формат, подключается к платформе без доработки ядра. Платформа обрабатывает данные одинаково, независимо от «железа».
Помимо приёма телеметрии предусмотрен обратный канал: через MQTT устройствам передаются команды настройки, добавления или удаления модулей. Один канал обслуживает и сбор данных, и управление.
Надёжность доставки заложена в протокол
MQTT предоставляет три уровня гарантии доставки (QoS): от «отправил и забыл» до «доставлено ровно один раз с подтверждением». Если устройство кратковременно потеряло связь, брокер сохраняет сообщения и передаёт их при переподключении. При аварийном отключении датчика брокер автоматически уведомляет подписчиков. Всё это работает «из коробки», без написания дополнительного кода на стороне платформы.
Что это даёт заказчику
Телеметрия поступает непрерывно, даже при нестабильной связи.
Устройства разных производителей подключаются по одному принципу.
Расходы на сотовый трафик и замену батарей сокращаются кратно.
Команды управления доставляются мгновенно, без опроса.
Масштабирование парка не требует перестройки архитектуры.
Что запомнить
Выбор MQTT: в разы меньше трафика и на порядок дольше работа от батареи по сравнению с HTTP; двусторонняя связь без постоянного опроса.
Единый формат топиков позволяет подключать оборудование любых производителей без доработки платформы.
Надёжность доставки (QoS) и буферизация встроены в протокол — не нужно писать свою логику повторной отправки.
Брокер вынесен в отдельный сервис, что изолирует нагрузку и позволяет масштабировать подключение устройств независимо от бизнес-логики.
Итог для бизнеса: непрерывный сбор данных, экономия на связи и обслуживании, быстрое подключение нового оборудования.
Именно такой подход имеет смысл использовать, когда нужно подключить к единой информационной системе парк удаленных IoT-устройств, работающих через нестабильные сети.
Если перед вашей компанией стоит похожая задача – сбор телеметрии, управление оборудованием, работа при нестабильной связи или интеграция устройств нескольких производителей, – опыт реализации MQTT-инфраструктуры ЕЦПП можно использовать как основу для проектирования такой системы.