Jump toUpdate content
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, 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.
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
Persistent sessionsare 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.
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.
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:
MQTTover Websocket over
MQTTover Websocket, port `80“
The certificate authority for the TLS endpoints can be downloaded directly from the management console in your IoT Hub overview page. Please note TLS endpoints support both server-only and mutual authentication.
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.
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 client ID.
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.
When creating a “shared” Hub, your Devices connect to the same message broker as other customer’s Devices. Getting a global view of the broker’s activity (through
$SYS topic subtree) is thus not relevant.
On a dedicated or high availability Hub, you are the only customer on the message brokers, you can access this topic subtree.
Any MQTT message between the Hub and a Device will be billed. If the message is bigger than 4kB, then each 4kB chunk of the message will be counted billed as one message. For example, a 9kB message will be billed as 3 messages.
The maximum size for a message is 4MB.