IoT industrial

Sensores Industriais Sem Fio com MQTT: Wi-Fi, LoRaWAN, WirelessHART e 5G Privado

Sensores industriais sem fio tornam barato medir o que nunca foi cabeado. Este guia compara as principais tecnologias de rádio e mostra como os dados de cada uma chegam a um único broker MQTT, com um bridge LoRaWAN para MQTT funcionando.

Sensores industriais sem fio em bombas e tanques enviando sinais de rádio para um gateway e um broker MQTT
Rode isso no seu próprio broker MQTTTenha um broker MQTT privado e gerenciado no plano Free e comece com exemplos de código prontos.
Teste grátis Exemplos de código Sem cartão de crédito

Sensores industriais sem fio permitem medir temperatura, vibração, pressão e nível em ativos que nunca foram cabeados, sem abrir valas para passar cabos em uma planta em operação. Neste guia você vai comparar as quatro tecnologias de rádio entre as quais os engenheiros de planta realmente escolhem, entender como os dados de cada uma viram mensagens MQTT e rodar um pequeno bridge em Python que encaminha uplinks LoRaWAN para uma árvore de topics estruturada.

Por Que os Sensores Sem Fio Estão Dominando os Projetos de Retrofit

Passar um cabo novo em uma planta raramente é só um cabo. Significa eletrocalhas, eletrodutos, permissões de trabalho a quente, janelas de parada e, às vezes, certificação para áreas classificadas. Para um único ponto de vibração no ventilador de uma torre de resfriamento de uma usina, a instalação pode custar muito mais que o sensor.

Os sensores sem fio mudam essa equação. Um sensor de vibração ou temperatura a bateria pode ser fixado com ímã ou prisioneiro em minutos e reporta por anos. A contrapartida é que agora você tem uma rede de rádio para projetar: alcance, autonomia da bateria, taxa de atualização e confiabilidade dependem da tecnologia escolhida.

A boa notícia é que, seja qual for o rádio, os dados acabam no mesmo lugar. Um gateway ou servidor de rede recebe os pacotes de rádio e os publica em um broker MQTT, de onde dashboards, historiadores e analytics os consomem.

Comparando Tecnologias de Sensores Industriais Sem Fio

Tecnologia Alcance típico Taxa de atualização Energia Topologia Uso típico
Wi-Fi (802.11) Dezenas de metros por access point Abaixo de um segundo é possível Rede elétrica ou bateria grande Estrela via access points Câmeras, sensores de alta taxa, dispositivos ligados na rede
LoRaWAN Quilômetros em áreas abertas, menos em ambientes internos Minutos (limitada por duty cycle) Anos com bateria Estrela via gateways Tanques, utilidades, ativos remotos, monitoramento ambiental
WirelessHART Dezenas a centenas de metros por salto Segundos Anos com bateria Malha autorregenerativa Instrumentação de processo em refinarias e plantas químicas
ISA100.11a Semelhante ao WirelessHART Segundos Anos com bateria Malha Plantas de processo padronizadas em ISA100
5G / LTE privado Todo o campus Abaixo de um segundo Rede elétrica ou bateria grande Celular Robôs móveis, AGVs, sites de alta densidade
Bluetooth Low Energy Curto Segundos Meses a anos Estrela via gateways Rastreamento de ativos, instrumentos portáteis

Sensores Wi-Fi

O Wi-Fi é a opção mais familiar e a única em que o próprio sensor normalmente fala MQTT diretamente. Um sensor baseado em ESP32 pode abrir uma conexão TLS com o broker e publicar sem nenhum gateway intermediário. A desvantagem é a energia: a associação Wi-Fi e os handshakes TLS são caros, então sensores Wi-Fi a bateria ou dormem por longos períodos ou exigem trocas de bateria frequentes. A cobertura Wi-Fi industrial também tende a ser irregular perto de estruturas metálicas. Se você vai construir o seu, o nosso tutorial de MQTT com ESP32 cobre o lado do firmware.

Sensores LoRaWAN

O LoRaWAN troca banda por alcance e autonomia de bateria. Os payloads são minúsculos, muitas vezes uma dúzia de bytes, e as regras regionais de duty cycle limitam a frequência com que um dispositivo pode transmitir. Os sensores enviam uplinks aos gateways, os gateways encaminham a um servidor de rede como ChirpStack ou The Things Stack, e o servidor de rede decodifica o payload e o expõe, muitas vezes via MQTT. O LoRaWAN é ideal para valores que mudam devagar em sites grandes: níveis de tanques, condições ambientais, hidrômetros e bombas remotas.

