Marcio Cunha

Integração de Dispositivos Modbus RTU com Brokers MQTT em Ambientes com Conectividade Intermitente

Descubra como conectar sensores industriais legados baseados em Modbus RTU a plataformas de nuvem via MQTT, superando quedas frequentes de rede com estratégias robustas de armazenamento local e sincronização.

Marcio Cunha•6 min
Também disponível em:EspañolEnglish
Resumo
  • Protocolos industriais antigos como o Modbus RTU dependem de cabos físicos e respostas imediatas, sofrendo em redes modernas sem fio.
  • O MQTT funciona como um sistema de correio eficiente que tolera falhas de sinal, armazenando mensagens na memória até que a internet volte.
  • Gateways locais atuam como tradutores inteligentes, convertendo comandos elétricos em pacotes leves de dados na nuvem.
  • A criação de um cache local em cartões de memória evita a perda de dados cruciais durante apagões prolongados de internet.
  • Sistemas de monitoramento residencial e industrial ganham resiliência operacional sem precisar trocar toda a infraestrutura de sensores.

O Desafio de Unir o Mundo Industrial Antigo à Nuvem Moderna

No universo da automação, é muito comum encontrar máquinas e sensores antigos que conversam apenas por um protocolo tradicional chamado Modbus RTU. Na prática, isso significa que esses dispositivos trocam informações através de cabos seriais simples, exigindo uma resposta imediata e constante para cada pergunta feita. Se o cabo falhar ou a conexão oscilar, o sistema inteiro cega instantaneamente. O problema é que, quando levamos esses equipamentos para locais remotos, fazendas ou postes na rua, a conexão com a internet nunca é perfeita. A internet cai, o sinal oscila e o engenheiro de campo sofre para manter os dados fluindo.

Para resolver esse impasse, precisamos de uma ponte tecnológica que entenda a linguagem rígida das máquinas e saiba lidar com a instabilidade do mundo real. É aqui que entra o MQTT, um protocolo de mensagens leve projetado especificamente para ambientes com conexões ruins e redes móveis intermitentes. O MQTT funciona de forma parecida com um aplicativo de mensagens instantâneas: o sensor envia o dado quando pode, e o sistema na nuvem recebe quando a rede está disponível, sem travar por causa de um sinal fraco. Unir essas duas pontes exige planejamento arquitetural, escolha correta de hardware e uma boa estratégia de armazenamento temporário.

Entendendo a Anatomia do Modbus RTU em Redes Instáveis

O Modbus RTU foi criado em uma época em que a internet sem fio nem sequer existia. Ele opera sob um modelo estrito de mestre e escravo, onde um computador central pede um dado e o sensor responde imediatamente. Na prática, se o computador pede a temperatura de um tanque e a rede móvel falha por um segundo exato naquele momento, a leitura é perdida. Não há tentativa automática de reenvio nativa no protocolo, o que transforma qualquer oscilação de sinal em um erro de leitura no painel de controle.

Além disso, o meio físico mais comum para o Modbus RTU é a linha serial RS-485, um par de fios de cobre que transmite sinais elétricos por longas distâncias, mas que sofre terrivelmente com interferências eletromagnéticas de motores e inversores de frequência. Quando combinamos essa fragilidade física com redes de celular que caem frequentemente, o resultado é um fluxo cheio de buracos. Para consertar isso, não adianta apenas tentar forçar o protocolo antigo a funcionar na marra; precisamos introduzir um intermediário inteligente na borda da rede, ou seja, um minicomputador instalado perto das máquinas.

O Papel do Gateway de Borda e o Armazenamento Local

O segredo para vencer a intermitência da internet é nunca confiar totalmente nela. Instalamos um pequeno computador local, conhecido como gateway de borda, que faz a leitura contínua dos dispositivos Modbus RTU por meio de cabos seriais curtos e protegidos. Como o gateway está fisicamente colado aos sensores, a comunicação local nunca falha por causa da operadora de celular. Ele coleta a temperatura, a pressão e o consumo de energia de segundo a segundo e armazena tudo em um banco de dados leve rodando no próprio equipamento.

Quando a conexão com a internet cai, o gateway continua trabalhando no escuro, guardando os registros na memória interna ou em um cartão de memória industrial. Na prática, isso cria uma zona de segurança contra quedas de sinal. Assim que a rede móvel ou o sinal de satélite se reestabelece, o gateway aciona o protocolo MQTT para descarregar todo o histórico acumulado em lotes organizados. O servidor na nuvem recebe os dados antigos, coloca-os na ordem cronológica correta e exibe os gráficos sem nenhuma lacuna visível para o operador humano.

Implementando a Ponte de Comunicação com Código Funcional

