From oil pipelines to IoT protocol
Let’s start with a brief history of MQTT. It was developed in 1999 to monitor oil and pipelines over the satellite, and it is a lightweight protocol that performs well at unreliable networks.
It is being used where bandwidth, speed, and battery life matters; for example, Facebook messenger uses MQTT connection and routing messages through their chat pipeline, and they can often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds.
There are four terminologies that you must know before going further. Publish/subscribe, messages, Topics, and Broker.
The first concept is a publish and subscribe, a device will publish a message to a topic, and all the devices which are subscribing to that topic will receive that message.
Messages are the information exchanging between devices in the form of command or data.
That is the topic, which you will subscribe to receive and publish to send data.
The broker is the central part of the network and receives all messages, filtering them and decide who is interested in them and publishing the message to all the subscribed devices.
For example, To explain all the four parts, we will take a sample of Magazine distribution. The Raspberry pi foundation publishes the magPi Magzine, the official raspberry pi project books through their website, and all the people who are interested in that magazine will subscribe to receive that magazine.
In that example, the Raspberry pi foundation publishes different magazines on their website; the Raspberry pi foundation is the publisher. Their website is here acting as a broker; the magpie is one of the publications from the pi foundation; the content inside them is the message, and the people who are getting these magazines on subscription are subscribers.
MQTT block diagram
To explain the network technology, we will consider four things, broker/cloud, devices, sensors, and actuators.
Two devices are subscribing to topic temp, so when nodemcu or esp 8266 will read data from the temperature sensor, it will publish the temp value on topic temp, the two devices which are subscribing to temp will receive that message. Similarly, two devices are subscribing to topic gas, when second esp will read data from the gas sensor it will publish the data to topic gas and the data will goes to the cloud which will decide on which devices to send the data and the device which have already subscribed to gas will receive the gas value. Collectively, there are three end devices, one is subscribing to temp, another is subscribing to gas, and one is subscribing to both. So they will get messages accordingly.