Device to Cloud: MQTT and the power of topic notation

Tiziano Modotti, Eurotech Group

September 27, 2012

Tiziano Modotti, Eurotech GroupSeptember 27, 2012

Here's a quick primer on MQTT, an open transport layer that may simplify how an embedded device talks to the cloud.

The Message Queuing Telemetry Transport (MQTT) protocol was developed by Eurotech and IBM in 2001 to collect data from multiple devices while using limited bandwidth and providing the information to several subscribers. An MQTT open transport layer is relatively simple to set up and provides an ideal network interconnect protocol for device-to-cloud solutions that is scalable, reliable, and flexible.

MQTT enables an embedded device to publish and receive messages from the cloud with a few lines of code. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. 

Figure 1: The publish/subscribe communication model

Click on image to enlarge.

With a single publisher and many subscribers, you can send information from a single point to many other devices or listeners interested in receiving the information. Deployment becomes very straightforward with MQTT--data producers publish data while data consumers consume data (see Figure 1). The workload shifts from the tedious process of implementing a proprietary protocol to defining and using the data that is being produced by any device that connects to the cloud.

The MQTT protocol uses a hierarchical subject naming convention. This topic-based publish and subscribe mechanism ensures fast, reliable data delivery.

The MQTT common message interface uses topic names, and it is important to understand the structure of topic name spaces (or information spaces). Although the topic name space is defined at the application level, it is useful to have an understanding of the notions of hierarchy and wildcards.

The topic of a message can contain any of the characters found in the Unicode character set. For example, "Busline," "ICE CREAM," and "The Top 50 Cities" are all valid topics. Figure 2 shows a sample hierarchical namespace.

Figure 2: A sample hierarchical namespace for a hypothetical bus transportation application.

Click on image to enlarge.

When building an application, the topic name design plays a crucial role in the application's communication possibilities. This design should account for the following principles of topic name syntax and semantics:
  • Topic names are case sensitive. For example, "BUSLINE" and "Busline" are recognized as two different topic names.
  • Topic names can include the space character. One example might be "accounts payable." Spaces are treated just like any other character in the topic name.
  • Though not recommended, a topic level may be the empty string. For example, "a//c" is a three level topic name whose middle level is empty.
  • For portability reasons, it is recommended that topic names do not include the null character (Unicode \x0000).
The following conditions apply to the construction and content of a topic tree:

1. There is no effective limit to length of the overall topic name string.
2. There is no limit to the height or the levels of depth (number of slash-separated strings) in a topic tree.
3. There is no limit to the length of any particular level name in the tree.
4. There may be any number of "root" nodes (that is, any number of topic trees).

Figure 3: Examples for subscribing to different topics in a hierarchical name space.

Click on image to enlarge.

A well-designed application will structure its topics into subject trees to simplify gathering data in the cloud. This structure will allow applications to subscribe to sub-trees by placing the multi-level wildcard (#) as the last level. For example, if the topic were "Busline/City_F/#” then matching topics would include all of the sensor data for all buses in City_F.

The use of multiple wildcards is also valid. A topic expression can include several plus signs and hashes.. Examples of valid topics include using plus signs to specify a number of levels after a certain node such as "Busline/+/+.TEMP", which would include all temperature sensor data in all busses in all cities.

Have you used MQTT? Any tips for naming? Has it made connecting to the cloud simpler?

Tiziano Modotti is a product marketing manager with Eurotech Group.

Loading comments...

Parts Search