In Sparkplug, a host builds its whole model of an edge node from the birth certificate the node sends when it connects, and after that it tracks lean updates that reference metrics by short aliases. But if the host loses track - it missed the birth, its sequence counting slipped, or it restarted with no memory of the node - those lean updates become meaningless, because the host no longer knows what the aliases stand for. The rebirth request is the recovery mechanism: the host asks the node to re-emit its full birth certificate from scratch by writing a specific command metric. This guide explains what a rebirth request is, how the host issues it through the Node Control/Rebirth metric, and why it is the standard cure when alias or sequence tracking desynchronizes.
Sparkplug Rebirth Request in one line: A Sparkplug rebirth request is a command a host sends to make an edge node re-publish its complete birth certificate, re-establishing the full set of metric names, data types, and aliases. The host triggers it by sending a node command that writes the node's Node Control/Rebirth metric to true, and it is the defined recovery path when the host's model of the node has become out of sync - through a missed birth, a sequence-number gap, or a host restart.
Sparkplug's efficiency comes from a bargain struck at birth. When an edge node connects, it publishes a birth certificate declaring every metric it will report, each with a name, a data type, and a short numeric alias. From then on, its data messages are lean: they refer to metrics by those aliases rather than repeating full names and types, which keeps payloads small over constrained links. The catch is that this only works while the host holds the mapping from aliases to their meanings, because an alias by itself is just a number.
That mapping can be lost. If the host restarts, it comes back with no memory of the node's aliases and cannot interpret the lean updates still arriving. If the host was subscribed but missed the original birth - it came online after the node did - it never received the mapping in the first place. And if messages were dropped so the host's sequence tracking no longer lines up with the node's, the host can no longer be confident it is interpreting the stream correctly. In every one of these cases the host holds updates it cannot make sense of.
When that happens, the host does not try to guess or reconstruct the missing definitions - it asks the node to start over. The rebirth request tells the node to re-emit its entire birth certificate, handing the host a fresh, authoritative, complete picture of the node's metrics from scratch. Rather than limping along with a partial or stale model, the host resynchronizes cleanly to a known-good state. Rebirth is the reset button for a host-node relationship that has drifted out of alignment.
The rebirth is requested through a specific mechanism, not an ad-hoc message. Every Sparkplug edge node publishes, as part of its own birth certificate, a control metric named Node Control/Rebirth - a writable boolean that exists precisely so a host can command a rebirth. The node advertises this metric so the host knows it is there and can target it. It is a piece of the node's own definition dedicated to the recovery workflow.
To trigger the rebirth, the host sends a node command - an NCMD - that writes the Node Control/Rebirth metric to true. NCMD is the command-direction message type a host uses to push writes down to an edge node, and here the write targets the rebirth control metric specifically. When the node receives that command and sees its Node Control/Rebirth metric set true, it responds by re-publishing its full NBIRTH - a brand-new birth certificate with the complete, current set of metrics, data types, aliases, and values, and a fresh start to its sequence counting.
From the host's perspective the loop then closes cleanly. It sent one small command, the node answered with a complete self-description, and the host rebuilds its model of that node from the new birth exactly as it would on first connect. The subsequent lean updates once again reference aliases the host understands, and the sequence counting begins afresh so both sides agree on where the stream starts. The whole exchange is deliberately minimal - a single command out, a single full birth back - which is why rebirth is a cheap, reliable recovery even over constrained field links.
Rebirth is the designated cure for the desynchronization problems that arise on real, imperfect networks. Sparkplug numbers its messages with a rolling sequence so the host can detect a gap - if the numbers skip, the host knows it missed something. But detecting the gap does not by itself repair the host's understanding, because a missed message may have carried a value change the host now lacks. On seeing a sequence break, the correct response is to request a rebirth and rebuild from a fresh certificate rather than continue on a model that may be wrong.
The alias case is just as common. Aliases are only meaningful relative to the birth that defined them, so if a host has lost that birth - through its own restart or by joining late - the aliases in incoming data are uninterpretable numbers. Trying to act on data whose metric identity is unknown would be worse than useless in a control context, so the host instead issues a rebirth and waits for the node to re-declare which alias means which metric. This is why the alias-and-sequence machinery and the rebirth mechanism are two halves of one design: one detects that something has gone wrong, the other fixes it.
For cloud SCADA ingesting from remote field devices, rebirth is what keeps the model honest across the messy realities of intermittent links. A platform such as Merobix acting as the host can, after its own reconnection or on detecting a sequence gap from a well-pad edge node, issue a rebirth to that node and immediately receive a complete, current picture rather than piecing together a possibly stale one. That self-healing matters because operators must trust that what they see reflects the real metric definitions and current values of the remote asset, and rebirth is the clean, standardized way the platform resynchronizes whenever the field connection has hiccuped.
It sends a node command, an NCMD, that writes the edge node's Node Control/Rebirth metric to true. Every node advertises this writable control metric in its birth certificate for exactly this purpose. When the node sees the metric set true, it responds by re-publishing its full NBIRTH with the complete set of metrics, aliases, and values and a fresh sequence start, giving the host a clean model to rebuild from.
Whenever its model of the node has become unreliable: after the host restarts and no longer knows the node's aliases, when it detects a gap in the node's sequence numbers, or when it subscribed after the node's original birth and never received the metric definitions. In all these cases the incoming lean updates are uninterpretable or suspect, so requesting a rebirth is the standard way to resynchronize to a known-good state.
Mechanically they are the same message - a rebirth is simply another NBIRTH, a full birth certificate re-published by the node. The difference is what triggers it: the original NBIRTH is emitted when the node first connects, while a rebirth is emitted in response to a host's command writing the Node Control/Rebirth metric. Both hand the host a complete, authoritative model of the node and reset the sequence counting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.