MQTT брокер

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

Когда ничего настраивать не нужно

Если у вас один хаб и все устройства подключены только к нему, чаще всего дополнительных настроек не требуется.

В таком случае используется локальный брокер mqtt://localhost.

Дополнительные MQTT брокеры

Дополнительные брокеры нужны, если одно рабочее поле должно видеть устройства другого хаба или глобального сервера.

Дополнительные MQTT брокеры
Окно добавления дополнительных MQTT брокеров
  • URL брокера — адрес подключения.
  • Имя брокера — удобное название для интерфейса.
  • Остальные поля меняйте только если понимаете их назначение.
Примеры

Другой локальный хаб

Если вы строите рабочее поле в realiot-1.local, а данные приходят с другого хаба, можно указать:

  • mqtt://realiot-office.local
  • или статический IP, например mqtt://192.168.1.100

Глобальный сервер

Если часть устройств подключена напрямую к глобальному серверу, добавьте его как отдельный брокер.

Привязки MQTT топиков

Новая часть раздела MQTT — это привязки топиков (topic bindings). Они определяют, как интерпретировать входящие MQTT сообщения.

Именно привязки говорят системе, какой топик относится к Zigbee, WiFi, Matter, LoRaWAN, Modbus или внутренним сообщениям RealIoT.
Что задаётся в привязке
  • Topic filter — шаблон MQTT топика, например zigbee2mqtt/+ или application/+/#.
  • Family — семейство протокола: internal, zigbee, wifi, matter, lora, modbus, virtual.
  • Message kind — тип сообщения: state, command, meta, availability, uplink и т.д.
  • Device SN extractor — как получить идентификатор устройства: из сегмента топика или из JSON-пути.
  • Process mode — обрабатывать как устройство или только слушать.
Process mode
  • Обрабатывать как устройство — сообщение попадёт в историю, сценарии и текущее состояние устройства.
  • Только слушать — сообщение останется доступно в мониторинге, но не будет менять состояние устройства в системе.

Это удобно, например, для служебных командных топиков, которые нужно видеть, но не нужно интерпретировать как телеметрию.

Типовые встроенные привязки
  • realiot/data/json — внутренний JSON поток RealIoT.
  • wifi/+, wifi/+/set, wifi/+/meta, wifi/+/availability — WiFi устройства.
  • zigbee2mqtt/+, zigbee2mqtt/+/set — Zigbee.
  • matter/+, matter/+/set — Matter.
  • application/+/# — LoRaWAN uplink через ChirpStack.
  • modbus/data, modbus/command/+ — Modbus.
  • realiot/command/+ — виртуальные и внутренние команды.

Мониторинг сообщений

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

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

Связь с MQTT консолью

Для ручной отправки команд и просмотра потока в реальном времени используйте MQTT консоль.

Консоль особенно полезна, если нужно:

  • понять фактический формат входящих сообщений;
  • увидеть, какой именно топик использует устройство;
  • сверить payload перед настройкой topic binding;
  • проверить командный топик до создания сценария.

Типичные ошибки

  • Указан правильный брокер, но неверный topic filter.
  • Device SN извлекается не из того сегмента топика.
  • Для LoRaWAN выбран неправильный JSON path.
  • Командный топик ошибочно обрабатывается как телеметрия.
  • Хабы находятся в разных подсетях, а вместо IP используется mDNS-имя.

✅ MQTT в RealIoT настроен правильно, когда

сообщения видны в мониторинге, устройство получает корректный Device SN, а его состояния и команды проходят через нужные topic bindings.

← Назад к справке