The Internet of Things (IoT), the collection of millions of physical devices connected to a network to merge the digital with the physical, is estimated to have billions of devices in the next few years. Devices range from household appliances, low cost devices (often nearly at disposable pricing) all the way up to critical national infrastructure. This article will explore one of the key unifying protocols which enables the likes of the Amazon Dash Button and even ferries to share sensor information with the world!
The original vision of the world of IoT was that all devices were addressable on the internet. In practice, implementer’s found that it was simply impractical in many situations to have devices talking to each other directly by initiating peer-to-peer communication. Without a server or service, generally known as a broker, every client would need to handle a number of common but often complex problems such as:
authentication and authorisation across multiple protocols retry attempts and subsequent handling of unreachable devices complex encryption methods which can be hard to optimise for efficiency
Introducing an Intermediary
The use of a broker provides an intermediary and a reliable address on the internet for devices. Brokers come in all forms, from cloud-based solutions powering the Amazon AWS IoT platform to software that can run embedded on a gateway device.
But how do the broker and the device communicate with each other?
This is where Message Queue Telemetry Transport (MQTT) steps in. It is a very lightweight messaging protocol which meets the needs of most IoT related communications. The protocol is mature, with the first use over a decade ago. At the end of 2014 MQTT, in a major milestone, received ratification by OASIS (an open standards consortium). Just like in HTTP, the protocol of the world wide web, a number of methods are defined: connect, disconnect, subscribe, unsubscribe and publish.
The Anatomy of a Topic
Messages and subscriptions in MQTT are based on ‘topics’. Topics can be viewed as a close relation to the URL we see in the location bar in our browsers. In the same way it is best practice for the structure of URLs to convey meaning about the resource retrieved; topics should also attempt to follow a similar pattern.
An example topic name which illustrates a topic structure:
Notice that the the topic gradually becomes more specific with a ‘/’ used to delimit each logical component.
One key difference between HTTP and MQTT is whilst publishing is an absolute topic (as shown above), subscriptions can use wildcards. Two types of wildcards are supported. The ‘#’ which matches any topic tree and the ‘+’ which matches only one level of the topic. Wildcards allows subscribers, subject to a sufficient topic structure, to subscribe to many devices with just one request.
For example, in the previous demonstration, a subscriber to ‘/world/#/temperature/’ will receive messages from any sensor publishing temperature information. This makes it easy to integrate logic with IoT devices, for example to automatically create a ticket for an engineer to investigate when the temperature of any customer’s sensors exceeded a predefined temperature. Whilst this is a simple example, the principles can apply in many situations.
In summary, MQTT provides the foundations needed for many IoT services and devices. It is as important to the world of the Internet of Things as HTTP is to the World Wide Web. For developers, it makes it easier to rationalise about fleets of devices on an unprecedented scale when used correctly. At Fast Web Media we are using MQTT to deliver novel real-time applications for clients.
What advantages have you seen from using MQTT to deliver applications? Tweet us your thoughts @FastWebMedia