MQTT Chili

MQTT_chiliIoT continues to be all the rage. Every CIO is talking to their automation people about what can be done to get and use factory floor data. And, of course, every vendor is now an IoT expert with the right hardware, software, and platforms to take on that challenge. Most have a single technology solution that is built around them selling you server space and an application with a monthly charge. Nobody wants that. They just want the technology that will give them the data they need.

There are lots of technologies that can be used in these applications. Sometimes I think there are more IoT technologies than Chili recipes. And just like Chili cooks, every IoT vendor believes that they have the best solution. In truth, you can be satisfied with almost any bowl of Chili on a cold winter day. IoT technologies are like that. There are differences between the technologies but you can design a solution using almost any of them.

Lately, I’ve been asked about a lot of proprietary IoT applications as opposed to applications that are meant for general automation. These are applications where there is some data in a proprietary system(s) and it must be moved to an Enterprise or Cloud application. It’s not an application where a lot of different customers will use the data; everything will be part of a proprietary application. The data will end up in the server of the company that owns the raw data in the originating device.

I’ve proposed MQTT (Message Queuing Telemetry Transport) for some of these applications. MQTT is one of the popular mechanisms for moving data around the factory floor or from the manufacturing environment to the cloud. MQTT is designed to meet the challenge of publishing small pieces of data in volume to lots of consumers’ devices constrained by low bandwidth, high latency, or unreliable networks. MQTT is really good at dynamic communication environments where large volumes of data and events need to be made available to tens of thousands of servers and other consumers. It’s also useful in applications that I am seeing where you have a small set of devices sending small data packages to proprietary server devices.

The heart and soul of MQTT is it’s publish/subscribe architecture. This architecture allows a message to be published once and go to multiple consumers, with complete message decoupling between the producer of the data/events and the consumer(s) of those messages and events. Data is organized by topic in a hierarchy with as many levels of subtopics as needed. Consumers can subscribe to a topic or a subtopic. They can also use wildcards to specify topics of interest.

Namespace designations are used to identify topics. A broker receives the information from the servers and matches the information to consumers by topic subscriptions. The information is distributed to every consumer that matches the topic. If no consumer requires the information, the information is discarded.
Topics are designated by a namespace. Subtopics are designated with a slash (“/”). An energy system might publish information about itself on:

Microsoft Word - 2016 Dec 04 Blog - IoT MQTT

Some of the benefits of using MQTT in these applications include:

• Very efficient event handling protocol. MQTT is a “PUSH” system in which the producers push data to brokers. No bandwidth is consumed by consumers requesting data.
• Low latency. Information is pushed immediately to consumers.
• Low resources required by publishers. This makes it very good for low resource devices like sensors and actuators.
• Very reliable operation on fragile and unreliable networks. Brokers can be configured to retain messages for consumers that are temporarily disconnected.

More and more, I think of myself as sort of an IoT Chili cook because I’m not wedded to any particular Chili recipe (or IoT technology). I really like MQTT. It’s easy to implement, it solves the problem, and it’s simple to understand—just like good Chili on a cold winter day.