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 especially useful for pushing data from the cloud to your devices. Imagine a cloud-controlled device that opens or closes a door remotely. With HTTP, the device would have to continuously make GET requests to the Ubidots server to check whether there’s a change in a variable, such as "Door Control Variable", and then take action depending on the last reading. This takes a lot of requests, and it’s not entirely a real-time interaction since it depends on 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 necessary, saving battery, reducing network bandwidth, and improving the real-time experience.

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

Quality of Service

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

0, At most once: This level does not guarantee message delivery; it is considered best-effort server QoS.

1, At least once: This level guarantees that the message is delivered at least once to the receiver. The receiver answers with a PUBACK packet. If this PUBACK packet is not received, the sender sends the message again.

2, Exactly once: This level guarantees that the message is received only once by the receiver. It is the slowest QoS packet exchange because 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, or LWT, refers to messages that are sent by the broker when 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 take 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 avoid collisions with other users sending data 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 subscribing.

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