SHOP eStore CONTACT US TECHNICAL SUPPORT CUSTOM ENGINEERING

The Basics of MQTT

by
January 19, 2015
in IoT Whitepapers
No Comments

Message Queue Telemetry Transport (MQTT), is an open, lightweight publish/subscribe messaging protocol that was developed specifically for small, constrained devices over wireless networks. MQTT brings a simplicity and scalability not found in traditional Internet or industrial protocols. The speed and efficiency of the protocol make it a popular choice for applications ranging from measurement and detection to supervisory control.

The following information is designed to provide an introduction to the unique features and functionality of the MQTT protocol.

MQTT   MQTT

MQTT Publish and Subscribe

Unlike traditional request-reponse type protocols such as http or Modbus, MQTT is based on the simple principle of publishing messages and subscribing to topics. Multiple clients connect to a broker by subscribing and/or publishing to topics and accessing the information.

The broker and MQTT act as a common interface for everything else to connect to. This means that you if you have clients that post subscribed messages or text files to a database; it then becomes easy to add new things, such as sensors or data.

Broker and connected Clients
a. Broker receives subscription from clients on topics
b. Broker receives messages and forward them
c. Clients subscribe/publishes on topics

MQTT Topics and Subscriptions

Messages in MQTT are published on topics. Topics are treated as a hierarchy, using a slash (/) as a separator. This provides a logical structure of common themes to be created, much like any file system you have used. So, for example, multiple computers could publish their hard drive temperature information on the following single topic, by inserting their unique computer and hard drive name: sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME

Multiple clients could then receive messages by creating a subscription to this specific topic. However, there are two wildcards available + or #. The + character can be used as a wildcard for a single level of hierarchy. In the topic above it could be used as follows to get information on all computers and hard drives:

sensors/+/temperature/+

Another example, for a topic of “a/b/c/d”, the following example subscriptions will match:

a/b/c/d
+/b/c/d
a/+/c/d
a/+/+/d
+/+/+/+

However, these following subscriptions would not match:

a/b/c
b/+/c/d
+/+/+

The # character can be used as a wildcard for all remaining levels of hierarchy, which means that it must be the final character in a subscription in order to match. With a topic of “a/b/c/d”, the following example subscriptions will match:

a/b/c/d
#
a/#
a/b/#
a/b/c/#
+/b/c/#

Quality of Service

MQTT has defined three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will work or attempt to ensure that a message is received. It’s much like sending an email to someone using normal settings versus sending it out using the read receipt feature to confirm that the email was received or opened. Messages can be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level, which means that the client chooses the maximum QoS level they will receive. For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0. If a second client is also subscribed to the same topic, but with QoS 2, then it will receive the same message but with QoS 2.

Another example could be if a client is subscribed with QoS 2 and a message is published on QoS 0, the client will receive it on QoS 0. Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

  • 0: The broker/client will deliver the message once, with no confirmation (fire and forget).
  • 1: The broker/client will deliver the message at least once, with confirmation required.
  • 2: The broker/client will deliver the message exactly once by using a four-step handshake.

Other MQTT Key Features

  • Keep-Alive message (PINGREQ, PINGRESP)
  • A broker can detect client disconnection even if it doesn’t send an explicit DISCONNECT message
  • “Last Will and Testament” message: specified in CONNECT message with topic, QoS and retain. On unexpected client disconnection, it the “Last Will and Testament” message is sent to to subscribed clients
  • “Retain” message: a PUBLISH message on a topic is kept on the broker which allows a new connected subscriber on the same topic to receive this message (last known good message)
  • “Durable” subscription: on client disconnection, all subscriptions are kept on the broker and recovered on client reconnection

For more complete information on MQTT, see http://mqtt.org/


Recommended Posts