Cumulocity IoT Feedback Portal
In many cases the default device registration does not work. In these cases, it would be good for protocol integrators to allow for defining their own device registration steps.
That’s the case for example for LoRa devices using the cumulocity-lora open source framework developed by @Cyril Poder . As you need to register a new connection to an LNS and a device will require some additional info such as the LNS connector to provision the device too.
I can also think of other specific platforms that we had to integrate with Cumulocity using an indirect and ugly approach in the microservice itself (by indirect I mean creating the device in Cumulocity when the microservice receives data from the device, instead of explicitly declare the device in Cumulocity to allow communication from this device).
Including LNS and Sigfox, most IoT gateways/platforms offer an API approach to define webhooks/http routing and provision devices, so I believe it would be great to generalize that approach in Cumulocity starting by the registration process.
For exemple, registering a thirdparty platform would require to define a registration process where you define a few parameters the user needs to fill in, like the URL, apikey or user and password, or more generally any kind of typed parameters and communicate the values of those parameters to a microservice. Some of those parameters would sometimes require a connection to the thirdparty system to retrieve a list of acceptable values (for example list of groups of devices).
Ideally this registration process definition should be stored as a managed object so it can be easily created by a microservice when it first starts, and easily retrieved by the UI to make it available to the user.
This is exactly the work I did in my framework, but since the Registration UI is apparently not extensible, I had to create my own UI to register LNS connectors and provision devices. It should be extensible in some way though, since Oliver team has been able to add new registration process if I’m not mistaken, but then it’s not documented or requires access to the source code, which is bad.
Short update: We do plan to improve the Device Registration Process for LWM2M devices. Our plan is to come up with a generic and documented process that can also be adapted for any custom device registration.
That’s the case for example for LoRa devices using my framework, as you need to register a new connection to an LNS and a device will require some additional info such as the LNS connector to provision the device too.
I can also think of other specific platforms that we had to integrate with Cumulocity using an indirect and ugly approach in the microservice itself (by indirect I mean creating the device in Cumulocity when the microservice receives data from the device, instead of explicitly declare the device in Cumulocity to allow communication from this device).
Including LNS and Sigfox, most IoT gateways/platforms offer an API approach to define webhooks/http routing and provision devices, so I believe it would be great to generalize that approach in Cumulocity starting by the registration process.
For exemple, registering a thirdparty platform would require to define a registration process where you define a few parameters the user needs to fill in, like the URL, apikey or user and password, or more generally any kind of typed parameters and communicate the values of those parameters to a microservice. Some of those parameters would sometimes require a connection to the thirdparty system to retrieve a list of acceptable values (for example list of groups of devices).
Ideally this registration process definition should be stored as a managed object so it can be easily created by a microservice when it first starts, and easily retrieved by the UI to make it available to the user.
This is exactly the work I did in my framework, but since the Registration UI is apparently not extensible, I had to create my own UI to register LNS connectors and provision devices. It should be extensible in some way though, since Oliver team has been able to add new registration process if I’m not mistaken, but then it’s not documented or requires access to the source code, which is bad.
Hi Cyril, could you provide a few more details on the use case at hand. Thanks!