Tech OVN

Compare

Modbus vs MQTT vs REST for energy meters

These are not competing answers to the same question. They solve different problems, and most working installations use two of them at once.

The short answer

Modbus for anything on the local network — PLC, BMS, SCADA, panel displays. It is a pull protocol, universally supported, and needs no internet.

MQTT for anything beyond it — cloud dashboards, multi-site analytics, alerting. It pushes, so it scales across hundreds of meters and works through firewalls without inbound access.

RESTfor provisioning, commissioning and occasional queries. It is the wrong tool for continuous interval data, and a meter advertising a “REST data API” is worth a second question about what it actually returns.

Most sites end up running Modbus and MQTT simultaneously — the building system polls, the analytics platform subscribes, and neither knows about the other.

Side by side

Judged on the things that decide an integration, not on protocol elegance.

ConsiderationModbus RTU / TCPMQTTHTTP / REST
DirectionPull — you poll the meterPush — meter publishesEither, depending on design
Needs internetNoNo — your own broker worksNo — your own endpoint
Native to BMS and SCADAYes — universalRarelyRarely
Good for cloud dashboardsPoor — polling doesn't scaleExcellentWorkable
Real-time events and alarmsPoor — only seen on next pollExcellentFair
Bandwidth on many devicesHigh — constant pollingLowMedium
Works across NAT / firewallsOnly within the networkYes — outbound connectionYes — outbound
Setup effort for an integratorLow — well understoodMedium — needs a brokerLow
Typical usePLC, BMS, SCADA, panelsFleet monitoring, analyticsProvisioning, one-off queries

Choosing by the job

A BMS needs live values on the panel

Modbus RTU over RS485, or Modbus TCP if there is Ethernet in the plant room. This is the path of least resistance and every BMS integrator already knows it.

You are building a dashboard across many sites

MQTT. Polling hundreds of meters over the internet does not scale, and outbound publishing avoids opening inbound access to each site.

You want alarms when something happens

MQTT or HTTP push. With polling, an event is only seen on the next cycle — which for a 15-minute poll means a 15-minute blind spot.

You are commissioning a meter on site

The provisioning interface. Set network credentials, choose the transport, configure the destination, update firmware, verify status.

You are feeding an existing ERP or reporting pipeline

HTTP push to your own endpoint. The meter posts a JSON frame on its own schedule and your pipeline ingests it without a poller.

The question worth asking any vendor

Not which protocols do you support — most will list several. Ask where the data is allowed to go. A meter that speaks MQTT only to the manufacturer's broker is not the same product as one that publishes to yours.

On Titan, every path points wherever you tell it. Modbus is local and needs no internet at all. MQTT publishes to any broker you configure. HTTP and TCP push post to endpoints you specify. None of it requires a Tech OVN server.

For integrators

Titan Communication & Integration Guide

The full register map with worked decode examples, MQTT topic scheme and command reference, JSON payload schemas and the provisioning API — enough to build the integration before raising a purchase order.

Download the integration guide

PDF · No signup required

Frequently asked questions

Use Modbus when something on the local network needs to read the meter — a PLC, a BMS, a SCADA head-end or a panel display. It is a pull protocol and every building system already speaks it. Use MQTT when data needs to reach software that is not on that network, or when you have many meters and polling each one would not scale. Most real installations use both at once, and that is normal rather than a compromise.
Yes, on hardware that supports it. Titan runs Modbus and MQTT simultaneously — the BMS keeps polling registers over RS485 or TCP while the meter independently publishes to a broker for cloud analytics. Neither path interferes with the other, which means the building system and the analytics platform do not have to agree on anything.
Usually not, and this is a common misconception. REST is excellent for configuration, provisioning and occasional queries, but polling a REST endpoint for continuous interval data is inefficient compared to Modbus locally or MQTT over a network. On Titan the REST interface is deliberately scoped to provisioning and commissioning — network setup, transport configuration, firmware updates, status and event reads — while bulk data moves over Modbus, MQTT or a push feed.
The protocol and register map are the same; the transport differs. Modbus RTU runs over a two-wire RS485 serial bus, which suits panels and long runs but is limited in speed and device count. Modbus TCP runs the same messages over Ethernet, which is faster and easier to route, and removes the need for a serial gateway. A meter with both lets you choose per site rather than per product.
Not if the meter can reach the network itself. Traditional installations put a data concentrator or protocol gateway between serial meters and the internet. A meter with built-in WiFi or Ethernet that speaks MQTT or HTTP push removes that box, along with its configuration, its failure mode and its cost.
Pull means your system asks the meter for data on a schedule you control — that is Modbus. Push means the meter sends data on a schedule it holds — that is MQTT or HTTP push. Pull is simpler on a local network. Push scales far better across many sites, works through firewalls and NAT because the connection is outbound, and delivers events when they happen rather than when you next ask.
MQTT for continuous data, because it scales across sites and does not require inbound network access to each meter. Keep Modbus available for customers whose building systems need it. Use the provisioning interface for commissioning. The important question to ask any meter vendor is whether all of that works against your own broker and endpoints, or only against theirs.

Related

Titan smart energy meter

Modbus RTU and TCP, MQTT and push — running simultaneously.

Learn More →

IoT energy meter

Cloud-connected metering without a gateway or concentrator.

Learn More →

EMS vs BMS vs SCADA

Where an energy management system fits alongside what you already run.

Learn More →

OEM & white-label metering

Hardware behind your own software, with a published integration surface.

Learn More →

Energy management system

The platform layer — dashboards, alerting and multi-site rollup.

Learn More →

Multifunction meter

Panel-mount metering with the same protocol stack.

Learn More →

Working out how to integrate metering?

Tell us what is on the other end — a BMS, your own platform, an ERP — and we'll tell you which interface to use and what it returns.

Talk to an engineerTitan specifications