Error when updating associated entity in a device

manucarrace commented 5 years ago

When updating a device, if the associated entity is changed, then the measures received by the IOTA can not reach the Context Broker, since the entity does not exist.

manucarrace commented 5 years ago

After some investigations we have seen the following.

When the IoTAgent receives a measure it makes a request to Context Broker like this: http://10.0.0.2:1026/v2/entities//attrs

This requests only updates the value of the attributes; if the entity doesn't exist, the Context Broker will respond with an error.

As a result of changing the entity_id of the device, the new entity doesn't exist. This issue would be solved by creating the new entity when updating the device.

fgalan commented 5 years ago

Just to add some complementary information to the @manucarrace report:

We have done tests with IOTA-JSON with MQTT transport but it seems a common behaviour in the library, so probably no matter the agent no matter the transport it will be the same.
The operation that IOTA does on CB is POST /v2/entities/<devEnt>/attrs. Thus, the error happens if <devEnt> doesn't exist. Curiously, if expression plugin is in place, the operation used in POST /v2/op/update with actionType: "append" so the problem doesn't happen (a new entity is created).
I fully agree in the suggested solution. It would be a metter of modifying the PUT /iot/device/<dev> operation logic to include new entity creation (actually, an upsert to avoid colission if the entity already exists) in the workflow.

manucarrace commented 5 years ago

Searching in the documentation I've found the following:

"PUT /iot/devices/:deviceId Changes the stored values for the device with the provided Device payload. Neither the name, the type nor the ID of the device can be changed using this method (as they are used to link the already created entities in the CB to the information in the device). Service and servicepath, being taken from the headers, can't be changed also."

If this is the desired behaviour, a change in the entity_name should be forbidden by APIn and it should return an error. If the desired behaviour is that a device could change its asociated entity (is sounds sensitive to me) then a change in line with Fermin solution would be nice.

fgalan commented 5 years ago

If this is the desired behaviour, a change in the entity_name should be forbidden by APIn and it should return an error.

Probably this is the easiest solution.

Madhu-NEC commented 3 years ago

Hi @fgalan , @manucarrace , I have started working on this issue. Could you please assign this issue to me?

[Current Behaviour] device_id: It does not get updated but does not return an error. entity_name: It gets updated. entity_type: It gets updated.

[Expected Behaviour] Below is my understanding for this issue. The change in three properties of device i.e device_id, entity_name and entity_type must be forbidden by API PUT /iot/devices/:deviceId. device_id: It does not get updated and should return an error. entity_name: It does not get updated and should return an error. entity_type: It does not get updated and should return an error.

Please confirm my understanding.

Madhu-NEC commented 3 years ago

Hi @fgalan , @manucarrace Could you please confirm my understanding?

fgalan commented 3 years ago

At the end we are going to go in this line:

If the desired behaviour is that a device could change its asociated entity (is sounds sensitive to me) then a change in line with Fermin solution would be nice.

Thus, independently of the current behavior (which I'm not sure what it is :) the desired behavior should be:

device_id: cannot be changed by PUT /iot/devices/:deviceId. If a client tries to do that, the request is not processed and a 400 BAD REQUEST response should be done.
entity_name and entity_type: could be changed by PUT /iot/devices/:deviceId. In that case, IOTA has to create the new entity as in the case of new device. This should be done using the Orion upsert feature, in order not to fail if the entity already exists.

Pay also attention to the multi-entity case. In that case, more than one entity are associated to the same device. I'm not sure how it works, but two things may happen:

If the extra entities are created at provision time: the same I have said above applies to them. If they are changed upon PUT /iot/devices/:deviceId then the new entities should be created in upsert way.
If the extra entities are created on the fly as new measures arrive: nothing to do upon PUT /iot/devices/:deviceId.

Finally, the documentation about PUT /iot/device/:deviceid has to be changed to clearly describe what the behaviour is.

Thanks for your willingness to work on this issue! I have assigned the issue to you :)

fgalan commented 3 years ago

With regards to

This should be done using the Orion upsert feature, in order not to fail if the entity already exists.

Please have a look to createInitialEntityNgsi2() function, based on entity upsert at Orion API. Probably this is the one to create the new entity in NGSIv2.

Madhu-NEC commented 3 years ago

There is one preprovisioned device as per below screenshot: create_device

If the device is updated using below query: curl -X PUT -H "Fiware-Service: issue770" -H "Fiware-ServicePath: /issue770" -H "Content-Type: application/json" -d '{ "attributes": [{ "object_id": "l", "name": "Luminosity", "type": "lumens" }]}' 'http://localhost:4041/iot/devices/sensorNgsiv2' the active attributes of the device gets updated and only newly added attribute "Luminosity" becomes the active attribute. That means if any attribute array(like active, static etc) is updated at IOTA then only newly provided payload will be the attribute list of the device as per below screenshot: update_device_1

•entity_name and entity_type: could be changed by PUT /iot/devices/:deviceId. In that case, IOTA has to create the new entity as in the case of new device. This should be done using the Orion upsert feature, in order not to fail if the entity already exists.

If new entity is created when only entity_name or entity_type is updated then what should be the list (empty or the attributes previously registered with the device) of active attributes or other attributes of that entity at context broker side? As per my understanding below are the two cases:

Entity created with empty attribute list, then we have to delete the list at IOTA side also.
Entity created with previously registered list, then we have to add those lists at context Broker side also. Please let me know your opinion on above points.

fgalan commented 3 years ago

As per my understanding below are the two cases:

Entity created with empty attribute list, then we have to delete the list at IOTA side also.

Entity created with previously registered list, then we have to add those lists at context Broker side also. Please let me know your opinion on above points.

Sorry, I couldn't provide feedback on this...

Which option did you implement at the end in PR #988? 1 or 2?

Madhu-NEC commented 3 years ago

Which option did you implement at the end in PR #988? 1 or 2?

I have implemented the option 2.

fgalan commented 3 years ago

PR https://github.com/telefonicaid/iotagent-node-lib/pull/988 has been merged. I understand this issue can be closed.

telefonicaid / iotagent-node-lib

Error when updating associated entity in a device #770