Para colocar a teoria em prática, podemos utilizar uma aplicação em Python rodando no gateway local que realiza a leitura Modbus e publica os dados via MQTT. Abaixo, apresentamos um script robusto que implementa lógica de reconexão e armazenamento em cache local quando o broker MQTT está inacessível.

import time
import json
import sqlite3
import paho.mqtt.client as mqtt
from pymodbus.client import ModbusSerialClient

# Configuração do banco de dados local para cache
conn = sqlite3.connect('offline_cache.db', check_same_thread=False)
cursor = conn.cursor()
cursor.execute('''CREATE TABLE IF NOT EXISTS metrics (id INTEGER PRIMARY KEY AUTOINCREMENT, payload TEXT, timestamp REAL)''')
conn.commit()

# Configuração Modbus RTU
client_modbus = ModbusSerialClient(method='rtu', port='/dev/ttyUSB0', baudrate=9600, timeout=1)
client_modbus.connect()

# Configuração MQTT
broker_address = "broker.hivemq.com"
broker_port = 1883
topic = "fabrica/sensor/temperatura"

mqtt_client = mqtt.Client("GatewayEdgeDevice")

def on_connect(client, userdata, flags, rc):
    print("Conectado ao broker MQTT com código: " + str(rc))

mqtt_client.on_connect = on_connect

try:
    mqtt_client.connect(broker_address, broker_port, 60)
    mqtt_client.loop_start()
except Exception as e:
    print("Falha ao conectar ao MQTT. Operando em modo offline.")

def flush_cache():
    cursor.execute("SELECT id, payload FROM metrics ORDER BY timestamp ASC LIMIT 50")
    rows = cursor.fetchall()
    for row in rows:
        msg_id, payload = row
        try:
            result = mqtt_client.publish(topic, payload, qos=1)
            if result.rc == mqtt.MQTT_ERR_SUCCESS:
                cursor.execute("DELETE FROM metrics WHERE id = ?", (msg_id,))
                conn.commit()
            else:
                break
        except:
            break

while True:
    try:
        # Leitura do registrador Modbus (ex: temperatura)
        result = client_modbus.read_holding_registers(address=0, count=1, slave=1)
        if not result.isError():
            val = result.registers[0]
            payload = json.dumps({"sensor_id": 1, "value": val, "time": time.time()})
            
            # Tenta enviar via MQTT ou salva no cache local
            try:
                res = mqtt_client.publish(topic, payload, qos=1)
                if res.rc != mqtt.MQTT_ERR_SUCCESS:
                    raise Exception("Erro de envio MQTT")
                flush_cache()
            except:
                cursor.execute("INSERT INTO metrics (payload, timestamp) FROM (?, ?)", (payload, time.time()))
                conn.commit()
        else:
            print("Erro na leitura Modbus")
    except Exception as ex:
        print(f"Erro no ciclo principal: {ex}")
    
    time.sleep(5)

Garantias de Entrega e Qualidade de Serviço no MQTT

O protocolo MQTT possui um recurso fundamental chamado QoS (Quality of Service), que define o nível de garantia na entrega das mensagens. No nosso cenário de conectividade intermitente, o nível QoS 1 é a escolha ideal. Na prática, isso significa que o gateway envia a mensagem e exige uma confirmação de recebimento do servidor na nuvem. Se a confirmação não chegar porque a internet caiu no meio do caminho, o gateway guarda a mensagem e tenta enviá-la novamente assim que o sinal voltar.

Outro ponto crítico é o uso de mensagens retidas, conhecidas como retained messages. Quando o gateway publica o último estado conhecido de um sensor com essa flag ativada, o broker MQTT guarda essa informação para sempre. Assim, quando um novo painel de controle se conecta à nuvem após uma reinicialização, ele não precisa esperar o próximo ciclo de leitura para saber se a máquina está ligada ou desligada; ele recebe o último valor válido imediatamente. Isso traz uma sensação de velocidade e confiabilidade para a interface do usuário, mesmo que a rede física seja instável. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Sincronização de Telemetria Industrial com Protocolos MQTT-SN em Ambientes de Borda com Conectividade Intermitente e Integração de Subsistemas de Climatização Predial com Gateways Modbus TCP e Brokers MQTT.

Considerações Finais sobre Arquiteturas Resilientes na Borda

Integrar dispositivos Modbus RTU legados em ecossistemas modernos baseados em nuvem e MQTT não precisa ser uma dor de cabeça se a arquitetura for desenhada considerando a falha de rede como um evento normal, e não como uma exceção. Ao descentralizar a inteligência e colocar um gateway com cache local na ponta, transformamos conexões intermitentes em uma preocupação menor. A tecnologia industrial pode, portanto, caminhar lado a lado com a flexibilidade da nuvem moderna, garantindo operações contínuas e seguras em qualquer lugar do mundo.