Enhance your IoT connectivity with MQTT.
Contents
ToggleWhat is MQTT?
MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol that transports messages between devices. It is designed for connections with remote locations and especially useful in environments where network bandwidth is limited. MQTT is widely used in the Industrial Internet of Things (IIoT) because of its efficiency, ease of implementation, and ability to scale. While most industrial protocols use the traditional client-server model, MQTT differs in its use of a publish-subscribe model where devices (clients) can publish messages to a broker and subscribe to receive messages from the broker
Sparkplug B
Sparkplug B is a specification that defines how to use MQTT in industrial automation and Internet of Things (IoT) applications. It provides a standard way to represent data, ensuring interoperability between different devices and systems. Sparkplug B is designed to work seamlessly with MQTT, adding structured data formats and state management to enhance MQTT’s capabilities for industrial use.
Key Features of Sparkplug B
Data Encoding
Sparkplug B defines a standard way to encode data in a binary format, making it efficient and compact. It uses Google’s Protocol Buffers (protobuf) for serialization, which is both space and time-efficient.
Topic Namespace
It defines a structured topic namespace that standardizes how topics are organized, making it easier to understand and manage the data flow between MQTT clients and brokers.
State Management
Sparkplug B includes mechanisms for managing the state of devices and applications. It allows clients to report their current state (e.g., online, offline) and ensures that the system is aware of the status of all components.
Birth and Death Certificates
Devices and applications send a “birth certificate” when they come online, which includes information about their state and capabilities. When they go offline unexpectedly, the broker can detect this and generate a “death certificate,” allowing other clients to handle the absence of the device gracefully.
Payload Structure
Sparkplug B specifies a well-defined payload structure that includes metadata, metrics, and the actual data values. This structured approach ensures that data is self-describing and easy to parse.
Edge of Network Nodes (EoN)
Defines a standard way for edge devices to communicate with the central system. EoN nodes act as intermediaries between field devices and the MQTT broker, aggregating data and managing local communication.
Interoperability
By providing a standard format and protocol for data exchange, Sparkplug B ensures interoperability between different vendors and systems, reducing integration complexity and enhancing system robustness.
MQTT Brokers
An MQTT Broker is the central server that receives messages from clients and routes them to the appropriate subscribers. There are Open Source MQTT Brokers as well as Commercial MQTT Brokers. A few examples of each,
Open Source Brokers
Mosquitto
- Very popular
- Lightweight and extremely efficient.
EMQX
- Highly scalable and extensible
- Suitable for large-scale IoT applications
NanoMQ
- Lightweight and high-performance tailored for IoT edge computing
RabbitMQ
- Robus messaging broker that supports various protocols, including MQTT
HiveMQ
- Designed for enterprise use with high availability and scalability
Commercial Brokers
Cirrus Link Chariot
- Integrates seamlessly with Ignition by Inductive Automation
- Purpose-built for OT and industrial applications
Ignition’s MQTT Distributor Module
- Ignition’s built-in MQTT Broker
Azure IoT Hub
- Microsoft Azure managed IoT service with MQTT support
- Comprehensive set of features for device management and data analytics
AWS IoT Core
- Amazon Web Services managed MQTT Broker service
- Scalabe and secure with deep AWS integration
Google Cloud IoT Core
- Managed service for securely connectin, managing, and ingesting data from globally dispersed devices
MQTT Clients
An MQTT Client is any device or application that connects to the broker to publish or subscribe to messages. A few examples of MQTT clients,
SCADA Systems as MQTT Clients
Most modern SCADA systems can function as MQTT clients which they achieve through either MQTT modules or plugins that facilitate easy integration with MQTT brokers. These modules handle the necessary MQTT communication and data mapping to SCADA tags. For example, Ignition by Inductive Automation uses MQTT modules by Cirrus Link to subscribe to and publish MQTT data. These modules include the MQTT Engine Module, MQTT Distributor Modules, MQTT Transmission Module and MQTT Recorder Module.
Software MQTT Clients
Software MQTT clients can be either desktop applications, browser extensions, mobile applications, or command line tools. MQTT Explorer is an example of a very popular desktop software MQTT client. It is a comprehensive MQTT client with a clean interface for visualizing MQTT topics and messages and is ideal for debugging and testing.
MQTT Message Types
Fourteen standardized message types are used to connect and disconnect clients from brokers, broadcast data, acknowledge data receipts, and maintain the client-server connection. For data transfer, MQTT uses the TCP protocol. However, these three message types are the most commonly used:
- CONNECT: Initiates a connection between the client and the broker.
- PUBLISH: Sends data from the client to the broker.
- SUBSCRIBE: Registers a client to receive messages on specific topics.
How does MQTT protocol work?
The MQTT protocol begins with clients, which can be either publishers or subscribers, connecting to a broker. This connection is initiated by the client sending a CONNECT message, to which the broker responds with a CONNACK message, establishing the connection.
Once connected, a publisher client can send a PUBLISH message containing a topic and the data payload to the broker. The broker receives this message and checks which clients have subscribed to the specified topic. Clients interested in this topic would have previously sent a SUBSCRIBE message to the broker, which acknowledges these subscriptions with a SUBACK message.
When the broker identifies subscribers for the published topic, it forwards the message to these subscriber clients. Depending on the Quality of Service (QoS) level set, the broker and clients exchange acknowledgment messages to ensure reliable delivery. The three QoS levels include: QoS 0 (at most once), QoS 1 (at least once), and QoS 2 (exactly once).
To maintain the connection, clients periodically send PINGREQ messages if no data is being transmitted, and the broker responds with PINGRESP messages to confirm the connection is still active. When a client wants to disconnect, it sends a DISCONNECT message, and the broker acknowledges and closes the connection.
Commonly Asked Questions about MQTT
Message Queuing Telemetry Transport
MQTT’s lightweight, efficient, and reliable nature, combined with its flexibility and scalability, makes it an ideal protocol for a wide range of IoT applications.
MQTT is designed for efficient, lightweight, and real-time communication, making it ideal for IoT and M2M applications. HTTP is more suited for traditional web applications, offering robust and versatile communication capabilities but with higher overhead. The choice between MQTT and HTTP depends on the specific requirements of the application, including factors like bandwidth efficiency, real-time communication needs, and the nature of the data being exchanged.
A real-time example of MQTT in action is the use of MQTT for monitoring remote tank levels.
No, MQTT cannot function without a broker. The broker is a central component of the MQTT protocol, responsible for receiving messages from publishers, filtering them, and distributing them to the appropriate subscribers. The broker manages all the communication between clients, ensuring messages are delivered reliably according to the specified Quality of Service (QoS) levels.