On Mon, Jun 5, 2017 at 4:35 PM, Ayyoob Hamza <[email protected]> wrote:
> >>> >>> *How to register a device type?* >>> 1) Create A Device Type: >>> >>> curl -X POST http://localhost:8280/api/devi >>> ce-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/dev >>> ice-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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
