MQTT

Два города, две отдельные сети. Каждый город общается внутри себя, но между городами mesh-связи нет.

Два города, две отдельные сети - Каждый город общается внутри себя, но между городами mesh-связи нет.

локальная mesh-связь пакет MQTT-мост

Что это такое

MQTT в Meshtastic нужен для связи mesh‑сети и интернет‑инфраструктуры. Через него нода может:

отправлять mesh‑пакеты в по сети;
получать пакеты из сети и отправлять в mesh по LoRa;
работать "мостом" для нод вокруг MQTT-ноды;
передавать данные в Home Assistant, карты, боты и другие внешние системы.

Проще говоря, MQTT делает мост между меш сетью на радиоканале и обычным интернетом.

Публичный MQTT‑сервер Meshtastic

Для Meshtastic есть ряд публичных и основных MQTT серверов к которым может подключится каждый желающий и передавать и снимать данные с передаваемые подключенным

не перегружать сеть;
не заливать локальные mesh‑сети лишними пакетами;
лучше защищать приватность пользователей;
держать под контролем объём трафика по общим каналам.

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

Ограничения публичного MQTT‑сервера

Zero‑hop policy

Трафик с публичного MQTT‑сервера не должен полноценно расходиться по локальной mesh‑сети.

На практике это значит:

напрямую подключённая к MQTT нода увидит пакет;
но дальше по локальной mesh‑сети этот пакет обычно не пойдёт.

Такой режим нужен, чтобы публичный MQTT не превращался в источник лавины трафика для всех локальных нод вокруг gateway.

Фильтрация трафика

При использовании дефолтного PSK публичный сервер приоритизирует только часть типов трафика. Обычно это:

NodeinfoApp
TextMessageCompressedApp
TextMessageApp
PositionApp
TelemetryApp
MapReportApp
RoutingApp

Это позволяет сосредоточить ресурсы сети на самом полезном трафике и не тратить эфир и брокер на всё подряд.

Ограничение точности координат

На дефолтном PSK публичный сервер также ограничивает точность геоданных. В topic попадают только позиции с грубой точностью, чтобы точные координаты пользователей не светились без необходимости.

Это сделано для приватности. Если вам нужна точная география, такое лучше делать в приватной инфраструктуре, а не в общей публичной.

Зачем всё это нужно

Такие ограничения введены не на уровне вашей ноды, а на уровне самой сети и сервера. Поэтому обычно:

обновлять прошивку только ради этой логики не нужно;
фильтрация применяется централизованно;
по мере роста сети ограничения могут становиться жёстче.

Смысл в том, чтобы публичный MQTT оставался полезным, но не ломал локальные LoRa‑сети чрезмерным интернет‑трафиком.

Private broker

Использовать дефолтный PSK на private broker не рекомендуется.

Причины:

это повышает риск утечек и других проблем безопасности;
private broker обычно не применяет zero-hop policy;
mesh может быстро получить лишний трафик и дубли;
общий публичный ключ на приватной инфраструктуре просто не даёт нормальной изоляции.

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

Но даже private broker не делает MQTT magically private. Он просто даёт вам больше контроля:

кто подключается;
кто читает topic;
какие пакеты публикуются;
какие интеграции получают доступ к содержимому.

Интеграции и автоматизация

MQTT часто используют для интеграций с внешним ПО:

Home Assistant;
Node‑RED;
пользовательские скрипты;
карты;
системы мониторинга;
свои JSON‑консьюмеры.

Когда MQTT включён, Meshtastic‑нода может uplink/downlink raw protobuf MeshPacket, которые заворачиваются в ServiceEnvelope. Для части типов пакетов данные ещё и сериализуются в JSON, чтобы внешним системам было проще их читать.

На брокер могут уходить пакеты:

от самой gateway‑ноды;
от других нод, которые она видит в mesh‑сети.

Именно поэтому Home Assistant, Node‑RED и другие подписчики часто видят данные уже в удобном для чтения виде, а не как “непонятный шифртекст”.

MQTT topics

Если root topic явно не задан, по умолчанию используется:

msh/REGION

Для каждого канала, где включён uplink и/или downlink, могут использоваться два основных типа topic.

Protobuf topic

Gateway‑нода публикует raw protobuf MeshPacket сюда:

msh/REGION/2/e/CHANNELNAME/USERID

Где:

CHANNELNAME - имя канала;
USERID - идентификатор ноды;
в прошивках до 2.3.0 вместо /e/ мог использоваться /c/.

Пример:

msh/US/2/e/LongFast/!abcd1234

Payload здесь - raw protobuf. Для отладки это не очень удобно: в mosquitto_sub вы увидите, что трафик идёт, но читать его глазами почти бесполезно.

Если encryption_enabled = true, payload MeshPacket останется зашифрованным ключом соответствующего канала.

Это наиболее близкий к “переносим шифртекст” режим, но и он не гарантирует приватность всей цепочки, если где-то рядом уже есть декодирующая интеграция.

JSON topic

JSON не поддерживается на платформе nRF52.

Если JSON включён, Meshtastic сериализует часть типов пакетов в JSON и публикует их сюда:

msh/US/2/json/CHANNELNAME/USERID

Обычно это касается таких типов:

