Contact Company
Internet of Things (IoT) and machine-to-machine (M-to-M) technologies require a messaging and connectivity protocol to exchange information from remote locations.
When choosing such a protocol, several desirable features come into play:
- Small code footprint (to make it easy to implement in small devices)
- Low power consumption
- Low bandwidth consumption
- Low latency
- Use of a publish/subscribe (“pub/sub”) pattern
MQTT (message queuing telemetry transport) fulfills all of these requirements and has gained momentum with the support of major public clouds — Amazon Web Services, Microsoft Azure, and Google Cloud Platform. In this article, we’ll explore why MQTT is the most popular choice of messaging protocol for IoT products.
What is MQTT?
MQTT is a lightweight messaging protocol that was developed by IBM and first released in 1999. It uses the pub/sub pattern and translates messages between devices, servers, and applications.
Originally, MQTT was created to connect sensors on oil pipelines with communications satellites, with a focus on minimizing battery usage and bandwidth consumption.
MQTT has seen ongoing development since its inception. Version 5.0, released in May 2018, brought significant changes and enhancements to the MQTT protocol.
How Does MQTT Work?
MQTT Architecture
In the MQTT protocol, connected devices are known as “clients,” which communicate with a server called the “broker.” The broker handles the task of data transmission between clients.
Whenever a client (also known as the “publisher”) wants to distribute information, it will publish on a particular topic. The broker then forwards this information to any clients that have subscribed to that topic (known as “subscribers”).
Publishers don’t need data on the number or the locations of subscribers, and subscribers don’t require any data about the publisher. Any client can act as a publisher, subscriber, or both. Typically, clients aren’t aware of each other — only of the broker that serves as the intermediary. This setup is commonly known as the “pub/sub model”.
Types of MQTT Messages
In MQTT protocol, clients use two main types of messages: publish and subscribe.
When a client wants to send data to the broker, this is known as a “publish.” Conversely, when a client wants to receive data from the broker, it will “subscribe” to a topic or topics. Upon subscribing to a topic, the client receives all messages published on that topic going forward.
We commonly refer to published data as “messages.” Messages can be anything one part of a system needs to communicate to other parts. Messages might be raw sensor readings, log messages, telemetry data, or heartbeats. Some messages might be more like commands, prompting a specific action in the receiving clients.
Along with the message itself, the publisher also sends a QoS (quality of service) level. This level defines the guarantee of delivery of the message. These QoS levels are as follows:
- At most once: when the message is published, the broker will only receive the message “at most once.” This level shouldn’t be used for mission-critical information since it carries the risk that the subscribers won’t receive the message.
- At least once: the publisher resends the message until it receives an acknowledgment from the broker. In other words, it’s more important to ensure the message is received than to ensure it’s only received once. This is the most commonly used QoS level.
- Exactly once: the publisher and broker work together to ensure the message is received and acted upon exactly once. This level involves additional overhead in the form of a four-part handshake. Although this is the safest QoS level, it is also the slowest and therefore only used when necessary.
MQTT Use Cases
MQTT is a versatile messaging protocol with numerous use cases in the IoT realm. Here are some common applications:
- Telemetry and Sensor Networks: MQTT is ideal for collecting data from sensors in environmental monitoring, industrial automation, and smart agriculture.
- Home Automation: MQTT enables seamless communication between smart devices for controlling and monitoring home systems like lighting, security, and thermostats.
- Industrial IoT: MQTT facilitates efficient data exchange between machines, enabling predictive maintenance, remote monitoring, and process optimization.
- Asset Tracking: MQTT’s ability to handle intermittent connectivity and low power consumption makes it valuable for real-time location tracking of vehicles and valuable assets.
- Energy Management: MQTT is employed in smart energy systems for efficient communication between smart meters, energy management systems, and devices, enabling load balancing and energy optimization.
- Healthcare and Wearables: MQTT facilitates remote patient monitoring, real-time health data transmission, and integration with wearable devices in healthcare settings.
MQTT finds extensive application in various IoT scenarios, demonstrating its versatility, efficiency, and reliability. Now let’s explore the benefits of MQTT in more detail.
What Are the Benefits of MQTT?
MQTT protocol offers several benefits for IoT applications:
- Lightweight code footprint: devices need only a few lines of code to get up and running with the MQTT protocol.
- Minimized data packets: MQTT is very energy-efficient, making it ideal for battery-powered devices or those with limited CPU power.
- Speed: MQTT operates in real-time, ensuring no delays outside of QoS.
- Ease of implementation: MQTT already has libraries in programming languages such as Elixir and Python.
- Last will and testament: in case a client unexpectedly disconnects, you can set message instructions to be sent to all subscribers to remedy the situation.
- Retained messages: Each topic can have one retained message that a client automatically receives when it subscribes (like a pinned post on social media).
What Are the Drawbacks of MQTT?
Here are things that might be problematic for your use case:
- Message ordering: ordering guarantees are not absolute in MQTT protocol. Although brokers generally send messages on the same topic in the order received, the specified QoS level can affect this. The protocol specification allows brokers to treat individual topics as unordered, and ordering across topics is not part of the specification.
- Maintaining Healthy Connections: while the protocol supports reestablishing connections after timeouts or crashes, it’s essential to verify if your client requires application code to implement this functionality.
- Throttling: overloading a client with excessive messages is possible. If neither your client nor your broker handles this automatically, you’ll need to implement application code to manage it.
Common Alternatives to MQTT
While MQTT protocol is widely used in IoT, there are alternatives to consider:
XMPP
XMPP (extensible messaging and presence protocol) is a communications protocol based on the XML language for storing and transporting data. It’s frequently used to power instant messaging services such as Jabber.
Some of the primary differences between XMPP and MQTT are:
- The XMPP code footprint is slightly heavier, and you need an XML parser to encode and decode information.
- XMPP doesn’t have support for the pub/sub model by default (although it can with an extension).
- XMPP takes up more bandwidth than MQTT.
HTTP(S)
HTTP (hypertext transfer protocol) and its extension HTTPS (hypertext transfer protocol secure) are foundational communications protocols for the World Wide Web. However, they are stateless and carry more overhead per transmission than MQTT. Additionally, HTTPS has a lower throughput than MQTT, meaning that you can’t send as many messages in the same amount of time.
Conclusion
MQTT plays a crucial role in IoT projects by providing a more “low-lift” solution in terms of technical specifications while achieving the desired connections among devices, servers, and applications. Its lightweight nature, energy efficiency, real-time operation, and ease of implementation make it a popular choice in the IoT landscape.
Latest IoT News