WirelessHART e ISA100

Esses padrões foram criados para plantas de processo. Eles formam malhas autorregenerativas, usam salto de canal sincronizado no tempo e carregam o modelo de dispositivo HART, então um transmissor de pressão sem fio aparece para o sistema de controle de forma muito parecida com um cabeado. Os dados normalmente chegam a um gateway sem fio com interfaces Modbus TCP, OPC UA ou HART-IP. Para levá-los ao MQTT, você acrescenta um gateway de protocolo, como faria com qualquer outro fieldbus.

5G e LTE Privados

Redes celulares privadas brilham quando você precisa de mobilidade, alta densidade ou cobertura determinística em um campus grande: robôs móveis, AGVs, pontes rolantes e dispositivos portáteis. Os dispositivos ganham conectividade IP e podem rodar clientes MQTT diretamente, exatamente como na rede celular pública. As questões de custo e espectro são significativas, então o 5G privado costuma chegar como parte de um projeto mais amplo do site, e não para um punhado de sensores. O comportamento da conexão é semelhante ao do MQTT sobre rede celular, incluindo a necessidade de valores de keepalive sensatos.

Como os Dados dos Sensores Sem Fio Chegam ao Broker

Há três caminhos de integração, e a maioria das plantas acaba usando mais de um:

  1. MQTT direto do dispositivo. Sensores Wi-Fi e celulares publicam direto no broker via TLS. Simples, mas cada dispositivo precisa de credenciais e de energia suficiente para o TLS.
  2. Do servidor de rede para o MQTT. Servidores de rede LoRaWAN publicam os uplinks decodificados em seu próprio broker MQTT ou integração. Um pequeno bridge os republica na árvore de topics da sua planta.
  3. Gateway mais conversor de protocolo. WirelessHART, ISA100 e muitos sistemas sem fio proprietários expõem Modbus ou OPC UA no gateway. Um gateway de borda IIoT consulta essa interface e publica em MQTT.

A decisão de projeto importante não é o rádio, e sim a estrutura de topics. Seja qual for a origem, normalize tudo em uma única hierarquia, por exemplo connectmq/site/area/asset/measurement, para que os consumidores nunca precisem saber de qual rádio veio um valor.

O script abaixo assina os eventos de uplink do ChirpStack v4 no broker do servidor de rede e republica os valores decodificados em uma árvore no estilo ISA-95 no servidor MQTT público da ConnectMQ. O ChirpStack publica os uplinks em application/<application_id>/device/<dev_eui>/event/up como JSON, com os valores decodificados no campo object quando há um codec de payload configurado.

import json
import uuid
import paho.mqtt.client as mqtt

# Origem: integração MQTT do ChirpStack (ajuste host e credenciais)
SRC_HOST = "chirpstack.local"
SRC_TOPIC = "application/+/device/+/event/up"

# Destino: broker público de testes da ConnectMQ, prefixo de demonstração único
DST_HOST = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1/utilities"

# Mapeia os device EUIs para nomes de ativos na sua hierarquia
ASSETS = {
    "a84041000181c061": "tank-farm/tank03",
    "a84041000181c062": "cooling/fan02",
}

dst = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-dst-{uuid.uuid4().hex[:6]}")
dst.connect(DST_HOST, 1883, keepalive=60)
dst.loop_start()

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected to ChirpStack:", reason_code)
    client.subscribe(SRC_TOPIC, qos=1)

def on_message(client, userdata, msg):
    event = json.loads(msg.payload)
    dev_eui = event["deviceInfo"]["devEui"]
    values = event.get("object")
    if not values:
        return  # nenhum codec configurado, nada a encaminhar
    asset = ASSETS.get(dev_eui, f"unmapped/{dev_eui}")
    rx = (event.get("rxInfo") or [{}])[0]
    for name, value in values.items():
        payload = {
            "value": value,
            "ts": event.get("time"),
            "rssi": rx.get("rssi"),
            "snr": rx.get("snr"),
        }
        topic = f"{PREFIX}/{asset}/{name}"
        dst.publish(topic, json.dumps(payload), qos=1, retain=True)
        print(topic, payload)

src = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"lora-bridge-src-{uuid.uuid4().hex[:6]}")
src.on_connect = on_connect
src.on_message = on_message
src.connect(SRC_HOST, 1883, keepalive=60)
src.loop_forever()

Acompanhe a saída em outro terminal:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM \
  -t 'connectmq/demo/+/site1/#' -v

