Re: [IoT] Registering Device Types through APIs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [IoT] Registering Device Types through APIs

Chathura Ekanayake
Few comments inline..

On Sun, Jun 4, 2017 at 6:22 PM, Ayyoob Hamza <[hidden email]> wrote:
Hi All,
 
I did a POC to implement the $subject.
 
How to register a device type?
1) Create A Device Type:

curl -X POST http://localhost:8280/api/device-mgt/v1.0/admin/device-types -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"name": "firealarm","deviceTypeMetaDefinition": {"properties": ["buildingId", "floorId"],"features": [{"code": "bulb","name": "control bulb","description": "on the bulb"},{"code": "ring","name": "ring","description": "this can be used test"}],"claimable": true,"pushNotificationConfig": {"type": "MQTT","scheduled": false},"policyMonitoringEnabled": false,"description": "this is a new remote control firealarm", "initialOperationConfig": {"operations": ["bulb"]}}}'
 
2) Create Event Definition 

curl -X POST http://localhost:8280/api/device-mgt/v1.0/events/firealarm -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"eventAttributes": {"attributes": [{"name": "temperature","type": "DOUBLE"},{"name": "status","type": "STRING"},{"name": "humidity","type": "FLOAT"}]},"transport": "MQTT"}'

As events published by a device type is a configuration of the device type itself, can we add this to the create device type method, instead of having a separate method for creating event definitions.
 
 
How to enroll a device 
 
curl -k -X POST https://localhost:8243/api/device-mgt/v1.0/device/agent/enroll -H 'accept: application/json' -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{ "name": "myhomealarmx1", "type": "firealarm", "description": "this alarm is placed in my house", "deviceIdentifier": "123422", "enrolmentInfo": {"ownership": "BYOD", "status": "ACTIVE", "owner": "admin"} ,"properties": [{"name": "buildingId","value": "wso2"}, {"name": "floorId","value": "2"}]}'

Does this return a token, which can be used by the device for subsequent interactions with the server? (i.e. device owner can embed such token in the device)
 
 
How to send operation from server

curl -X POST http://localhost:8280/api/device-mgt/v1.0/devices/firealarm/operations -H 'accept: application/json' -H 'authorization: Bearer 7e5cad0f-cf78-3981-b50e-db9d674fb741' -H 'content-type: application/json' -d '{"deviceIdentifiers":[123422],"operation":{"code":"ring","type":"CONFIG", "payLoad":"volume:30%"}}'
 
How to retrieve operation for the device 

HTTP
curl -k -X GET https://localhost:8243/api/device-mgt/v1.0/device/agent/pending/operations/firealarm/123422 -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json'
 
MQTT 
topic: carbon.super/firealarm/123422/operation/#

How to send a response to the operation from the device?

HTTP
curl -k -X PUT https://localhost:8243/api/device-mgt/v1.0/device/agent/operations/firealarm/123422 -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{"id": 1,"status": "COMPLETED", "payload": "this is my response"}'
 
MQTT
topic: carbon.super/firealarm/123422/update/operation
Payload: {"id": 1,"status": "COMPLETED", "operationResponse": "this is my response"}

How to send data from the device?

HTTP
curl -k -X POST https://localhost:8243/api/device-mgt/v1.0/device/agent/events/publish/firealarm/123422 -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{"temperature":10,"status":"workingh","humidity":20}'             
 
MQTT
topic: carbon.super/firealarm/123422/events
  payload: {"temperature":10,"status":"working","humidity":20}
 
How to read data from the device?

History: 
curl -k -X GET 'https://localhost:8243/api/device-mgt/v1.0/events/firealarm/123422?offset=0&limit=100&from=1496534699000&to=1496577899000' -H 'authorization: Bearer 7e5cad0f-cf78-3981-b50e-db9d674fb741' -H 'content-type: application/json'
 
Last Known:
curl -k -X GET 'https://localhost:8243/api/device-mgt/v1.0/events/last-known/firealarm/123422' -H 'authorization: Bearer 7e5cad0f-cf78-3981-b50e-db9d674fb741' -H 'content-type: application/json'

Architecture

we have extended the existing Java API on CDMF as jax-rs API. A device type author can consume the low-level jax-rs APIs and write their own developer friendly APIs and deploy in on an external server or they can use the exposed low-level API directly. 

I think we can recommend using the provided JAX-RS API and provide SDKs for different platforms to program against this API. SDK can support basic operations such as get operations, publishing data, etc.

 



Generic UI Support for Device Types
we have created set of default UI unit(given below) on top of the common APIs. It is also possible to create their own UI in an external server by consuming the product APIs.
  • Device Type View
  • Device View
  • Device Operation View
  • Device Event View(Acts as a data explorer for the device data)
  • Device Type Policy View
  • Device Type Add & Edit View

Device Type Add & Edit View

Dashboard

Create Device Type


Edit Device Type


Edit Device Event 


Device Type View



Device View


Device Operation View



Device Events View

Device Type Policy View




I have completed the implementation and the code is available on [1], [2] and [3] (There are few UX issues that need to be fixed).


