What is MQTT 5.0, and How Does it Work in IoT?

What Is MQTT?

MQTT serves as a tool to connect many types of IoT devices in deployments of all magnitudes. It originally started in 1999 for oil and gas pipelines to communicate over remote satellites.

Operating above TCP/IP, MQTT is a network protocol that functions on a publisher-subscriber communication model. It’s lightweight enough to be used for a wide variety of IoT devices yet powerful enough to work through unstable network conditions.

Why Is MQTT Used in IoT Development?

Thanks to its energy-efficient method of delivering data, MQTT is common for low-powered devices with limited CPU power or RAM.

An Example of an MQTT 5.0 Small System Deployment

Let’s look at a case where we need to organize a local MQTT v5.0 network with Python-based clients. We will describe the challenges, issues, and pros and cons along the way. We will conclude by comparing it with an MQTT v3.1.1 network.

Description

We have a building with several rooms containing a local area network (LAN). One room contains three standalone devices (e.g., activity standalone sensor, photo camera sensor, or audio sensor).

The host device is located inside the LAN and connected to the router wirelessly or via cable. It must provide data gathering (and processing) functions from the standalone device in a period and must store this data locally in the database.

For the current scope, an SQLLite database or simpler alternative is usable. The photo camera sensor and audio sensor must activate only after receiving the message from the activity sensor.

Goal

To ensure communication between the host device and standalone devices; and provide local database deployment and communication on the host side.

Requirements

1. All messages going from the sensors to the host device must be constrained with the additional properties of MQTT 5.0 (e.g., the byte size of the message transferred to the topic).
2. Messages from topics must contain a MIME type for easier encoding on the host side.
3. Messages must be stored inside a database instance locally.

Notations

Standalone device: x86 or ARM-based (e.g., Raspberry Pi) with connected sensors and access to the local network.

Host device: x86 or ARM-based (e.g., Raspberry Pi) hosts MQTT broker and handles messages from standalone devices.

Which Clients Support MQTT 5.0 and Python?

Currently, we have two options to work with: paho-MQTT and gMQTT. However, these options do not have a built-in MQTT 5.0 broker and therefore are not preferable with a local deployment of a network. There is a non-Python implementation of the broker called Mosquitto that does support MQTT 5.0.

It is able to support up to 50 000 devices per broker. Mosquitto has an “inflight queue” that can be configured in size (typical setting: 1000 messages) so that even under heavy load conditions like thousands of messages per sec or thousands of connected clients no connection or message gets lost.

How a Python-Based System Works With MQTT 5.0

Not many libraries and documentation exist for the MQTT v5.0 protocol, especially from a Python developer’s point of view. The only current v5.0 clients for Python are gmqtt and paho-mqtt.

Pros and Cons of an MQTT v5.0 Local Network

Pros

1. Fully autonomous device interaction inside the local area network. There is no need for cloud providers like GCP or AWS and no need for a WAN connection for local IoT system functioning.
2. Network latency and data transfer speed. Transfer speeds depend only on the hardware capability of local devices. The disposition of devices within a LAN environment enables minimal latency.
3. Energy efficiency with MQTT compared to the competition.
4. Network security. Since the local network is not exposed to WAN, packets with messages cannot be captured or traced by an entity outside of the local network. The MQTT v5.0 protocol provides authentication of clients by servers and of servers by clients. MQTT also may use TLS certificates for secure connections and data transferring.
5. Packet restrictions can be applied to brokers inside the network.
6. Containerization. Easier containerization makes simulation and debugging much easier.

Cons

1. Process and thread management for receiving messages and parallel works must be done beforehand. Threads for processing messages should be parallelized and managed properly for your devices to operate properly.
2. WAN connection. Developers must debug and troubleshoot regularly, and having a proper connection between the host and standalone devices must be organized first, usually with a secure SSH connection.
3. No support for stream transfer with the MQTT protocol. Look to other protocols if your organization needs them.
4. Transfer of large files not available on MQTT. Consider bucket uploads or the HTTP protocol.
5. Brokers cannot intelligently manage data. However, data can be stored for a limited time during a disconnection.

Major Practical Differences Between MQTT v3.1.1 and v5.0

• Properties for storing additional data
• Payload format indicators (bytes, UTF-8, or UTF-8 string pair)
• Request/Response Pattern
• Reason codes for client connection and disconnection
• Session expirations and control

The upgraded protocol version allows simplifying data payload processing and parsing. It brings the ability to separate and precise control over messages, connections, and sessions. And it allows transferring additional data through properties, which could lead to creating more sophisticated IoT solutions.

MQTT 5 Challenges

• Process/thread management for parallel publishing and listening for messages on standalone devices. You need to pay attention in a production environment.
• Limited documentation available, and the implementation process of classes inside the package (paho-mqtt) is not obvious.
• Installation of a broker and its upgrade to MQTT v5.0 is difficult because of a lack of documentation.
• To recognize a device in the network, we need an IP discoverer to be added to the system.

Big Improvement

MQTT v5.0 is a suitable option for local IoT device communication if you have a central device that can host a message broker for communication between devices and/or the host. Despite its drawbacks (most of which were eliminated in MQTT v5.0), this protocol can be used for communication between small-to-medium sized networks of IoT devices.

• Device Management
• Network and Protocols

• Device Management
• Network and Protocols