MQTT (MQ Telemetry Transport)
A simple messaging communication protocol between muliple devices. Official Site here
MQTT is a messaging protocol for the Internet of Things (IoT). It is designed as a lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. MQTT today is used in a wide variety of industries, such as automotive, manufacturing, telecoms, oil and gas, etc.
The way MQTT works
Brokers, Publishing, Subscribing, Messages and Topics
Pub/Sub Architecture
Publishing
Small messages are sent or 'published' on the internet by one or more 'clients' via a 'broker' which listens on a server usually on port 1883.
This broker can be on your own server hardware such as a PC or Raspberry Pie or in the cloud as a 'Private' or 'Public' broker.The messages are distinguished from each other by the use of 'topics' in them. The job of an MQTT broker is to filter messages based on topic, and then distribute them to subscribers.
Topics
Examples of messages could be:
topic: sport/headlines/football payload: 17:00 West Brom Win 4-0
topic: myhome/groundfloor/livingroom/temperature payload: 22
topic: myhome/catToby/lat payload 54.037
topic: myhome/catToby/long payload -1.320
The topic is a tree type hierarchy of topics. It’s similar to a URL path but without the protocol and domain components.
ie sport/headlines is all the sports headlines but sport/headlines/football only refers to football headlines
In the last 2 examples the 'client' to the broker could be a tracking device on the cat's collar that 'publishes' location data periodicly to the broker.
Subscribing
Similar to the way 'youTube' and 'Twitter' and lots of other platforms work a client 'subscribes' to a topic .
The broker might be 'publishing' out messages on a sport topic such as
topic: sport/headlines/cricket payload: 16:00 Warwickshire Bears beat Worcester Warriors by 2 wickets
topic: sport/headlines/football payload: 16:10 Birmingham City Appoint Wayne Rooney as Manager
topic: sport/headlines/motorracing payload: 16:15 Verstappen wins Las Vegas Grand Prix
topic: sport/headlines/football payload: 17:00 West Brom Win 4-0
topic: sport/scores/football payload: 17:00 West Brom 4 Wolverhampton 0
topic: sport/scores/football payload: 17:05 Birmingham City 2 Aston Villa 0
If a client is subscribed to a 'topic' when the 'broker' sends a message out about that topic, they will receive it.
The client subscribing to the topic sport/headlines/football wiill only receive the football headlines:
16:10 Birmingham City Appoint Wayne Rooney as Manager &
17:00 West Brom Win 4-0
but subscribing to sport/theadlines will receive all the sport/headlines.
MQTT provides two types of wildcards to use with topic subscriptions:
- "+" (plus sign) is used to match a single level in the hierarchy. For example, a subscription to
"sport/+/football"would match “sport/headlines/football” and “sport/scores/football”, but not “sport/headlines/cricket”. - "#" (hash sign) is used to match multiple levels in the hierarchy. For example, a subscription to “sport/headlines/#” would match “sport/headlines/cricket”, “sport/headlines/football”, and “sport/headlines/motorracing”.
Why MQTT is good for IOT.
Because IOT sensors are power and data dependant the lightweight MQTT is ideal. It is not necessary to listen all the time on a topic. ie the cat's collar only has to send out its location if it strays past the garden fence and you only need to subscribe to your car's location if someone has stolen it. Because MQTT clients don’t have addresses like email addresses, phone numbers etc. you don’t need to assign addresses to clients like you do with most messaging systems.
What is an MQTT PUBLISH Message?
The client publishes an MQTT-Packet which contains the attributes 'topicName' and 'payload'.
topicName
The topic name is a fundamental concept. It structures this name hierarchically using forward slashes as delimiters and creates a simple string. It’s similar to a URL path but without the protocol and domain components. MQTT topics are used to label messages and provide a way for clients to subscribe to specific messages.
payload
The 'payload' of each message includes the data to transmit in byte format, and the sending client can choose to send any type of data, including text, numbers, images, binary data, and even full-fledged XML or JSON.
As well as the topicName and payload attributes the MQTT-Packet contains the following other attributes:
packetId
qos
retainFlag
dupFlag
packetId
The Packet Identifier (PacketId) is an essential attribute in MQTT. It is used to identify the specific message and to ensure that messages are delivered in the order they were sent,
qos
QoS is indicated by a number that ranges from 0 to 2. Each level provides a different level of reliability and assurance for message delivery.
- QoS 0 (at most once): This level provides no guarantee that a message will be delivered. The message is sent once, and if it is lost or not received by the recipient, it will not be resent.
- QoS 1 (at least once): This level ensures that a message is delivered at least once, but it may be delivered multiple times in the case of network issues or failures.
- QoS 2 (exactly once): This level provides the highest level of assurance for message delivery. The message is guaranteed to be delivered exactly once, but this level requires more communication between the sender and receiver, which can increase latency and network traffic.
retainFlag
The Retained Flag is an important feature that determines whether the broker saves a message as the last known good value for a specified topic. When the retained flag is set to true, the broker will save the most recent message that matches the specified topic, regardless of whether there are any subscribed clients.
When a new client subscribes to a topic with a retained message, the broker sends the last retained message (on that topic) to the client. This allows clients to receive the most recent and relevant information even if they have not subscribed to that topic before.
dupFlag
The MQTT DUP Flag indicates that a message is a duplicate and has been resent because the intended recipient (client or broker) did not acknowledge the original message. It is only relevant for messages with QoS greater than 0. When a client or broker receives a message with the DUP flag set, it should ignore the message if it has already received a message with the same message ID. The client or broker should process the message normally if they have not previously received it.