One of the first things that confuses people learning Sparkplug is why it distinguishes between an edge node and a device, when both seem like just things reporting data. The distinction is central to how Sparkplug organizes an industrial network: the edge node is the gateway that actually connects to the broker, and each device is a piece of equipment - often a PLC behind that gateway - that the node represents. Sparkplug ties them together with a three-level topic hierarchy of group, edge node, and device identifiers. This guide explains what separates an edge node from a device, how one physical gateway fans out to many logical devices, and how PLCs behind a gateway map cleanly into the Sparkplug namespace.
Sparkplug Edge Node vs Device in one line: In Sparkplug, an edge node - also called an Edge of Network node or EoN - is the component that connects to the MQTT broker and speaks Sparkplug, while a device is a piece of equipment behind that node, such as a PLC, that does not connect to the broker itself. The node represents its devices, and the topic hierarchy group_id/edge_node_id/device_id addresses exactly which group, which gateway, and which device a message concerns.
The edge node, formally the Edge of Network node or EoN, is the participant that actually holds an MQTT connection to the broker and publishes Sparkplug messages. It is typically a gateway, a piece of edge software, or an industrial computer that sits at the boundary between the field equipment and the network. The edge node is the thing that logs in, sends its birth certificate, publishes data, and registers a death message as its last will. In Sparkplug terms, it is a first-class citizen on the broker.
A device, by contrast, is a piece of equipment the edge node speaks for but which does not itself connect to the broker. A PLC on a field bus, a flow computer on a serial line, or an instrument on a local network is a device: it produces data and accepts commands, but it has no MQTT stack and no direct relationship with the broker. It reaches the Sparkplug world only through the edge node, which polls it in its native protocol and represents it upward. The device is real equipment; the edge node is its ambassador to the broker.
This division mirrors how industrial sites are actually built. Field equipment rarely speaks MQTT natively, and putting every PLC directly on the broker would be neither practical nor desirable. Instead a gateway at the edge collects from many pieces of local equipment and presents them to the network as a tidy set of devices behind one node. Sparkplug's edge-node-versus-device model names that arrangement directly, so the protocol's structure matches the physical reality of a gateway fronting a collection of controllers.
Sparkplug addresses everything through a topic namespace built on three identifiers arranged as a hierarchy: the group identifier, the edge node identifier, and the device identifier. The group is the top level, a logical grouping of edge nodes - often used to represent a site, a region, or a functional area so that all the gateways belonging to one facility share a group. The group is how you carve a large deployment into meaningful segments rather than one flat list of nodes.
Within a group, the edge node identifier names a specific gateway, and within that node the device identifier names a specific device behind it. So a fully qualified address reads as group, then edge node, then device - identifying which site, which gateway there, and which controller behind that gateway a message concerns. Node-level messages carry just the group and edge node identifiers, because they are about the node itself, while device-level messages add the device identifier to pinpoint the equipment behind the node. The presence or absence of the device identifier is what distinguishes a message about the gateway from a message about a device it fronts.
This hierarchy is what makes a Sparkplug namespace both organized and unambiguous. Every metric in the system has a clear address that says where it lives in the group-node-device tree, so a host consuming the data knows exactly which piece of equipment at which site each value belongs to. It also scales cleanly: adding a new controller behind an existing gateway is a new device identifier under that node, and standing up a new site is a new group, without disturbing anything already in place. The three levels give a deployment room to grow while keeping every point precisely located.
The fan-out from one edge node to many devices is the practical heart of the model. A single gateway at a remote site might front a dozen PLCs, several flow computers, and a handful of instruments, polling each over its native protocol and representing all of them as devices behind that one node. To the broker and the host, that is one connected edge node with many devices hanging off it, even though physically it is one box wired to a rack of controllers. This is exactly how PLCs behind a gateway map into Sparkplug: each becomes a device under the node that the gateway is.
This structure keeps a large field deployment comprehensible. Rather than a flat swarm of disconnected points, the data arrives organized by which gateway collected it and which device produced it, all nested under the group that names the site. When the edge node publishes its birth, it declares itself and can birth its devices too, so the host learns the whole tree - this gateway, these devices behind it, these metrics on each - in one coherent picture. Connectivity is tracked at the node level, so if the gateway goes offline, the host knows every device behind it just went stale together, because they all depended on that one connection.
For cloud SCADA, this hierarchy is what lets a platform present remote field assets in a way that matches how operators think about them. When a platform such as Merobix consumes Sparkplug data, the group, edge node, and device identifiers map naturally onto site, gateway, and equipment, so a well pad's gateway and the controllers behind it appear as an organized set rather than a jumble of tags. Operators see which site, which gateway, and which device each reading came from, and when a remote gateway drops, they see the whole site's devices flagged together - a clarity that comes directly from Sparkplug modeling one edge node fanning out to many devices.
An edge node is the component that actually connects to the MQTT broker and publishes Sparkplug messages - usually a gateway or edge software at the boundary of the field network. A device is a piece of equipment behind that node, such as a PLC, that does not connect to the broker itself and is represented by the node. The node is the broker-connected ambassador; the devices are the real equipment it speaks for.
They are the three levels of Sparkplug's addressing hierarchy. The group_id is a top-level logical grouping, often a site or region; the edge_node_id names a specific gateway within that group; and the device_id names a specific device behind that gateway. Together they give every point a clear address that identifies which site, which gateway, and which controller a message concerns.
Each PLC becomes a device behind the edge node that the gateway represents. The gateway polls the PLCs in their native protocols and presents each as a device with its own device_id under the node, so one physical gateway fans out to many logical devices in the Sparkplug namespace. To the host, that appears as a single connected edge node with several devices hanging off it.
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.