Lazy, Commands and Static Attributes ignored when creating a new service

[Cerfoglg]

When trying to create a device group (service) I've been having issues with assigning lazy, commands and static attributes to it. Using a similar payload to the example from the documentation:

{
    "services": [
        {
            "entity_type": "Device",
            "resource": "/iot/ul",
            "protocol": "HTTP_UL",
            "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
            "iotagent": "http://agentHost:port",
            "commands": [
                {
                    "name": "wheel1",
                    "type": "Wheel"
                }
            ],
            "lazy": [
                {
                    "name": "luminescence",
                    "type": "Lumens"
                }
            ],
            "attributes": [
                {
                    "name": "status",
                    "type": "Boolean"
                }
            ]
        }
    ]
}

Sending this payload in a POST to /iot/services on a IoT UL Agent doesn't return any error, and the service will be created, however when retrieving this service with a GET, only the attributes seem to have been taken into consideration, as the lazy and commands are not present. Static attributes behave the same way. When creating a Device, lazy, commands and static attributes are all created as expected, but with the device groups only attributes work.

Is this intended behaviour? If so, what determines whether or not you can have lazy, commands or static attributes in a device group? And shouldn't the API respond with a 400 error if those are included when they aren't meant to be?

[fgalan]

Not sure if I'm understanding correcly the case... I have done a quick test with IOTA-UL

Create service:

curl -X POST http://localhost:4061/iot/services -H "Fiware-Service: myhome" -H "Fiware-ServicePath: /environment" -H "Content-Type: application/json" -d @- <<EOF
{
    "services": [
        {
            "entity_type": "Device",
            "resource": "/iot/ul",
            "protocol": "HTTP_UL",
            "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
            "iotagent": "http://agentHost:port",
            "commands": [
                {
                    "name": "wheel1",
                    "type": "Wheel"
                }
            ],
            "lazy": [
                {
                    "name": "luminescence",
                    "type": "Lumens"
                }
            ],
            "attributes": [
                {
                    "name": "status",
                    "type": "Boolean"
                }
            ],
			"static_attributes": [
                  { "name": "serialID", "type": "string", "value": "02598347" }
            ]
        }
    ]
}
EOF

Retrive service:

curl -s -S http://localhost:4061/iot/services -H "Fiware-Service: myhome" -H "Fiware-ServicePath: /environment" | python -mjson.tool

and I get:

{
    "count": 1,
    "services": [
        {
            "__v": 0,
            "_id": "5c40b736e3462299aee0fc46",
            "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
            "attributes": [
                {
                    "name": "status",
                    "type": "Boolean"
                }
            ],
            "commands": [
                {
                    "name": "wheel1",
                    "type": "Wheel"
                }
            ],
            "entity_type": "Device",
            "internal_attributes": [],
            "lazy": [
                {
                    "name": "luminescence",
                    "type": "Lumens"
                }
            ],
            "resource": "/iot/ul",
            "service": "myhome",
            "static_attributes": [
                {
                    "name": "serialID",
                    "type": "string",
                    "value": "02598347"
                }
            ],
            "subservice": "/environment"
        }
    ]
}

Which as far as I understand includes all the provisioned elements (i.e. attributes, static attributes, lazy and comands).

[Cerfoglg]

Sorry, my bad. As it turns out the issue wasn't with the agent not taking those values into consideration. The problem was that we also use the IoT Agent Manager in front of the agents, and when querying that on the /iot/services path it returns the services, but lazy, static attributes and commands are left empty regardless of whether they exist on the agent or not.

[fgalan]

So you mean that doing the GET on IOTA itself works ok but if you do GET on the IOTA Manager it "eats" the lazy, static attributes and commands. Is my understanding correct?

[Cerfoglg]

Yes, correct, they get displayed as an empty array even when they are present.

[fgalan]

Thus, let's tranfer this issue to IOTAManager repository.

[Cerfoglg]

@fgalan After taking another look, I think the issue may actually be in the iot agent node library. When the agent registers to the IoT Manager it doesn't appear to be including lazy attributes and commands, but it does include the attributes and static attributes (which both do show up when querying the manager for services). See here for instance https://github.com/telefonicaid/iotagent-node-lib/blob/2f986b73dfbd96732edd310c344548470598b1a1/lib/services/common/iotManagerService.js

