Page History

...

Aspect	MQTT	Sparkplug
Data Format	Flexible but undefined. Devices may send data in JSON, plain text, or binary, requiring custom parsing logicFlexible but undefined. Devices may send data in JSON, plain text, or binary, requiring custom parsing logic	Enforces a standardized Protobuf-based payload structure for consistent data formatting
Topic Structure	Flexible but unstructured. Topic naming conventions vary across devices, often requiring manual configuration	Uses a strict topic structure that organizes data consistently across devices
State Awareness	No built-in state management. Systems must rely on custom logic to track device connectivity	Introduces birth and death certificates to ensure systems always know which devices are online or offline
Device Integration	Adding new devices may require manual updates to data parsing logic or custom topic rules	Standardized structure enables plug-and-play scalability for new devices
Data Integrity	No built-in mechanisms to prevent stale data from being mistaken for live updates	Ensures stale data is removed when devices disconnect, reducing the risk of inaccurate insights
Bandwidth Efficiency	Supports efficient communication, but payload size can vary depending on data format	Uses Protobuf for compact, efficient payloads that minimize bandwidth usage
Discover Data Sources	No built-in mechanisms for discovering data sources and requires manual configuration	Built-in mechanism for finding new data sources within the network

...

The Sparkplug Transmitter creates a Sparkplug Client
After connection to the MQTT server, two way communication is available between the Sparkplug Host Application and the Sparkplug Client
Uses BIRTH and DEATH messages together with Primary Host ID to maintain system state awareness
Data is always published as QoS0.
- This is because Sparkplug features ensure data delivery rather than MQTT itself.
The published messages can be consumed by any Sparkplug Host Application such as MQTT Engine.
- The topic uses the identified SPARKPLUG IDs for Group, Edge Node and Device
- The payload includes Metrics, Timestamps and Metadata encoded using Google’s Protocol Buffers (Protobuf)
Understands Ignition UDTs and can be configured to publish UDT definitions in BIRTH messages
Is capable of publishing thousands of tag change (or many more) events in a single message with the payload containing all the associated metrics and meta data

...

The UNS Transmitter creates an MQTT Client
After connection to the MQTT server, data can only be published from the MQTT Client to the MQTT Server
Uses LWT to maintain system state awareness
- Publishes a properties message for each tag on a client connection
Data can be published as QoS0, QoS1 or QoS2
The published messages can be consumed by any MQTT Client
- The topic is the identified Ignition tag path
- The payload contains only the tag name, dataType, value, timestamp and quality formatted as JSON
Publishes the leaf tags of Ignition UDTs (a.k.a. Sparkplug Templates) and the structure of the UDT (i.e. UDT name itself and folders in the UDT) become topic tokens
Is limited to publishing a single data message for each tag change event event
This 'topic per datapoint' strategy is very expensive from a resource perspective on both the MQTT clients as well as the MQTT Server

Versions Compared