Smart REST Template - Cumulocity web interface

Hello,

I am testing smart Rest by pushing an API call from python and I am receiving:
Response: 41,1,Bad response template definition

what should be filled exactly in the smart rest request and response template when creating it via Cumulocity’s web interface if the json output is similar to the following:

Hi,

there is a static template for exactly your payload here: Static Template - 401 - Location Updates . So you do not have to compose your own template, you can just publish:

topic: s/us
msg: 401,<your latitude as float>,<longitude as float>,<altitude as float>

Just for completeness, this is how the smart rest templates would look like in the Web UI:


and you would use it with:

topic: s/uc/kobu-1
msg: 10,<optional time, server time if empty>,<altitude float>,<longitude float>,<latitude float>

But as stated, no need to create that one, instead use the 401 template available on topic s/us.

thanks, i Also need to specify the ID (which is the device ID) additionally to lat,lng,alt and time just like the json output of a regular REST. does it mean that 401 template will not be enough for my case?

thanks for providing an example for the request template, thats exactly what I tested but still getting “41,1,Bad response template definition” as a reply. would you please provide your input about response template part which would convert on the proxy the REST (JSON) to smart REST (CSV)?

not sure if it is a bad response template or the received message is missleading since I don’t see the event created even after receiving back 200 response code and “41,1,Bad response template definition” as the message

by the way I am using a python code as the smart rest client during the initial test

Smart Rest is ID-less, so you don’t need to state the device-id in your requests. Instead, it correlates the proper Cloud-Device based on your MQTT Client ID. That’s the case for both, static- and custom templates. You can read more about this here: Handling of IDs - Cumulocity documentation

So maybe let’s go one step back and start from the beginning:

  1. Delete the Device in your tenant so that we start fresh
  2. Execute the following steps in your script:
# 1. Connect your Client with an arbitrary (but unique) client ID. Often the serial number of your device is used. 

# 2. Create the device via below message. 
# After that one you'll find a device created in your Cumulocity Tenant. Go to the devices 'identity' tab, you'll find your MQTT Client ID registered as `c8y_Serial` there.
send message: topic=s/us, message=100,your-device-name,your-device-type

# 3. We should make sure the device-creation message is the first message arriving on platform side, so let's do a sleep of 5 seconds
sleep(5)

# 4. Let's send a location update via below message now
# On Cloud side you'll find a new event in the 'events' tab
send message: topic=s/us, message=401,<latititude>,<longitude>,<altitude>

# 5. Optionally, create a child-device with below message:
# Once the message is sent (and your browser UI is updated), you'll find a new device listed in 'child-devices' tab
send message: topic=s/us, message=101,<unique child Id>,<child device name>,<child device type>,true

# 6. Optionally, let's send a location update to that child-device
# After message is sent, you'll find a location update event on your child-device you created in step 5
# Note the last token in the topic, that one is used to route it to proper child-device
send message: topic=s/us/<your unique child id from step 5>, message=401,<latititude>,<longitude>,<altitude>

Regarding the response templates in custom templates: you only need a smart rest response template for querying data from the cloud. As you want to do PUTs/POSTs here, I didn’t configure any, you don’t need it here. In general its a good practice to let your devices only push data and minimize the needs for querying data.

As general pointers:

  • Make sure you’ve read the ID-less concept linked above. It’s important to understand (and really convenient as your device does not need to bother around with source-/device ids)
  • For every message you send, first check if there’s a static template available here: MQTT Static templates - Cumulocity documentation . If yes, use that one, they are available on s/us topic
  • If you need custom smart rest templates: The request templates are for PUTs/POSTs, the response templates are only needed to query data

And another important note, if you’re doing a new device integration I highly recommend you to look at https://thin-edge.io/ & Overview | Thin-edge . It is a lightweight framework to ease your device-integration. It needs either a Linux OS or a container runtime being available on your device/gateway.

With that one you’ll only need to send your data to a local MQTT broker and thin-edge.io takes care of transmitting it to the Cloud via MQTT. It also comes with out of the box functionality for topics like device configuration, service monitoring, logfile management, remote software/firmware updates and certificate handling.
If your device/environment fulfills the prerequisites, I wouldn’t see a reason to implement my own Client => Cloud connectivity, I’d use thin-edge instead.

// Edit: if you’d like to play with it, you’ll find installation instructions in the thin-edge docs. Additionally, here is a demo container showcasing thin-edge and it’s feature set: GitHub - thin-edge/tedge-demo-container: thin-edge.io demo container setup to showcase thin-edge.io and all its features .

