LoRaWAN, Modbus, MQTT, Pulse: A Plain-English Guide to Meter Data

If you've ever tried to get data out of the meters and sensors in your building, you've run into an alphabet soup: LoRaWAN, Modbus, MQTT, pulse outputs, BACnet, and more. Vendors throw these terms around as if everyone knows them, and the confusion is often what stalls a monitoring project before it starts. Here's a plain-English guide to what these protocols actually are, where you'll encounter them, and — importantly — why, with the right platform, you shouldn't have to care.

Why there are so many protocols

Meters and sensors are made by hundreds of manufacturers over many decades, for many purposes. Each generation and each vendor picked a way to communicate that made sense at the time. The result is that a real building accumulates a mix — an old pulse meter here, a Modbus power meter there, some newer wireless sensors, a gateway pushing data to who-knows-where. There's no single standard because the installed base is a museum of every standard.

That's the reality a monitoring platform has to deal with. Let's demystify the main ones.

Pulse outputs

What it is: The simplest of them all. A pulse meter emits an electrical pulse for each unit of energy (or water, or gas) it measures — say, one pulse per kWh. Count the pulses over time and you know the consumption.

Where you'll find it: Extremely common on older and inexpensive meters — utility-style meters, water meters, gas meters, and basic submeters.

In plain English: It's a meter tapping out its usage like a heartbeat. Simple, reliable, and everywhere — but it only tells you a running count, not rich detail like voltage or power factor.

Modbus

What it is: A decades-old industrial communication protocol (in flavors like Modbus RTU over serial wiring and Modbus TCP over Ethernet) that lets devices share detailed data by reading numbered "registers."

Where you'll find it: The workhorse of industrial metering. Most power meters, PLCs, drives, and building equipment speak Modbus. If you have a proper power meter in a panel, there's a good chance it talks Modbus.

In plain English: A common industrial language that lets a meter report rich data — power, voltage, current, power factor, energy — not just a pulse count. Widely supported, but the specifics vary by device, which is where integration effort usually goes.

LoRaWAN

What it is: A modern wireless protocol designed for long range and very low power. Sensors send small packets of data over long distances to a gateway, running for years on a battery.

Where you'll find it: Increasingly common for retrofit sensing — wireless energy sensors, and especially vibration and condition-monitoring sensors where running wires would be impractical.

In plain English: Long-range, battery-powered wireless. Perfect for adding sensors to hard-to-reach equipment without pulling conduit — mount it, and it quietly reports for years.

MQTT

What it is: A lightweight messaging protocol widely used in IoT. Devices "publish" data to a broker, and systems that care "subscribe" to it. It's less a meter protocol than a way of moving data around efficiently.

Where you'll find it: Modern gateways and IoT systems, including many that aggregate other protocols and then push the combined data onward over MQTT.

In plain English: A modern postal system for data. Sensors drop messages in the box; interested systems pick them up. It's how a lot of newer equipment ships its data to the cloud.

Others you might meet

• BACnet — the dominant protocol in building automation (HVAC, lighting controls). If your data comes from a building management system, it's often BACnet.
• JSON over HTTP/API — many newer devices and cloud services simply push data as JSON to a web endpoint. Flexible and modern.

Why you shouldn't have to care

Here's the punchline: the protocol is a plumbing detail, and choosing your monitoring platform based on which protocol you happen to have is a trap. The value you want — knowing what your loads cost, catching waste, spotting failures — has nothing to do with whether the data arrived over Modbus or MQTT.

A hardware-agnostic platform exists precisely to make the protocol irrelevant to you. It speaks all of these languages, ingests from each source, and normalizes the different units, scales, and formats into one consistent model. Your pulse water meter, your Modbus power meter, your LoRaWAN vibration sensor, and your MQTT gateway feed all land in one place, translated into a common picture. You stop thinking about protocols and start thinking about your facility.

The alternative — a platform locked to one protocol or one vendor's hardware — forces you to either replace everything that doesn't match or run multiple disconnected tools. Both are expensive and unnecessary.

A worked example

A plant has a decade-old Modbus power meter on its main, a couple of pulse meters on water and gas, and it wants to add wireless vibration sensors (LoRaWAN) to its critical compressors, plus it already has a gateway pushing some data over MQTT. Under a hardware-locked model, that's potentially three or four separate systems. Under a hardware-agnostic platform, all of it flows into one unified view — the operator sees energy, water, gas, and vibration together and never once thinks about the underlying protocols. Adding a new sensor later is just "point it at the platform," regardless of how it talks.

Common questions

Do I need to know which protocol my meters use? Not really — a hardware-agnostic platform figures that out. It helps to have a rough inventory, but you don't need to become a protocol expert.

What if I have a really old or obscure meter? Pulse and Modbus cover the vast majority of older devices, and both are well supported. Genuinely obscure devices can usually be bridged with a gateway.

Is wireless (LoRaWAN) reliable enough for real monitoring? Yes — it's purpose-built for reliable, low-power sensing at range, which is exactly why it's become the standard for retrofit vibration and energy sensors.

The bottom line

The protocol alphabet soup — LoRaWAN, Modbus, MQTT, pulse, BACnet — is just the different languages your meters happen to speak. It shouldn't dictate your monitoring strategy or stall your project. A hardware-agnostic platform speaks all of them and hands you one clean picture, so you can focus on your facility instead of its plumbing.

OptimizeOS ingests pulse, Modbus, LoRaWAN, MQTT, and JSON sources into one unified model — so the protocol is our problem, not yours.

Book a demo → or see the platform →.