Alguns detalhes valem ser levados para produção. As mensagens são retidas, então um novo dashboard vê imediatamente o último nível do tanque em vez de esperar o próximo uplink, que no LoRaWAN pode estar a quinze minutos de distância. A qualidade do rádio (RSSI e SNR) viaja junto com cada valor, o que facilita identificar um sensor cuja antena levou uma pancada. E dispositivos desconhecidos caem em unmapped/, então aparecem em vez de sumir silenciosamente. Em produção, mude o destino para a porta 8883 com TLS e as suas credenciais da ConnectMQ, e use o servidor MQTT público apenas para testes, já que tudo ali pode ser lido por qualquer pessoa.

Dicas Práticas para Implantar Sensores Sem Fio

  • Faça um levantamento antes de comprar. Percorra o site com um gateway ou access point de teste. Tanques de aço, concreto e máquinas em movimento mudam drasticamente a cobertura.
  • Ajuste a taxa de atualização à física. Um nível de tanque que muda ao longo de horas não precisa de atualizações a cada segundo. Taxas menores significam baterias que duram mais.
  • Publique por exceção no gateway. Encaminhe um valor apenas quando ele mudar de forma significativa e use retained messages para o estado atual. O nosso guia de report by exception explica os limites.
  • Monitore os sensores, não só o processo. Tensão da bateria, horário da última comunicação e intensidade do sinal merecem seus próprios topics e regras de alerta.
  • Planeje as lacunas. Links sem fio caem. Os consumidores devem tratar um timestamp desatualizado como dado ausente, e não como o último valor conhecido.

Um Broker Que Atende Todos os Rádios

Como todas as tecnologias de rádio convergem para o MQTT, o broker se torna a peça da qual todas as equipes dependem. Um broker MQTT gerenciado como a ConnectMQ oferece endpoints TLS, um explorador de topics ao vivo para verificar se cada sensor está chegando ao lugar certo e regras de alerta por limite para valores como bateria baixa ou vibração alta. A visão de dispositivos agrupa os topics por níveis ISA-95, uma forma prática de conferir se os dados de LoRaWAN, Wi-Fi e WirelessHART seguem a mesma hierarquia. Com todos os rádios em um único namespace, fica simples alimentar um gêmeo digital da planta. Para o contexto mais amplo, leia o guia de IoT industrial com MQTT.

Conecte Seus Sensores Sem Fio à ConnectMQ

Cadastre-se em app.connectmq.com e crie um broker Serverless gratuito, sem cartão de crédito. Aponte o seu bridge ou gateway para ele com as credenciais geradas e depois use o explorador de topics ao vivo e o dashboard da ConnectMQ para ver os dados dos seus sensores sem fio chegando a um namespace estruturado único.

Perguntas frequentes

Qual tecnologia sem fio é a melhor para sensores industriais?

Depende da tarefa. O LoRaWAN atende valores que mudam devagar, em longas distâncias e com bateria; o WirelessHART atende instrumentação de processo em redes em malha; o Wi-Fi atende dispositivos ligados na rede ou de alta taxa; e o 5G privado atende equipamentos móveis e campi densos.

Sensores LoRaWAN conseguem publicar MQTT diretamente?

Não. Dispositivos LoRaWAN enviam pequenos pacotes de rádio aos gateways, e o servidor de rede os decodifica. O servidor de rede, ou um bridge como o deste guia, então publica os valores decodificados via MQTT.

Como levo os dados WirelessHART para o MQTT?

Gateways WirelessHART normalmente expõem Modbus TCP, OPC UA ou HART-IP. Um gateway de borda consulta essa interface e publica os valores no seu broker MQTT.

Os valores dos sensores sem fio devem ser retained messages?

Normalmente sim para valores de estado atual, como níveis e temperaturas, porque novos assinantes recebem o último valor na hora. Não retenha mensagens do tipo evento, como alarmes, que devem ser vistas apenas uma vez.

Artigos relacionados

Cliente MQTT no CODESYS: Publicando Variáveis do CLP em um Broker

Configure a biblioteca IIoT MQTT Client do CODESYS para publicar variáveis do CLP em JSON, verifique-as no servidor MQTT público broker.connectmq.com e depois migre para um broker privado com credenciais e TLS.

8 min de leitura

Todos os artigos →

Seu broker MQTT privado está a poucos cliques de distância

Crie uma conta, receba as credenciais do seu broker e conecte seu primeiro dispositivo — sem servidores para instalar, atualizar ou escalar.