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? :)