What Is a Sparkplug DDEATH Message?
NDEATH gets discussed constantly, but its quieter sibling DDEATH matters just as much for correct SCADA state. DDEATH marks one device offline while the gateway hosting it stays perfectly alive. For an engineer whose gateway serves several downstream PLCs, understanding DDEATH is how you avoid flagging a whole site bad when only one instrument dropped. This page explains what DDEATH is, how it differs from NDEATH, and what it means for the host.
Sparkplug DDEATH in one line: A Sparkplug DDEATH is a device death message published by an edge node to announce that one of the devices behind it has gone offline, while the node itself remains connected. It tells the SCADA host to mark that specific device's metrics as stale, without affecting the node or the other devices the node still serves. It is the device-level counterpart to the node-level NDEATH.
DDEATH Versus NDEATH: Scope Is Everything
The difference between DDEATH and NDEATH is entirely about scope, and getting it right is what keeps a SCADA display honest. An NDEATH announces that the whole edge node is gone; every device behind that node is implicitly dead too, because the gateway carrying them has vanished. A DDEATH is narrower: the edge node is alive and well and still publishing, but it is reporting that one particular device it fronts has lost communication.
This maps directly onto the edge node and device hierarchy. A single gateway, the edge node, often speaks to several downstream instruments or PLCs, each modelled as a device. If one of those PLCs loses its serial link or power while the gateway stays online, the gateway detects the device is unreachable and publishes a DDEATH for just that device. The gateway itself never died, so no NDEATH is issued and the other devices keep reporting normally.
There is a mechanical difference too. NDEATH is registered as the edge node's MQTT last will and testament, so the broker publishes it automatically if the node's connection drops without warning. DDEATH is different: the edge node is alive and detects the device failure itself, so the node actively publishes the DDEATH. It is not a broker-driven will; it is the node reporting a downstream loss it observed. That distinction explains why a DDEATH arrives promptly and cleanly while an NDEATH may depend on keepalive timing to fire.
What DDEATH Means for the SCADA Host
When a consumer receives a DDEATH, the correct behavior is to mark every metric belonging to that one device as stale, so operators know those values are no longer live, while leaving the node's own metrics and every other device's metrics untouched. This is the crucial precision that DDEATH provides. Without a device-level death, a host would either have to declare the whole gateway suspect when one instrument dropped, which is wrong and alarming, or fail to flag the stale device at all, which is worse.
For an operator this is the difference between a useful screen and a misleading one. A gas gathering site whose gateway serves five wellhead PLCs should show four healthy wells and one flagged bad when a single PLC loses communication, not a whole site greyed out. DDEATH is what makes that granular, accurate picture possible, and it is why a cloud SCADA host that models the Sparkplug hierarchy faithfully can show exactly which instrument is in trouble rather than a coarse site-level alarm.
Recovery follows the mirror image. When the device comes back, the edge node publishes a fresh DBIRTH for it, redeclaring its metrics and current values, and the host clears the stale flags and resumes trusting that device's data. So the device lifecycle within a live node is DBIRTH, then DDATA as values change, then DDEATH if it drops, then DBIRTH again on recovery, all while the node's own birth-death lifecycle continues independently. Understanding both lifecycles running in parallel is the key to reasoning about mixed device health under one gateway.
Frequently Asked Questions
Is a DDEATH sent as an MQTT last will like NDEATH?
No, and that is a meaningful difference. NDEATH is registered as the edge node's MQTT last will and testament, so the broker publishes it automatically if the node's connection drops unexpectedly. A DDEATH, by contrast, is published by the edge node itself, because the node is still alive and has detected that one of its downstream devices has lost communication. The node observes the device failure and actively reports it, rather than relying on the broker's will mechanism, which is only for the node's own unexpected disconnection.
What should a SCADA host do when it receives a DDEATH?
Mark only that specific device's metrics as stale, leaving the edge node's own metrics and every other device behind the same node untouched. The DDEATH scopes the loss to a single device, so the host should reflect exactly that: one instrument's values are no longer live while the rest of the site continues normally. When the device recovers, the node publishes a fresh DBIRTH, and the host clears the stale flags and resumes trusting that device's data from the new baseline the birth establishes.
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.