Scaleway IoT Hub - Introduction to MQTT Topics

The Internet of Things, or in short IoT, is about creating a wide ecosystem of services for connected devices to turn them into smart devices.

Imagine an Internet-connected computer without search engine, emails, e-shops, video streaming, and so on - there is not much value in it. The same applies to connected devices. From common household appliances like lightbulbs or refrigerators, shipping labels, cars, or even entire cities; making them smart requires to connect them to high quality services. This is where IoT Hub kicks in.

Scaleway IoT Hub is a new block in the Scaleway Elements ecosystem: a PaaS fitting between connected devices and services, enabling secure device-to-device and device-to-cloud communication. Using a Publish/Subscribe architecture, the service ensures flexible data delivery to many destinations, including non publish/subscribe targets such as databases, object storage, or any REST API.

You can see IoT Hub as a managed message broker. Its main features include:

• A Publish/Subscribe architecture
• Use of the MQTT protocol, with or without TLS, with or without WebSockets
• Mutual authentication is available on TLS connections
• High Availability and Scalability
• Routes to non Publish/Subscribe services
• Multiple other IoT Networks such as SigFox or LoRa
• Detailed usage metrics per Hub and Device

IoT Hub uses the MQTT protocol, an open, lightweight, simple, and easy-to-implement publish/subscribe messaging transport protocol. Invented by Dr. Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech) in 1999, the protocol was initially designed to connect oil pipelines via satellite with minimal battery power and bandwidth usage in mind. In 2010 the protocol was released as an open standard, and its primary use has evolved from proprietary embedded systems to Internet-of-Things (IoT) and Machine-to-Machine (M2M) use cases. Its design makes it ideal for Internet of Things contexts where a small code footprint is required and/or network bandwidth is limited.

Traditional Client/Server Architecture vs. Publish/Subscribe Architecture

In a traditional client/server architecture, such as HTTP, the client has to know which server hosts the required service, connect to it, send a request and receive a response. Servers are classified by the services they provide. For example, web servers deliver websites, and email servers deliver emails, file servers deliver computer files, and so on. This pattern is well suited in many-to-1 communications, but very poor at many-to-many relationships.

The publish/subscribe architecture provides a different approach: It decouples the publisher (the client sending a message) from the subscribers (one or several clients receiving the message). No direct connection is established between the publisher and the subscriber. There is even no need for them to know that the other one exists. Messages are published to a third component, called broker, which job is to forward messages from publishers to subscribers based on topics. A topic describes the data contained in the message (eg: weather in Paris, France) so subscribers can choose which messages to receive based on the service they provide.

The brokers allows for plug and play operations, publishers and subscribers can join and leave at any time. This is especially relevant for battery powered devices.

Introduction to MQTT

MQTT is one of several Publish/Subscribe implementations. It is very lightweight in comparison to a traditional message queue system:

In a traditional message queue, queues must be named and be created before use. It will only be possible to publish or consume messages on pre-created queues. With MQTT there is no such restriction, any client can use any topic without prior configuration. IoT Hub has a topic filtering feature if you want to enforce per-device topic access control.

In a message queue, messages are stored until a client picks them up. Each message remains in the queue until they are processed. It is not possible for a message not to be processed, this is possible in MQTT if no client subscribes to a topic.

Also, in a message queue, a message can only be consumed by one client, and the load is distributed between the clients for the queue. In MQTT, while this data distribution pattern is doable (with MQTT 5, this is called shared subscriptions), by default every subscriber of a topic receives all messages published to this topic.

Introduction to Topics

On IoT Hub, senders and receivers will identify messages by a name describing their content: the topic.

The term topic in MQTT refers to a simple UTF-8 string that the broker uses to dispatch messages to subscribers. Topics can consist of one or several topic levels, each of them separated by a forward slash - referenced as topic level separator. A topic can be, for example, fr/paris/weather/temperature for the temperature in Paris, France.

Topics are case sensitive and must contain at least one character. This means that fr/Paris/Weather/Temperature refers to a different topic than fr/paris/weather/temperature.

Topic Levels & Topic Level Separators

Other valid examples for topics could be:

• compute/instance/f97d95cd-b349-4bee-9ac8-92e12542d4e9/status
• myhome/first-floor/bedroom/temperature
• Bavaria/Munich/Marienplatz

Given the previous example, a publisher could be a weather station that broadcasts the actual weather in Paris to IoT Hub, the broker. Two subscribers are connected to the broker: a database (to keep a history of the weather data) and a real-time display. IoT Hub takes care of delivering a copy of the published message to each subscriber. Publishers and subscribers do not need to know each other.

The subscribers subscribe to a topic at the broker (Scaleway IoT Hub) (1), the publisher publishes information in the topic to the broker (2) and the broker publishes the topic to the subscribers (3)

Working with Wildcards

Another benefit of MQTT is that you can subscribe to categories of information and therefore know, in advance, the list of information the device will receive.

Instead of subscribing to the exact topic of a published message, it is possible to use wildcards to subscribe to multiple topics simultaneously.
Two different types of wildcards exist single-level and multi-level. They can only be used to subscribe to topics, it is not possible to publish a message using wildcards.

Single-Level Wildcards

A single-level wildcard replaces, as the name suggests, one topic level. The plus symbol (+) represents a single level wildcard in a topic:

Single-level Wildcard

For example, you can subscribe to the topic fr/+/weather/temperature to receive the weather forecast for all cities in France. When you add a new weather station in France, your subscriber will automatically receive the information it publishes.

Multi-Level Wildcards

A multi-level wildcard spreads across many topic levels. It is represented by a hash symbol (#)in the topic. It is required to place the multi-level wildcard as the last character in the topic:

Multi-level Wildcard

The device will receive all messages of a topic that begins with the pattern before the wildcard character, for example:

• fr/paris/weather/temperature
• fr/paris/weather/humidity
• fr/paris/weather/airquality/city
• fr/paris/weather/airquality/subway

When using a multi-level wildcard, all messages are received by the device, no matter how long or deep the topic is.

$ Topic Prefix

MQTT introduces a special topic prefix: the $ sign.

Applications are not allowed to use topics beginning with a $. These are reserved for broker use. Wildcards do not match the $ sign.

Summary

Now you know the principles behind the topics, for more information about MQTT topics, read our documentation and try IoT Hub now.