Sparkplug B & UNS Topic Builder
Build, validate and bulk-generate Sparkplug B topics and ISA-95-based Unified Namespace paths.
Generated topic
Subscribe filters
everything in the groupall messages of the nodespBv1.0/#all Sparkplug traffic
| Type | Scope | Meaning | QoS | Retain |
|---|---|---|---|---|
NBIRTH | node | Node birth: announces all metrics and metadata | 0 | false |
NDEATH | node | Node death: published as the Last Will when the connection drops | 1 | false |
NDATA | node | Node data: changed metrics | 0 | false |
NCMD | node | Command to a node | 0 | false |
DBIRTH | device | Device birth: announces the device’s metrics | 0 | false |
DDEATH | device | Device death: when the device becomes unreachable | 0 | false |
DDATA | device | Device data: changed metrics | 0 | false |
DCMD | device | Command to a device | 0 | false |
STATE | host | Online/offline state of the host application (spBv1.0/STATE/{host_id}) | 1 | true |
Values follow the Eclipse Sparkplug 3.0 specification; verify against the specification and your product documentation before going to production.
Generated UNS path
Hierarchy
Practical principles for UNS naming
- Go from general to specific: enterprise → site → area → line → cell → asset → metric (the ISA-95 equipment hierarchy).
- Keep names stable: renaming affects every subscriber. Put information that changes over time (such as an order number) in the payload, not the path.
- Avoid spaces, mixed case and non-ASCII characters; “+”, “#” and “/” cannot be used inside names.
- Topics starting with “$” are reserved for MQTT brokers (for example $SYS); do not start your enterprise name with it.
- Do not make the hierarchy deeper than needed; every extra level complicates subscription filters and maintenance.
Read more in What is a Unified Namespace? and UNS topic naming.
0 paths
How does the Sparkplug B topic structure work?
Sparkplug brings an industrial convention to MQTT’s flexible topic structure. A topic has four parts: the namespace version (spBv1.0), the group_id (logical grouping such as a site or line), the message type and the edge_node_id. Device messages append a device_id.
“Birth” messages announce every metric a node or device provides; “Death” messages are published when the connection drops. Subscribing applications therefore know whether data is current or stale.
For the concepts, see our glossary: Sparkplug B, MQTT, Unified Namespace, ISA-95.
Frequently asked questions
What does a Sparkplug B topic look like?
It follows spBv1.0/{group_id}/{message_type}/{edge_node_id}[/{device_id}]. Node messages (NBIRTH, NDEATH, NDATA, NCMD) have no device_id; device messages (DBIRTH, DDEATH, DDATA, DCMD) do. Host application state uses spBv1.0/STATE/{host_id}.
Are Sparkplug and UNS the same thing?
No. A UNS is an architectural approach (one meaningful namespace); Sparkplug is a specification defining topic structure, payload format and state management on MQTT. A UNS can be built with Sparkplug or with plain MQTT.
Is the data I enter sent anywhere?
No. The tool runs entirely in your browser; the names you enter are not transmitted to a server.
Want to build a UNS in a real project?
Let’s design a Unified Namespace implementation together with the embedded MQTT broker and Sparkplug support of HighByte Intelligence Hub.