What Is Sparkplug bdSeq and seq Numbering?
Sparkplug carries two different counters that people constantly confuse: seq, which orders messages within a session, and bdSeq, which pairs a birth with its correct death. Getting them straight is essential to understanding why a node reissues a rebirth or why a stale will gets ignored. For an engineer debugging session confusion after a flapping link, this page explains what each counter does and why both exist.
Sparkplug bdSeq and seq in one line: Sparkplug uses two counters. The seq number rolls with each message in a session so a consumer can detect a missed or out-of-order message and request a rebirth. The bdSeq, the birth-death sequence number, is set in each NBIRTH and its matching NDEATH so the consumer can confirm a death belongs to the current session and ignore a stale will from an old one.
seq: Ordering Messages Within a Session
The seq number is a small counter that increments on every Sparkplug message from an edge node within a session, wrapping around after it reaches its maximum. The NBIRTH starts the sequence, and each following data or command message carries the next value. Its job is gap detection: a consumer tracking the seq can tell if a message went missing or arrived out of order, because the numbers would skip or reverse. This is the same mechanism described alongside the metric alias and sequence number.
Gap detection matters precisely because Sparkplug reports by exception. Since the consumer is trusting a stream of on-change updates and holding last-known values in between, a silently dropped data message would leave the consumer holding a wrong value with no way to notice. The rolling seq gives it a way to notice: a break in the sequence means it may have missed a change, so its cached state might be stale. The consumer's correct response is not to guess but to ask the node to resynchronize.
That resynchronization is the rebirth. When a consumer detects a seq gap, or otherwise loses confidence in its state, it issues a rebirth request, and the node responds by reissuing its full birth with current values and a fresh sequence start. So seq is not just a diagnostic; it is the trigger for the recovery path that keeps the consumer's picture correct despite a lossy link. Without it, report-by-exception state could drift undetected.
bdSeq: Tying a Birth to Its Correct Death
The bdSeq counter solves a different and subtler problem: matching a death to the birth it truly belongs to. Recall that an NDEATH is registered as the node's MQTT last will, so it is composed at connect time and the broker holds it until the connection drops. Now imagine a node that connects, disconnects uncleanly, and reconnects. The broker may still fire the will from the earlier connection after the node has already come back. Without a way to tell, a consumer could receive a death for a node that is actually alive.
bdSeq prevents that confusion. Each time the node connects, it chooses a bdSeq value and places it in both the NBIRTH it sends and the NDEATH it registers as the will for that same connection. When a consumer receives a death, it checks the bdSeq: if it matches the birth of the session it currently believes is active, the death is real and the node is gone. If the bdSeq belongs to an older session that has already been superseded by a newer birth, the death is stale and the consumer ignores it. The birth-death pairing is what makes the will trustworthy across reconnects.
This is why bdSeq and seq must not be confused, even though both are numbers on Sparkplug messages. seq lives within a session and orders its messages; bdSeq identifies which session a birth or death belongs to. A flapping link stresses both: it can drop messages, which seq catches, and it can leave stale wills queued at the broker, which bdSeq neutralizes. Debugging a node that seems to die and revive erratically almost always comes down to reading these two counters correctly, and it is closely related to troubleshooting a node going offline.
Frequently Asked Questions
What is the difference between seq and bdSeq in Sparkplug?
The seq number increments on every message within a single session so a consumer can detect a missed or out-of-order message and request a rebirth. The bdSeq, or birth-death sequence, is chosen once per connection and placed in both the NBIRTH and the matching NDEATH so a consumer can confirm that a death belongs to the session it currently considers active. In short, seq orders messages inside a session; bdSeq identifies which session a birth or death belongs to.
Why does bdSeq stop a stale death from confusing a consumer?
Because the NDEATH is a last will registered at connect time, the broker can fire an old will after the node has already reconnected. By stamping the same bdSeq into the birth and its matching will, the node lets a consumer check whether an incoming death belongs to the current session or an older one. If the death carries an outdated bdSeq that a newer birth has already superseded, the consumer recognizes it as stale and ignores it, so a node that is actually alive is not mistakenly marked dead.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.