MQTT Protocol


MQ Telemetry Transport (MQTT) is a lightweight open messaging protocol. The protocol provides publish-and-subscribe messaging, and it runs over TCP/IP. It is handy for network bandwidth-constrained devices or when a small code footprint is required.

The MQTT protocol requires a Client and a Broker (also called Server):

  • Client: virtually any device that runs an MQTT implementation and is connected to an MQTT Broker. This can be subdivided into Publisher and Subscriber: The Publisher sends messages to subscribers via a Topic. The Subscriber receives the messages. There are many client libraries in many programming languages. You can check some of them here.


A Topic is an identifier to a resource.


The Vitro SDK is built around Mbed OS and it has an MQTT built-in library.

  • Broker: the Broker is tasked with receiving, filtering, and sending all messages to subscribed clients.


There are free self-hosted brokers available. The most popular and open-sourced is Mosquitto that runs on Windows, macOS, and Linux. Our Github repository has an implementation of Mosquitto. It is a fork from Emutex.

There are some actions that the MQTT protocol can perform. They are called methods, and there are 5:

  • Connect: waits for a connection to be established with the Server.
  • Disconnect: waits for the MQTT client to finish any work.
  • Subscribe: requests the Server to let the Client subscribe to one or more topics.
  • Unsubscribe: requests the Server to let the Client unsubscribe from one or more topics.
  • Publish: returns immediately to application thread after passing a request to the MQTT client.

If you want to learn more about MQTT, you can check this website and the official MQTT website.

Communication Patterns

You can use the MQTT protocol to communicate in many different patterns:

  • Point-to-Point: This one-to-one communication pattern is achieved when two things have the same MQTT topic. One thing publishes to this topic, while the other subscribe to it.
  • Broadcast: This is a one-to-many communication pattern. This can be done by subscribing many things to a single topic. Usually, this topic is a category or a group of devices. The sender then publishes to the topic.
  • Fan-In: A many-to-one message system. It is simply the opposite of Broadcast. Multiple devices have a shared topic with a single subscriber. This is useful to aggregate telemetry to an IoT application.

You can read more about it here.

Best Practices

This AWS guide show some best practices for MQTT topics. Some examples are:

  • MQTT topic only uses lowercase letters, numbers, and dashes.
  • MQTT topic should follow a general to a specific pattern.
  • Include any relevant routing information in the MQTT topic.
  • Prefix your MQTT topics to distinguish data topics from command topics.
  • Document proposed MQTT topic structures as part of your operations practice.
  • Use the AWS IoT Thing Name as the MQTT client ID for connecting as a device over MQTT.
  • Include the Thing Name of the device in any MQTT topic the device uses for publishing or subscribing to its data.
  • Include additional contextual information about a specific message in the payload of the MQTT message.
  • Avoid MQTT communication patterns that result in a sizeable fan-in scenario to a single device.
  • Never allow a device to subscribe to all topics using #, and only use multi-level wildcard subscription in IoT rules.

What’s Next