Message Queuing Telemetry Transport or MQTT is an emerging protocol thats designed to be used for machine-to-machine communication by Internet of Things devices. In recent times, it has gained more and more traction as a de facto standard by which smart devices communicate with each other. In this post we’ll explore how Totem is levering the strong support of MQTT basis in their design.
To better understand how Totem devices interface with one another, it’s good to start by examining MQTT. While the standard is open, and you can always review the latest specifications HERE, we’ll go through the basics here.
MQTT is a typical start type network with a centralised control point. There are two types of roles in MQTT. First one is the role of client – it is able to generate and send messages with data, as well as make requests to receive them. The other one is broker – it is responsible for collecting sent messages, and then publish them to other clients, who have requested (and were allowed by the broker) to receive messages. Only one broker is allowed to be in a single MQTT network.
MQTT by design have 14 different types of messages. While only one of them are used for actual data transmission, we must use several others until communications can be established.
- CONNECT – a client may send a request to connect to the broker. Inside this message you may place information about yourself, as well as authentication data such as login name and password, as well as additional protocol information.
- CONNACK – broker must respond to all CONNECT messages with this message. This message has a positive or negative response indicating whether the request to connect was fulfilled or not. Any message is ignored by the broker until the connection has been opened.
- PUBLISH – this is the actual data transmitting packet. This one contains payload (data) that is being sent, as well as its topic, which will be discussed later.
- SUBSCRIBE – any connected client can request broker to receive messages by the topic indicated in the packet.
- SUBACK – similarly to CONACK packet, SUBACK is sent by the broker to the client attempting to subscribe to a topic. Broker may refuse to subscribe client to a topic based on its configuration.
- DISCONNECT – a client can disconnect from the network by sending this messages. Broker has the ability to disconnect any client by sending the same message as well.
These messages form the minimal basis of topics that must be used for successful communication between client and broker.
Data messages in the MQTT network are grouped by a special name called topic. If the client wishes to receive messages to a topic, it must first subscribe to it. You can image messages as different types of newspapers or journals. If you wish to receive daily news from a certain magazine, you make a subscription to it. Afterwards, whenever a new print is released, you will receive your own copy of the magazine in your hands. MQTT builds even further upon the concept by having structured topics: similarly to the folder structure in your computer, you can have topics that have subtopics inside of them. If building further upon the analogy, it allows you to only subscribe not only to the whole newspaper, but also only to certain sections of it.
To take a real-world example, sensor might publish a message with a topic such as “/house/sensors/livingroom/temperature“. Acting devices, such as a central heating unit might subscribe to temperature messages, and act upon certain rules and turn the heat on.
For certain types of data it is critical to know if the sent message reached the intended destination or not. MQTT specifies three different types of reliability:
At most once – message is sent once and only once, neither the client nor broker takes any additional steps to ensure successful message delivery.
At least once – clients retransmits data until acknowledgment is received.
Exactly once – this case involves a two-way handshake to ensure a successful message has been transmitted successfully.
As each higher reliability involves additional transmissions, considerations must be taken before the quality of service is increased.
MQTT by design also allows to use wildcard characters in the subscription request. That way you could subscribe to a range of topics without knowing exact topic structure. Supported wildcard symbols are plus sign “+”, substituting a single level or a hashtag “#”, substituting any number of character in the topic. As in aforementioned example, if you have a TotemBus system of temperature sensors and want to subscribe to all of them, you could approach that either by subscribing to “/house/sensors/livingroom/temperature”, “/house/sensors/bathroom/temperature”, “/house/sensors/kitchen/temperature”. But the same could be achieved by issuing a subscribe command to “/house/sensors/*/temperature”.
How we use MQTT in Totem
As was mentioned before, Totem Bus consists of individual boards with different capabilities. Each of the capability has a number of methods by which it is governed (or produces data). You might have a board with three DC motor channels, an array of sensors on another, or even a higher level interface in it. This object based approach fits MQTT seamlessly, as each board has its own unique root topic, inside of which you have capability. Lastly, there are separate topic for actual control methods, so for example a DC motor control might have a setPower or setPosition control topics.
Having this kind of system allows us to have a network with any type of functions boards on it. Using wildcards messages might be broadcasted to a number of different boards, having simultaneous, synchronised control. Additionally, the system can be expanded by new nodes without any kind of interference to the existing bus.
By using MQTT, TotemBus automatically became compatible with a wide number of other clients available on different kind of platforms – cloud platforms, PCs, smartphones and smart devices. This allows quick vertical integration of either new or existing systems into Totem.
This was a brief introduction of the MQTT protocol and what uses it found in the TotemBus. In the next post we’ll try to build our first robot platform by using Totem Android smartphone app. Stay tuned!