MQTT no Meshtastic: Guia Rápido pra Não Detonar a Rede e o Dispositivo
Por Que o MQTT Existe no Meshtastic
O Meshtastic nasceu em 2020, criado por Kevin Hester, com uma premissa clara: comunicação de longo alcance via rádio LoRa, sem depender de infraestrutura. Mensagens saltam de nó em nó, formando uma mesh que funciona mesmo sem celular, sem Wi-Fi, sem internet.
Mas aí vem a realidade. O rádio LoRa tem limites físicos. Típico são 2 a 5 km em área urbana, chegando a dezenas de quilômetros com visada direta e boas antenas. O recorde da comunidade é 331 km - mas isso é exceção, não regra. Entre duas cidades sem repetidores no caminho, uma serra no meio, ou uma área rural isolada… o rádio simplesmente não alcança.
Foi pra resolver isso que o MQTT foi adicionado ao projeto. A ideia central: usar a internet como ponte entre meshes que o rádio não consegue conectar. Um nó com acesso à internet (via Wi-Fi ou via proxy do celular) publica o tráfego da mesh local em um servidor MQTT. Outro nó, em outra região, se conecta ao mesmo servidor e injeta essas mensagens de volta na mesh local. O resultado é que nós em cidades diferentes se comunicam como se estivessem no mesmo bairro.
Não é só extensão de alcance. O MQTT também abre porta pra outras coisas:
- Monitoramento remoto - acompanhar posição e telemetria dos nós de casa, via Home Assistant ou Grafana
- Integração com IoT - conectar dados da mesh a dashboards, automações, bots
- Mapa global - o recurso de Map Reporting permite que nós apareçam em mapas online, mostrando posição, hardware e firmware
- Contingência - em cenários onde uma região tem internet e outra não, o MQTT permite que a região conectada sirva de ponte
Mas aqui mora o problema: o MQTT é opcional, e muita gente ativa sem entender como funciona. O resultado é o cenário mais comum de dor de cabeça na comunidade - nó recebendo dezenas de milhares de pacotes, app crashando, mesh local degradada. Tudo porque alguém ligou o MQTT no canal errado com o tópico errado.
Esse post existe pra que você use o MQTT como ele foi pensado: como ponte, não como bomba.
O Cenário: Quando o Rádio Não Alcança
Você montou sua mesh local. Tudo funcionando - mensagens chegando, telemetria subindo, nós se vendo. Mas aí você quer alcançar um pessoal que está do outro lado da serra, em outra cidade, ou em um estado onde não tem nenhum nó repetidor no caminho. O rádio LoRa não alcança. E agora?
O LoRa é incrível pelo que é: comunicação de longo alcance sem infraestrutura. Mas tem limites físicos. Alguns cenários comuns:
- Cidades separadas por serras ou florestas - sem repetidores no caminho, não há hop que resolva
- Comunidades rurais isoladas - a mesh local funciona entre si, mas não alcança a próxima vila
- Família distribuída em cidades diferentes - cada um tem sua mesh local, mas estão fora do alcance de rádio
- Emergências em áreas sem cobertura celular - a mesh local está no ar, mas você precisa alcançar alguém em outra região que tenha internet
Em todos esses casos, o cenário é o mesmo: a mesh funciona localmente, mas as regiões estão desconectadas entre si. O MQTT resolve isso usando a internet como "cabamento invisível" entre as meshes.
Como o MQTT Funciona como Ponte
O fluxo é simples na teoria:
Mesh Local A → Gateway MQTT → Broker na Internet → Gateway MQTT → Mesh Local B
Um nó com acesso à internet (via Wi-Fi ou proxy do celular) atua como gateway. Ele pega as mensagens da mesh local e publica em um servidor MQTT (broker). Outro gateway em outra região se inscreve no mesmo tópico e injeta as mensagens na mesh local de lá.
O resultado? Nós em regiões diferentes se veem e trocam mensagens como se estivessem na mesma mesh - mesmo que estejam a centenas de quilômetros de distância.
O que trafega pela ponte
Depende da sua configuração, mas tipicamente:
- Mensagens de texto (canais com uplink/downlink ativado)
- Telemetria (bateria, sinais, posição)
- Map reporting (posição no mapa, se habilitado)
Tudo continua criptografado com a chave do canal - o broker MQTT vê pacotes, mas sem a chave PSK, o conteúdo é ilegível (se você manteve a criptografia ativada).
Tópicos: O Filtro que Separa o Sinal do Ruído
Esse é o ponto mais importante do post. O MQTT organiza o tráfego em tópicos (topics) com esta estrutura:
- Base:
msh/ - Região:
{região}/ - Índice do canal:
{índice_canal}/ - Codificação:
{codificação}/ - Nome do canal:
{nome_canal}/ - ID do nó:
{node_id}
O root topic define o escopo do que seu nó vai receber. Pense nisso como um filtro de bairro:
- ❌ Root topic genérico + canal LongFast → Você recebe pacotes de milhares de nós do mundo inteiro
- ✅ Root topic regional (
msh/BR/BA/) → Você recebe pacotes da sua região - manejável - ✅ Canal privado com tópico específico → Só quem está no seu canal e tópico - ideal para ponte
Fonte: Jkpg Mesh
O perigo do tópico amplo
Se você ativar MQTT no canal LongFast padrão com o root topic genérico do broker público, seu nó vai receber dezenas de milhares de pacotes por hora. Isso não é exagero - é o problema mais reportado na comunidade:
- O app crasha por sobrecarga (especialmente no iOS)
- O nó congela e para de responder
- A mesh local é degradada pelo tráfego injetado
- Você não consegue nem abrir o app pra reverter
Um usuário reportou o app recebendo mais de 50.000 pacotes - impossibilitando qualquer configuração.
Regra de ouro: Quanto mais específico o tópico, menos ruído. Para ponte entre regiões para uso pessoal, use um canal privado com um tópico restrito ao seu grupo.
Os Problemas que o MQTT Mal Configurado Causa
Antes de sair configurando, é importante entender o que dá errado quando o MQTT é ativado sem critério. Esses não são problemas teóricos - são casos reais reportados diariamente na comunidade:
Crash do app por flood de pacotes
O problema mais comum. Um usuário ativa MQTT no canal padrão com tópico amplo, e o nó começa a receber pacotes de milhares de nós. Em um caso reportado no Reddit, o app iOS recebia mais de 50.000 pacotes, fazendo o app crashar repetidamente - impossibilitando até mesmo abrir as configurações para reverter.
Degradação da mesh local
Quando um nó com MQTT mal configurado injeta tráfego excessivo na mesh local, o canal de rádio fica congestionado.
O Meshtastic usa uma métrica chamada channel utilization - o tempo que o canal de rádio está ocupado transmitindo dados, medido em porcentagem. Em condições normais, a utilization fica baixa (poucos por cento). Quando sobe demais, o canal fica congestionado e as mensagens demoram pra passar - ou simplesmente não passam.
Na comunidade do sul de Gales, a utilization do canal local disparou para mais de 50 segundos por causa de nós vizinhos com MQTT configurado incorretamente - afetando toda a mesh da região.
Confusão com as opções do firmware
O firmware tem duas opções que geram dúvida constante e estão em lugares diferentes da configuração:
oktomqtt (configuração do nó, em Settings → Device Configuration) Controla se o nó permite que seus pacotes sejam enviados via MQTT. Se desativado, o nó não publica nada no broker - mesmo que o gateway local esteja conectado. É uma configuração por nó, pensada pra dar ao dono do nó controle sobre seus dados. A partir do firmware 2.5, pacotes de nós com oktomqtt desativado são ignorados por mapas e serviços públicos.
ignore_mqtt (configuração do canal, em Settings → Channels → [canal]) Controla se o nó ignora mensagens recebidas via MQTT naquele canal específico. Se ativado, o nó envia pacotes pro broker (uplink funciona) mas descarta tudo que vem do broker (não recebe downlink). Útil pra quem quer contribuir com a rede sem ser inundado por tráfego externo.
A confusão acontece porque as duas opções parecem fazer a mesma coisa (controlar MQTT) mas atuam em níveis diferentes: uma no nó todo, outra no canal. E não existe um guia no app que explique a diferença.
Nós visíveis mas sem comunicação
Um problema que se agrava com MQTT: você vê um nó na lista com timestamps atualizados, mas não consegue enviar mensagens, traceroute, ou obter resposta. O nó está "ali" na lista, mas a qualidade do sinal é tão ruim que nenhuma comunicação real acontece. O MQTT pode dar a falsa impressão de conectividade que não existe de verdade.
Região errada no Brasil
Alguns usuários não sabem qual região/frequência usar no Brasil. O consenso da comunidade é claro: ANZ (915-928 MHz) é o padrão nacional. Configurar a região errada significa que seu nó não consegue falar com a rede brasileira, e o MQTT não resolve isso.
O Servidor MQTT do Meshtastic Brasil
A comunidade brasileira (meshbrasil.com) mantém um broker MQTT próprio que complementa o servidor oficial. Existe uma ponte entre o tópico msh/BR no broker oficial e o tópico meshdev no broker brasileiro - não importa qual você use, as mensagens chegam nos dois.
Para instruções completas de configuração do servidor MQTT brasileiro, consulte a página Junte-se à Rede no site da comunidade. Lá você encontra as credenciais, o passo a passo para app e CLI, e tudo o que precisa pra conectar seu nó.
Prefere usar o broker oficial? Aponte para mqtt.meshtastic.org com root topic msh/BR.
A comunidade brasileira se encontra no Telegram: @meshtasticbr. Confira também o mapa Meshtastic Brasil pra ver os nós online.
Preocupações de Segurança
O MQTT conecta sua mesh local à internet. Isso traz poder, mas também traz risco. É importante entender as implicações antes de ativar.
Exposição à internet
Quando seu nó está conectado ao broker MQTT, ele está acessível globalmente. Qualquer pessoa conectada ao mesmo broker e tópico pode ver os pacotes trafegando. Se a criptografia do canal estiver desabilitada, as mensagens trafegam em texto limpo - qualquer um no broker pode ler.
Vulnerabilidades no firmware
Se uma vulnerabilidade for descoberta no firmware do Meshtastic, um nó conectado ao MQTT está mais exposto. Ele está na internet, recebendo pacotes de fontes que não estão no alcance físico de rádio - ou seja, um atacante não precisa estar perto de você para explorar a falha. Pode estar do outro lado do mundo. Caso real: CVE-2024-45038, uma vulnerabilidade de crash via pacote malformado, corrigida no firmware 2.4.1.
O broker público é de todos
O broker oficial (mqtt.meshtastic.org) é público e gratuito. Qualquer pessoa pode se conectar e inscrever nos tópicos regionais. Em agosto de 2024, o projeto Meshtastic teve que restringir o acesso a tópicos globais porque sites de mapas de terceiros estavam rastreando e armazenando posições de nós sem o conhecimento dos usuários. Isso mostra que o risco é real - não teórico.
Riscos do JSON enabled
Ativar JSON no MQTT envia pacotes sem criptografia, legíveis por qualquer sistema. Isso é útil para integração com Home Assistant e dashboards, mas significa que qualquer pessoa no broker pode ler o conteúdo. Nunca use JSON enabled em canais com comunicação sensível.
Como se proteger
- Sempre ative encryption_enabled - sem isso, tudo trafega em texto limpo
- Prefira canais privados com PSK aleatório para comunicação sensível
- Considere um broker próprio se privacidade é crítica (Mosquitto ou HiveMQ com TLS)
- Desative MQTT se você não precisa de ponte entre regiões - a mesh via rádio é mais segura por natureza
- Mantenha o firmware atualizado - vulnerabilidades são corrigidas com frequência
Broker: Público vs. Próprio
O broker público do Meshtastic (mqtt.meshtastic.org) é gratuito e funciona bem para a maioria dos casos. Mas há motivos para considerar um broker próprio:
- Custo: Público é grátis. Próprio requer VPS barato (~$5/mês)
- Privacidade: Público - qualquer um pode se conectar. Próprio - controle total
- Tráfego: Público - compartilhado com milhares de nós. Próprio - só o seu grupo
- Configuração: Público - zero. Próprio - Mosquitto/HiveMQ + TLS
- Estabilidade: Público - depende do projeto. Próprio - você controla
Para pontes entre regiões com canais privados e criptografia ativada, o broker público é seguro o suficiente. Se a operação é sensível (emergências, segurança), rode seu próprio.
O que Fazer e o que Evitar
✅ Faça
- Prefira canais privados com PSK aleatório para a ponte
- Restrinja o root topic ao seu grupo/região
- Ative encryption_enabled - sempre
- Um gateway por mesh - não precisa configurar todos os nós
- Teste antes de expandir - comece com dois gateways e confirme que funciona
💡 Iniciativa: Expandindo a Rede na Sua Região
Se você quer ajudar a crescer a rede Meshtastic na sua região, uma das contribuições mais valiosas é montar um gateway fixo com Wi-Fi. Um nó ESP32 (Heltec, T-Beam, T-Deck, Station G2, M5Stack C6L) conectado ao seu roteador e com MQTT configurado serve de ponte 24/7 para toda a mesh local. Quem tiver interesse, a comunidade no Telegram (@meshtastic_br) pode ajudar com orientações.
❌ Evite
- Ativar MQTT no canal LongFast padrão - o firmware bloqueia isso no gateway, e com boa razão
- Usar root topic genérico - você vai inundar sua mesh com tráfego do mundo inteiro
- Configurar MQTT em todos os nós - desperdício e saturação da rede. Um gateway por mesh basta
- Desativar encryption_enabled - suas mensagens trafegam em texto limpo no broker
- Usar JSON enabled em canais privados - expõe dados sem criptografia
Quando Não Usar MQTT: A Escolha pelo Off-Grid Puro
Muitas pessoas na comunidade fazem uma escolha consciente de não usar MQTT - e o motivo vai além de configuração ou conveniência.
O Meshtastic foi criado com um princípio fundamental: comunicação sem depender de nenhuma infraestrutura. Sem torres de celular, sem provedor de internet, sem servidor central. A mesh via rádio LoRa é, por natureza, descentralizada e autossuficiente.
O MQTT, por definição, depende da internet. Ele conecta sua mesh a um servidor central (broker), que por sua vez depende de infraestrutura de rede. Para muitos na comunidade, isso vai contra o espírito do projeto - a ideia de que sua comunicação deve funcionar mesmo que toda a infraestrutura moderna falhe.
E essa é uma posição válida. A mesh via rádio funciona muito bem sem MQTT. Mensagens locais chegam, telemetria funciona, a rede se sustenta sozinha. Se todos os nós estão no alcance de rádio, MQTT é completamente desnecessário.
A decisão de usar ou não MQTT depende do seu caso de uso:
- Precisa conectar regiões distantes? MQTT faz sentido como ferramenta pontual
- Sua mesh local já resolve? Não precisa de MQTT
- Você acredita que comunicação deve ser 100% off-grid? MQTT não é pra você - e tudo bem
O importante é entender que MQTT é uma opção, não um requisito. A mesh funciona sem ele, e muita gente prefere assim.
Dica Final
O MQTT é uma ferramenta poderosa, mas é como uma estrada: conecta pontos distantes, mas se todo mundo jogar o tráfego na mesma pista, engarrafa. Use canais privados, tópicos restritos, e gateways dedicados. Sua mesh (e a dos outros) agradece.
Baseado em problemas reais reportados pela comunidade Meshtastic no Reddit e Telegram, e na documentação oficial do projeto.