What is the exact use case for the response templates

[sumit.singh]

What product/components do you use and which version/fix level?

1011.0.12

Are you using a free trial or a product with a customer license?

What are trying to achieve? Please describe in detail.

https://cumulocity.com/guides/reference/smartrest-one/#templates

We currently receive measurements and some data in events and alarms section. So is there any use case for the response templates related to data in these sections… if yes can you please list it down ?

Do you get any error messages? Please provide a full error message screenshot and log file.

Have you installed latest fixes for the products

[Philipp_Emmel]

Measurements are typically sent with a fire-and-forget approach. Events and alarms are different, devices may need to update alarms at a later time. In SmartREST 1 the device needs to provide the internal ID of a resource it intends to update. Response templates are necessary to obtain this ID when the device either creates the event/alarm or when it queries for it later.

SmartREST is intentionally kept very open in terms of its capabilities, so it would be impossible for me to list all possible use cases for response templates. Generally response templates are designed for data that needs to be delivered from the platform to the device. They can be triggered as response to messages sent by the device directly or by operations that need to be delivered to the device.

I’d also recommend looking into SmartREST 2 which is improved and much easier to use than SmartREST 1

[sumit.singh]

Thanks for support @Philipp_Emmel
can you please give an example on how we can initiate a response from CC to end device for any information received in alarms & Events section?

[Philipp_Emmel]

Let’s there is a device that sends an alarm like this:

POST /alarm/alarms

{
  "source": {
    "id": "12345"
  },
  "type": "c8y_HighTemperatureAlarm",
  "text": "Machine temperature too high",
  "severity": "MAJOR",
  "time": "2022-05-18T12:00:00.000Z",
  "c8y_TemperatureInfo": {
    "currentValue": 90,
    "thresholdValue": 70
  }
}

The HTTP response when creating this alarm contains the created object including its ID. The device records this ID of later usage. Once the alarm state is resolved the device should clear the alarm it raised earlier like so using the remembered alarm ID from earlier.

PUT /alarm/alarms/<alarmID>

{
  "status": "CLEARED"
}

In order to achieve the same flow using SmartREST 1 the device requires a template collection with at least 3 templates like this:

10,100,POST,/alarm/alarms,application/json,application/json,%%,UNSIGNED NOW UNSIGNED,"{""source"":{""id"":""%%""},""type"":""c8y_HighTemperatureAlarm"",""text"":""Machine temperature too high"",""severity"":""MAJOR"",""time"":""%%"",""c8y_TemperatureInfo"":{""currentValue"":%%,""thresholdValue"":70}}"
10,101,PUT,/alarm/alarms/%%,application/json,,%%,UNSIGNED,"{""status"":""CLEARED""}"
11,1000,,$.c8y_TemperatureInfo,id

Then the device may create the alarm using the 100 template like this:

100,12345,,90

Creating this object will trigger the response template 1000 because it matches the response of created data. Then the device will receive back this message:

1000,1,23456

I’m using ‘23456’ here as example for the returned alarm ID that the 1000 response template extracts from the alarm creation response. As described in the REST API example the device records this alarm ID for later usage when the alarm state is resolved. Then it can use the 101 template to clear the alarm like so:

101,23456