Subscribe to our blog to get the latest articles straight to your inbox.

Internet of Things (IoT) and machine-to-machine (M2M) technologies need to use a messaging and connectivity protocol in order to exchange information from a remote location.

A few desirable features of such a protocol are:

MQTT fulfills all of these requirements and has the momentum of the big public clouds—Amazon Web Services, Microsoft Azure, and Google Cloud Platform—behind it. In this article, we’ll explore why MQTT is the most popular choice of messaging protocol for IoT products.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) 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.

The MQTT protocol was initially created in order to link sensors on oil pipelines with communications satellites, with an emphasis on minimal battery loss and bandwidth consumption.

Since its inception, MQTT has continued to undergo development, with version 5.0 arriving in May 2018. Version 3.1.1 was submitted to the OASIS consortium in 2013 and accepted as an ISO standard.

How Does MQTT Work?

MQTT architecture

The connected devices in the MQTT protocol are known as “clients,” which communicate with a server referred to as the “broker.” The broker handles the task of data transmission between clients.

Whenever a client (known as the “publisher”) wants to distribute information, it will publish to a particular topic, the broker then sends this information to any clients that have subscribed to that topic (known as “subscribers”).

The publisher does not need any data on the number or the locations of subscribers. In turn, subscribers do not need any data about the publisher. Any client can be a publisher, subscriber, or both. The clients are typically not aware of each other, only of the broker that serves as the intermediary. This setup is popularly known as the “pub/sub model.”

MQTT messages

When a client wants to send data to the broker, this is known as a “publish.” When a client wants to receive data from the broker, it will “subscribe” to a topic or topics. When a client subscribes to a certain topic, it will receive all messages published on that topic going forward.

Along with the message itself, the publisher also sends a QoS (Quality of Service) level. This level defines the guarantee of delivery for 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 should not be used for mission-critical information since it carries the risk that the subscribers will not receive the message.
  • At least once: The publisher continues to resend the message until it receives an acknowledgment from the broker regarding the particular message. In other words, it’s more important that the message is received than it is to ensure it is only received once. This is probably the most commonly used QoS level.
  • Exactly once: The publisher and broker work together to ensure the broker will receive and act on a message exactly once. This requires some 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.

How Does MQTT Work in IoT Projects?

In this section, we’ll discuss how you can use MQTT in an IoT project, using one of our recent clients as an example.

An automotive battery company wanted to offer “fresher” batteries to sell to its customers nationwide. This meant implementing a “first in, first out” strategy so that batteries wouldn’t sit on the shelf for too long.

Of course, this required the company to track the dates of arrival of the stock on their shelves. In need of a trusted IoT partner, the company reached out to Very.

Very helped install IoT sensors on the company’s batteries and on their shelves. These sensors transmit information via MQTT to Amazon Web Services (AWS) in the cloud. Each battery has a signal-emitting device that sends a Bluetooth signal to convey its presence on the rack. In addition, a single battery-powered hub wakes up once per day in order to transmit information to AWS using MQTT (as well as the TLS protocol for secure transmission).

The Benefits of MQTT

The benefits of MQTT include:

  • Lightweight code footprint: Devices need only a few lines of code in order to get up and running with the MQTT protocol.
  • Minimized data packets: MQTT is very energy-efficient. This is great if a device is battery-powered or has little CPU power.
  • Speed: MQTT operates in real time, with no delays outside of QoS.
  • Ease of implementation: MQTT already has libraries in programming languages such as Elixir and Python.
  • Last will and testament: If a client unexpectedly disconnects, you can set message instructions to be sent to all subscribers in order 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).

Common Alternatives to MQTT

XMPP

XMPP (Extensible Messaging and Presence Protocol) is a communications protocol based on the XML language for storing and transporting data. It is frequently used to power instant messaging services such as Jabber.

Some of the 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 does not 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 communications protocols that are the foundation of the World Wide Web. However, they are stateless and carry more overhead per transmission than MQTT. In addition, HTTPS has a lower throughput than MQTT, meaning that you can’t send as many messages in the same period of time.

Conclusion

MQTT plays a crucial role in making IoT projects more “low-lift” in terms of technical specifications while achieving the desired connections among devices, servers, and applications. If you’re considering using MQTT in your IoT project, partner with a skilled, experienced development agency like Very who knows the right way to do it.