Closed tudamp closed 2 months ago
AlvaroVega
commented
3 months ago Not sure if is a corner case or what should be the right behaviour. At the second step device named Sensor01 with an entityType and entityName is already found and then used.
If your add an static attribute to each group then the resulting entity has both static attributes.
Maybe the bug is that at second step Sensor01 device should be updated with new provided entityName and entityType?
AlvaroVega
commented
3 months ago Maybe (or not) before second step (send second measure) you can update provisioned device to ensure entityName and entityType are updated on Sensor01 device and then send the measure.
tudamp
commented
3 months ago Hi Alvaro, thank you for your reply.
According to the documentation about service groups: They are identified by an apikey and a resource and mapped to a particular entity type. [...] For every config group, the pair (resource, apikey) must be unique (as it is used to identify which group to assign to which device).
From my point of view, once a measurement is 'identified' with a specific apikey and resource, it cannot be mapped to a different entity that belongs to a different group. Probably the main problem is that the agent seems to ignore the entity type, which is instead important when talking to the context broker.
There are probably two solutions:
The second solution, however, seems to me to contradict what is written in the documentation.
AlvaroVega
commented
3 months ago Currently is not possible provision two devices in the same service/subservice with the same id but different apikey. And apikey at device level is mandatory since not along ago
tudamp
commented
3 months ago Perhaps this should be made clearer in the documentation, because at present it seems to describe a different behaviour (at least in my interpretation of the text).
The problem I see is that the definition of uniqueness within the agent and the CB is different. This causes confusion as there is a 1:1 logical mapping between the device in the iot agent and the CB. Do you think it makes sense to also include the device type in the uniqueness definition to standardise the behaviour with the CB?
Regardless of these considerations in the roadmap, given the current definition of uniqueness, I think the current behaviour may not be correct and the second measurement should be rejected.
fgalan
commented
3 months ago Perhaps this should be made clearer in the documentation, because at present it seems to describe a different behaviour (at least in my interpretation of the text).
Maybe you could do a pull request with a proposal of change to the documentation to make things clearer, based in your experience with this issue, please? Thanks in advance!
fgalan
commented
3 months ago Do you think it makes sense to also include the device type in the uniqueness definition to standardise the behaviour with the CB?
As far as I understand "type" is a concept used in CB associated to entities but it doesn't have an equivalent at device level at IOTA. In sum:
The mapping between both worlds (entity_id+entity_type <-> device_id) is done by IOTA, either by explicit provision or by autoprovision.
Please @AlvaroVega provide feedback if I'm wrong.
AlvaroVega
commented
3 months ago entity_name and entity_type are fields of device to link a device with a CB entity (which has id ant type), but are not a key in Devices model and typically are inhered from Group (as apikey) when autoprovision.
fgalan
commented
3 months ago PR https://github.com/telefonicaid/iotagent-node-lib/pull/1592 should fix this issue, allowing several devices with same device_id in the same service and subservice (as long as they are using different apikeys).
@tudamp could you test again, please? You can get the latest iotagent-json docker container from dockerhub at telefonicaiot/iotagent-json:latest. Thanks in advance!
fgalan
commented
2 months ago Release 4.4.0 including this fix has been released today, so we are going to close this issue.
@tudamp of course it can reopened if needed, if you provided feedback at the end.
IoT Agent Node Lib version the issue has been seen with
4.1.0
Bound or port used (API interaction)
Southbound (Devices data API)
NGSI version
NGSIv2
Are you running a container?
Yes, I am using a contaner (Docker, Kubernetes...)
Image type
distroless
Expected behaviour you didn't see
By sending the measurements first of Type1:Sensor01 with apikey1 and then of Type2:Sensor01 with its apikey2, the agent should:
recognise the service group of the first send (using apikey01 and resource), create the device if not present with the correct Entity type of the service group, send the measurement to cb
repeat the same behaviour with the second data send from the Type2:Sensor01
Unexpected behaviour you saw
The step1:
occurs correctly: the service group matched to the apikey is recognised and the settings (type1) combined with the measurement arriving from the device.
In step 2, the service group matched to apikey2 is recognised, but given the presence of a device with the same id, the measurement is combined with this device, resulting in an incorrect match with the entity in the cb (type1 instead of type2). The device in the second service group is never created.
Steps to reproduce the problem
No response
Configs
Log output