Thanks for the valuable details and for your will to help, appreciated.

allow me to clarify that we have a public instance on the cloud, as far as i know the new Cumulocity MQTT Service will be publicly available on our public cloud instances in few weeks and it is not available right now

in addition the MQTT packets are received from the positioning engine (which is the publisher/broker) → we receive them on a middleware → from there we were doing REST API calls for every device ID → now with smart REST we are trying to push multiple device IDs lines together using CSV

2nd part: I agree with you that with POST/PUT I don’t need the answer, but how to get rid of this “41,1,Bad response template definition” when I do a post using smart REST? how to remove the response template from being a road block? Initially I didn’t have any response template created and I created it after seeing the “41,1,Bad response template definition” message, my priority for now to see the event created on Cumulocity which is still not happening

for your reference providing the very simple python code issuing smart rest API call (POST):

import requests

# Define the Smart REST API endpoint
url = "https://xxx.emea.cumulocity.com/smartrest/1001"  # '1001' is our Smart REST template ID


headers = {
    "Authorization": "Basic TVFUVxxxAAAAA", credentials
    "Content-Type": "text/plain"  # Smart REST generally uses plain text payloads
   
}

# Smart REST payload (formatted as per the template)
# Message ID 10 followed by time,altitude,longitude,latitude,sourceId,
payload ="10,2025-05-1T00:00:47.000+02:00,0,55.2957114,25.1878645,7742688525"

# Perform the POST request
try:
    response = requests.post(url, headers=headers, data=payload)
    
    # Check response status
    if response.status_code == 200:
        print("Request successful!", response.status_code)
        print("Response:", response.text)
    else:
        print("Error:", response.status_code)
        print("Response:", response.text)
except Exception as e:
    print("An error occurred:", e)

and that is our template:

Finally just by curiosity why I am receiving response code 200 for the API call is the undelying message payload contains 41 error code which indicates that the post was not successful

I think I would need more info on the big picture here. If I understood correctly:

  • You’re having an MQTT broker that is already receiving data from many different devices

  • You’re having already a Client that reads from your broker and creates the measurements/events/alarms in Cumulocity. This is done via the Platforms HTTP/REST APIs

  • Now you’d like to change this implementation to use Smart Rest over HTTP instead of the “standard” REST APIs.

My questions would be:

  1. Is this understanding correct?

  2. What is your motivation to move over from REST to Smart Rest? (Especially, having the “SmartREST 1.0 will be maintained by Cumulocity but no longer actively developed” note from here in mind)

  3. Typically, the majority of data is telemetry data. Are you aware that the standard Measurement API allows to post measurements from multiple devices altogether in one API call?

  4. You mentioned the upcoming MQTT Service, are you planing to move to that one and this would be just an intermediate solution here?

  5. Where is this broker located? Is network bandwith/traffic important (I guess no as it’s not in mobile connection)? Asking this to judge if MQTT or HTTP is the better choice.

thanks

  1. Yes your understanding is correct
  2. the motivation is streamlining multiple location updates events in one smart REST API Call instead of 1 REST API call for every location update
  3. here we are posting location update events not measurements
  4. Yes in the long run but for now I need to find a solution
  5. Broker is located on-prem just like the python middleware while cumulocity is on a public instance, a delay of 100ms network RTT is between the middleware and cumulocity and each API call takes around 600ms

The main question here: is smart REST a good fit for our requirement? and if not, is there a way to send multiple location update events in the same POST?

Hi @GII ,

okay, if you are using Smart Rest over HTTP here, you are using Smart Rest 1. Smart Rest 1 has been superseded by Smart Rest 2. One reason is that SR1 is noticeable slower than your other options - so I would really not recommend you continuing this route here, especially when you target high throughput.

Instead, I see three options:

  1. Continue with your current integration - which is using the standard HTTP/REST API between your Broker and Cumulocity. There is no endpoint to ingest multiple events at once, but that should not be any issue (just make sure to have proper threading in your client)
    I really doubt your parallel Max retries exceeded SSL issue is related to this. That should be treated as a separate issue, “doing batch import” probably won’t fix this.

  1. Use Smart Rest 2 via MQTT, do batch-import via the 401 CSV template but have in mind:
  • All events in your batch needs to be from the same Device
  • It requires your Devices being child-devices (but once you add c8y_IsDevice to a Child-Device, it will be treated like any other within the tenant)

  1. Same as 2, but use the event/events/createBulk topic from Json-via-Mqtt API. Also here, batching is supported but - as the device identifier is part of your topic - all events in your batch need to be from the same source.

1 Like