by Israel Vicars, on Feb 12, 2018 10:57:08 AM
by Israel Vicars, Software Developer at eFlex Systems
Connecting machines, people, and data in manufacturing facilities across 4 continents keeps us busy. One of the connectivity protocols that we support is MQTT (Message Queuing Telemetry Transport). Invented in 1999, the protocol has long been used in industry with rapidly increasing adoption because of its suitability for machine-to-machine, Internet of Things, and mobile applications.
You can use MQTT to connect your M2M, IOT and iOS devices over TCP/IP with SSL. Any Acronym Bingo winners yet?
To understand MQTT, we have to first talk about the Publish-Subscribe (“Pub/Sub”) design pattern. Because design patterns are thrilling. Let’s get there by way of Twitter and text messages.
Twitter was invented as a text message that anyone could read. Instead of sending a text message directly to someone, users would send their text message to Twittr.com which would forward that text message to only those users who wanted to see it. This demonstrates the three roles of the Pub/Sub pattern: publishers send messages to a broker, the broker filters and distributes those messages to subscribers who have subscribed to a particular topic or publisher.
MQTT is an implementation of Pub/Sub-type messaging for a different kind of publisher and subscriber. Just like Twitter’s 140 character limit made it ideal for quick status updates and text message delivery, MQTT has rules and procedure that makes it optimal for a particular set of use cases. It takes very little code to run on a device. Messages have very little overhead for minimal network bandwidth. It’s bidirectional, so a device can be both publisher and subscriber. It works over TCP/IP, i.e. Internet and local area network connections. Authentication and encryption over SSL are supported for security.
At eFlex, there are a growing number of device integrations we can support without custom integrations because of MQTT. An MQTT broker runs alongside eFlex applications. Events from network-connected devices are sent to the broker which can be monitored and responded to in an application. Similarly, application commands can be sent to the broker which distributes them to a device. There’s no need for rewriting integration protocols for every machine when there’s a common protocol in place.