In the last instalment I took a look at the classic TCP protocol and how it transfers IP packets between sockets (network subscribers with an IP address and port number) over an IP network. TCP employs mechanisms to ensure the data arrives securely. So many programming languages include built-in socket programming features that it is relatively easy to implement your own, simple application protocol to perform some control tasks by using control bytes such as ‘ON’, ‘RED’, or ‘3’ as the TCP/IP payload.

In a typical IoT application there will be a number of sensors measuring environmental variables and providing inputs from home automation devices for many subscribers. Some nodes produce information and some nodes will consume data for further processing or for display purposes. It is also important to recognise also that not all the nodes are continuously online. Fortunately there is an efficient protocol already available which runs on top of the TCP/IP protocol and is ideally suited to this type of use. It is a messaging protocol developed at the turn of the century called MQTT. Instead of a direct connection between the message generators and message consumers it employs a message-broker, distributing messages to interested clients based on the message topic.
Subscribe
Tag alert: Subscribe to the tag Journey into the Cloud - Article series and you will receive an e-mail as soon as a new item about it is published on our website!

Message generators (e.g. sensor nodes) and message clients (e.g. smartphone apps) all subscribe to the broker. The message broker also takes care of the IP addresses so that the developer/user no longer needs to concern themselves with long cryptic number sequences. Message generators, otherwise known as ‘publishing clients’, identify to the broker the theme or ‘topic’ of the published message. The topics use easy to remember character strings such as:

Building / Office / Temperature
Building / Kitchen / Temperature

A smartphone app can subscribe to specific topics to receive relevant messages, the use of wildcards are also allowed:

Building / + / Temperature

MQTT can do more: It offers a ‘Quality of Service’ (QoS) level for messages (in addition to the secure data exchange built into TCP). Level 0 sends the message once only (you may not get it) Level 1 ensures the message is received at least once (multiple copies of the messages may be received) or level 2 ensures that the message is received exactly once. Also useful is the Last Will and Testament (LWT) feature; each client can define a message per topic, to be sent out by the message broker when the client goes offline and is no longer participating in the topic. The broker can also store ‘retained messages’ i.e. the last message (plus the QoS) for that topic. When a client subscribes to a topic matching the topic of the retained message, it receives the message. This feature is useful when working with sensors that only send information sporadically to ensure that the last measured value is always available.

It’s worthwhile getting acquainted with this protocol, the code is open source and is already in use by many well-known players in the IoT field. We will delve a bit deeper in the next instalment!
Official MQTT pages: http://mqtt.org/
Readers tip: www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt

Read more