Xcellhost IoT Hub has been natively developed with the MQTT protocol. Nevertheless, we also support other IoT communication protocols such as Sigfox or LoRa to let you build your applications and give value to your data no matter how your device communicate with the cloud. These connections between your devices and the message broker are called IoT Networks.

A virtual device is a representation of a device or an application that is connected to the cloud. Through a Hub, the virtual device exchanges messages with other Devices and cloud services. Devices use the MQTT protocol to send and receive messages with the Hub. The Hub provides per-device usage metrics, security, and filters.

Xcellhost IoT Hub is compatible with other elements of the Xcellhost ecosystem and with other cloud provider or third party applications.  The IoT Routes provide a gateway between these cloud services and your IoT Hub. Several IoT Routes can be currently used:
Object Storage, to store your metrics in a S3 compatible Object Storage Bucket.
Database, to store your connected objects received information in a PostgreSQL database.
REST routes give you millions of possibilities to connect with either your instances, your Serverless functions or with third party applications.

Each Device has a unique identifier that is used both for API calls and for MQTT connections (as the MQTT Client Identifier). To obtain a secure communication between a Hub and a Device, the MQTT connection may be protected by TLS. Any Device can use TLS to connect, but it is possible to bypass it: this is the allow/deny insecure toggle. There are three modes of connection: Mutual-authentication TLS, Server-authentication TLS or Plain (no security).

The Hub can be asked to keep a copy of the last message published on a topic. In such case, a subscriber will immediately receive it upon subscription. This is called a retained message and allows to keep track of the last known state of your system. In this case the publisher of message will asked the Broker to keep this message in memory by adding a Retain flag in the message. Any subscriber will immediately receive the last memorized message published on the subscribed topic.

MQTT’s Quality of Service levels determine how the relationship between the sender and the receiver should unfold when they are communicating.
Three levels exist in the protocol:
QoS 0 – “At most once”, also known as “fire and forget”, the message is not guaranteed to be received by the receiver
QoS 1 – “At least once”, this level guarantees that a message sent will be received but doesn’t prevent it from being received multiple times
QoS 2 – “Exactly once”: This level of service guarantees that the message sent won’t be received multiple times

Message filters allow you to control which topics a device can publish and subscribe to. There is a publish filter and a subscribe filter, each filter operates independently. You can either accept topics in the list (and reject others) or reject topics in the list (and accept others). Topics in the lists may contain MQTT wildcards.

Metrics can be displayed at your Hub level or at your devices level and they give a complete report of the usage of your assets. The metrics interface includes a message counter and your devices activity overview over a chosen period of time.