Handling of IDs

Concept of ID-less communication

The MQTT implementation of Cumulocity IoT is specifically designed for device communication. Therefore, it tries to remove as much unnecessary logic from the client side as possible.

Using the REST (or SmartREST) protocol requires to know the ID of every object, alarm and operation you want to update. Hence, a client must keep a state of these IDs. For example, if it creates an alarm, it must know the ID of the alarm so it can clear it afterwards.

With the MQTT implementation we want to reduce the logic required on the device to do such actions and move the logic to the server.

Example 1: ID of the device

You must know the ID of the device object to update data in it via REST. Also, this ID is required for every other data that needs to be associated with the device, for example, the source in a measurement, alarm or event.

To remove the necessity of persisting the ID on the device, Cumulocity IoT offers the identity API where you can link external IDs (for example a serial number) to the object, so you can query the ID any time.

A typical device start looks like this:

REST Receiving Device ID

With MQTT, we automatically use the identity API with the MQTT clientId. This removes the necessity to tell the ID to the device, and because the client sends also the other data on this connection, we can associate every measurement, alarm, event, and so on with the correct device.

MQTT Automatically Resolve ID

Example 2: ID of alarms

When a client creates an alarm using the REST API, it must ensure that it gets the ID of the alarm that was generated by Cumulocity IoT in return.

The client will need this ID to later update the alarm, for example, to status CLEARED, if the alarm is not active anymore.

REST Handling Alarms

In Cumulocity IoT, a device can only have a single alarm per type in status ACTIVE. If it creates another alarm with the same type, it will get de-duplicated. Therefore, the MQTT implementation uses the type of an alarm as identifier. The client must only send which type of alarm has been resolved, and the server will find the correct alarm object.

MQTT Handling Alarms