10 Sensor Communication Protocols

Reviewing Source Protocols Before Gateway Translation

integration-gateways

communication

protocol

bridging

Overview: The Source Side Decides What a Gateway Can See

A gateway can only translate what the source protocol actually exposes. Before any bridging decision, you have to understand the source boundary — the side facing the sensors and equipment — because that is where meaning is created and where it is most often lost. A gateway cannot translate a source well if the source meaning is undocumented, and the most common reason a bridge ships wrong data is that nobody wrote down what the source value meant.

The trap is that the same numeric value can mean very different things. A reading of 21 might be a temperature, a fault code, a counter, an echo of the last command, or a stale cached value that the device never refreshed. Nothing about the number itself tells you which. A source-protocol review makes that meaning explicit, so the rest of the IoT system inherits a trustworthy record instead of a guess.

If you only need the intuition, this layer is enough: for every source protocol, ask one question — what does the gateway know, what does it infer, and what evidence proves the inferred value is still safe to use?

Start Simple: Label the Raw Number

Before choosing a bridge pattern, take one raw source value and write down what the gateway really knows about it. Is the value a measurement, a state bit, a command echo, or a stale cached result? The protocol bridge can normalize only what this source review makes explicit: identity, scale, unit, source time, quality, and owner.

flowchart TD
  A["Classify the source family"] --> B["Write the review packet: identity, meaning, timing, failure"]
  B --> C["Decode with scale, byte order, source time, and quality"]
  C --> D["Publish a normalized record with evidence"]
  D --> E["Run stale, bad-map, and recovery drills"]

Source protocols fall into a few recognizable families. Some expose a raw analog level or a discrete contact state. Some expose serial bytes on a shared bus. Some expose named or numbered registers that hold values, status bits, counters, or commands. And some publish self-contained packets or event records. Each family hands the gateway a different kind of meaning, and each needs a different review.

For example, a greenhouse input labelled channel AI-3 might be a 4-to-20 milliamp pressure loop today and a dry-contact alarm after a maintenance change next month. The gateway cannot infer that intent from the signal alone. It needs the channel schedule, calibration span, fault-state convention, owner, and change record before the number is safe to normalize.

The One-Minute View: Know, Infer, Prove

Meaning lives at the source

A number with no unit, scale, identity, time, or quality is not a measurement yet; the source review supplies that meaning.

Know, infer, prove

Separate what the gateway directly knows from what it infers, and keep evidence that the inference is safe.

Families, not one model

Analog, serial, register, and packet sources carry different assumptions; do not review them with one checklist.

Beginner Examples

A 4-to-20 milliamp current loop carries a level, but only the calibration rule says whether that level is a temperature, a pressure, or a tank percentage.
A register labelled "status" might pack several independent bits, so reading it as a single number quietly merges separate meanings.
"The gateway received a value" is not the same as "the gateway knows what the value means, when it was measured, and whether it is fresh."

Overview Knowledge Check

If you can ask the know/infer/prove question for any source, you have the core idea. Continue to Practitioner for the source families, the review packet, and the normalized record.

Practitioner: Classify the Family, Build the Review Packet

The practitioner workflow starts by classifying the source family, because the family decides what the gateway can read and what evidence the review needs. Treating a register source like a packet source, or an analog input like a serial bus, imports the wrong assumptions.

Source Family

What the Gateway Reads

Review Evidence

Main Risk

Analog or discrete

A measured level, contact state, pulse count, or alarm state on an input channel.

Calibration rule, expected span, fault state, sample time, quality flag.

A channel number published as a value with no unit.

Local serial bus

Bytes exchanged with one or more devices through a shared bus driver.

Address plan, bus owner, framing rule, timeout and collision behavior.

Bus contention or an ambiguous frame boundary.

Named or numbered registers holding values, status bits, counters, or commands.

A wrong map or swapped order gives a believable wrong value.

Packet or event

A self-contained message, frame, or record emitted by the source.

Schema version, source identity, event time, duplicate and gap rule.

Duplicate or replayed events double-counted.

The Source Review Packet

For each source, write a small review packet before implementation, organized around four questions:

For a tank-level loop, the packet might say that AI-3 maps 4-to-20 milliamps to 0-to-5 meters, that open circuit means communication fault rather than zero level, that the gateway samples every 30 seconds, and that a maintenance technician owns calibration changes. That packet lets the MQTT record, dashboard alarm, and troubleshooting note inherit the same meaning instead of each guessing from the raw channel.

Identity

Source name, channel, address, register, or message type, plus ownership. A reviewer must be able to point to the exact physical or logical source.

Meaning

Unit, scale, offset, enumerations, status bits, and what each quality state means. Do not leave the normalized payload to guess.

Timing

Source time, sample interval, poll interval, freshness limit, and how the gateway marks a value stale.

Failure

Timeout, checksum failure, invalid value, bus error, retry, fallback, and the operator-visible diagnostic behavior.

From Raw Sample to Normalized Record

Translation is a chain of small decisions: decode the raw input, map it to a named point, scale it, timestamp it, mark its quality, and record the evidence. A normalized record should carry, at minimum, a stable source identity (not just a display name), the normalized point name, the converted value with its unit or enumeration, the source measurement time, the gateway-read time, an explicit quality state, and a reference to the raw sample and map version. Crucially, the source time and gateway time are separate fields whenever both are known — collapsing them is how staleness disappears.

