How to receive cumulocity real time notifications with SmartREST?

Question

We use the cumulocity REST API. Regular real time notifications work, e.g. we subscribe to /alarms/*, start our connection/polling loop and when we create an alarm we receive the expected JSON. We did not install any specific modules or statements, it just works. But when we try to do the same with SmartREST we receive this error, as soon as the alarm is created:

40,,/alarms/177649296,Could not find any templates subscribed for the channel

Following the reference guide (http://cumulocity.com/guides/reference/smartrest/) we tried it like this, where all requests have the same X-Id-header and all requests result in the expected http status 200 and no error messages, except for the last one:

1. Register a smart response template by doing a POST to /s
   Body: 11,102,,,$.channel
2. Handhake: POST to /cep/realtime
   Body: 80 Response is our clientId (e.g. 191het1z38bp7iq1m96jqqt8jnef)
3. Subscribe: POST to /cep/realtime
   Body: 81,191het1z38bp7iq1m96jqqt8jnef,/alarms/*
4. Connect: POST to /cep/realtime
   Body: 83,191het1z38bp7iq1m96jqqt8jnef

In the normal REST case the notification consists of a JSON array with 2 elements, both of which have a property "channel". So that is what we would expect from our response template. Instead, we get the aforementioned error 40.

Is our response template wrong? Is it not properly matched by the X-Id? What does it mean, that there are no "templates subscribed for the channel"? The subscriptions are done for a clientId, and not for a specific response template, and the templates are supposed to be matched automatically anyway. So probably "template" means "X-Id" here? The documentation seems ambiguous as to the meaning of that word. But anyway, we did use the same X-Id header in all of the requests.

Any pointer about what we're doing wrong would be appreciated, since we tried pretty much anything by now.

Answer 1

The SmartREST protocol was developed for a IoT-device <-> platform communication. So there was never any design around using it to subscribing to realtime data (except of course for the operations a device needs) as usually devices to not need subscribe to the data that they created themselves.

That said it is possible to use it but with a couple of limitations. Your approach is basically correct but there is one problem with the subscription. The wildcard subscriptions will not work with SmartREST because on subscription it links your X-Id with the channel you subscribed to but there is never a message published on the channel /alarms/*. Thus this kind of weird error message that said that there was no template subscribed for the channel the alarm appeared on. Inside CometD you still receive the alarm because of the wildcard subscription but the SmartREST part does not work.

The messages are published on the channel with the deviceId (e.g. /alarms/12345). If you subscribe to /alarms/12345 it will work. You can of course subscribe to as many channels as you want but wildcard subscription won't work.

Regarding the templates you need to know the following. The SmartREST parsing is not done on the raw JSON of CometD but on the payload inside it (e.g. the alarm). So a template for an alarm could look like this:

11,500,,$.severity,$.id,$.type,$.severity

This would trigger only if the object has a severity and would return id, type and severity.