Page History

...

• 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