TEXT_MESSAGE_APP
TELEMETRY_APP
NODEINFO_APP
POSITION_APP
WAYPOINT_APP
NEIGHBORINFO_APP
TRACEROUTE_APP
DETECTION_SENSOR_APP
PAXCOUNTER_APP
REMOTE_HARDWARE_APP

Это как раз тот случай, когда содержимое в broker уже становится удобным для чтения и обработки.

Пример NODEINFO_APP:

{
  "id": 452664778,
  "channel": 0,
  "from": 2130636288,
  "payload": {
    "hardware": 10,
    "id": "!7efeee00",
    "longname": "base0",
    "shortname": "BA0"
  },
  "sender": "!7efeee00",
  "timestamp": 1646832724,
  "to": -1,
  "type": "nodeinfo"
}

Что значат основные поля JSON

id - уникальный ID сообщения.
channel - индекс канала, на котором пакет был получен.
from - Node ID отправителя в десятичном виде.
payload.id - Node ID отправителя в hex‑виде.
hardware - модель железа ноды.
longname - длинное имя устройства.
shortname - короткое имя устройства.
sender - hex Node ID gateway‑ноды.
timestamp - Unix time, когда сообщение было получено.
to - Node ID получателя в десятичном виде.
-1 в поле to означает broadcast.
type - тип сообщения.

Поле from удобно использовать как стабильный идентификатор конкретной ноды.

примечание

В прошивках до 2.2.0 поле from в JSON могло быть signed, а начиная с 2.2.0 значения стали unsigned.

Если в payload уже лежит валидный JSON, он может быть десериализован как объект, а не как строка.

JSON downlink: как заставить ноду отправить сообщение

Через JSON topic можно не только читать данные, но и instruct gateway‑ноду отправить пакет в mesh.

Для этого нужен topic:

msh/US/2/json/mqtt/

Чтобы это работало:

На ноде должен быть канал с именем mqtt.
Для него должен быть включён Downlink.
PSK у этого канала может быть случайным, он здесь не критичен.
После создания канала ноду нужно перезагрузить.

Формат JSON‑сообщения:

{
  "from": 2130636288,
  "to": 1234567890,
  "channel": 0,
  "type": "sendtext",
  "payload": "hello"
}

Обязательные поля:

from
payload

Остальные зависят от сценария.

Что важно:

from должен совпадать с десятичным Node ID той ноды, которая реально будет передавать сообщение в mesh;
channel можно указать явно, если нужен не основной канал;
to нужен для direct message;
если to не задан, сообщение уйдёт как broadcast.

Сейчас обычно используются два основных типа:

sendtext
sendposition

Для sendtext payload - строка с текстом.
Для sendposition payload - объект с полями latitude_i, longitude_i, а также altitude и time, если они нужны.

Это ещё один пример того, что MQTT в Meshtastic ориентирован не на “максимальную скрытность”, а на удобную интеграцию с внешним софтом.

Базовая настройка

Для работы MQTT обычно нужно:

Подключить gateway‑ноду к интернету:
- через Wi‑Fi (network.wifi_ssid, network.wifi_psk, network.wifi_enabled);
- либо через Ethernet, если железо это поддерживает.
Настроить брокер:
- mqtt.address
- mqtt.username
- mqtt.password
Включить uplink_enabled и/или downlink_enabled на нужном канале.

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

Для большинства пользователей достаточно одного канала, обычно с индексом 0.

Gateway‑ноды

Любая нода Meshtastic, у которой есть прямой доступ к интернету, может работать как gateway‑нода. Это может быть:

нода с Wi‑Fi;
нода с Ethernet;
нода, которой интернет даёт телефон или клиентское приложение;
нода со вспомогательной сетевой инфраструктурой.

Такие gateway‑ноды обычно используют whitelist и фильтрацию, чтобы решать:

какой трафик отправлять в интернет;
какой трафик пускать из интернета обратно в mesh.

Если к одной и той же mesh‑сети подключено несколько gateway‑нод, в MQTT topic могут появляться дубли пакетов. Поэтому внешним подписчикам лучше уметь делать deduplication по packet ID.

Практические выводы

Для публичной сети MQTT полезен, но только с жёсткими ограничениями.
Для своих интеграций лучше использовать отдельную стабильную ноду.
Для приватных сценариев лучше поднимать свой broker и свои PSK.
JSON удобен для автоматизации, но не везде поддерживается.
Если после включения MQTT сеть “просела”, первым делом проверяйте объём трафика, downlink и интервалы.
Если важна приватность, исходите из того, что broker и подписчики могут увидеть уже декодированные данные.
Не полагайтесь на MQTT как на end-to-end приватный канал для DM, координат и чувствительной телеметрии.

Что это такое​

Публичный MQTT‑сервер Meshtastic​

Ограничения публичного MQTT‑сервера​

Zero‑hop policy​

Фильтрация трафика​

Ограничение точности координат​

Зачем всё это нужно​

Private broker​

Интеграции и автоматизация​

MQTT topics​

Protobuf topic​

JSON topic​

Что значат основные поля JSON​

JSON downlink: как заставить ноду отправить сообщение​

Базовая настройка​

Gateway‑ноды​

Практические выводы​

Что дальше​