MQTT is an Internet of Things connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium"

(Source: MQTT.org).

MQTT is specially useful to push data from the cloud to your devices. Imagine a cloud-controlled device to open/close a door remotely. In the case of HTTP, the device would have to continuously make GET requests to the Ubidots server to see if there’s a change in a variable, say "Door Control Variable", and then take an action depending on the last reading. This takes a lot of requests and it’s not entirely a real-time interaction since it depends of the polling frequency. With MQTT, the device can "listen" to the cloud and only get notified when there’s a change in the variable. This way, the connection between the device and the cloud is left open but data only travels when is necessary, saving battery, network bandwidth and improving the real-time experience.

In this section you will find the documentation needed to handle your devices with Ubidots over MQTT.

Quality of Service

In MQTT, the quality of service, QoS for short, guarantees the delivery of a specific message. There are three levels of QoS:

0, At most once: This level does not guarantee the message delivery, it would be labeled as best-effort server QoS.

1, At least once: This level guarantees that the message is delivered at least one time to the receiver. The receiver answer with a puback packet, if this puback packet is not received the sender sends again the message.

2, Exactly once: Guarantees that the message is received only once by the receptor. It is the slowest packet interchange QoS as it requires two request/response flows.

📘
QoS in Ubidots
Ubidots supports QoS up to 1 (at least once).

Last Will Testament (LWT)

In MQTT, Last Will Testament, LWT for short, are messages that are sent by the broker once the connection with the client has been interrupted (the client has gone offline).

📘
LWT in Ubidots
Ubidots doesn't support LWT messages.

Persistent Sessions

In MQTT, persistent sessions are a way of having the broker save relevant information about the client in case the connection is lost. Once the connection is back up, the broker will have the connection information immediately.

📘
Persistent Sessions
Ubidots doesn't support Persistent Sessions (setting the cleanSession flag to false won't make effect). Once the connection has been lost, the client must establish the connection settings again.

Client ID

The ClientId is a unique identifier that distinguishes each MQTT client connecting to a broker and enables the broker to keep track of the client’s current state.

📘
Client ID
To ensure uniqueness, and hence avoid collisions with other users sending to Ubidots, make sure your Client Id is:

Alphanumeric.

No shorter than 20 characters.

Random.

Retain flag

A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for that topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe

📘
Retain flag
By design, every message publication to Ubidots broker is marked as retained, regardless if the message itself doesn't has the flag. This ensure that the last value published to a variable is always available over MQTT subscription.
Similarly by design, when data is post it over HTTP, TCP or UDP, Ubidots publishes the last value to the broker to ensure consistency regardless of the protocol.