Guide to MQTT
With the rise of IoT devices and Smart Home systems, there are many things to consider as you pick your devices, brands, and protocols. We have recently started to offer Shelly line products - known for providing powerful and flexible solutions for smart home automation, integration, and power monitoring.
Shelly is a full line of IoT devices based on IP, WiFi and Bluetooth technologies. It works with a variety of systems, including HomeKit, Smart Assistant, SmartThings, Home Assistant, HomeSeer, Homey, Hubitat, OpenHAB, REST integration and more. It also supports advanced protocols like MQTT.
With MQTT support, the customization options are near endless. You can create perfect systems with efficiency. But why choose MQTT? What is this advanced protocol, and is it worth it? We hope this resource helps fill in those gaps and answer any questions you may have about MQTT.
What is MQTT?
Simply put, MQTT is a lightweight messaging protocol designed to allow devices to communicate reliably using minimal bandwidth, even over unreliable networks. Often used in manufacturing and logistics applications, MQTT also lends itself to IoT devices. Internet of Things (IoT) devices supporting MQTT can transmit and receive data over a resource-limited bandwidth. Some examples of IoT devices are Shelly smart sensors, Google Home, some smart locks etc. IoT devices use MQTT for efficient and secure data transmission. MQTT supports messaging between devices, devices to cloud, and vice versa.
Quick History of MQTT
MQTT was created for a specific use before being applied to IoT and smart technology. It was invented in 1999 for use in the oil and gas industry. Engineers needed a protocol that required minimal bandwidth and less energy to monitor oil pipelines via satellite.
The MQTT name comes from Message Queuing Telemetry Transport due to the IBM MQ Series first used with the protocol.
The protocol was released as a free and open protocol in 2010, and in 2013, it was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) for maintenance. As of 2019, MQTT is on version 5.
Why MQTT?
MQTT is an effective protocol for IoT networks. Here's a breakdown of some of the benefits:
Lightweight & Efficient
MQTT does not require a lot of resources to run effectively. It is optimized to reduce network bandwidth usage - Messages can be as small as two data bytes, meaning the load is reduced. MQTT also works with small microcontrollers for system flexibility where needed.
Reliable
Many modern devices rely on cellular networks that can have unreliable connections with low bandwidth and high latency. MQTT has been fine-tuned to reduce those issues and increase the speed at which a device can connect to the cloud.
Secure
With MQTT, it is easy to encrypt messages and allows users to authenticate on devices using OAuth, TLS1.3, Customer Managed Certificates, and more.
Well-supported
Languages used for MQTT, such as Python, have a lot of readily available support, making developments quick to implement with minimal coding.
Scalable
MQTT requires minimum code and consumes little power. It has built-in features to support communication and connect thousands of IoT devices.
How does MQTT Work?
The MQTT protocol uses a publish/subscribe model to communicate between devices.
A publish/subscribe pattern is used to separate the message sender, known as a publisher, from the message receiver, known as a subscriber. A third aspect called a broker, is added to handle the communication between the publisher and subscriber. The broker filters the incoming messages from the publisher and sends them to the correct subscribers.
MQTT Components
There are a few different parts to MQTT systems. Understanding the parts and what they do to make the protocol work is helpful in understanding the flow of information in MQTT systems. Here are some definitions and additional info:
Publisher/Subscribe Model Terms
MQTT Client - Any device that communicates over a network using MQTT
Publisher - A client that sends a message
Subscriber - A client that receives a message
Topic - A keyword the broker uses to filter messages for clients
Publishing - a topic message sent out by a client in the form of a data byte format
Subscribing - a message from a client asking the broker to receive messages on a specific topic
MQTT Brokers
A Broker is a backend system that coordinates the messages between clients. It receives and filters messages while identifying which clients are subscribed to the topic of the messages and sends the message out. Its role also involves authorizing and authenticating MQTT devices, passing messages onto other systems, and handling missed messages and client sessions.
Since its main job is filtering incoming messages from publishers and sending them to the correct subscribers, the broker decouples or separates the subscribers and publishers in a few different ways depending on the system orientation:
Space decoupling - where a publisher and subscriber are not aware of each other's location in the network and do not share info like IP addresses or port numbers
Time decoupling - where the publisher and subscriber don't run or have a network connection at the same time
Synchronization decoupling - where both publishers and subscribers can send and receive messages without interrupting each other. Where the subscriber does not have to wait for a publisher to send a message
MQTT Connections
Clients and brokers communicate using MQTT connection. Clients initiate communication by sending out a "connect" message to the broker. The broker confirms the connection and responds with its own version of a connection message, "connack." The individual clients do not communicate with each other, just with the broker that filters the messages. It's important to note that both the clients and the broker require a TCP or IP stack to communicate.
How Does MQTT Operate?
With the terms, definitions, and functionality clarified, how exactly do all of these pieces work together to form a protocol? How do MQTT systems work? A functional system would operate as such:
An MQTT client will establish a connection with an MQTT broker. Once they are connected, the client will publish a message or subscribe to a particular message it is interested in (or both). The broker will receive the message, filter it, and forward it to an interested subscriber.
The broker will use an MQTT topic to filter a message from a client. Topics are sorted hierarchically like a file or folder directory - ourhome/firstfloor/familyroom/light.
The clients publish messages that have the topic and related data in a byte format. For example, a lamp may publish an on message for the topic of office/light.
Clients can send a subscribe message to the broker, asking to receive specific messages on a topic. The message has unique identifiers and contains a list of subscriptions. For example, a smart home app on a mobile device may want to display the number of controllable lights available in the home. It will ask to subscribe to the topic of light and will increase the counter for messages.
The below image shows how the MQTT system will work for a temperature sensor:
MQTT Security
MQTT communication uses SSL protocol to protect data from IoT devices. Identity authentication and authorization can be applied between system clients and the broker using SSL certificates or passwords. The broker can authenticate via passwords and unique client identifiers for each MQTT client. The client can authenticate the server with certificates or DNS lookups. Other encryption protocols can also be set up with MQTT as desired.
MQTT and REST
MQTT is not considered RESTful. Rest uses a request/response pattern approach to network communication between message senders and receivers, whereas MQTT uses a publish/subscribe model and requires TCP/IP connection to transmit.