[1] https://github.com/ayyoob/carbon-device-mgt/tree/devicetype-3.1.0

[2] https://github.com/ayyoob/carbon-device-mgt-plugins/tree/devicetype-3.1.0

[3] https://github.com/ayyoob/product-iot-server/tree/devicetype-3.1.0


Thanks

Ayyoob Hamza
Senior Software Engineer
WSO2 Inc.; http://wso2.com
email: [hidden email] cell: <a href="tel:%2B94%2077%207779495" value="+94777779495" style="color:rgb(17,85,204)" target="_blank">+94 77 1681010

--
You received this message because you are subscribed to the Google Groups "WSO2 IoT Team Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/a/wso2.com/d/optout.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IoT] Registering Device Types through APIs

Ayyoob Hamza

 
How to register a device type?
1) Create A Device Type:

curl -X POST http://localhost:8280/api/device-mgt/v1.0/admin/device-types -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"name": "firealarm","deviceTypeMetaDefinition": {"properties": ["buildingId", "floorId"],"features": [{"code": "bulb","name": "control bulb","description": "on the bulb"},{"code": "ring","name": "ring","description": "this can be used test"}],"claimable": true,"pushNotificationConfig": {"type": "MQTT","scheduled": false},"policyMonitoringEnabled": false,"description": "this is a new remote control firealarm", "initialOperationConfig": {"operations": ["bulb"]}}}'
 
2) Create Event Definition 

curl -X POST http://localhost:8280/api/device-mgt/v1.0/events/firealarm -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"eventAttributes": {"attributes": [{"name": "temperature","type": "DOUBLE"},{"name": "status","type": "STRING"},{"name": "humidity","type": "FLOAT"}]},"transport": "MQTT"}'

As events published by a device type is a configuration of the device type itself, can we add this to the create device type method, instead of having a separate method for creating event definitions.
 
I had the same doubt while implementing this but had to do this because of two reasons

1) Above event defintiion api call creates a stream, event sink, event purge and a websocket publisher. Since this is part of analytics flow had to separate the api call. 

2) we don't maintain the stream definition as part of device type definition in the device management layer(AFAIK, upto now we didnt had a requirement todo so, earlier we tried todo this as part of sensor management but event defniniton might not depend only on sensor definition). In addition, I seperated the api calls to avoid transaction failures, since these are two separate systems
 
 
How to enroll a device 
 
curl -k -X POST https://localhost:8243/api/device-mgt/v1.0/device/agent/enroll -H 'accept: application/json' -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{ "name": "myhomealarmx1", "type": "firealarm", "description": "this alarm is placed in my house", "deviceIdentifier": "123422", "enrolmentInfo": {"ownership": "BYOD", "status": "ACTIVE", "owner": "admin"} ,"properties": [{"name": "buildingId","value": "wso2"}, {"name": "floorId","value": "2"}]}'

Does this return a token, which can be used by the device for subsequent interactions with the server? (i.e. device owner can embed such token in the device)
Is'nt it enrollment of a device and token generation are two different task ?. This is why in Device Type View UI I have listed the command to generate token.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IoT] Registering Device Types through APIs

Ayyoob Hamza
In reply to this post by Chathura Ekanayake


I think we can recommend using the provided JAX-RS API and provide SDKs for different platforms to program against this API. SDK can support basic operations such as get operations, publishing data, etc.
+1, Since we have a clear contract for the devices that uses http and mqtt transport. I was searching for an api specification tool similar to swagger[1] which supports both HTTP and MQTT, This would ease out the process on creating SDKs for different language. I found [2] but its not matured as swagger yet. Therefore I think the best approach for now would be to handle http transport flow through swagger code gen and mqtt(+http) flow through our own implementations.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IoT] Registering Device Types through APIs

Chathura Ekanayake
In reply to this post by Ayyoob Hamza


On Mon, Jun 5, 2017 at 4:35 PM, Ayyoob Hamza <[hidden email]> wrote:

 
How to register a device type?
1) Create A Device Type:

curl -X POST http://localhost:8280/api/device-mgt/v1.0/admin/device-types -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"name": "firealarm","deviceTypeMetaDefinition": {"properties": ["buildingId", "floorId"],"features": [{"code": "bulb","name": "control bulb","description": "on the bulb"},{"code": "ring","name": "ring","description": "this can be used test"}],"claimable": true,"pushNotificationConfig": {"type": "MQTT","scheduled": false},"policyMonitoringEnabled": false,"description": "this is a new remote control firealarm", "initialOperationConfig": {"operations": ["bulb"]}}}'
 
2) Create Event Definition 

curl -X POST http://localhost:8280/api/device-mgt/v1.0/events/firealarm -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"eventAttributes": {"attributes": [{"name": "temperature","type": "DOUBLE"},{"name": "status","type": "STRING"},{"name": "humidity","type": "FLOAT"}]},"transport": "MQTT"}'

As events published by a device type is a configuration of the device type itself, can we add this to the create device type method, instead of having a separate method for creating event definitions.
 
I had the same doubt while implementing this but had to do this because of two reasons

