Scaleway Elements IoT Hub
Scaleway Elements IoT Hub Overview
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.
Scaleway Elements IoT Hub is a PaaS fitting between connected devices and services, enabling secure device-to-device and device-to-cloud communication. Using a Publish/Subscribe architecture, the Hub ensures flexible data delivery to many destinations, including non MQTT targets such as databases, object storage, or any REST API.
You can see IoT Hub as a managed message broker which main features are:
- Full MQTT compliance, secured with mTLS
- Routes to non MQTT services
- Available over many IoT Networks including MQTT, Websockets, REST, SigFox and LoRaWAN.
- High availability and scalability
Core Concepts
MQTT: MQTT is the standard protocol used to exchange messages. It is a publisher/subscriber protocol that is very lightweight, even for the smallest micro-controllers. It works pretty much the same as a web forum: when a client publishes a message under a topic, all the clients which had subscribed to this topic get the message.
Hub: A Hub can be seen as an MQTT message broker that can be dedicated, highly-available, and scalable, and that integrates with Scaleway’s ecosystem. See IoT Hub.
Device: A Device can be seen as an MQTT client that exchanges messages with other Devices and cloud services through its Hub. It can very well be a physical device or a program. See IoT Hub Device.
Route: A Route forwards messages to non Publish/Subscribe targets. See IoT Hub Route.
Network: A Network is a front door to the IoT Hub, allowing devices to exchange messages with it. See IoT Hub Network.
Kickstart: A Kickstart is a regular Scaleway instance that has been pre-populated with an MQTT-ready application (eg a Grafana that displays MQTT stats). See IoT Hub Kickstart.
IoT Hub Operation Procedures
A Hub is the central piece to which Devices can connect to exchange messages, and by which they get access to cloud services.
Under the hood, a Hub acts as an MQTT broker, meaning devices use it to publish messages on topics or subscribe to them. Hub Routes allow Devices to push messages to other, non MQTT, services.
Hubs also provide usage metrics, see this page for more information.
How to Create a Hub
In the IoT section of the side menu, click IoT Hub. If you do not have a Hub already created, the product presentation is displayed.
1 . Click Create a Hub. The creation page displays.
2 . Enter a name for your Hub:
3 . Choose the geographical region of the Hub. Currently IoT Hub is available in our Paris region, with other regions to follow:
4 . Choose a product plan for your Hub. There are currently 3 product plans for Hubs:
Shared plan: This is a cost-effective, straightforward plan. Good for proofs-of-concept or DIY projects. The price is kept low by sharing resources between users, but it is therefore forbidden to use MQTT features which require memory (no messages with
QoS1,QoS2,retainedand no anonymous devices). Although this plan does not limit the number of devices, you will be billed for devices exceeding the number allowed within the free tier.Dedicated Plan: This plan offers dedicated resources for the Hub, which means more predictable performances and full support of the MQTT protocol.
HA Plan: Not only are resources dedicated to the Hub, but they are also replicated so that the broker is highly available. This setting is ideal for workloads that require greater robustness for their Hub.
5 . Click Create a Hub or Create a Hub and Add a Device.
If you want to add directly a first device to the hub, click Create a Hub and Add a Device and continue with the documentation IoT Hub - Devices
Once the hub is created, read how to:
- Add devices to the hub
- Check IoT Hub metrics
- Interact with the Scaleway Ecosystem using IoT Hub Routes.
How to Delete a Hub
1 . From the IoT Hub section click on the IoT Hub that you want to delete.
2 . On the Hub details page, click Delete Hub:
Important: Note that this will also delete any Device added to the Hub.
3 . Confirm the deletion by typing the word DELETE in the pop-up window and confirm by clicking on Delete this Hub.
It is also possible to delete multiple Hubs at once by selecting them in the Hub list.
How to Disable/Enable a Hub
1 . From the IoT Hub section of the Scaleway console, click on the hub that you want to disable or enable.
2 . On the Hub details page, click on the Enabled/Disabled toggle.
3 . Confirm the status change in the popup window.
Important: As long as a Hub is disabled it will not be billed, but its Devices won’t be able to connect.
How to Change Hub product plan
To change your Hub product plan, you must disable your Hub. See the previous section on how to disable a Hub.
1 . From the IoT Hub section of the Scaleway console, click on the hub that you want to change plan.
2 . Click Change Plan button.
3 . Choose the new Product Plan to apply to your Hub.
4 . Click on Update Plan button.
Once done, you need to re-enable your Hub.
IoT Hub Events
You can receive your Hub Events (including errors, activity reports, events, …) through MQTT, as explained here: IoT Hub events.
Providing your own Certificate Authority
When creating a Hub, a certificate authority will be automatically created and a certificate will be issued for each Device subsequently added. However, you can opt for the Hub to use a custom certificate authority, to enable more complex scenarios.
Important:
- If the Hub’s certificate authority is changed to a custom one, this action is definitive. It is not possible to reinstate the original Scaleway-managed PKI at a later point.
- If a Hub has devices, their certificates will be deleted. This means that to connect again using mTLS, new certificates must be generated for each device, and signed by the provided certificate authority.
Note: As a security measure to protect certificates, Scaleway does not store the private keys of custom certificate authorities. Therefore the Hub won’t issue certificates for a custom certificate authority.
When using a custom certificate authority, devices must present the whole certificate chain, including the certificate authority. Failing to present the complete chain will result in a disconnection during the TLS handshake. Device are identified by the Common Name (CN) taken from the device certificate. If a device of the same name does not exist inside the target Hub, it will be disconnected unless device auto-provisioning is set up (see the next section).
Switching to a custom certificate authority has several benefits:
- It allows for a greater flexibility, by allowing different key sizes & algorithms.
- It enables industrial usage.
To change your Hub certificate authority, you must disable your Hub. See the section on how to disable a Hub.
1 . From the IoT Hub section of the Scaleway console, click on the hub on which the certificate authority should be installed.
2 . Prepare the CA certificate and a proof of possession certificate. A proof of possession is needed to prove that you own that certificate authority and possess its private key, without sending the private key over the network. This helps to protect the CA certificate from being reused by malicious actors after a hub has been deleted, as certificates alone are public by nature. To generate a proof of possession, sign a certificate having the target Hub ID (that looks like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) as Common Name using the CA certificate.
3 . Find the Add a Certificate Authority section of the page.
4 . Input your CA certificate pem file.
5 . Input your verification (proof of possession) certificate pem file.
6 . Click on Save button.
Once done, you need to re-enable your Hub.
Note: Once the CA is uploaded, all existing devices will have their scaleway certificates deleted, as they won’t match the newly installed certificate authority. You will need to generate new certificates for those devices for them to be able to connect again.
How to enable Device Auto-Provisioning on a Hub
Enabling device auto-provisioning will automatically create missing devices in your Hub when they supply valid TLS information. The certificate chain will be verified against the custom certificate authority of the target hub. If there is no device having the same name as the device certificate Common Name (CN), a device with that CN will be created on this Hub.
This enables industrial use cases, where the secure element provider issues certificates itself on its production lanes, and burns them directly into the chips. The secure element provider will use intermediate certificates signed by a certificate authority, which together with the generated certificate will create a full TLS certificate chain. After installing the certificate authority in a Hub and enabling device auto-provisioning, the previously unseen device will be able to connect to the Hub without having to manually provision it. In this use case, the common name of the generated certificate will be the serial number of the secure element.
Created devices have the following properties:
- Name: Equal to the Common Name of the device certificate.
- Description: A message that states the IP address that provisioned the device.
- Message filters: None, all messages & subscriptions allowed.
- Allow insecure: False. As the security relies on the use of mTLS, it’s not possible to connect with this device using insecure connections.
- Allow multiple connections: False. The certificate should represent a unique physical device.
To enable the device auto-provisioning, you must have a custom certificate authority on your hub. See the previous section on how to install a custom certificate authority.
1 . From the IoT Hub section of the Scaleway console, click on the hub on which to enable the device auto-provisioning.
2 . Find the Device Auto-Provisioning section of the page.
3 . Toggle the feature on.
When auto-provisioning is enabled, IoT Hub will try to add new devices upon first connection. A Hub events will be raised upon success or failure.
IoT Hub Limitations
mqtt messages payload:
MQTT messages payload is limited to 4MiB maximum.
Hub reserved memory:
The total memory reserved per Hub to store the retained, inflight and will messages currently is 140MiB. If you need more memory, please contact us to work out a solution.
Note: Only Dedicated and HA Hubs can be used to send retained messages. Please see the Shared Hub documentation for more information.
Quotas: (please contact us if you need more)
| Â | Shared plan | Dedicated plan | HA plan |
| Maximum number of Hubs per account | 5 | 50 | 50 |
| Maximum number of Devices per Hub | 10k | 10k | 10k |
| Maximum number of Routes per Hub | 100 | 100 | 100 |