Что вообще такое MQTT

MQTT - лёгкий протокол обмена сообщениями, широко применяемый в системах IoT и автоматизации.

Вместо прямого соединения каждого устройства с каждым используется брокер.

Клиент публикует данные в определённую тему, а другие клиенты подписываются на нужные темы.

Это удобно для:

• датчиков;
• телеметрии;
• Home Assistant;
• Node-RED;
• логирования;
• автоматических уведомлений;
• соединения удалённых сетей.

Как MQTT работает вместе с Meshtastic

В обычном Meshtastic сообщение передаётся только по LoRa:

Интернет для этого не требуется.

При использовании MQTT появляется дополнительный путь:

MQTT в этом случае не увеличивает физическую дальность одного LoRa-радиомодуля.

Он создаёт IP-мост между двумя сетями.

Что такое Gateway Node

Gateway Node - Meshtastic-узел, который одновременно имеет доступ:

• к локальной LoRa mesh-сети;
• к интернету или другой IP-сети;
• к MQTT broker.

Интернет может предоставляться через:

• Wi-Fi;
• Ethernet на поддерживаемом оборудовании;
• подключённый смартфон;
• другую реализованную IP-инфраструктуру.

Не каждый Meshtastic-узел должен становиться MQTT Gateway.

Для одной локальной mesh-сети часто достаточно одного нормально работающего шлюза.

Uplink и downlink: две настройки, которые нужно понимать

Эти направления можно настраивать для каналов отдельно.

Когда нужен только uplink

Например, необходимо:

• собирать состояние аккумуляторов;
• видеть телеметрию;
• записывать историю;
• отслеживать доступность узлов;
• передавать данные в систему мониторинга.

В таком случае возврат интернет-трафика в LoRa может вообще не требоваться.

Uplink-only является хорошим вариантом, когда MQTT нужен именно для мониторинга.

Когда требуется downlink

Downlink нужен, если требуется передавать информацию из MQTT обратно в радиосеть.

Например:

• соединить два удалённых Meshtastic-сегмента;
• отправить сообщение из внешней системы;
• организовать управляемую интеграцию с автоматизацией.

Но именно downlink требует наибольшей осторожности.

Как связать две удалённые Meshtastic-сети

Рассмотрим понятный пример.

Упрощённая архитектура:

Оба шлюза должны использовать согласованные:

• MQTT broker;
• root topic;
• каналы;
• ключи канала;
• направления uplink/downlink.

Если на обоих концах нужен двусторонний обмен, соответствующим каналам требуется и uplink, и downlink.

Что будет, если интернет пропадёт

Локальная LoRa mesh-сеть продолжит работать самостоятельно.

Пропадёт только MQTT-мост между удалёнными сегментами.

MQTT через смартфон: отдельный интернет на радиомодуле не обязателен

Meshtastic позволяет использовать интернет-соединение телефона в качестве MQTT transport.

Это называется Client Proxy или MQTT Proxy.

Получается схема:

Это особенно удобно для устройств на nRF52, у которых нет собственного Wi-Fi.

В актуальном Android-приложении есть отдельный переключатель MQTT proxy on this phone. Он показывает, работает ли смартфон сейчас как MQTT-прокси, и позволяет быстро остановить передачу без изменения сохранённой конфигурации узла.

Для iOS в 2026 году также дорабатывалась логика MQTT client proxy, включая управление downlink по каналам и zero-hop injection.

MQTT Proxy и автономность

Если MQTT работает через телефон, нужно помнить, что система становится зависима от:

• Bluetooth-соединения;
• работы приложения;
• энергосбережения смартфона;
• мобильного интернета или Wi-Fi.

Для постоянной базовой точки обычно надёжнее отдельный стационарный gateway с собственной IP-связью.

Для мобильного пользователя proxy через смартфон, наоборот, может быть самым простым вариантом.

Публичный MQTT broker Meshtastic

Проект предоставляет собственный публичный MQTT broker.

Его назначение:

• общие Meshtastic-сети;
• тестирование;
• публичные карты;
• региональный обмен трафиком.

Но это не бесконтрольный глобальный транспорт.

По мере роста Meshtastic проект ввёл ограничения для защиты серверов и локальных LoRa-сетей.

Zero-hop policy

Трафик, полученный из публичного MQTT, не должен бесконечно распространяться через локальную mesh.

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

