20 Frequently asked questions about MQTT protocol

What MQTT protocol means?

MQTT protocol is a lightweight messaging protocol for use in scenarios where clients require a small code footprint and are linked to erratic or bandwidth-constrained networks. Its primary application is machine-to-machine (M2M) communication or Internet of Things connections.

What MQTT stands for?

 Message Queuing Telemetry Transport.

What is MQTT topic ?

The term “topic” in MQTT describes a UTF-8 string that the broker employs to filter messages for each connected client.

You will subscribe to the topic to receive and publish to send data.

One or more topic levels make a topic.A forward slash separates each topic. Here is the example,

home1/room1/temp1
home1/room1/temp2
home1/room2/temp1
.
.
.
.
home3/room2/temp2

MQTT topics are extremely lightweight as compared to a message queue. Before publishing or subscribing to a topic, the client is not required to create it. The broker doesn’t require any initialization before accepting any valid topic.

What is MQTT payload ?

MQTT is used to transmit messages to other hardware or software via a broker. Every communication has a topic that the Broker can use to further process the message. Each message also includes a message payload, sometimes known as the message content. The MQTT payload can be created as it wants and is not restricted to any particular structure. To make the message content readable by other hardware or software, it is useful to define a specific structure. A predetermined format allows for easy internal communication once all devices and software interact using the same structure, which can be JSON, XML, or OPC UA.

What is MQTT protocol ?

MQTT is an OASIS messaging standard for the Internet of Things (IoT). The intention of MQTT protocol is to be a very lightweight publish/subscribe messaging transport for connecting remote devices with a small code footprint and low network bandwidth. The use of MQTT is in a wide range of industries, including automotive, manufacturing, telecommunications, oil and gas, and so on.

What is MQTT broker ?

An MQTT broker is a middleman that permits communication between MQTT clients. In more detail, a MQTT broker takes messages published by clients, categorize them, and then sends the messages to subscribers.

MQTT becomes a far more effective and scalable protocol when the MQTT broker enables the publish/subscribe (pub/sub) communication mechanism.

What are MQTT clients ?

MQTT clients include both publishers and subscribers. Whether the client is presently publishing messages or has subscribed to receive messages is indicated by the publisher and subscriber labels (publish and subscribe functionality can also be implemented in the same MQTT client). Any device that runs a MQTT library and connects to a MQTT broker across a network is a MQTT client, ranging in size from a small controller to a full-fledge server. A very small, resource-constrained device with a wireless network connection and a bare-bones library, for instance, can be the MQTT client. For testing reasons, the MQTT client can alternatively be a standard PC running a graphical MQTT client. An MQTT client is essentially any device that speaks MQTT across a TCP/IP stack.

What are MQTT QoS (Quality of services) ?

A guarantee of message delivery is known as Quality of Service (QoS) in MQTT messaging and is an agreement between the sender and the receiver.

There are three different QoS levels:

0 – ideally once : This is the simplest and least expensive way to send a message. The broker doesn’t acknowledge the communication; the client only broadcasts it.
1 – a minimum of once: This approach ensures that the message will reach the broker successfully.
The sender receives an acknowledgement from the broker, but if the acknowledgement is lost, the sender won’t realize the message was delivered and will resend it. Until it receives the broker’s acknowledgement, the client will keep sending. This means that even if the message might reach the broker many than once, sending is guaranteed.
2 – precisely once: The four messages that make up this highest level of service serve as a form of handshake between the sender and the recipient, confirming that both the main message and the acknowledgement have been sent and received. Both the sender and the recipient are certain that the message was sent exactly once after the handshake is complete.

Which QoS to use for your IoT Application ?

In terms of data transfer volume, QoS 0 is the cheapest. This is appropriate if the broker and device have a solid connection.

You should think about whether your IoT application can withstand the occasional message loss. For instance, the consequence of a missed communication will only be a delay in the readings’ arrival at the server if a device is monitoring something and delivering cumulative readings.

If you need to ensure delivery of every message yet your IoT application can handle receiving a message more than once, QoS 1 is a viable option.

Because the sending device should have little impact if a message is received more than once by the server, QoS 1 may be appropriate if it is transferring cumulative data readings from an asset.

However, if there has been a “change since last transmission” in the measurements sent (for instance, the number of times a button has been pressed), a duplicate message could result in inaccurate data being displayed on the portal.

Making sure that every message by a device has a distinct timestamp is one approach to get around this. Based on the timestamp, Assetwolf will recognize repeated messages and ignore them.

