clarification needed on expected usage of deviceGroup -> device

[chicco785]

1. looking at the code and the docs it looks like that at creation time a deviceGroup is identified by the tuple (resource,apiKey). This means that under the same service,subservice there may be different deviceGroups.

2. it is then unclear, at provisioning time of a device provisioning time how the relation is created since, the only information passed is service,subservice, which seems to imply that device group can be only and only one for a tuple service,subservice.

3. the only moment were apikey is used is during the device update. which can imply that with a single deviceId registered and linked to a tuple service,subservice if 2 service groups with different apiKey are recorded, you would end up being able (for the same device) to register total different data (due to the two configuration of device group) but just using the two different apiKey.

not sure this is a feature or a bug :)

[fgalan]

With regards to 1 and 2, the desired behaviour (feature) is that under a given service, subservice several deviceGroups can be defined. If the behaviour is not currently that, the it could be a bug.

With regards to 3, not sure if I get the point... A device using two apiKeys would be managed, from a IoTAgent point of view, as two different devices.

[chicco785]

the behaviour is that you can provide different deviceGroup given that singleconfigurationmode = false

the issue is that in this case (looking at the code), when you create a device, there is no explicit binding between the device and deviceGroup since the only information that you pass on the device creation is the tuple service, subservice which is not enough to identify the deviceGroup (which is identified by the tuple resource, apiKey since neither resource neither apiKey are used at device creation time.

on the other hand, this may mean that if you create two different device groups in the same service, subservice tuple, when you updated the data of a given device you created for the given service, subservice tuple, you will be able to "bind" the device to a different deviceGroup (and hence model) by using the apiKey of deviceGroup1 or deviceGroup2.

[fgalan]

Thanks for clarifying the point :)

Under my understanding, the behaviour you describe is the intended one. I mean, the devices are not bound to at specific group on creation time but when the device sends measures and the apiKey identified the group.

[chicco785]

so it's a feature... but a confusing one (and error prone one), because when you create a deviceGroup you think you will create devices for a specific group. now, this is not true, a device may belong to more groups (but only one service), and if users do not know they by using by mistake the wrong apiKey they can mess up a lot.

[fgalan]

The point here is if the use case of a device able to report using two different apiKeys

• If the answer is "yes", then it makes sense to have the behaviour as it is now
• If the answer is "no", then this could be changed in order to avoid the confusion. Probably documentation could be also improved in order to clearly state how it works. However, not sure about the complexity and extension of the change.

CC: @AlvaroVega @mrutid @manucarrace

[chicco785]

sure it is something to be clarified :)

The use case though, it is not much about the two different apiKey (which could be interesting as well) but about a device belonging "dynamically" to two device groups, given that, depending on the apiKey you may change the device model according to the deviceGroup description.

[manucarrace]

As far as i understand, devices don't belong to a specific group. They can send measures using several apikeys. I think this is correct.

It's true that this behaviour would lead to have entities with a extrange data model. It would have static_attributes, commands, transformations, etc, from both groups.

From an e2e point of view, i think this is something to be clarified in the documentation. From a component point of view it is an extra degree of freedom (and also to improve documentation would be nice)

[fgalan]

+1 to improve documentation including the clarifications/findings in this issue. Until that, let's keep the issue opened. I'll change label from "question" to "documentation".