Servitly includes an MQTT Broker that you can use to establish a direct connection with your products.

To use it, select the Servitly Thing Connector (STC) within the Connection configuration tab.

Connection Configuration

Within the Connection tab, under the editing page of a customer, location, or thing you can configure the Servitly Thing Connector by providing the following information:

• Username: the unique username used to open the MQTT connection.

• Password: the password requested during the MQTT channel authentication; it must be at least 8 characters long and it must contain at least one lower case letter, one upper case letter, and one number

Moreover, it is possible to specify the payload format, by default only JSON is available, but depending on the enabled plugins it is possible to use other formats.

ASCII and BINARY payload formats are deprecated.

Thing Connection Mapping

At the thing level, you can configure the specific mapping for the thing.

• Asset Id: an identifier of the thing. It can be the MAC address, the serial number, or any other identifier.
• Path (optional). It can be used for more structured MQTT topics, needed when under the same location multiple connected things are sharing the same gateway.

Asset Id and Path are used to compute the full topic for metric publishing and subscribing.

MQTT Broker Availability

Servitly has multiple running instances of the MQTT broker which are automatically managed to limit the downtime in case of problems, pay attention that the embedded MQTT broker service related to the STC (Servitly Thing Connector) is critical and thus subject to the availability defined by the subscribed SLA (Service Level Plan).

Publishing Limits

MQTT data points publishing rate is limited by the commercial offer and by the system for security reasons. 

Commercial limit

Within the commercial offer, the manufacturer agrees that each thing can post a certain number of data points each hour. This limit should be considered as the average between all things and data points published during the month. 

For example, if the limit is set at 600 data-points/hour, you can have one thing publishing at 200 data-points/hour and one thing publishing at 800 data-points/hour, the average is 600 data-points/hour.

And also, you can have a thing publishing from 08:00 AM to 08:00 PM at 1200 data-points/hour and from 08:00 PM to 08:00 AM at 0 data-points/hour (e.g. offline thing).

System Limit

In addition to the commercial limit, there is a system rate limit, which is higher than the previous one, and used to limit things that could publish too many data points (e.g., bugs in the firmware).

The system rate limit is verified by a bucket based on a sliding window.

A token is consumed for each data point published, and the bucket ensures a certain amount of tokens per period of time.

This means that each thing has a number of tokens it can consume in a period of time. When the thing runs out of tokens, the excess data points are discarded. Unfortunately due to the limitations of MQTT, there is no way to inform the thing that the rate limit has been exceeded.

The period is subdivided into 60 slots, each of which has a certain number of tokens depending on the overall rate limit, the default rate limit is 3600 data-points/hour, if you need more, you must contact Servitly support.

When a token is used, that token is restored (and can be used again) after the time period has passed.

In this way, one thing can post data constantly, but it can also post data points with a higher rate consuming burst of tokens, but remaining into the rate limit.

For example, suppose a limit of 3600 data points/hour, this means 3600 tokens/hour and 60 tokens available every minute. If a thing uses 600 tokens at 6:05 PM, the thing could only publish up to another 3000 data points until 7:04 PM. At 7:05 PM, the thing would get 60 tokens back and so on every minute forward.