Choosing the right protocol
Nearly every device can be read in more than one way, and the choice is paid for later: in the reading interval, in how stable the link is, and in what it costs to add the twentieth site.
Connecting a plant nearly always starts from the wrong question. It is not “which protocols do you support”, it is “what has to come out of this device, how often, and who else is already reading it”. Answer those three and the protocol mostly falls out on its own, and the choice stops being a preference.
You do not choose the protocol, the site does
A power analyser fitted into a panel in 2014 exposes what it exposes. A PV inverter has its interface and will never have another. A fiscal heat meter has a regulated output and a contract behind it. In the large majority of cases the choice is not between every protocol in existence: it is between the two or three that device already carries.
That changes the order of work. First inventory what is there and what it exposes, then decide how to read it. The reverse order — pick the architecture, then look for devices that fit it — leads to hardware replacements nobody budgeted for.
Start from the data, not from the port
Before looking at terminal blocks, write down what has to arrive at the other end. Three lines per device:
- The quantity and its unit: active energy in kWh, power in kW, temperature in °C. Not “the meter data”.
- The interval at which reading it makes sense: quarter-hourly for a plant load, per second for a transient you are investigating.
- Who else is already reading it, and whether they will share the device or insist on having it to themselves.
The third line is the one most often skipped and the one that costs most. Many serial devices tolerate a single master: if the supervision system is already polling them, your second master does not join in, it collides.
Modbus, and why in doubt it is the answer
Modbus is old, minimal and carries no semantics: it reads numbered registers, not quantities with names. That is exactly why everyone implements it, and why it remains the lowest common denominator across power analysers, meters, PLCs and inverters.
The price is that the register map is not in the protocol, it is in the device manual. Every connection brings a table with it: address, data type, byte order, scaling factor. It is dull work, but finite, and it is done once per model rather than once per unit — which is why it belongs somewhere other than the drawings of a single site.
The two variants pick themselves: RTU over serial, when the device only has a two-wire line and lives on a shared bus; TCP when it has an Ethernet port and an address. They are not two protocols, they are one protocol over two transports, and the practical difference is entirely in how many devices have to wait their turn.
Field note
On a shared serial bus the bottleneck is not line speed, it is how many requests a second the slowest devices can serve. A bus with twenty nodes and one elderly meter among them runs at the pace of the elderly meter.
When Modbus is not enough
There are three cases where insisting on Modbus is a mistake: when the quantity is not electrical, when the semantics matter more than the number, and when the device belongs to a world that already has its own standard.
| Protocol | When it is the right choice | What it adds |
|---|---|---|
| M-Bus | Heat, gas and water meters | The non-electrical vector, with the meter identity and the unit already in the telegram |
| OPC-UA | Line supervision, machine historians | Names, types and structure: you read a quantity called what it is called, not register 40012 |
| BACnet | Building controls, air handlers, plant rooms | The object model of the thermal plant, as it already is in the controller |
| SNMP | UPS, PDUs, network equipment | Infrastructure state and alarms, in the language the IT side already speaks |
| IEC 60870-5-104 | Telecontrol, remote stations | Timestamping at source and handling of spontaneous events |
For an energy audit the heaviest row is the first. An audit is done per vector, and heat, gas and water do not speak Modbus: without M-Bus you measure electricity and estimate the rest, which is precisely what an audit resting on measured data cannot do.
The reading interval is a decision, not a default
The interval follows the phenomenon, not the capability of the link. Plant consumption is read quarter-hourly because that is the interval the tariff is built on and the one the baseline will be compared against. A start-up transient simply does not exist at quarter-hourly resolution: either you read it per second or you are not measuring it.
Reading everything per second “to be safe” looks prudent and is not. It multiplies the load on the bus, fills the history with points nobody will look at, and above all adds no information: a meter that integrates internally over fifteen minutes returns the same value fifteen times, not fifteen values.
The working rule is the longest interval that still describes the phenomenon you need to see. If a decision is taken hourly, measuring by the minute is already generous.
Three mistakes that surface six months in
Byte order taken for granted. A 32-bit value read with the words swapped does not raise an error: it returns a number. Wrong by orders of magnitude, but plausible enough to reach a report. It is checked once, by comparing the reading against the device display, and then never again.
The totaliser that rolls over. A counter has a full scale, and on reaching it starts again. If consumption is computed as the difference between consecutive readings, that roll produces a huge negative figure or — worse — is silently discarded and leaves a hole. It is handled when the reading is designed, not when it happens.
The address left to chance. A device that takes its network address automatically will change it eventually, and the link stops working without anyone having touched anything. The same holds for node addresses on a serial bus: undocumented, they get reassigned by the first maintenance visit.
Before connecting
A short list, once per site:
- An inventory of devices with make, model and the interfaces actually fitted — not the ones in the catalogue.
- For each: the quantities to read, with unit and interval.
- Who else polls that device today, and in what role.
- The register or point map, verified on a real unit against the display.
- What the system does when a device does not answer: a declared gap is data, a silent zero is an error that will end up in the totals.
The last line is what separates a connection done properly from one that appears to work. A measured plant also produces the information of when it did not measure, and that information is kept alongside the rest.
Not sure which of these applies to you?
A 30-minute technical call to work out where you stand on the thresholds and what measuring would take. No commitment.