Modbus: three ways a reading is wrong

The controller reads Modbus registers over RS‑485 (Modbus RTU) or over TCP and publishes them alongside everything else it knows, with the same age and quality rules as a Matter bulb or a sensor node. The reading part is simple. The believing part is where installations go wrong.

There is no discovery

Modbus has no way to ask a bus what is on it. The controller's scan walks every unit address in turn, and a silent address costs a full timeout, so it is something you run once when you wire a device up, never on a schedule. What a device means by its registers is not on the wire at all. It is in the manufacturer's manual, and the controller's register map is where you write it down.

The three failures, in the order they happen

The address is off by one. Manuals number registers from 1, or from 30001, or from 40001. The wire numbers them from 0. The register map uses the wire address. The symptom is a neighbouring value, which usually looks plausible.

The type is wrong. A temperature below zero read as unsigned appears as roughly 65,500. A float read from one register instead of two is nonsense. A float read with the wrong word order is a finite, wrong number, which is worse, because it gets recorded and trended and believed.

The scale is wrong. Devices commonly report tenths. 213 is 21.3 degrees, not a fire.

A sane range catches all three

Every register in the map carries a sane_range: the values the device can physically produce. A reading outside it is not published as a value. It is published as a fault, with the raw register attached, and the capability layer marks the reading's quality accordingly. A plausible wrong number believed for a week costs more than an obvious error today.

{
  "unit": 1,
  "address": 0,            // wire address, not the manual's
  "type": "int16",         // signed: the sensor can read below zero
  "scale": 0.1,            // device reports tenths
  "unit_of_measure": "°F",
  "sane_range": [-40, 185] // outside this is a fault, not a value
}

Why the controller does not write

Writing a register is implemented and tested, and no endpoint exposes it. A wrong value written to a lamp is a lamp. A wrong value written to a drive is a machine moving. When writing is wanted it goes behind the same control gate as everything else the controller can actuate, reachable only from the private network, and probably behind something stricter still. Read‑only by default is not a limitation of the prototype. It is the posture.

Two rules of the serial bus

• One transaction at a time. RTU is half‑duplex on a shared pair. Two transactions at once are not slow, they are corrupt. The controller serialises every request on a bus, whichever part of the system asked.
• Silence is the delimiter. RTU frames end with a pause rather than a terminator character. The controller enforces the inter‑frame silence the standard requires. Skipping it produces framing errors that only appear under load, which is the worst time to discover them.