Switch Language

index

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

Общая схема MQTT

Проект Meshtastic предоставляет публичную MQTT-службу, к которой пользователи могут подключаться с определёнными ограничениями для обеспечения стабильности сети. Эта служба позволяет устройствам Meshtastic связываться через интернет, обеспечивая глобальную связь для удалённых сетей.

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

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

Для поддержания оптимальной производительности и защиты LoRa-сетей на публичном MQTT-сервере применяются ограничения трафика.

Политика нулевого хопа

Трафик с публичного MQTT-сервера не распространяется полностью по локальным сетям mesh. Прямо подключённые узлы получат данные, но из-за политики нулевого хопа они не распространятся дальше на другие узлы в локальной сети mesh.

Оптимизированная фильтрация трафика

При использовании PSK по умолчанию для передачи через публичный MQTT-сервер приоритет имеют только определённые portnums:

Фильтрация точности местоположения

При использовании PSK по умолчанию публичный сервер также ограничивает точность данных о местоположении для защиты конфиденциальности пользователей. На топике публикуются только пакеты позиций с неточными данными о местоположении (10–16 бит), что гарантирует отсутствие раскрытия точных деталей местоположения. Подробнее о работе точности местоположения см. раздел Position Precision.

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

Использование приватных брокеров

Не рекомендуется использовать ключ по умолчанию (PSK) на приватном брокере. Это может создать уязвимости безопасности и перегрузить mesh трафиком, поскольку приватные брокеры не применяют политику нулевого хопа, необходимую для публичных каналов. Приватные брокеры предназначены для использования с приватными каналами, где пользовательские PSK обеспечивают безопасную изолированную связь.

Интеграции с ПО

Использование или отправка пакетов напрямую в/из ПО для управления умным домом, такого как Home Assistant, или других потребителей, работающих с JSON-сообщениями.

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

Темы MQTT Topics

Если не настроена конкретная корневая тема, корневая тема по умолчанию будет msh/REGION.

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

Тема Protobufs

Шлюзовый узел будет отправлять uplink и/или downlink сырые (protobuf) MeshPackets на тему:

msh/REGION/2/e/CHANNELNAME/USERID, где CHANNELNAME — имя канала (версии прошивки до 2.3.0 публикуют на тему с /c/ вместо /e/).

Например: msh/US/2/e/LongFast/!abcd1234

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

苓????"!
    !937bed1cTanksTnk"D???05??=???aP`
    ShortFast   !937bed1c

Если encryption_enabled установлено в true, полезная нагрузка MeshPacket останется зашифрованной с использованием ключа для указанного канала.

Тема JSON

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

Если включён JSON, пакеты с следующих port numbers сериализуются в JSON: TEXT_MESSAGE_APP, TELEMETRY_APP, NODEINFO_APP, POSITION_APP, WAYPOINT_APP, NEIGHBORINFO_APP, TRACEROUTE_APP, DETECTION_SENSOR_APP, PAXCOUNTER_APP и REMOTE_HARDWARE_APP. Они затем перенаправляются на тему:

msh/US/2/json/CHANNELNAME/USERID.

Пример полученного сообщения 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"
}

Значение этих полей следующее:

Поле from таким образом может использоваться как стабильный идентификатор конкретного узла. Обратите внимание, что в прошивках до 2.2.0 это значение в JSON было знаковым, а в прошивках 2.2.0 и выше значения JSON беззнаковые.

Если полученное сообщение содержит в полезной нагрузке корректный JSON, JSON десериализуется и добавляется как JSON-объект, а не как строка с сериализованным JSON.

Вы также можете отправить JSON-сообщение на тему msh/US/2/json/mqtt/, чтобы указать шлюзовому узлу отправить сообщение в mesh.

Для этого убедитесь, что на вашем узле настроен канал Meshtastic с именем "mqtt". Включите Downlink. PSK может быть случайным, это не важно. Этот канал позволяет узлу прослушивать сообщения на теме msh/US/2/json/mqtt/.

Перезагрузите устройство после создания этого канала.

JSON-сообщение должно содержать следующие поля:

{
   "from": <decimal Node ID of MQTT node>,
   "to": <decimal Node ID of recipient for a DM (optional)>,
   "channel": <channel index (optional)>,
   "type": "type",
   "payload": {
       "key":"value"
       ...
    }
}

Поля from и payload обязательны для корректного envelope (обратите внимание, что в прошивках <2.2.20 требовалось поле sender, но теперь это не так). Поле from должно соответствовать Node ID узла, который передаст сообщение, в десятичном эквиваленте. Если Node ID (иногда называемый User ID) — !7efeee00, то десятичный эквивалент — 2130636288. Опционально вы можете указать другой канал, отличный от основного, установив поле channel в индекс канала (0–7). Кроме того, вы можете отправить прямое сообщение, установив поле to в Node ID получателя в десятичном эквиваленте. Если поле to не установлено, сообщение будет отправлено широковещательно всем узлам в mesh.

В настоящее время поддерживаются два типа сообщений: "sendtext" и "sendposition". Для типа sendtext поле payload должно быть строкой с текстом для отправки. Для типа sendposition полезная нагрузка должна быть объектом с полями latitude_i, longitude_i, altitude (опционально) и time (опционально).

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

Подробную информацию см. в настройках MQTT. Для быстрого старта читайте дальше.

uplink_enabled укажет устройству публиковать пакеты mesh в MQTT. downlink_enabled заставит устройство подписаться на MQTT и пересылать любые пакеты оттуда в mesh-сеть.

Узлы-шлюзы

Любой узел Meshtastic, имеющий прямое подключение к интернету (либо через вспомогательное приложение, либо через установленное оборудование WiFi/4G/спутниковое), может функционировать как «узел-шлюз».

Узлы-шлюзы (через код, выполняющийся в телефоне) будут содержать две таблицы для белого списка определенного трафика, чтобы он доставлялся либо в интернет, либо вниз в mesh-сеть. Пользователи, разрабатывающие кастомные приложения, смогут настраивать эти фильтры/подписки.

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

Примеры