Field

What It Carries

Why It Matters

Trap If Missing

Source id + point

Stable source identity and the normalized point name.

Ties the record back to one real, addressable source.

Two sources blur into one stream.

Value + unit

The converted value with its unit, scale, or enumeration.

Makes the number a measurement, not a raw count.

A unit-less number is read with the wrong scale.

Source + gateway time

When it was measured and when the gateway read it.

Lets a consumer tell a fresh value from a stale one.

A stale value looks freshly observed.

Quality + evidence

Good, stale, estimated, invalid, or fault, plus raw-sample and map references.

Lets a reviewer reproduce and judge the translation.

A bad value passes as good with no trace.

The adapter strategy should follow the source behavior, not the reverse. A signal adapter converts an input channel to an engineering value and carries calibration and fault state. A bus adapter owns address, frame, timeout, and retry behavior and records raw frame evidence. A register adapter applies the point map, byte order, scale, and status bits, and separates read-only values from commands. A packet adapter validates the schema, preserves event time and source identity, and handles duplicates.

Practitioner Knowledge Check

If you can classify the family, write the review packet, and produce a reproducible normalized record, you can stop here. Continue to Under the Hood for byte order, timing semantics, and the failure drills.

Under the Hood: Byte Order, Timing, and Failure Drills

The deeper layer is about the source-side details that produce believable wrong values — the most dangerous kind, because they pass casual inspection. A failed read is loud and easy to notice; a quietly mis-decoded value looks normal and corrupts decisions downstream.

Byte Order and Word Order

When a value spans more than one byte or more than one register, the gateway must know the byte order within each word and the word order across registers. These are independent choices, and a source can combine them in more than one way. If the gateway assumes the wrong order, a multi-register value does not fail — it decodes to a plausible but incorrect number. That is harder to catch than a failed read, which is exactly why a register review must pin down byte order, word order, and signedness explicitly, then prove them with a decoded sample whose value is independently known.

Bus Ownership and Contention

On a shared serial bus, the review must record who initiates each transaction, how devices are addressed, and what happens on collision or timeout. If two parties can drive the bus without a clear owner, transactions interleave and frames corrupt. The adapter that owns address, framing, timeout, and retry behavior — and records raw frame evidence — is what keeps a multi-device bus reviewable.

Timing and Quality: Do Not Hide Staleness

Translation is not only value conversion; timing and quality decide whether a value can be trusted. Capture the source measurement time, the gateway read time, a freshness rule that defines when a value becomes stale, the poll interval, the timeout rule that turns a missing response into a communication fault, and the recovery rule that returns quality to good. The cardinal sin is repeating the last good value as if it were fresh: reuse is acceptable only when the quality state makes the stale condition visible. Likewise, never overwrite the source time with the current gateway time, because that erases the age of the reading.

Failure Drills Before Acceptance

Drill

What You Inject

Evidence to Keep

Trap If Skipped

Decode sample

One representative sample from each source family.

Raw value, decoded value, unit, map version, quality.

Decoding errors hide until production.

Stale sample

The source stops updating or the gateway misses reads.

Freshness rule, stale flag, last-good behavior, operator signal.

A frozen value is trusted as live.

Bad map

A deliberately wrong register or field mapping.

Validation failure, rejected record, review note.

A wrong map ships a believable wrong value.

Fault recovery

Source communication fails and then recovers.

Fault quality, retry evidence, recovery quality, no hidden reuse.

Recovery silently reuses stale data.

Accept a source adapter only when every source has identity, ownership, and a review packet; raw samples are preserved long enough to verify decoding; units, scale, byte order, and enumerations are documented; source and gateway time are separate when both are known; stale, invalid, estimated, and fault quality states are visible; commands are separated from read-only values; and a reviewer can reproduce the normalized record from the raw evidence.

Under-the-Hood Knowledge Check

At this depth, a sensor-protocol review is a defense against believable wrong values. Pin down byte and word order, name the bus owner, keep source and gateway time apart, make every quality state visible, and run the decode, stale, bad-map, and recovery drills so a reviewer can reproduce one normalized record from its raw evidence.

10.1 Summary

A gateway can only translate what the source protocol exposes, so the source review is where meaning is established and most often lost.
The same numeric value can mean a temperature, a fault code, a counter, a command echo, or a stale reading; a source review makes the meaning explicit.
Classify each source into a family first: analog or discrete, local serial bus, register protocol, or packet and event, because each carries different assumptions.
Write a source review packet covering identity, meaning, timing, and failure before implementation.
A normalized record carries source id, point name, value with unit, separate source and gateway times, an explicit quality state, and a reference to the raw sample and map version.
Multi-register values need explicit byte order, word order, and signedness, because the wrong order yields a believable wrong value that is harder to catch than a failed read.
Timing and quality must be explicit: keep source and gateway time apart, define freshness and recovery rules, and never repeat a stale value as if it were fresh.
Run decode, stale, bad-map, and fault-recovery drills, and accept the adapter only when a reviewer can reproduce the normalized record from the raw evidence.

Key Takeaway

The source boundary decides what a gateway can ever know, so a sensor-protocol review preserves identity, meaning, timing, quality, and failure evidence, not just bytes. Its real purpose is to prevent believable wrong values: pin down units, scale, and byte order; keep source and gateway timestamps separate; make every quality state visible; and prove the translation with a single raw sample a reviewer can decode again to the same normalized record.