Using the MQTT IoT protocol for unusual but useful purposes

Thing Minder

Once upon a time, IBM developed the lightweight, TCP-based protocol MQTT. The name was an acronym for "Message Queuing Telemetry Transport"; however, the long form of the name disappeared with the ratification of MQTT as an official OASIS standard at the end of 2014.

MQTT is a pub/sub protocol. Clients connect to a server known as a broker and, if they are authorized, they can issue messages or wait for messages to arrive. By default, MQTT uses TCP port 1883 and TLS-TCP port 8883.

Unlike HTTP, MQTT does not require polling by the client; instead, the broker informs waiting subscribers as soon as a message arrives and communicates the message to them. This approach saves bandwidth and allows communication with lower latency.

The broker doesn't know what the clients do with the messages; the broker's job is over and done with as soon as the message is delivered. MQTT enables a decoupled 1-to-n or 1-to-1 relationship between different devices or programs that do not specifically need to know each other in order to communicate. The entities just need to understand each other's data.

MQTT clients, both subscribers and publishers, can come and go at any time. New clients can connect to the server at any time. However, an MQTT broker usually has access control lists (ACLs) that govern access to certain topics.

Topic, a Name String

Each message is associated with a topic. Topics are hierarchically structured name strings in UTF-8 with a length up to 64KB, and they resemble Unix paths. Unlike path names, topics do not start with a leading forward slash. For example – staying with the Internet of Things (IoT) theme – a lamp could publish its state via a lamp/kitchen/state topic, while the lamp/living_room/switch topic switches a lamp in the living room on or off. On the same broker, a fan can publish its state via

... comments powered by Disqus