All posts

MQTT and Sparkplug B in the Real Field

MQTT looks simple in a demo. The field is not a demo. Here is what changes when your broker is in the cloud and your devices are on a cellular link that drops every afternoon.

Why plain MQTT is not enough

Vanilla MQTT gives you publish and subscribe and not much else. It does not tell a consumer whether a device is currently online, what the full set of its tags is, or whether the last value it saw is still valid. In a clean network none of that matters. In the field, where links drop and devices reboot, it matters constantly.

What Sparkplug B adds

Sparkplug B is a specification layered on top of MQTT that fixes exactly these gaps. It defines birth and death certificates, so every consumer always knows which devices are live and what their tag structure looks like. It uses report-by-exception, so a device only publishes a value when it changes rather than flooding the network with redundant polls. And it defines a clear state model, so there is never ambiguity about whether the data you are looking at is current.

  • Birth certificates announce a device and its full tag set when it comes online.
  • Death certificates, delivered through the MQTT will, tell consumers the instant a device drops.
  • Report-by-exception keeps bandwidth low, which matters enormously on metered cellular links.
  • State awareness means a consumer never silently trusts a stale value.

Store-and-forward is not optional

The single most important thing you can do for field reliability is put store-and-forward at the edge. When the link drops, the edge node keeps recording. When it comes back, it forwards everything it buffered, in order. Without this, every connectivity blip is a hole in your data, and those holes always seem to land during the events you most wanted to see.

Design for the link being down, because in the field it will be.

Practical guidance

Keep your tag namespaces consistent across devices so consumers can reason about them generically. Set sensible report-by-exception deadbands so you are not publishing noise. Test your death-certificate handling by actually pulling power, not by closing a connection cleanly. And monitor broker health as carefully as you monitor the process, because in this architecture the broker is part of the process.

Done right, the field disappears as a source of worry. Devices come and go, links flap, and consumers always have an accurate, current picture, because the protocol was built for exactly this.

Back to all posts Talk it through ->