Unless there's something I'm missing, this is more a bug on the nodelib side.

[chicco785]

clearly this is a bug in the node-lib, @fgalan can we move it there?

[fgalan]

Moved! Thanks for the feedback @chicco785 !

[manucarrace]

It seems, the data is stored in Mongo, so could be a problem in the GET /iot/services operations.

Apart from that, it makes me wonder about the sense of commands in device groups.
Which registrations would be done in Context Broker?
Devices doesn't belong to any device group so when a new device is created, it is not possible to set the device group commands, since there is no group at all. (remember we could have several groups for the same protocol)
Commands should only apply to device provisioning.

[chicco785]

@manucarrace
data are stored in mongo, i.e. when you create the service those attributes are stored by the iot agent.
now, if the agent is registered into the iot-agent manager, it sends a registration with the description of the services (see link https://github.com/telefonicaid/iotagent-node-lib/blob/2f986b73dfbd96732edd310c344548470598b1a1/lib/services/common/iotManagerService.js).
this registration does not include all the data used to register the service, so when using the iot agent manager, information is not consistent.

we could argue that probably not only device queries should be proxied by the iot agent manager, but also service queries. Thus changing the way it works today the iot-agent manager and thus not sending anymore this payload at registration, but only letting know the iot-agent manager that there is an agent somewhere, and the when querying service retrieving data directly from the agent.

thoughts?

[chicco785]

in line 46 on you see which information are sent currently to the iot manager for each service:

iotagent-node-lib/lib/services/common/iotManagerService.js

Line 46 in 2f986b7

return {

[manucarrace]

Agree with you @chicco785. I'm not discussing the bug, neither the IoT Agent communication mechanism. I'm just wondering what is the real use case of including commands in a device group.

[chicco785]

not sure :) but i can think that, as attributes in groups are used to describe 'attributes' that are common to a set of devices, the same may apply to 'commands'. surely, static_attributes are needed. who am I to question why originally 'service' included the supports for command definition? :)

[manucarrace]

I will try to explain myself again, sorry I wasn't clear enough.

Commands and lazy attributes need registrations in CB. These registrations cannot be done at group provisioning time, since you need to know the name of the device (and the name of the entity). The name of the device and the name of the entity are only available when you provision a device but not when you provision a group. So, from my point of view, it has no sense to set lazy attributes and commands at group provision time.

Different situation applies for static_attributes. There's no need to set anything at device level, so it is possible to set static_attributes at group level. Keep in mind that the static attribute is applied when a measure is send to a specific group, even if the device doesn't exist.

[chicco785]

While registrations cannot be done at provisioning time (which i totally agree!), my understanding of the value of attaching them to "service group" is that you can define their configuration once for all the devices that will have them in common (so to avoid to re-enter the same information 20 times). Then when the device is created, the registration occurs based on service groups lazy and commands (plus the specific ones to the devices).

[Cerfoglg]

Commands and lazy attributes need registrations in CB. These registrations cannot be done at group provisioning time, since you need to know the name of the device (and the name of the entity). The name of the device and the name of the entity are only available when you provision a device but not when you provision a group. So, from my point of view, it has no sense to set lazy attributes and commands at group provision time.

My understanding is similar to @chicco785 's: that the group configuration is meant to be shared across all devices in that group. In the documentation of this library there are examples of device groups being provisioned with the lazy and commands present, so I'm a bit confused as to what the intent there is. Same with the internal attributes.

Different situation applies for static_attributes. There's no need to set anything at device level, so it is possible to set static_attributes at group level. Keep in mind that the static attribute is applied when a measure is send to a specific group, even if the device doesn't exist.

In the documentation there is an example of static attributes that are set as a serial number of a device, doesn't that count as a device level static attribute?

I opened a pull request with the change I had in mind to include those at least when it comes to the interaction with the IoT Manager.

[fgalan]

Once PR #793 has been merged, should this issue be closed? Or is there anything else pending?

[fgalan]

Once PR #793 has been merged, should this issue be closed? Or is there anything else pending?

Having received no feedback in the last months, I think we can close. @Cerfoglg @chicco785 please just tell me in the case I'd be wrong.