MQTT Transmission supports two different configurations to send data using MQTT:

• Transmitter - which is an agent that monitor tags, converts them to Sparkplug Messages, and publishes to an MQTT Server. 
• UNS Transmitter - which is an agent that monitors tags and publishes them as MQTT Messages with a JSON payload to an MQTT Server. 

To determine which one to use we need to understand the difference between MQTT and MQTT Sparkplug.

MQTT

MQTT is a lightweight messaging protocol designed for efficient communication between devices. It was created to address the challenges of transmitting data reliably over low-bandwidth, high-latency, or unstable networks — conditions commonly found in industrial settings, remote monitoring systems, and embedded devices.

...

These characteristics have made MQTT a popular choice in IoT ecosystems, enabling everything from smart home automation to large-scale industrial control systems.

MQTT in Industrial IoT (IIoT) systems

MQTT has become a key messaging protocol for Industrial IoT (IIoT) thanks to its lightweight design and efficient data delivery. Yet despite its strengths, MQTT lacks a standardized way to define and structure data, often leaving developers to build custom logic for every device type. This approach works — but it doesn’t scale easily.

...

This is where MQTT Sparkplug comes in. Sparkplug builds on MQTT’s foundation, adding data standardization, state awareness, and improved scalability — all essential for complex IIoT environments.

MQTT Sparkplug

MQTT Sparkplug is an open-source specification designed to bring structure and standardization to MQTT data in industrial environments. Built on top of MQTT, Sparkplug introduces a standardized payload format, a defined topic structure, and a set of state management rules. This ensures that devices, sensors, and software systems all speak the same language to seamlessly integrate data and improve scalability.

...

By combining these features, Sparkplug transforms MQTT from a flexible data transport protocol into a robust, self-describing communication standard for IIoT. It eliminates the need for custom parsing logic, reduces integration headaches, and enables true plug-and-play scalability across industrial networks.

Key Differences

...

This is the MQTT Transmission module using Transmitter configuration

Host Application

The Host Application is the system that consumes data from Edge Nodes. Typically, this is an industrial control system, IoT platform, or data analytics tool.

...

This is the MQTT Distributor module or Chariot® MQTT Server

How MQTT Sparkplug Works

By introducing standardized messaging rules, Sparkplug ensures that data is not only delivered efficiently but also consistently understood across devices and applications. At the core of this system are Sparkplug’s defined message types, topic structure, and state management mechanisms.

...

Sparkplug enforces a strict topic structure that organizes data consistently across devices and systems. Each topic follows a predefined format of Sparkplug's topic format: spBv1.0/<Group ID>/<Message Type>/<Edge Node ID>/<Device ID> where:

• spBv1.0 – Identifies the Sparkplug protocol version.
• Group ID – Represents a logical grouping of devices (e.g., production line, factory floor).Edge Nodes (eg, facility name) 
• Message Type – Defines the message purpose (e.g., NBIRTH, NDATA, NDEATH).
• Edge Node ID – Identifies the originating device.logical Edge Node.
• Device ID ( optional) - Identifies the  device (eg. PLC)

This structure simplifies data organization, ensuring that all systems can identify device sources and message types without custom logic.

...

Each payload follows a consistent format that includes:

• Metrics – The actual data points being transmitted

...

• Timestamps – For precise data tracking

...

• Metadata – Additional details about the device or data source.

This structured payload eliminates the ambiguity seen in traditional MQTT deployments, where payloads can vary significantly between devices.

...

To maintain system awareness, Sparkplug introduces birth and death certificates.

• Birth Certificate (NBIRTH): Sent by an Edge Node when it comes online.
  • This message announces the node’s presence, publishes its available metrics, and signals to the system that the device is active.
• Death Certificate (NDEATH): Sent by the MQTT Broker if an Edge Node unexpectedly disconnects.
  • This ensures the system is immediately aware when a device goes offline.

Real-Time State Awareness

Sparkplug’s state management goes beyond simple message delivery. By requiring devices to maintain active connections with the broker, Sparkplug ensures that system state is always known.

When devices disconnect, the broker automatically alerts Host Applications by publishing a death certificate — preventing stale or inaccurate data from being mistaken as live.

Unified Namespace for Simplified Data Management

Sparkplug’s structured topics and payloads enable a unified namespace, where all devices adhere to the same data model. This simplifies the integration of new devices, reduces configuration overhead, and ensures data is always delivered in a predictable format — critical for scaling IIoT ecosystems.

Which One to Use?

Plain MQTT is ideal for lightweight IoT deployments where flexibility is key, and devices produce minimal data points.

The MQTT Sparkplug is better suited for Transmitter is designed to be used at the Edge of complex IIoT environments where data consistency, system state awareness, and scalability are critical.

Transmitters

A Transmitter is an agent that monitor tags, converts them to Sparkplug Messages, and publishes to an MQTT Server. 

• 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 Messages can be consumed by any Sparkplug Host Application such as MQTT Engine.
  Any MQTT client created by the agent will publish and subscribe to data using the Sparkplug B protocol.
  • 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)
  • Uses the namespace spBv1.0
  • Using the Sparkplug B protocol provides the benefits of session management including Primary Host ID
  • Understands Ignition UDTs and can be configured to publish UDT definitions in BIRTH messages
  • Is capable of publishing 10s of thousands data messages contain multiple tag change events

  UNS Transmitters

  A UNS Transmitter is an agent that monitors tags and publishes them as MQTT Messages with a JSON payload to an MQTT Server. 

  The UNS Transmitter would be configured to read tags from a UNS structure, such as created by MQTT Engine, and publish tag changes over MQTT to any Enterprise consuming clients.

  • thousands (or many more) events in a single message with the payload containing all the associated metrics and meta data 

  
  

  The UNS Transmitter is ideal for lightweight IT deployments where minimal data points are required by Enterprise consuming clients.

  It is generally used on the IT side of an OT/IT infrastructure

  • 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
  • Messages can be consumed by any MQTT client that can parse JSON messages.
  • Any MQTT client created by the agent will only publish data using the MQTT protocol.
    • Uses the namespace unsAv1.0 (which can be disabled)
    • Publishes a single data message for each tag when QualifiedValue of the tag changes 
    • Publishes a single properties message is published for each tag on every client connection
  • 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
  • This 'topic per datapoint' strategy is very expensive from a resource perspective on both the MQTT clients as well as the MQTT Server