PART 3. CONNECTING DEVICES TO THE EVERYWARE CLOUD
Introducing MQTT

 

Introduction to MQTT Protocol

·         Overview

·         Concepts

·         Protocol Basics

 

 

 

Introduction to MQTT Protocol

 

 

Overview

Everyware™ Cloud uses MQ Telemetry Transport (MQTT) V 3.1 as the default transport protocol for device connectivity.  MQTT is a lightweight broker-based publish/subscribe messaging protocol designed to be open, simple, lightweight, and easy to implement.

 

Features of the protocol include:

 

·         Publish/subscribe paradigm allows separation of data producers and data consumers and creation of one-to-many message distribution

·         Data agnostic enables transmission of any type or content of data, in any user-defined form

·         Open standard protocol, based on TCP/IP

·         Quality of Service (QoS) levels determine how messages will be delivered and are used to assure of delivery of messages

·         Small transport overhead provides efficiency of communication

·         Built-in mechanism for connection monitoring

 

 

 

Concepts

MQTT is based upon two main concepts:

 

·         Topic is the destination to which data is published. It is hierarchical in nature.  The topic namespace can be designed to capture, in a tree-like structure, the target destination of the data being published or subscribed.

·         Payload consists of the value/s of the variable/s that has to be transmitted.

 

As a simple example of an environment monitoring application, a Topic can be represented as follows:

 

            acme/123456/continent/country/region/city/temperature

 

In the Everyware Cloud topic naming convention, the first two nodes of the topic namespace represent the Everyware Cloud account name (acme) and the identifier of the gateway that published the data (123456).  The following nodes of the topic namespace are referred to as the “semantic namespace”.  This is user-defined for the application, in this case a geographic-based namespace (continent/country/region/city).  The semantic topic is a user-defined hierarchy of sub-topics, and should be carefully designed with the goal of allowing appropriate sets of data to be published or subscribed according to the needs of the application.

 

In MQTT, the payload is open and can be simply represented by the numeric value of the variable:

 

            24.56

 

The Everyware Cloud uses an additional open payload structure that is optimized for telemetry-type applications, using “Metrics” to define the names and data types of published values.  This structure allows third party devices that adopt MQTT to be connected to the platform and to use the Metrics for rules-based statistical analysis.  See Communication Data Model for more information on the Everyware Cloud data structure.

 

 

Protocol Basics

Following are the main elements of the MQTT protocol:

 

·         CONNECT to the broker – the CONNECT message contains a header identifying the client ID, and other properties of the connection, such as whether to use a Keep Alive timer, and whether to use a Last Will and Testament.

·         DISCONNECT from the broker – normally a client should issue a DISCONNECT message to the broker to close the session

·         PUBLISH messages – data is published to the broker using the topic namespace.

·         SUBSCRIBE – a device or system can subscribe to one or more topics, including wildcards, in order to receive messages published on those topics.

·         QOS – all messages are published with a Quality of Service value:

o   QOS=0: "At most once", where messages are delivered according to the best efforts of the underlying TCP/IP network.  Message loss or duplication can occur.  This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.

o   QOS=1: "At least once", where messages are assured to arrive but duplicates may occur.

o   QOS=2: "Exactly once", where message are assured to arrive exactly once.  This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.

·         Keep Alive – the client can request a certain Keep Alive interval.  The broker issues a ping request (PINGREQ), and the client responds (PINGRESP).

·         Last Will and Testament – the CONNECT message can include an optional LWT.  This is a message that gets published to other subscribers when a client unexpectedly disconnects without sending a DISCONNECT message.

·         Retain – all messages may be published with an optional Retain flag, indicating that the server should retain the last published message (one retained message per topic).  This allows another client to connect and subscribe later and still receive last known data on certain topics.

 

 

For more information on the MQTT protocol, visit http://mqtt.org/, or see Appendix B in the IBM Redbook.

 

Within this basic MQTT structure, the Everyware Cloud uses some specialized payload formats and topic names.  See Communication Data Model for more details on the Everyware Cloud data structure.