How IOT communicates (MQTT protocols)

This series is going to be a comprehensive yet accessible guide to understanding how IoT devices communicate, breaking down complex concepts into easy-to-follow steps for both beginners and experienced professionals.

How IOT communicate with the user ?

The IoT communication process involves five key components, they are:

• Sensors : In a smart home system, temperature sensors detect the room's temperature and gather data to be transmitted.
• Connectivity protocols : The sensor data is sent to a central hub using protocols like Wi-Fi or Bluetooth, enabling communication between the sensor and other devices.
• Application protocols : The hub uses application protocols like MQTT to structure the data and ensure it reaches the cloud or other connected devices.
• Cloud services : The data is then sent to cloud services, where it can be stored, processed, and analysed to make informed decisions, such as adjusting the thermostat.
• User interfaces : Finally, the processed data is presented to the user through a mobile app or web interface, allowing them to monitor and control the temperature settings remotely.

We'll not be deeply involved into the hardware aspects; instead, we'll focus on the software side, including machine-to-machine communication and the protocols involved.

IoT Communication Protocols

Some widely used IoT communication protocols are MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol), HTTP (Hypertext Transfer Protocol), and Zigbee. There are various advantages/disadvantages of one over another, but in this article we will be covering the MQTT protocols and moving with the same.

Advantage of MQTT over HTTP is as below :

Getting Started with MQTT protocol

Imagine MQTT as a TV broadcaster transmitting a program on a specific channel, while the viewer tunes in to that channel to watch. There's no direct connection between the broadcaster and the viewer.

In short, MQTT is a messaging protocol designed for transferring messages using a publish-subscribe model. This model allows messages to be sent to 0, 1, or N clients. In MQTT, a publisher sends messages on a specific topic, and a subscriber must subscribe to that topic to receive the message.

Important Points to Note

1. Clients do not have addresses like in email systems, and messages are not sent to clients.
2. Messages are published to a broker on a topic.
3. The job of an MQTT broker is to filter messages based on topic, and then distribute them to subscribers.
4. A client can receive these messages by subscribing to that topic on the same broker
5. There is no direct connection between a publisher and subscriber.
6. All clients can publish (broadcast) and subscribe (receive).
7. MQTT brokers do not normally store messages unless we have a Last Will Messages enabled.

MQTT Client-Broker Connections

MQTT Client-Broker Connections can be defined in terms of Quality of Service (QoS). MQTT provides three levels of QoS:

1. At most once (QoS 0) :

This provides a best-effort delivery mechanism where the sender neither expects an acknowledgment nor guarantee delivery of message. In this setup, the recipient doesn't confirm receipt of the message, and the sender doesn't store or re-transmit it. It is often referred to as "fire and forget" operates similarly to the underlying TCP protocol, where the message is sent without any follow-up or confirmation.

2. At least once (QoS 1) :

The emphasis is on guaranteeing that a message is delivered to the receiver at least once.

1. Initial Transmission: The sender sends a QoS 1 PUBLISH packet to the receiver.
2. Acknowledgment of Receipt: When a message is published, the sender retains a copy of the message until it receives a PUBACK packet from the receiver, which confirms successful receipt. If the sender does not receive the PUBACK packet within a reasonable time, it re-transmit the message to ensure it is delivered. Upon receiving the message, the receiver can process it immediately.

If the sender republishes the same message, it includes a duplicate (DUP) flag. This flag is for internal tracking and is not processed by the broker or client. Despite the DUP flag, the receiver will still send a PUBACK packet to confirm receipt, ensuring the sender is aware of successful delivery.

3. Exactly once (QoS 2) :

QoS 2 provides the highest level of service in MQTT by ensuring that each message is delivered exactly once to the intended recipients. It involves a four-step handshake between the sender and receiver:

1. Initial Transmission: The sender sends a QoS 2 PUBLISH packet to the receiver.
2. Acknowledgment of Receipt: Upon receiving the PUBLISH packet, the receiver processes the message and responds with a PUBREC packet to acknowledge receipt.
3. Release: The sender then sends a PUBREL packet, and the receiver, after discarding its stored states, replies with a PUBCOMP packet.
4. Completion: Once the sender receives the PUBCOMP packet, it can safely discard the original PUBLISH packet, and the packet identifier can be reused.

If the sender does not receive the PUBREC packet within a reasonable time, it will retransmit the PUBLISH packet with the duplicate (DUP) flag until acknowledgment is received. The receiver retains a reference to the packet identifier of the original PUBLISH packet until the PUBCOMP packet is sent, ensuring that the message is not processed more than once.

Client ID (Client Name)

Each client must have a unique client name or ID.

The MQTT broker uses this client name to manage subscriptions and other functions.

If you try to connect to an MQTT broker using a client name that is already in use, the existing client's connection will be dropped. Since most MQTT clients will attempt to reconnect after being disconnected, this can create a cycle of disconnections and reconnections.

The screenshot below illustrates what occurs when you attempt to connect a client with the same client ID as one that is already connected to the broker.

Last Will Messages (LWM)

The last will and testament message is used to notify subscribers of an unexpected shut down of the publisher.

The basic process is.

1. The publisher tells the broker to notify all subscribers?to a topic, using the last will message, in the event that the connection breaks
2. If the broker detects a connection break it sends the last will message to all subscribers of that topic.
3. If the client disconnects using the disconnect message then no last will message is sent.

Attached is the comprehensive article about Last Will Message. Feel free to read this amazing article from steves-internet-guide

Clean Sessions

By default, MQTT clients establish a clean session with the broker.

In a clean session, the broker does not retain any information about the client after it disconnects.

In contrast, a non-clean session allows the broker to remember client subscriptions and potentially store undelivered messages.

Whether or not messages are held depends on the Quality of Service (QoS) levels used when subscribing to and publishing to topics.

Attached is the comprehensive article about Clean Sessions. Feel free to read this amazing article from steves-internet-guide

Stay tuned for 2 more upcoming articles on MQTT protocols and forget not to subscribe to this newsletter.