Concept of ID-less communication
The MQTT implementation of Cumulocity is specifically designed for device communication and therefore tries to remove as much unnecessary logic from the client side.
Using the REST (or SmartREST) protocol requires to know the ID of every object, alarm and operation you want update. Therefore a client needs to keep state of these IDs for example if it creates and alarm it needs to 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
To update data in the device object via REST you need to know the ID of the device object. Also this ID is required for every other data that needs to be associated with the device e.g. the source in a measurement, alarm or event. To remove the necessity of persisting the ID on the device Cumulocity offers the identity API where you can link external IDs (e.g. a serial number) to the object so you can query the ID any time. Therefore a typical device start looks like this:
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, ... with the correct device.
Example 2: ID of alarms
When a client creates an alarm using the REST API it needs to ensure that it gets the ID of the alarm that was generated by Cumulocity 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.
In Cumulocity a device anyways can have only 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 only needs to send which type of alarm has been resolved and the server will find the correct alarm object.