IoT Hub

What is IoT Hub?

IoT Hub is an IoT Platform as a service, it sits between connected devices and business-specific software. Connected devices is the common name for all devices able to communicate over the internet (via Wi-Fi or 4G for instance). Connected devices are everywhere and can be used in a very broad range of applications. They can be smartphones, doorbells, light bulbs, refrigerators, cars, or TVs. Even a web browser can act as a connected device.

MQTT is a lightweight and standardized publish/subscribe messaging transport protocol, designed for low-power usage, minimized data packets, and efficient distribution of information to one or many receivers. MQTT supports secure communication using TLS, and it is often used in IoT use cases. All kinds of connected devices supporting the MQTT protocol can be connected to IoT Hub. MQTT through WebSockets is also supported. There is no limitation to specific vendors. To learn more about what is a Hub, what is a Device and what is a Route, head over to our dedicated pages:

IoT Hub is only available at PAR1 (Paris, France) for the moment, other regions are planned.

What are the differences between the IoT Hub offers?

There are two categories of IoT Hub offers:

Stateful provides full MQTT protocol support.
Stateless provides a subset of MQTT protocol, generally speaking, the broker will not store any data on your behalf. This excludes the following MQTT messages: Publish QoS 2, Subscribe QoS 1-2, and Retained messages. Persistent sessions are also disabled.

The following plans are currently available:

Shared Plan (stateless): Devices are connected to a virtual broker that runs on a broker that is shared with other customers. Isolation is provided natively through the virtual broker mechanism.
Dedicated Plan (stateful): The broker is provided with dedicated CPU and memory resources, and you can use them as you wish. There is no limitation in the usage of the broker, everything is dedicated to you.
High Availability Plan (stateful): Two dedicated brokers, connected together, are provided to avoid service interruption if one of them fails.

Each IoT Hub can be fully configured both from the management console, and a powerful REST-API.

How secure is Scaleway IoT?

Scaleway IoT was designed with security in mind. Therefore, we implemented mutual authenticated TLS as the default authentication method. Each device needs its certificate+key pair to connect to the hub. For devices not supporting secure connections, it is possible to also enable plaintext and server-only TLS authentication.

Can you detail what messages are?

MQTT is a Publish/Subscribe protocol (more info on the MQTT protocol here). A message is the base unit for data transmission, it mainly contains:

a topic: the message information type identifier, such as fr/paris/weather. Devices that have subscribed to a topic will receive any message published to this topic.
a payload: the actual data to be transmitted. Can be anything (temperature, image, notification, …) in any format (binary, xml, json, yaml, …)

The Hub will provide an endpoint to connect the devices to and supports the following protocols:

MQTTs: MQTT over TLS, port 8883
MQTT: Plaintext MQTT, port 1883
WSs-MQTT: MQTT over Websocket over TLS, port 443
WS-MQTT: MQTT over Websocket, port `80“

The certificate authority for the TLS endpoints can be downloaded directly from the management console on your IoT Hub overview page. Note that TLS endpoints support both server-only and mutual authentication.

What is a Device ID and a Client ID?

A Device ID is a unique identifier for a device, in the format of a UUIDv4. It is used in calls to the IoT API to designate a specific device. It must also be used as the MQTT Client Identifier field during connection. If your software doesn’t have a setting for Client ID, you can use the Device ID in the Username field instead. If no Device ID is found in the client ID field, but it is present in the Username field, the one used in the Username field will be used as the Client ID.

My software/library limits MQTT client ID to 23 characters, what should I do?

MQTT’s specifications state The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length and The Server MAY allow ClientId’s that contain more than 23 encoded bytes. Certain software/libraries restrict MQTT client ID field to 23 characters maximum.

If you fall into this situation, you can type your Device ID in the MQTT Username field. If no valid Device ID is found in the MQTT client ID field, but one is found in the MQTT Username field, the one found in the Username field will be used as the client ID.

What is Deny/Allow insecure connection?

Each Device has 2 different levels of security:

Deny insecure connection: in this mode, the only way for a Device to connect to a Hub is to use TLS with mutual authentication. This is the strongest security setting, but it means the Device has to use a TLS certificate+key pair to connect and must know the Hub’s certificate.
Allow insecure connection: in this mode, a Device can connect using TLS with mutual authentication as before, but can also connect with TLS with server-side authentication only, and with no TLS at all. This is the weakest security setting, but it is more flexible as the Device does not necessarily need to use certificates.