Head-end systems, data concentrators and sub-metering gateways publish interval reads, registers and events from electricity, water and gas meters — next to line sensors and transformer monitors. MDM, billing, outage management and analytics each subscribe to what they need.
No card required
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
Every AMI vendor’s head-end has its own export: nightly files, a proprietary API, sometimes a database view. MDM gets reads hours later, outage management gets last-gasp events through a separate integration, and grid sensors from a third vendor land in yet another system. Every new consumer — a DER program, a customer app, a loss analysis — means one more point-to-point interface to build and maintain.
Meters report over their usual network — RF mesh, PLC (G3-PLC, PRIME), cellular, wM-Bus or M-Bus — to a head-end or concentrator; line sensors and transformer monitors report over cellular.
An adapter at the head-end, or the gateway itself, publishes interval data, registers and events over TLS to topics per region, concentrator and meter.
MDM validates and stores reads, billing takes register values, outage management follows power-fail and restore events, analytics takes everything — each independently.
Threshold rules flag voltage excursions or a silent concentrator. On-demand reads and relay requests go back to the head-end on a command topic only authorised systems may publish.
Thousands of meters per concentrator, many consumers per topic: one publish reaches MDM, billing and analytics without separate interfaces, and shared subscriptions spread the load across workers.
QoS 1 for interval data and events, persistent sessions so a consumer that restarts picks up where it left off, and a retained status for every concentrator and gateway.
Per-system credentials and topic ACLs: a sub-metering gateway publishes only its own meters, a customer app reads only its own topics, and only the head-end adapter receives commands. TLS throughout.
The live dashboard and topic monitor show which concentrators are reporting; alerts fire when a gateway goes offline (Last Will) or a reading crosses a threshold.
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/telemetryYes — most often between the head-end or gateway and the business systems. Meters themselves usually speak DLMS/COSEM, M-Bus or a vendor protocol over RF mesh, PLC or cellular, while some newer cellular meters and sub-metering gateways publish MQTT directly. ConnectMQ connects both to MDM, billing and analytics.
DLMS/COSEM is the metering data model and protocol used to read and configure meters. MQTT is a publish/subscribe transport that moves the resulting data between systems. They complement each other: the head-end speaks DLMS to the meter and publishes the decoded values over MQTT.
Add a small adapter — or use the head-end’s MQTT export if it has one — that publishes interval reads and events to ConnectMQ, and let your MDM subscribe with a persistent session and QoS 1. Other systems can subscribe to the same topics later without touching the head-end again.
Start on the Free plan — no card required — connect your first devices today and upgrade when you go live.
