Skip to content
QUBIQ 1.0.4 is available.Download it
All posts
Protocols3 min read

Sparkplug B state management, explained without the spec

Birth certificates, death certificates and the primary host. What each one actually does, and the three mistakes that cause phantom stale data.

Administrator
The Sparkplug state cycle around a single primary host, with the three mistakes that cause stale data.

Sparkplug B gets described as "MQTT with a schema", which undersells the part that actually matters: it defines how you know whether the data you are looking at is still true.

Plain MQTT gives you a retained message. A retained message tells you what a device last said. It does not tell you whether the device is still there to say it.

The three certificates

NBIRTH / DBIRTH — when an edge node or device comes online it publishes a birth certificate containing every metric it will ever publish, with aliases, datatypes and current values. This is the schema announcement. Anything not in the birth certificate should not appear later.

NDATA / DDATA — subsequent changes, published by alias rather than by name. This is why Sparkplug is compact on the wire: after the birth, you are sending integers, not topic strings.

NDEATH / DDEATH — registered as an MQTT Last Will and Testament at connection time. The broker publishes it if the node disappears without saying goodbye. This is the mechanism that turns "I have not heard from this device" into "this device is gone, mark its data stale".

The primary host is not optional

The primary host application publishes its own STATE message and is what edge nodes watch to decide whether anyone is listening. If the primary host goes away, compliant edge nodes will rebirth when it returns, resynchronising the whole namespace.

Skipping the primary host is the single most common Sparkplug deployment error. Without it you get MQTT with extra steps: data flows, but nothing reconciles after a disconnect, and stale values sit on dashboards looking perfectly healthy.

Three mistakes that produce phantom data

Setting the LWT QoS to 0. The death certificate is the one message you cannot afford to lose. QoS 1, retained false.

Reusing a client ID across two edge nodes. The broker will disconnect the first when the second connects, firing a death certificate for a node that is perfectly healthy. Values go stale, then un-stale, then stale again, and everyone blames the network.

Ignoring the sequence number. Every message carries seq, incrementing 0–255 and wrapping. A gap means you missed a message and your local state is now wrong. The correct response is to request a rebirth, not to carry on and hope.

A quick conformance check

Before you trust a Sparkplug deployment in production, unplug an edge node's network cable and watch:

  1. Within the keepalive window, the broker should publish that node's NDEATH.
  2. Every consumer should mark that node's metrics as stale, not simply stop updating them.
  3. On reconnect, the node should publish a fresh NBIRTH with current values.
  4. Consumers should discard their old alias map and adopt the new one.

If step 2 does not happen, you have an operator staring at a number that stopped being true twenty minutes ago. That is worse than a blank screen, because the blank screen is honest.

  • #Unified namespace
  • #Sparkplug B
  • #MQTT
Share this

Keep reading

See this running on your own data

Install QUBIQ in three minutes, point it at an OPC UA endpoint or MQTT broker, and watch a live value in your browser.