Monday, March 20, 2017

MQTT - First Steps

The goals for this tutorial are as follows:

  1. Discuss the history and purpose of MQTT
  2. Introduce the concepts of MQTT topics and quality of service (QoS)
  3. Install MQTT broker and client software on a Raspberry Pi
  4. Send some messages!
  5. Shutdown the MQTT broker


History and Purpose of MQTT
Andy Stanford-Clark (of IBM) and Arlen Nipper (of Arcom, now Cirrus Link) in 1999 were working on a SCADA (supervisory control and data acquisition) system for oil and gas pipelines. This system involved large numbers of low power sensors remotely distributed, and they needed to gather information from all those sensors. Since network bandwidth was at a premium, the sensors had to be very bandwidth efficient, which means the messages they sent had to be very short. Also, the network and sensors could be unreliable, so their SCADA system had to recognize and respond to those types of faults.

MQTT - which originally was an acronym for Message Queue Telemetry Transport - was the protocol they developed in solution to their problem.

Stanford-Clark and Nipper's original use-case closely parallels what is now called IoT: they had to gather data from a large number of sensors, sensors that are underpowered both in terms of power supply and computational ability, sensors that send data across what could be an unreliable network. This is one of the reasons MQTT has been adopted as a messaging protocol in IoT.

MQTT is a publish/subscribe architecture, and can be viewed as follows:

This system consists of two types of items: brokers and clients. The broker's job is to receive and redirect messages that are sent by the clients. Clients send messages to the broker as well as listen for messages from other clients routed through the broker. An example of a simple client is the ESP8266 temperature sensor we built previously! An example of a not-so-simple client is an application that listens for messages from the broker, and save those messages to a database.


MQTT Topics
The potentially large number of clients and the number of messages they can send requires that there be some way of organizing these messages. For this purpose, MQTT uses "topics".

Here's an example of a topic: suppose that there is a temperature sensor located in your living room. This sensor can send temperature readings every 60 seconds to a MQTT topic, and a good name for that topic would be "home/living-room/temperature". An application that saves those readings to a database would listen to the same topic.

There are several activities that clients must be able to do in an MQTT system:

  • Clients connect to brokers over TCP/IP
  • Clients disconnect from brokers
  • Clients subscribe to a topic, meaning they receive messages on that topic
  • Clients unsubscribe from a topic
  • Clients publish messages to a topic

Several clients can subscribe to the same topic, so that when a message is published to that topic, that message is broadcast by the broker to all the subscribers.


Quality of Service (QoS)
As mentioned above, MQTT is designed for messaging among low-powered devices in less-than-perfect networks. So, when a client publishes a message, it may not reach the broker, and the message may not be received by the subscribers. There are three types of guarantees that can be made about reliability. These are called levels of Quality of Service (QoS):

QoS 0
the message will be delivered at most once (either by client or by broker), but with no acknowledgement or confirmation. This is "fire and forget". The message is not retained, and may indeed be lost if the client disconnect or the broker fails.
QoS 1
the message will be delivered at least once to the receiver, but it could be delivered more than once. A confirmation message must be sent. The message must be stored locally at the sender until confirmation of receipt is received.
QoS 2
each message will be delivered exactly once, and all this is confirmed using a four-step process. The message must be stored locally at both the sender and the receiver until the confirmation process is complete.

Thus, higher levels of QoS are more reliable, but this reliability comes at the cost of higher bandwidth, latency, and additional local storage.


Installing MQTT on a RaspPi
There are several different MQTT brokers available. For our projects, we will be using the Mosquitto MQTT broker - notice the non-standard spelling here. We will install Mosquitto on a Raspberry Pi. The RasPi is not a serious choice for commercial production work, but will be sufficient for home and experimental use.

First, we make sure that Raspian is up to date:

sudo apt-get update
sudo apt-get dist-upgrade

Now we will install the Mosquitto MQTT broker, a MQTT client, and the Python bindings for Mosquitto. We will not be using Python in this tutorial.

sudo apt-get install mosquitto mosquitto-clients python-mosquitto


Sending Messages
MQTT is "message agnostic" - it doesn't care about how the messages are formatted. The messages can be formatted as JSON or XML, or not formatted in any way!

To start the broker running in the foreground (meaning in the current Terminal window), we will use the following command:

mosquitto -v
The '-v' flag is for verbose mode - all connection and messaging events will be shown!

Now that Mosquitto is running, we open three more Terminal windows.

In the first and second new windows, we issue the following command:

mosquitto_sub -d -h localhost -t home/living-room/temperature
This command starts a client and subscribes it to the topic home/living-room/temperature. All that this client will do is listen for messages sent to that topic and display them in the terminal window.
  • -d means that debug messages should be shown
  • -h is the host (which will be localhost)
  • -t is the topic this client will be subscribing to (in this case home/living-room/temperature)

In the third new window, we publish a message as follows:

mosquitto_pub -d -h localhost -t home/living-room/temperature -m 'Hello, MQTT!'

And the message 'Hello, MQTT!' will be displayed in the other two windows. Also, in the window we used to start MQTT there will be a description of what just happened.

Congrats, you just sent your first message using MQTT!

To get help about the Mosquitto broker or the subscriber or publisher clients, use the following commands:

mosquitto -h
mosquitto_sub --help
mosquitto_pub --help


Stopping MQTT
To stop the broker or the subscriber when they are running in foreground mode, just press Control-C.

To stop the broker when it is running in background mode, try the following command:
sudo /etc/init.d/mosquitto stop
If that doesn't work, one can get the PID of Mosquitto:
ps aux | grep mosquitto
and then kill the associated PID.

No comments:

Post a Comment