iotagent-node-lib
iotagent-node-lib copied to clipboard
Returning empty value from iotagent-json to Orion in case if no value is passed from Device to iotagent-json
Current behaviour As per the current behaviour of Orion, if some attribute has not passed from device to iotagent-json then in this case, Orion will assign the previous value to those attribute.
Problem: But if it is required as Orion should consider empty value i.e. "" for such attributes then currently it is not possible.
Please check the below is the example for more understanding: Device Provisioning:
curl -X POST
'http://localhost:4041/iot/devices'
-H 'Content-Type: application/json'
-H 'fiware-service: openiot'
-H 'fiware-servicepath: /'
-d '{
"devices": [{
"device_id": "device03",
"entity_name": "sensor01",
"entity_type": "sensortest",
"attributes": [{
"object_id": "wagnonNo",
"name": "wagnonNo",
"type": "int"
},{
"object_id": "ContainerNo",
"name": "ContainerNo",
"type": "int"
},{
"object_id":"macAddress",
"name": "macAddress",
"type": "string"
}]}]
}'
First time data passed from device to IOT agent:
curl -X POST
'http://localhost:7896/iot/json?i=device03&k=testkey01'
-H 'content-type: application/json'
-H 'fiware-service: openiot'
-H 'fiware-servicepath: /'
-d '{
"wagnonNo": "900",
"containerNo": "5000",
"macAddress": "84:24:8D:EE:2F:D1"
}'
2nd time data pass from device to iotagent-json
curl -X POST
'http://10.0.2.15:7896/iot/json?i=sensor01&k=testkey01'
-H 'content-type: application/json'
-H 'fiware-service: openiot'
-H 'fiware-servicepath: /'
-d '{
"wagnonNo": "901",
"macAddress": "22:54:8A:EC:2B:B6"
}'
Output at Orion after passing 2nd data as per current feature:
{
"id": "sensor01",
"type": "sensortest",
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.00Z",
"metadata": {}
},
"wagnonNo": {
"type": "string",
"value": "901",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
} }},
"containerNo": {
"type": "string",
"value": "5000",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
}}},
"macAddress": {
"type": "string",
"value": "22:54:8A:EC:2B:B6",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
}} }}
Expected output
{
"id": "sensor01",
"type": "sensortest",
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.00Z",
"metadata": {}
},
"wagnonNo": {
"type": "string",
"value": "901",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
}} },
"containerNo": {
"type": "string",
"value": "",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
}} },
"macAddress": {
"type": "string",
"value": "22:54:8A:EC:2B:B6",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-04-05T08:44:43.914Z"
} }}}
I think the current behaviour is ok in the IOTA-CB interaction.
I mean, when IOTA receives a measure from the device, it updates the attributes associated to that measure. Other attributes are left untoched in the CB.
Note this is typically the desired behaviour. Consider for instance a device able to measure tempearture and pressure, but that sometimes send temperature and some others send pressure (depending on its internal way of working). You don't want the measure on temperature "ruins" the pressure with a blank value or the other way arround.
This is a kind of enhanced feature. In your explained example, If an instance of a device sent Temperatue and sometimes sent Pressure then in this caseTemperature value will be updated but value of pressure will remains old. Some application needs to maintained changes in each attribute i.e. if there is no cange in an attribute then it should be considered as empty.
In my patch, default behaviour will be same as existing but if user wants as empty value returned from device where no value sent then in this case below variable need to marked as true config.setDefaultValueToAttribute = false; above variable is added in config.js present at https://github.com/telefonicaid/iotagent-json.git
We are still a bit unsure about the usefullness of the behaviour you described, based in the utilization case we knows. Could you provide more detail about your use case (real-world examples if possible)?
However, if the feature is useful for you, we can include it as long as:
- It would be a configurable behaviour at group/device provisioning type via API. I mean, not as a global variable. Some device/group could have such behaviour while other not and the same IOTA instance should be able to deal with it.
- Instead of setting atributes to blank, the attribute should be removed. Using the replace semantics in the CB API would allow this (either PUT /v2/entities/E/attrs or POST /v2/op/update with actionType: "replace").
- The new field in the provisioning API has to be described in the documentation (not sure which right noew which is the right document...)
- The new feature has to be covered by unit test (both happy cases and fail cases)
- And entry corresponding to the new feature is included in the CHANGES_NEXT_RELEASE file
Thanks for the feedback!