Message Queue Telemetry Transport (MQTT)

3 minutes of reading
Availability: na
Category: software
Type: procommunication protocol
Implementation difficulties: low


MQTT it's a proProtocol machine-to-machine (or to make dialogue macChina) ideal for the world of personal domotics, more generally for the world of and production . His characteristics, profirst for the objectives that it is proposes, are those of being extremely flexible, light, fast and effective.

To quickly understand what it is, what it is for and what the functional model isnamewe will use la metaphor of lighthouses.

Metaphor of lighthouses

LighthouseLet us assume the case exists of signal lights along a coast and that the guardians of these lighthouses can dialogue in some way (for the purposes of the explanation we can imagine using a telephone) only with a communications sorting office. We will call him broker. Finally, let's say that the order to turn on or turn off a given light can come from one or more controllers, which do not know the telephone number of the lights but only the broker's. Furthermore, lighthouse keepers have a duty to notify the broker - occasionally - the lighting status of the light itself, confirming that it is actually switched off or on. Also, check that there are commands or not status change by controllers. The controllers themselves call from time to time to know if there is any change of state signaled by the headlights.

The dusk is coming and a controller calls the broker and tells him the command to turn on the lighthouse - let's say - number 2. A moment later he calls, for his cyclic verification, the number 8 beacon, which communicates "been switched off" and verifies if there are changes of state required, but gets a negative answer. A moment later they call other lighthouses, again for cyclical verification, until they call profirst the 2 number, which communicates an "off state" and checks if there are any commands for it. Yes, there is an ignition command, and receives it from the broker.

At this point, the lighthouse keeper, diligent, prosees to light the lamp, after which it calls the broker and it communicates "been on" and, while it is there, check if there are new status change commands, but in this case he gets negative answer.

When the controller interested in the 2 beacon calls, is informed of the 2 headlight lighting up, who reported, appanointed, this new state.

And so on.

MQTT and home automation

In the domotic environment, MQTT works, broadly, as explained by the lighthouse metaphor. First of all, where we want to exploit this protocollo, it is good - if not vital - have a broker (we suggest Eclipse Mosquitto), or a "sorting office" of MQTT messages from and to the various devices, be it of final management, be it sensors, actuators or devices.

Typically sensors, actuators and devices (with MQTT support) offer a set of commands to be checked and one of telemetry, which provide, apptogether, the status of the various components and metrics they are able to offer.
For example, using a device Sonoff equipped with firmware Sonoff-Tasmota is available a list of commands and telemetry useful for turning the actuator on / off, knowing its status, adjusting response times, etc.

Who sends and receives these MQTT commands / telemeters are usually the "clients", ie those subjects on the network who want to pilot the components and know the various states. Taking a practical example, a typical MQTT client is the Home pluginbridge "homebridge-mqtt-switch-tasmota“, Which allows you to create a switch within the HomeKit that, if operated, does nothing but send the broker an MQTT command (on or off) addressed to a Sonoff specific (identified by the command itself) present on the network, which receives and executes it.
Furthermore, the client receives the various status telemeters from the broker, which in turn, over time, receives them from the device.

Taking up the metaphor of lighthouses, in domotics we can imagine the headlights like many actuators (like the Sonoff Basic) connected, for example, to lamps; the broker will be for theappgotten the MQTT broker present on the network and, always on the net, we will finally have the MQTT clients, which will impersonate the controllers.

More information on how to configure MQTT in home automation are available on this our guide.

Please comment below