Кто за что отвечает

Устройство или шлюз выступает издателем. Например, шлюз опрашивает датчик по Modbus и публикует температуру по MQTT. Брокер не опрашивает Modbus и сам по себе не строит графики: он принимает публикации и доставляет их по подпискам. Мониторинг отображает данные, а отдельный подписчик записывает историю в базу.

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

Пример схемы топиков

plant/line1/sensor-07/telemetry/temperature
plant/line1/sensor-07/state/availability
plant/line1/sensor-07/config/reporting

Согласуйте идентификаторы, единицы измерения и формат времени. В JSON можно передать {"value":23.7,"unit":"C","ts":"2026-11-09T10:00:00Z"}. Если шлюз догружает накопленные измерения после обрыва, время внутри сообщения позволит отличить старый замер от нового.

Что переживёт обрыв связи

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

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

Что проверить перед подключением парка устройств

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

Детали сессий и доставки можно сверить через спецификацию MQTT 5.0 от OASIS.