1) Above event defintiion api call creates a stream, event sink, event purge and a websocket publisher. Since this is part of analytics flow had to separate the api call. 

2) we don't maintain the stream definition as part of device type definition in the device management layer(AFAIK, upto now we didnt had a requirement todo so, earlier we tried todo this as part of sensor management but event defniniton might not depend only on sensor definition). In addition, I seperated the api calls to avoid transaction failures, since these are two separate systems

IMO both above are implementation details. It is better if an external user who is creating a device type doesn't need to worry about it. In the current API call user can provide properties and operations of a device type. If the user can provide data that will be published by the device type as well in the same config, I think it will make it more complete.
 
 
 
How to enroll a device 
 
curl -k -X POST https://localhost:8243/api/device-mgt/v1.0/device/agent/enroll -H 'accept: application/json' -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{ "name": "myhomealarmx1", "type": "firealarm", "description": "this alarm is placed in my house", "deviceIdentifier": "123422", "enrolmentInfo": {"ownership": "BYOD", "status": "ACTIVE", "owner": "admin"} ,"properties": [{"name": "buildingId","value": "wso2"}, {"name": "floorId","value": "2"}]}'

Does this return a token, which can be used by the device for subsequent interactions with the server? (i.e. device owner can embed such token in the device)
Is'nt it enrollment of a device and token generation are two different task ?. This is why in Device Type View UI I have listed the command to generate token.

In that case, we have to provide an API to get a token by providing the device identifier and the device identifier has to be returned from the above call.
 


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IoT] Registering Device Types through APIs

Imesh Chandrasiri
Hi Ayoob,

We will go through the provided screens and come up with a UXD as soon as possible. Will contact you for any clarifications.

On Tue, Jun 6, 2017 at 10:52 AM, Chathura Ekanayake <[hidden email]> wrote:


On Mon, Jun 5, 2017 at 4:35 PM, Ayyoob Hamza <[hidden email]> wrote:

 
How to register a device type?
1) Create A Device Type:

curl -X POST http://localhost:8280/api/device-mgt/v1.0/admin/device-types -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"name": "firealarm","deviceTypeMetaDefinition": {"properties": ["buildingId", "floorId"],"features": [{"code": "bulb","name": "control bulb","description": "on the bulb"},{"code": "ring","name": "ring","description": "this can be used test"}],"claimable": true,"pushNotificationConfig": {"type": "MQTT","scheduled": false},"policyMonitoringEnabled": false,"description": "this is a new remote control firealarm", "initialOperationConfig": {"operations": ["bulb"]}}}'
 
2) Create Event Definition 

curl -X POST http://localhost:8280/api/device-mgt/v1.0/events/firealarm -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H 'content-type: application/json' -d '{"eventAttributes": {"attributes": [{"name": "temperature","type": "DOUBLE"},{"name": "status","type": "STRING"},{"name": "humidity","type": "FLOAT"}]},"transport": "MQTT"}'

As events published by a device type is a configuration of the device type itself, can we add this to the create device type method, instead of having a separate method for creating event definitions.
 
I had the same doubt while implementing this but had to do this because of two reasons

1) Above event defintiion api call creates a stream, event sink, event purge and a websocket publisher. Since this is part of analytics flow had to separate the api call. 

2) we don't maintain the stream definition as part of device type definition in the device management layer(AFAIK, upto now we didnt had a requirement todo so, earlier we tried todo this as part of sensor management but event defniniton might not depend only on sensor definition). In addition, I seperated the api calls to avoid transaction failures, since these are two separate systems

IMO both above are implementation details. It is better if an external user who is creating a device type doesn't need to worry about it. In the current API call user can provide properties and operations of a device type. If the user can provide data that will be published by the device type as well in the same config, I think it will make it more complete.
 
 
 
How to enroll a device 
 
curl -k -X POST https://localhost:8243/api/device-mgt/v1.0/device/agent/enroll -H 'accept: application/json' -H 'authorization: Bearer 34670364-56c8-3f25-ac04-5c01af28c6d1' -H 'content-type: application/json' -d '{ "name": "myhomealarmx1", "type": "firealarm", "description": "this alarm is placed in my house", "deviceIdentifier": "123422", "enrolmentInfo": {"ownership": "BYOD", "status": "ACTIVE", "owner": "admin"} ,"properties": [{"name": "buildingId","value": "wso2"}, {"name": "floorId","value": "2"}]}'

Does this return a token, which can be used by the device for subsequent interactions with the server? (i.e. device owner can embed such token in the device)
Is'nt it enrollment of a device and token generation are two different task ?. This is why in Device Type View UI I have listed the command to generate token.

In that case, we have to provide an API to get a token by providing the device identifier and the device identifier has to be returned from the above call.
 

--
You received this message because you are subscribed to the Google Groups "WSO2 IoT Team Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/a/wso2.com/d/optout.



--
Thanks and Best Regards,
Imesh Ashandimal Chandrasiri
Software Engineer
WSO2, Inc. 
lean . enterprise . middleware
E: [hidden email] | P: 0716519187


Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture