Most introductions to Sparkplug focus on data flowing upward - edge nodes publishing measurements to a host - but a real control system also needs to send commands the other way, writing setpoints and toggling outputs down to the field. Sparkplug carries that reverse direction with two command message types: NCMD, which targets an edge node, and DCMD, which targets a specific device behind that node. Together they form the writeback path that lets a host push control actions to the field over MQTT. This guide explains what NCMD and DCMD are, how they address the node versus the device, and how the writeback flow works from an operator changing a setpoint to the value landing on a PLC.
Sparkplug DCMD/NCMD Commands in one line: In Sparkplug, NCMD (node command) and DCMD (device command) are the message types a host uses to send control writes downward. An NCMD targets an edge node itself - for example to change a node-level metric or request a rebirth - while a DCMD targets a specific device attached behind that edge node, such as writing a setpoint to a PLC. They are the writeback path that lets a host command the field, the mirror image of the data messages nodes publish upward.
Sparkplug's data messages flow from the field up to the host: an edge node publishes its birth certificate and then a stream of node data and device data as values change. That upward flow is what most tutorials cover, because monitoring is the common first use case. But a SCADA system is not only for watching - operators need to act, changing a setpoint, opening or closing a valve, starting or stopping a pump. Those actions require messages that travel the opposite way, from the host down to the field, and Sparkplug defines specific message types for exactly that.
The two command types are NCMD and DCMD, mirroring the two data types NDATA and DDATA. Where NDATA and DDATA carry values upward from a node and a device respectively, NCMD and DCMD carry commands downward to a node and a device respectively. The naming is deliberately parallel: the N types concern the edge node itself, the D types concern a device behind it, and swapping DATA for CMD swaps the direction from reporting to commanding. This symmetry is what makes Sparkplug a full two-way protocol rather than a one-way telemetry feed.
Understanding this command direction matters because it is where writeback lives, and writeback is what separates a monitoring system from a control system. A platform that can only receive can show an operator that a tank is filling but cannot let them throttle the inflow. NCMD and DCMD are the messages that close that loop, giving the host a defined, structured way to push intent down to the equipment. That they are underexplained in most introductions does not make them optional - any real control application over Sparkplug depends on them.
The distinction between NCMD and DCMD follows Sparkplug's addressing hierarchy. An edge node is the gateway or software component that connects to the broker and speaks Sparkplug on behalf of itself and any devices attached behind it. A device is a piece of equipment - often a PLC or instrument - that sits behind the edge node and does not connect to the broker itself; the node represents it. Commands are addressed to one or the other depending on what you are trying to reach.
An NCMD targets the edge node itself. It is used to write metrics that belong to the node - node-level configuration or control metrics - the most notable being the rebirth control metric a host writes to make a node re-emit its birth certificate. An NCMD is addressed to the node using its group and node identifiers, and the node is the entity that receives and acts on it. When the thing you want to change lives at the node level, NCMD is the message.
A DCMD targets a specific device behind the node. It carries the additional device identifier so the message is aimed not just at the node but at the particular device the node fronts, and it is how a host writes an actual field value - a pump speed, a temperature setpoint, an output state - to a given PLC or instrument. The edge node receives the DCMD, sees which device and which metric it addresses, and translates the write into whatever the device's native protocol requires. This is the crucial hop where a Sparkplug command becomes a concrete action on real equipment, with the edge node acting as the bridge between MQTT and the field bus.
Following a single command end to end shows how the pieces fit. An operator at a dashboard changes a setpoint - say, raising a compressor's target pressure. The host constructs a DCMD addressed to the correct group, edge node, and device, carrying the metric to write and its new value, and publishes it. The broker delivers it to the edge node that owns that device. The node recognizes the target device and metric, converts the Sparkplug write into the device's native protocol, and writes the new value to the PLC. The setpoint is now live in the field.
The loop then confirms itself through the data direction. Once the PLC's value actually changes, the device reports the new value back upward in a DDATA message, and the host sees the reported value match what it commanded. This closes the write with real confirmation rather than blind hope: the operator does not just fire a command into the dark but sees the field confirm that the change took effect. That report-back is why the command and data directions work as a pair - one carries the intent down, the other carries the confirmation up.
For cloud SCADA over MQTT, this writeback path is what turns a cloud dashboard into genuine remote control. When a platform such as Merobix acts as the Sparkplug host, an operator can change a setpoint on a remote well pad from a browser, and the platform issues the DCMD that travels through the broker to the site's edge node and down to the PLC, with the resulting value reported back so the operator sees the change confirmed. Because the command path is defined and structured, and because writes are addressed precisely to a device and metric, this remote control can be governed carefully - which commands are permitted, who may issue them - while still giving field operations real two-way reach from anywhere.
NCMD is a command addressed to an edge node itself - used to write node-level metrics such as the rebirth control metric. DCMD is a command addressed to a specific device sitting behind that edge node, carrying an extra device identifier, and is how a host writes a real field value like a setpoint to a particular PLC. Both travel downward from host to field; the difference is whether the target is the node or a device behind it.
The host publishes a DCMD addressed to the group, edge node, and device, and the broker delivers it to the edge node that fronts that device. The edge node receives the command, identifies the target device and metric, and translates the Sparkplug write into the device's native protocol to write the value to the PLC. The edge node is the bridge that converts an MQTT command into a concrete write on the field equipment.
After the command is applied, the device reports its new value back upward in a DDATA message, and the host sees the reported value match what it commanded. This confirmation closes the loop, so an operator does not merely fire a write and hope, but sees the field acknowledge that the change took effect. The command direction sends the intent down and the data direction sends the confirmation back up.
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.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.