Although QoS 2 assures delivery exactly once, it has a high data transfer cost.

The majority of apps should operate without issue with QoS 2, but you should think about if a less expensive QoS would be appropriate. It’s usually simple to eliminate the QoS 2 overhead by selecting the data fields carefully, such as timestamps and cumulative data readings.

What are MQTT “retained messages” ?

An MQTT message with the retained flag set to true is referred to as a retained message. The broker saves the most recent message that was kept as well as the relevant QoS for that subject. The retained message is delivered instantly to every client that has subscribed to a topic pattern that matches the retained message’s subject. Only one retained message per topic is stored by the broker.

MQTT messages are in order ?

Regarding the relative ordering of messages published with various QoS values, no guarantees are given. (For instance, QoS 0 can surpass QoS 2 because it only uses one packet as opposed to the latter’s four.)

• Orderly delivery of QoS 0 messages will be maintained (though messages may get lost)
• The order of QoS 2 messages will be delivered.
• Message duplicates are permitted in QoS 1; it is possible that a duplicate will arrive after the first instance of the next message published.
• If the client/broker only allows one message in flight at a time, QoS 1 ordering can be guaranteed.

Is MQTT protocol reliable ?

While no one denies that MQTT is extremely reliable for message delivery, one criticism is that there are frequently issues with speed and latency.

This is due to the fact that data must pass through the cloud. While this isn’t a big deal in certain scenarios and IoT functions, it can be problematic in the wrong situation.

For example, if you’re using MQTT as your data connection IoT protocol for a medical device, a delay of one or two seconds can make controlling the device extremely difficult for the operator and potentially dangerous for the patient.

If speed and latency aren’t critical factors in your IoT stack requirements, MQTT may be a viable option. If latency is a problem for your internet of things connectivity, look for an alternative.

Is MQTT protocol safe and secure ?

Another disadvantage of using MQTT in IoT is the lack of built-in security. It does not come ready to use out of the box, so it is up to the end user to manage. This necessitates the creation of a security layer on top of the MQTT.

One advantage of not having built-in security is that users can change their security solution as devices and technology evolve. Having said that, it is still a source of concern for many.

Does MQTT requires Internet ?

No, MQTT might function offline.  It simply requires an IP network since the publisher or subscriber and the broker communicate using TCP/IP. You don’t need need internet access if you have an IP network. Two devices and one Ethernet wire can create a network. In this project we connect ESP8266 and raspberry pi without using the internet.

Can you send images using MQTT protocol ?

Yes, it is possible. Here is the tutorial.

Can we use MQTT protocol for streaming videos ?

MQTT is not the solution if you want to create an IoT stack that enables video streaming.  you should search elsewhere if you want to stream video.

Which ports MQTT uses ?

IANA has designated TCP/IP port 1883 for use with MQTT. Additionally registered is TCP/IP port 8883 for MQTT over SSL.

Which OSI layer MQTT works on ?

A transport protocol like TCP serves as the foundation for the application layer protocol MQTT. It is comparable to other application layer protocols like HTTP in that regard.

When or who uses MQTT protocol ?

Many large businesses, particularly those in the automotive, industry 4.0, transportation, and entertainment industries, employ MQTT. Data interaction between confined devices and server applications takes place using MQTT. It accommodates unstable networks, needs little effort from developers to deploy, and has extremely low bandwidth requirements, making it perfect for machine-to-machine (M2M) communication.

Which is better MQTT, CoAP or AMQP ?

Although it is not first in every aspect of data transfer and network communication, MQTT is indeed a strong rival. CoAP, for instance, performs better than MQTT in throughput and overhead. And AMQP leads in terms of security.

However, MQTT offers its consumers a number of significant advantages, including:

Reliability, quick response times, infinite device compatibility, publish/subscribe messaging that is ideal for many-to-many communication, enough documentation, and a vibrant development community all make it easier to use the MQTT protocol.

All of these factors combine to make MQTT a good choice for your IoT device.

What is difference between MQTT and MQTT over websockets?

Only if you intend to publish/subscribe to messages directly from webapps should you need to use MQTT via websockets (in page).

In essence, You should run everything on pure MQTT and only add the websockets if you really needed them.

The MQTT client libraries only support native MQTT for all other non-browser languages. Both a websocket-based in-page library called Paho and a pure MQTT library are available for Javascript.

New client libraries that aren’t web-based or written in JavaScript have gained support for MQTT over websockets.