An Introduction to IoT & MQTT
This article introduces the concept of the Internet of Things (IoT) and the popular, lightweight Message Queuing Telemetry Transport (MQTT) protocol for moving data from IoT devices into processing frameworks. These topics provide background for my subsequent article, which shows how IRI software could process that data on the edge with the CoSort SortCL program, or in a hub with the Voracity platform, improving both price-performance and time-to-action.
IoT Basics
IoT is a technical framework for related, network-connected devices, data objects, and brokers, along with programmed software and hardware platforms, that use unique identifiers to transfer and analyze data, without human interaction. IoT platforms automatically capture and process data so that conditions and events can be detected, recorded, monitored and analyzed, and ultimately, acted upon in one or more useful ways.
The concept was introduced way back in 1999, when MIT’s Auto-ID Center’s co-founder, Kevin Ashton, explained its rationale and potential benefits this way:
“Today computers — and, therefore, the internet — are almost wholly dependent on human beings for information. Nearly all of the data … available on the internet were first captured and created by typing, pressing a record button, taking a digital picture or scanning a barcode. The problem is, people have limited time, attention and accuracy — which means they are not very good at capturing data about things in the real world. If we had computers that knew everything there was to know about things — using data they gathered without any help from us — we would be able to track and count everything and greatly reduce waste, loss and cost. We would know when things needed replacing, repairing or recalling and whether they were fresh or past their best.”
Practical applications of IoT technologies and its data uses abound in many industries already, including precision agriculture, building management, healthcare, energy, and transportation. Here is a graphical representation of IoT architecture, from end-to-end:
I’ll describe each element, starting at the bottom:
Physical Devices
This first layer includes the actual devices that are connected physically to an edge node (computer). These can be climate or motion sensors, parking or utility meters, pacemakers and other medical monitors, cameras and alarms, or even network detectors that sniff packets.
Connectivity
This layer involves the communication protocols and network infrastructures, like WiFi, bluetooth, and ethernet, that connect and move data between devices, networks, and IoT platforms, as well as between networks themselves.
Edge Computing
This term refers to the relocation of computing applications, data, and services, from centralized nodes to the “logical extremes of a network …” or the edge nodes to which devices connect. Computing on the edge enables filtering and aggregation, and even analytics, on a more limited set of data closer to its source. That frees up network bandwidth and hub overhead. My POC demonstrates how an IRI CoSort SortCL program can rapidly process data on the edge.
Data Accumulation
IoT data move through the network at a rate and format determined by the devices generating it, and are converted in this phase from data in motion to data in rest. Decisions here also determine what level of data is sent where, how it persists, where it will be stored, and how it will be organized, recomputed, or recombined with other data.
Data Abstraction
This layer address the storage of data in ways that support simpler, performance-enhanced (analytic) apps; i.e., reconciling multiple data formats from different sources, applying consistent semantics to data across sources, and confirming that data is complete to the application. In the IRI Voracity platform (IoT hub) environment, this involves data connections, discovery, integration, and metadata management from its Eclipse GUI.
Application
Software at this level interacts with the abstracted data and/or data at rest, rather than data moving through the network (which would be slower to analyze). This is where, for example, specific detection or prediction algorithms can spot problems or trends, and alert or advise stakeholders to take specific actions based on discrete conditions in the data. In Voracity, these analytics could be performed in a number of ways, either in the platform (through SortCL or BIRT) or by preparing data for external BI and analytic (visualization) software products.
Collaboration and Processes
The IoT system, and the information it creates, is of little value unless it supports action, which often requires people and processes. Applications execute business logic to empower people. People use applications and associated data for their specific needs. Communication and collaboration often requires multiple steps, and usually transcends multiple applications.
MQTT Basics
Message Queuing Telemetry Transport (MQTT) refers to an open, low-impact data movement protocol used by a wide variety of IoT devices and operational platforms to communicate over a network. Many applications making use of MQTT can be developed just by implementing its control packets: CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT.
The MQTT protocol was specifically built to support machine-to-machine (M2M) and IoT applications, and its lightweight design has facilitated a revolution in intercommunication performance. MQTT has thus enabled rapid messaging between the billions of “things” that are now, and will continue to be, connected through the Internet.
By way of further detail, MQTT provides the mechanism for asynchronous communications, and can also act as a pipe for binary data. Every message published to an address is called a topic. Clients may subscribe to multiple topics. Every client subscribing to a topic receives all messages published to the topic. In MQTT architecture, sensors act as the clients, and the Server acts as a broker over a TCP layer.
Sequence Diagram
The client can either publish or subscribe a message. Here, Client1 wishes to share a particular topic (message) by publishing it through the MQTT Server once it is available. Clients 2 and 3 subscribe to (acknowledge) the message.
QoS=0 means the client doesn’t expect any response to the message sent, whereas QoS=1 means the message is stored and a response (PUBACK Response) is expected.
In my next article, I report on IRI’s first IoT-specific uses of the SortCL data processing program available to CoSort and Voracity users. We aggregate and analyze streaming sensor data from an MQTT broker on the edge and in a hub.
References:
- https://www.mysensors.org/build/mqtt_gateway
- http://www.eclipse.org/community/eclipse_newsletter/2014/february/article3.php
- http://www.instructables.com/id/Installing-MQTT-BrokerMosquitto-on-Raspberry-Pi/?ALLSTEPS
- https://www.youtube.com/watch?v=VaWdvVVYU3A
- http://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe
- https://mosquitto.org/documentation/
- https://wiki.eclipse.org/images/7/7c/MQTTIntroEclipseWebinarv1.pdf
- https://www.infoq.com/articles/practical-mqtt-with-paho
- https://eclipse.org/paho/clients/java/
- https://aws.amazon.com/blogs/iot/how-to-bridge-mosquitto-mqtt-broker-to-aws-iot/
- http://stackoverflow.com/questions/19506939/how-can-i-publish-a-file-using-mosquitto-in-python
- http://stackoverflow.com/questions/24023277/mqtt-publish-the-last-line-from-a-file-that-is-periodically-updated
- https://iot.eclipse.org/projects/getting-started/
- http://cdn.iotwf.com/resources/71/IoT_Reference_Model_White_Paper_June_4_2014.pdf