Это крайне важная защита.

Фильтрация типов пакетов

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

Это ещё один механизм ограничения нагрузки.

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

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

Это сделано не только ради нагрузки, но и ради приватности пользователей.

Почему публичный LongFast не является приватным

Стандартный публичный канал использует известные параметры и известный ключ.

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

Если требуется конфиденциальный обмен, нужен собственный секретный PSK канала.

Когда нужен собственный MQTT broker

Свой брокер полезен, когда требуется:

• полностью контролировать трафик;
• не использовать публичный сервер;
• разделить несколько собственных сетей;
• организовать закрытую инфраструктуру;
• интегрировать Meshtastic с собственными сервисами;
• вести историю;
• строить автоматизации;
• применять собственные ACL и учётные записи.

В роли брокера можно использовать, например, Mosquitto, EMQX или другую совместимую MQTT-систему.

Для домашней инфраструктуры Mosquitto часто является простым вариантом.

Но свой broker не автоматически лучше

Публичный сервер Meshtastic уже применяет механизмы защиты LoRa от чрезмерного интернет-трафика.

На собственном broker ответственность за фильтрацию ложится на владельца.

Как быстрый интернет может перегрузить медленный LoRa

Это главная инженерная проблема MQTT + Meshtastic.

MQTT работает через обычную IP-сеть с пропускной способностью, которая на порядки выше LoRa.

LoRa, наоборот, специально оптимизирована под небольшое количество коротких пакетов и большую чувствительность.

Поэтому схема:

создаёт бутылочное горлышко.

Каждый downlink-пакет:

• занимает эфир;
• конкурирует с локальными сообщениями;
• может вызвать ретрансляции;
• увеличивает Channel Utilization;
• повышает вероятность коллизий.

Когда uplink-only лучше

Если необходимо только:

• видеть батареи;
• собирать температуру;
• строить графики;
• следить за uptime;
• получать информацию о появлении узла;

downlink может не требоваться вообще.

Это самый простой способ защитить LoRa от случайной нагрузки из автоматизации.

Опасный пример с Home Assistant

Представим автоматизацию:

Если датчик меняется раз в несколько секунд, а автоматизация каждый раз отправляет LoRa-пакет, получится постоянный поток.

Поэтому для интеграций нужны:

• фильтрация;
• ограничение частоты;
• debounce;
• порог изменения;
• отправка только значимых событий.

LoRa не должна использоваться как транспорт для каждого изменения состояния домашней автоматизации.

Дубли пакетов: почему одно сообщение появляется несколько раз

В одной mesh-сети может одновременно работать несколько MQTT Gateway.

Например, один и тот же LoRa-пакет слышат два шлюза:

В итоге MQTT subscriber может получить дубликаты.

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

А может ли образоваться бесконечная петля?

При правильно работающих механизмах Meshtastic пакеты имеют идентификаторы и правила обработки, предотвращающие примитивное бесконечное повторение.

Но при создании собственных MQTT-скриптов, Node-RED flows и автоматизаций легко организовать логическую петлю:

Поэтому внешняя система должна понимать источник события и не возвращать бездумно каждое полученное сообщение обратно.

MQTT, TLS и шифрование: это разные вещи

В этой теме легко запутаться, потому что защита работает на нескольких уровнях.

Ключ Meshtastic-канала

Определяет конфиденциальность содержимого радиообмена соответствующего канала.

MQTT encryption

У Meshtastic есть отдельная настройка передачи зашифрованных payload в MQTT.

TLS

TLS защищает сетевое соединение между MQTT-клиентом и broker.

Эти механизмы нельзя считать взаимозаменяемыми.

Map Reporting и публичные координаты

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

Map Report может включать:

• имя узла;
• ID;
• координаты с настроенной точностью;
• высоту;
• аппаратную модель;
• роль;
• версию прошивки;
• регион LoRa;
• preset;
• имя основного канала.

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

Важное изменение 2026 года: старые гайды с JSON устарели

Это один из наиболее важных моментов для тех, кто ищет инструкции Meshtastic MQTT в интернете.

Раньше firmware умела публиковать некоторые типы пакетов непосредственно в JSON.

Поэтому большое количество старых инструкций строилось так:

В 2026 году ситуация изменилась.

JSON MQTT output удалён из актуальной firmware, а параметр json_enabled оставлен только как deprecated для совместимости конфигурационных структур.

