What is MQTT used for?
MQTT is a lightweight messaging protocol typically used with IoT devices that are designed to be power efficient and consume minimal bandwidth.
MQTT is commonly used for IoT applications to connect to and communicate with low-power devices such as sensors, actuators, and home appliances, efficiently managing the payload of data transmitted.
In agriculture, MQTT is used to monitor environmental factors such as soil moisture, temperature, and humidity, allowing farmers to take the appropriate action. In industrial automation, MQTT can monitor the end-to-end manufacturing process, ensuring consistent quality and identifying systemic issues on the production chain. In transportation, MQTT is used to monitor traffic lights, parking meters, and the real-time location of public transportation, all while being mindful of the ecosystem and low bandwidth requirements.
Why use MQTT instead of HTTP?
HTTP and MQTT are two very different communication protocols used for different purposes.
HTTP is a request/response protocol that only delivers data in response to a request by a client. It is designed for large amounts of data and is commonly used for transferring web pages, images, and videos. MQTT is a pub/sub protocol that enables asynchronous message delivery, with multiple clients able to subscribe to a single topic and receive messages from a publisher or publishers. MQTT is optimized for small amounts of data but is more efficient than HTTP in terms of network overhead and device power consumption, making it a suitable choice for applications requiring low bandwidth and minimal power usage, such as those managed by AWS IoT services.
What languages is MQTT written in?
MQTT is just a protocol and can be written in many languages. However, MQTT client libraries—which are used to communicate using the MQTT protocol—are available in multiple languages such as C/C++, Java, Python, and JavaScript—including Node.js, Ruby, Go, PHP, and Swift. An MQTT client library communicates through an MQTT broker, which is also available in several programming languages.
Popular MQTT brokers include:
- Eclipse Mosquitto is a widely used open-source MQTT broker known for being lightweight and efficient. It supports all MQTT versions and is ideal for small to medium-sized projects.
- EMQX is an open-source, highly scalable broker designed for handling millions of connections. It also supports enterprise features like clustering, making it a good fit for large-scale IoT deployments.
- HiveMQ offers both an open-source free of charge community edition and an enterprise paid version. It is known for reliability and scalability in industrial IoT use cases and supports features like MQTT over WebSockets and advanced security.
- VerneMQ is another open-source MQTT broker focused on scalability and fault tolerance, designed for high availability in large-scale systems.
- AWS IoT Core, Microsoft Azure IoT Hub, and Google Cloud IoT Core are cloud-based solutions that integrate MQTT to handle IoT devices' data, offering built-in security, scaling, and other cloud services.
MQTT session lifecycle
MQTT relies on TCP/IP for connectivity, so follows a similar lifecycle
Connection
The MQTT client initiates a connection to the MQTT broker. Typically, this will be over the standard MQTT ports (1883/883 for secure and insecure connections, respectively)
Authentication
The MQTT protocol does not have any authentication considerations beyond TLS for the underlying TCP/IP connection, which is sufficient for most use cases.
Publish / Subscribe
Once connected, clients can publish or subscribe to topics to send and receive messages.
Disconnect
Disconnection can be initiated by either the client or broker and will cause the MQTT session to end after any in-progress requests have been processed.
MQTT use cases and examples
IoT (The Internet of Things) is the most popular example where MQTT is a great fit. IoT devices are typically battery-powered and can be very expensive to maintain, so lasting a long time between battery swaps is preferred. Whilst in the home environment it is not difficult to replace a battery now and then, in an industrial environment, with thousands of sensors, spread across a wide area and often in very difficult-to-reach locations their maintenance can get costly very quickly.
MQTT IoT use cases include fire detectors, theft tracking, location monitoring, sensors, engine status, etc. MQTT also has very low data overheads so, in those environments where data is expensive, or where thousands of devices are deployed so bandwidth is a concern, MQTT is ideal.
PubNub and MQTT work great together for IoT. Please see our IoT demo and IoT tutorial to learn more about how PubNub and MQTT can deliver a reliable, scalable, and efficient IoT solution.
MQTT is also very popular in real-time communication, the best-known example being Facebook Messenger. Why would Facebook choose to use MQTT? Because it would not drain your phone’s battery, would not use excessive data, runs on secure protocols, allows scaling, easily facilitates group chats, and distributes all data through a central MQTT broker backbone infrastructure.
How to leverage MQTT use cases
At the heart of using MQTT as a communication avenue is the topic. It’s a remarkably simple idea not unique to MQTT; however, the MQTT protocol leverages the power of this quite nicely. A topic implicitly accomplishes several tasks, most importantly ensuring that a message is delivered to the correct listeners. MQTT treats a topic as a file path. When thinking of a topic as a simple communication filter, the path application can become very powerful.
You could be interested in a particular higher level of the path or the leaf element. Without explicitly saying so, MQTT filters messages based on where you subscribe in the tree path. It’s a simple idea, that can be used very effectively.
MQTT technical specifications to meet your use case
Let’s dig a little deeper into the technical aspects of MQTT. First, the protocol runs on top of the TCP/IP networking stack. When clients connect and publish/subscribe, MQTT has different message types that help with the handshaking of that process. The MQTT header is two bytes and first byte is constant.
In the first byte, you specify the type of message being sent as well as the QoS level, retain, and DUP (duplication) flags. The second byte is the remaining length field. There is more information you can glean from the MQTT specification if you are interested.
