- Published on
MQTT vs Sparkplug B: Comparison of Communication Protocols Part I
- Authors
- Name
- Martin Szerment
Introduction
In the world of the Industrial Internet of Things (IIoT), choosing the right communication protocol is crucial.
Two popular protocols are MQTT and Sparkplug B. Both have their unique features and applications. In this article, we will discuss these protocols, their origins, operation, quality of service, message retention, and the differences between them. Additionally, we will present the application of Sparkplug B in the Omnimes system by Multiprojekt.
Origin of MQTT
The MQTT protocol was invented in 1999 by Andy Stanford-Clark from IBM and Arlen Nipper from Arcom (now Cirrus Link). Its main principles are:
- Simple implementation
- Delivery of quality of service (QoS) data
- Lightweight and bandwidth-efficient
- Data independence
- Session continuity (retention)
Operation of MQTT
MQTT operates in a publish/subscribe model, where a client subscribes to specific topics and receives messages. An example topic could be switch/light/
, and the payload could be a JSON document:
{status: "ON", color:"red", date:"2023-01-08", time:"10:23"}

Quality of Service (QoS) in MQTT
MQTT offers three levels of QoS:
- QoS 0: "At most once" - The message is delivered once, without acknowledgment.
- QoS 1: "At least once" - The message is delivered at least once, with acknowledgment of receipt.
- QoS 2: "Exactly once" - The message is delivered exactly once, with acknowledgment of receipt and feedback to the sender.
Message Retention in MQTT
Message retention allows the last state of a message to be saved, which is useful for notifications about the status of devices. This way, a new user can learn about the last known state of the machine.
Origin of Sparkplug B
Sparkplug B is a protocol based on MQTT, developed by Arlen Nipper (founder of Cirrus Link). It was created in response to industry needs, offering a more standardized and less complex protocol compared to OPC UA.
Differences Between MQTT and Sparkplug B
- Channel and Payload Schema:
-
Sparkplug B: Standardized topic and payload schema. Example topic:
spBv1.0/switch/light/#
. Example payload:{ "timestamp": 1673262477011, "metrics": [ { "name": "status", "timestamp": 1673262477011, "dataType": "Int16", "value": "ON" }, { "name": "color", "timestamp": 1673262477011, "dataType": "Int16", "value": "red" } ], "seq": 9 } -
MQTT: Flexibility in creating topics and payloads. Example topic:
switch/light/
. Example payload:{ "status": "ON", "color": "red", "date": "2023-01-08", "time": "10:23" }
-
- Message Retention:
- Sparkplug B: No native message retention. It is necessary to create a data store that will maintain the last states/information from a given device.
- MQTT: Built-in message retention functionality.
Application of Sparkplug B in the Omnimes System by Multiprojekt
The implementation of Sparkplug B in the Omnimes system has brought several benefits:
- Creation of a configuration wizard
- Simplified connection setup
- No imposition of data structure on the user
- Shifting the responsibility for configuration to the user

Summary
The choice between MQTT and Sparkplug B depends on the specific needs and requirements of the application.
- MQTT: More flexible with native message retention.
- Sparkplug B: Offers standardized structures and is more optimized for industrial applications.
Both protocols have their place in the IIoT ecosystem, and it is essential to carefully analyze which one best meets the requirements of your project.
← Back to the blog