A Sparkplug rebirth is a command a host application sends to an edge node to make it republish its NBIRTH and DBIRTH messages, so the host can rebuild a complete and current view of that node. In this guide you will learn which situations call for a rebirth, how to send one by hand, how a correct edge node responds, and how to diagnose the most common problem in the field: nodes that rebirth over and over again.
What a Rebirth Does
Sparkplug consumers rely on birth messages for three things: the list of metrics, the mapping from aliases to names and datatypes, and the current value of every metric. If a host misses a birth or loses track of sequence, its model of the node is incomplete. A rebirth fixes this without dropping the MQTT connection.
The command is an NCMD message on spBv1.0/{group}/NCMD/{edge_node} containing a boolean metric named Node Control/Rebirth set to true. The edge node responds by publishing a new NBIRTH with seq reset to 0 and the same bdSeq as its current session, followed by a DBIRTH for each device. There is no separate device-level rebirth; a node rebirth always republishes all of its devices.
When a Host Should Request a Rebirth
| Trigger | Why it matters |
|---|---|
| Host starts or reconnects after the node is already online | Host never saw the original births |
| Sequence gap in seq | A message was lost; values and possibly metric definitions may be wrong |
| Data received with an unknown alias | Host cannot map the value to a metric |
| Data from a node or device with no known birth | Host has no metric definitions at all |
| Metric with a name not present in the birth | Node configuration changed without a new birth |
| Operator asks for a refresh | Manual recovery during commissioning |
Well-behaved host applications send these automatically. If you are writing your own consumer, implementing the first three triggers covers most real situations.
How the Edge Node Should Respond
- Receive the NCMD and confirm the
Node Control/Rebirthmetric is true. - Reset seq to 0.
- Publish NBIRTH with every node metric, its current value, the current bdSeq and the
Node Control/Rebirthmetric set back to false. - Publish a DBIRTH for every device that is currently connected.
- Resume NDATA and DDATA with seq continuing from the births.
The bdSeq stays the same because the MQTT session, and therefore the registered NDEATH will, has not changed. A node that increments bdSeq on rebirth without reconnecting will confuse hosts that check bdSeq when a death arrives later. The full certificate rules are explained in Sparkplug birth and death certificates.
Send a Rebirth by Hand
During commissioning it is useful to trigger a rebirth yourself. This Python script uses paho-mqtt 2.x and classes generated from the Eclipse Tahu sparkplug_b.proto file (see our tutorial on how to decode Sparkplug B in Python for the one-time generation step):
import sys
import time
import uuid
import paho.mqtt.client as mqtt
import sparkplug_b_pb2 as spb
if len(sys.argv) != 3:
sys.exit("usage: python rebirth.py <group_id> <edge_node_id>")
group, node = sys.argv[1], sys.argv[2]
payload = spb.Payload()
payload.timestamp = int(time.time() * 1000)
metric = payload.metrics.add()
metric.name = "Node Control/Rebirth"
metric.timestamp = payload.timestamp
metric.datatype = 11 # Boolean
metric.boolean_value = True
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"rebirth-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
info = client.publish(f"spBv1.0/{group}/NCMD/{node}", payload.SerializeToString(), qos=0)
info.wait_for_publish()
client.disconnect()
client.loop_stop()
print(f"rebirth sent to {group}/{node}")
Run it against a simulator on the public MQTT test broker, for example python rebirth.py demo-3f9a1c line1, while watching the group:
mosquitto_sub -h broker.connectmq.com -p 1883 -i rebirth-watch-77d2 -v \
-t "spBv1.0/demo-3f9a1c/#"
You should see the NCMD, then an NBIRTH and DBIRTH within moments. On a production broker, connect over port 8883 with TLS and your portal credentials, and remember that only authorised host applications should send commands to real equipment.
Troubleshooting Flow
When a host shows stale or missing metrics, work through these steps in order:
- Is the node connected? Check its connection. On ConnectMQ, subscribe to
$SYS/broker/connection/{clientId}/statefor the node's client ID, or look at the portal. - Did the node publish births? Look for NBIRTH and DBIRTH on its topics. If none appear after connecting, it may be waiting for a primary host application whose STATE it cannot see.
- Does the node subscribe to NCMD? Send a manual rebirth. If nothing happens, the node is not subscribed to
spBv1.0/{group}/NCMD/{node}or does not implement rebirth. - Do births contain all metrics? Compare the decoded DBIRTH with the tags you expect. Missing metrics are a node configuration issue, not a transport issue.
- Is seq continuous? Watch several data messages after the birth. Gaps point to message loss or a second client using the same edge node ID.
- Do aliases resolve? Every alias in NDATA or DDATA must appear in the latest birth. If not, the node is sending aliases it never declared.
- Is the host processing births correctly? If the broker shows correct births but the host still shows stale data, the problem is on the host side.
Seeing decoded payloads makes steps 2, 4, 5 and 6 much faster. ConnectMQ decodes Sparkplug B in its portal topic explorer, so you can read the metric list in a birth, check seq values and spot aliases without writing a decoder.
Rebirth Storms and How to Stop Them
A rebirth storm is a loop where a node rebirths continuously, flooding the broker and the host with birth messages. Typical causes:
| Cause | How to recognise it | Fix |
|---|---|---|
| Two clients with the same edge node ID | Interleaved seq values, frequent disconnects | Give every node a unique ID per group |
| Duplicate client ID | Node disconnects whenever another client connects | Use unique client IDs; on ConnectMQ use the issued ID |
| Host treats seq wrap 255 to 0 as a gap | Rebirth every 256 messages | Fix host gap logic |
| Several hosts each requesting rebirths | Rebirth whenever any host restarts | Limit which hosts may send NCMD |
| Node publishes aliases not in birth | Rebirth after every data message | Fix node alias configuration |
| Broker rate limits hit during births | Births truncated, gap detected, rebirth again | Smaller births or a plan with higher limits |
The last row deserves attention on shared infrastructure. The public broker allows 10 messages per second per client and 64 KB per message, and Serverless plans have their own message size limits. A node with thousands of metrics may produce a large birth, so check sizes when you move from a simulator to real equipment.
Hosts should also rate-limit their own requests. A simple rule is at most one outstanding rebirth per node, cleared when the NBIRTH arrives, with a backoff if the birth never comes.
Prevention Checklist
- Unique edge node IDs per group and unique MQTT client IDs per connection.
- Births always published before data, with every metric and alias declared.
- seq reset to 0 on every NBIRTH; bdSeq unchanged on rebirth.
- Host gap detection that handles wrap-around from 255 to 0.
- One designated host allowed to send commands in production.
- Birth sizes checked against broker limits.
Keep the Transport Reliable
Most rebirths are a symptom of something upstream: dropped connections, duplicate IDs or a host restart. A stable broker reduces the first category. A managed MQTT broker or an MQTT broker in the cloud takes patching, certificates and monitoring off your plate. For the wider picture of Sparkplug in plant architectures, read the Industrial IoT with MQTT guide.
Get Started with ConnectMQ
Create a free Serverless broker at app.connectmq.com, no credit card required. Connect your edge nodes and host, trigger a rebirth with the script above, and inspect the decoded births in the ConnectMQ topic explorer.
Frequently Asked Questions
Does a Sparkplug rebirth disconnect the edge node?
No. The node stays connected and republishes its births on the same MQTT session. That is why bdSeq does not change during a rebirth.
Can I request a rebirth for a single device?
No. The rebirth command targets the edge node, which then republishes its NBIRTH and a DBIRTH for every connected device.
Why does my host keep requesting rebirths?
The most common causes are duplicate edge node IDs, aliases that are not declared in births, or host logic that treats the normal seq wrap from 255 to 0 as a gap.
Should births be retained to avoid rebirths?
No. Sparkplug births are never retained. A host that starts later requests a rebirth so it always gets current values.