Основной MQTT-формат сейчас - Meshtastic protobuf.

Почему в документации всё ещё можно встретить JSON

На момент подготовки этого материала официальная документация Meshtastic содержит страницы, которые обновлены не полностью синхронно.

Старая страница интеграции Home Assistant всё ещё показывает создание MQTT sensors через JSON и отдельно предупреждает о несовместимости такого способа с nRF52.

Одновременно актуальная Android-документация и protobuf-схема уже указывают, что JSON output из firmware удалён.

В данном случае ориентироваться нужно на актуальное состояние firmware и protobuf, а старую JSON-инструкцию рассматривать как исторический вариант.

Как интегрировать Meshtastic с Home Assistant в 2026 году

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

Вариант 1. Meshtastic → MQTT protobuf → обработчик → Home Assistant

Промежуточное приложение декодирует Meshtastic protobuf и передаёт нужные значения в Home Assistant.

Это гибкий вариант для:

• телеметрии;
• собственных сенсоров;
• больших сетей;
• логирования;
• нестандартной обработки.

Вариант 2. Специализированная Meshtastic-интеграция

Проект Meshtastic также развивает отдельную Home Assistant Integration.

Она рассчитана на прямую работу с Meshtastic-устройствами и поддерживает различные типы подключения, включая TCP, Serial и Bluetooth.

Она умеет, в частности:

• импортировать выбранные mesh-узлы;
• получать метрики;
• записывать сообщения;
• отправлять сообщения;
• получать координаты узлов.

Поэтому в 2026 году сначала стоит определить, нужен ли MQTT вообще.

Что полезно передавать в Home Assistant

Практический набор:

• напряжение батареи;
• уровень заряда;
• последнее время связи;
• температуру удалённого датчика;
• влажность;
• Channel Utilization;
• Air Utilization TX;
• координаты мобильного узла;
• статус удалённой точки.

Это особенно полезно для автономного солнечного ретранслятора.

Пример полезной автоматизации

Допустим, на крыше установлен автономный Meshtastic-узел.

Вместо передачи его напряжения каждую минуту можно:

1. получать телеметрию с разумным интервалом;
2. сохранять её в Home Assistant;
3. создать локальную автоматизацию;
4. уведомлять владельца только при снижении батареи ниже заданного уровня.

Так система остаётся информативной, но не превращает LoRa в постоянный поток служебной телеметрии.

Чего не стоит отправлять через Meshtastic MQTT

Плохие кандидаты:

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

Для таких задач существуют Wi-Fi, Ethernet, LTE и другие сети с намного большей пропускной способностью.

MQTT включён, но сообщения не проходят: что проверять

Известная проблема ветки 2.7 с отдельными gateway-устройствами

В 2026 году в официальном репозитории Meshtastic также фиксировались проблемы MQTT-конфигурации на отдельных gateway-вариантах RAK и Wi-Fi/Ethernet оборудования.

Симптомы включали:

• mqtt.enabled не сохранялся;
• proxy_to_client менялся непредсказуемо;
• после сохранения настройка возвращалась в предыдущее состояние;
• возникали проблемы API-сессии.

Поэтому если правильная конфигурация упорно не сохраняется, это не всегда ошибка пользователя. Стоит проверить точную версию прошивки и актуальные issues проекта.

Публичный или свой MQTT: что выбрать

Оптимальная схема для своего дома и удалённого объекта

Для управляемой частной инфраструктуры я бы строил её примерно так:

И главное правило:

Итог

MQTT превращает Meshtastic из изолированной радиосети в часть более крупной сетевой инфраструктуры.

Он позволяет:

• соединять удалённые LoRa-сегменты;
• собирать телеметрию;
• интегрировать сеть с автоматизацией;
• работать через публичную или собственную инфраструктуру;
• использовать смартфон в качестве временного gateway.

Но MQTT не отменяет ограничений LoRa.

Интернет практически всегда быстрее радиоканала Meshtastic, поэтому главный принцип правильной интеграции - фильтровать данные на стороне IP, а не пытаться пропустить весь интернет-трафик через LoRa.

И ещё одна важная поправка для 2026 года: старые инструкции с MQTT JSON непосредственно из firmware уже нельзя считать универсальными. Актуальная архитектура ориентируется на protobuf, а для Home Assistant появились более современные способы интеграции.