Why does my Modbus value look wrong?
Almost always one of four things. If it is exactly ten or a hundred times too big, the device reports tenths or hundredths and you need a multiplier. If it is a huge number like 65524 where you expected a small negative one, it is a signed value being read as unsigned. If it is wild nonsense — 3.6×10-41 or 2.4×1031 — it is a 32-bit value whose two halves are in the other order, and switching ABCD to CDAB will fix it. If it is a sensible-looking number belonging to something else entirely, your address is off by one.
Ten or a hundred times too big
You expected 72.4 and got 724. The device is reporting tenths, which is the most widespread convention in Modbus equipment: it gives one decimal place without needing floating-point maths, which mattered a great deal in 1985 and still matters on cheap hardware.
The fix is a multiplier of 0.1 (or 0.01 for hundredths). Occasionally it goes the other way — a device reporting kilowatts where you wanted watts needs a multiplier of 1000.
A huge number where you expected a small negative one
You expected −11.8 and got 6541.8, or you expected −12 and got 65524. A sixteen-bit register can hold 0 to 65535 as an unsigned number, or −32768 to 32767 as a signed one, and the protocol does not say which. Read it as signed — INT16 rather than UINT16 — and it comes right.
Outside-air temperature sensors are where this bites, because everything looks fine until the first cold morning.
Wild nonsense
You expected something like 12.75 and got 3.6×10-41. This is a 32-bit value — a float or a big integer spread across two registers — and the two halves are arriving in the opposite order to the one you assumed.
Vendor documents name the orders with four letters, where the 32-bit value's four bytes are A, B, C and D:
| Order | Also called | How common |
|---|---|---|
ABCD | Big endian, high word first | The standard choice. Try it first. |
CDAB | Word swapped, mid-little endian | Very common — a large share of power meters and variable-speed drives. |
BADC | Byte swapped | Rare. |
DCBA | Little endian | Occasional, usually PLC-hosted maps. |
With only four possibilities and an obvious right answer, trying each one is a perfectly respectable method. The giveaway is magnitude: real engineering values live roughly between a thousandth and a few million. A float decoding to 10-41 or 1028 is not a weak guess, it is a wrong one.
A sensible number, but the wrong thing
The value is plausible but it is clearly the return air temperature rather than the supply. That is an addressing problem, not an interpretation one: see why is my Modbus address off by one.
A number that never changes, or reads 65535
- Always 0xFFFF (65535) — on most equipment this means “no value” or “sensor fault”, not sixty-five thousand. Check whether that sensor is connected.
- Always 0 — often an unused register, or a feature the equipment does not have fitted.
- Never changes but looks plausible — you may be reading a configuration register rather than a live measurement.
A value that jumps around impossibly
A temperature reading 72, then 4096, then 71 is usually a 32-bit value being read as two separate 16-bit ones, or a reply arriving one register out of step after a timeout. If the jumping started when you added more readings, try asking for fewer registers at a time.
The systematic way through it
- Look at the raw register in hex, not just the decoded number.
- Compare against what the equipment's own display says. That is ground truth, and it settles scaling and addressing in one move.
- Change one thing at a time: signedness, then multiplier, then word order.
Easy Modbus does the arithmetic for you: it shows the raw registers in hex and binary, lists every plausible interpretation with the reasoning, and warns when a value is outside the range the quantity can physically have — a humidity of 452% being the obvious case.