Head-ends, concentradores e gateways de submedição publicam memória de massa, registradores e eventos de medidores de energia, água e gás — ao lado de sensores de linha e monitores de transformador. MDM, faturamento, gestão de interrupções e analytics assinam só o que precisam.
Sem cartão de crédito
PUBLISH ami/region-east/dc-0731/em-30418877/interval
{"start":"2026-10-22T05:45:00Z","period":"PT15M","import_kwh":0.412,"export_kwh":0.118,"v_l1":231.6,"quality":"valid"}QoS 1 · TLS 8883 · PUBACK
O head-end de cada fornecedor AMI tem sua própria exportação: arquivos noturnos, uma API proprietária, às vezes uma view no banco. O MDM recebe as leituras horas depois, a gestão de interrupções recebe os eventos de last gasp por outra integração e os sensores de rede de um terceiro fornecedor vão parar em mais um sistema. Cada novo consumidor — um programa de GD, um app para clientes, uma análise de perdas — exige mais uma interface ponto a ponto para construir e manter.
Os medidores reportam pela rede de sempre — RF mesh, PLC (G3-PLC, PRIME), celular, wM-Bus ou M-Bus — a um head-end ou concentrador; sensores de linha e de transformador, via celular.
Um adaptador no head-end, ou o próprio gateway, publica memória de massa, registradores e eventos via TLS em tópicos por região, concentrador e medidor.
O MDM valida e armazena as leituras, o faturamento pega os registradores, a gestão de interrupções acompanha eventos de falta e retorno de energia e o analytics recebe tudo — cada um de forma independente.
Regras de limite sinalizam desvios de tensão ou um concentrador em silêncio. Leituras sob demanda e comandos de corte e religação voltam ao head-end por um tópico reservado a sistemas autorizados.
Milhares de medidores por concentrador e vários consumidores por tópico: uma publicação chega a MDM, faturamento e analytics sem interfaces separadas, e assinaturas compartilhadas distribuem a carga entre workers.
QoS 1 para leituras e eventos, sessões persistentes para que um consumidor reiniciado continue de onde parou e um status retido para cada concentrador e gateway.
Credenciais por sistema e ACLs por tópico: um gateway de submedição publica só os próprios medidores, um app de cliente lê só os seus tópicos e só o adaptador do head-end recebe comandos. TLS em tudo.
O painel ao vivo e o monitor de tópicos mostram quais concentradores estão reportando; alertas disparam quando um gateway cai (Last Will) ou uma leitura cruza um limite.
ami/region-east/dc-0731/em-30418877/interval
ami/region-east/dc-0731/em-30418877/events
ami/region-east/dc-0731/status (retained)
grid/region-east/feeder-12/tx-0457/telemetrySim — principalmente entre o head-end ou gateway e os sistemas de negócio. Os medidores costumam falar DLMS/COSEM, M-Bus ou um protocolo do fabricante via RF mesh, PLC ou celular, enquanto alguns medidores celulares mais novos e gateways de submedição já publicam MQTT. O ConnectMQ liga os dois a MDM, faturamento e analytics.
DLMS/COSEM é o modelo de dados e protocolo de medição usado para ler e configurar medidores. MQTT é um transporte publish/subscribe que leva esses dados entre sistemas. Eles se complementam: o head-end fala DLMS com o medidor e publica os valores decodificados via MQTT.
Adicione um pequeno adaptador — ou use a exportação MQTT do head-end, se houver — que publique leituras e eventos no ConnectMQ, e faça o MDM assinar com sessão persistente e QoS 1. Outros sistemas podem assinar os mesmos tópicos depois, sem mexer no head-end de novo.
Comece no plano Free — sem cartão de crédito —, conecte hoje seus primeiros dispositivos e faça upgrade quando entrar em produção.
