Orion CB doesn't update lazy attributes on IoT Agent

Question

I'm trying to use Orion CB as Contex Provider for an IoT Agent in which I have registred a device with lazy attributes only.

On the IoT Agent I need to handle updateContext requests so I did a handler for these requests like this:

iotAgentLib.setDataUpdateHandler(updateContextHandler);

And in the updateContextHandler function I have only one instruction:

console.log(attributes);

In order to see if all the values I want to update have been received correctly.

Now if I do an update on one of the attributes of the entity represented by the device:

curl -i -X POST \
-H "fiware-service:service1" \
-H "fiware-servicepath:/subservice1" \
-H "X-Auth-Token:wNRwDwqYlLoLD8U9sFkTAEE6PfYMbQ" \
-H "Content-Type:application/json" \
-d \
'{
    "contextElements": [
        {
            "id": "ncc_estimate",
            "attributes": [
                {
                    "name": "arrival",
                    "type": "string",
                    "value": "some_value"
                }
            ]
        }
    ],
    "updateAction": "UPDATE"
} ' \
'http://{orion_address}/v1/updateContext'

What I see on the IoT Agent output console is:

time=2018-01-09T08:14:59.539Z | lvl=DEBUG | corr=2f4fdb0c-f515-11e7-86b2-0242ac110003 | trans=6ac5c35d-d7bf-419c-8f64-bc843b991d47 | op=IoTAgentNGSI.GenericMiddlewares | srv=service1 | subsrv=/subservice1 | msg=Body:

{
    "contextElements": [
        {
            "type": "nccestimate",
            "isPattern": "false",
            "id": "ncc_estimate",
            "attributes": [
                {
                    "name": "arrival",
                    "type": "string",
                    "value": ""
                }
            ]
        }
    ],
    "updateAction": "UPDATE"
}

Where as you can see the value field is empty, as I can also see from the console.log() output in the UpdateHandler function that is:

[ { name: 'arrival', type: 'string', value: '' } ]

It seems that Orion is deleting the value before sending it to the IoT Agent. What could be the problem? Am I wrong doing something?

edit:

Here is the response for the call to: /v1/registry/contextEntities/ncc_estimate

{"contextRegistrationResponses":[
    {"contextRegistration":
        {"entities":[
            {
                "type":"nccestimate",
                "isPattern":"false",
                "id":"ncc_estimate"
            }
        ],
        "attributes":[
            {
                "name":"transport_type",
                "type":"string",
                "isDomain":"false"
            },
            {
                "name":"arrival",
                "type":"string",
                "isDomain":"false" 
           }
        ],
        "providingApplication":"http://192.168.199.151:4044"}
    }
]}

edit2:

This is what Orion is sending to the iot agent when performing the updateContext operation described before:

POST //updateContext HTTP/1.1
User-Agent: orion/1.10.0-next libcurl/7.19.7
Host: 192.168.199.151:4044
fiware-service: service1
Fiware-ServicePath: /subservice1
X-Auth-Token: M62UkJc7yKX5aQwaHrsODfIrV4Ou85
Accept: application/json
Content-length: 169
Content-type: application/json; charset=utf-8
Fiware-Correlator: 42561e9a-f615-11e7-8610-0242ac110003

{"contextElements":[{"type":"nccestimate","isPattern":"false","id":"ncc_estimate","attributes":[{"name":"arrival","type":"string","value":""}]}],"updateAction":"UPDATE"}

As you can see the "value" field for the attribute is empty. I'm using Orion version 1.10.0 and iot agent node lib version 2.5.1.

Lazy attributes are based in registrations that IOTA creates at CB at provisioning time. It would be a very useful information to find what can be happening. Please, check the registration at CB asociated to the device (see fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv1/… to see how to discover existing registrations at CB) and edit you question post to include it. Thx! — fgalan
I've added what you asked for, hoping it can help. Thank you. — F. Aragona
Registration seems to be ok, it includes the lazy attribute. Let's check what is Orion actually sending, to discard a bug in the IOTA log system. To do that just stop IOTA after provisioning the device, them start a listener process at the same port (as nc or netcat). Then, update the attribute at CB and check what you get in your listner process. Please edit the question post including that information. — fgalan
In addition it would be great if you add to your question post information about the IOTA and Orion version being used. — fgalan
I've added what you asked for. As you can see no values are sent from Orion to the IoT Agent. — F. Aragona

fgalan fgalan · Accepted Answer · 2018-01-15T16:15:37

I have done the following test using CB same version as yours (i.e. 1.10.0)

First, create a registration as the one that IOTA would create:

(curl -s -S localhost:1026/v1/registry/registerContext -H "fiware-service:service1" -H "fiware-servicepath:/subservice1" -H 'Content-Type: application/json' -d @- | python -mjson.tool) <<EOF
{
    "contextRegistrations": [
        {
            "entities": [
                {
                    "type": "nccestimate",
                    "isPattern": "false",
                    "id": "ncc_estimate"
                }
            ],
            "attributes": [
                {
                    "name": "transport_type",
                    "type": "string",
                    "isDomain": "false"
                },
                {
                    "name": "arrival",
                    "type": "string",
                    "isDomain": "false"
                }
            ],
            "providingApplication": "http://localhost:4044"
        }
    ],
    "duration": "P1M"
}
EOF

Next, check that it is exactly the same registration shown in the question post (except by the providingApplication, that points to localhost):

curl localhost:1026/v1/registry/contextEntities/ncc_estimate -s -S -H "fiware-service:service1" -H "fiware-servicepath:/subservice1" -H 'Accept: application/json' | python -mjson.tool

which response is

{
    "contextRegistrationResponses": [
        {
            "contextRegistration": {
                "attributes": [
                    {
                        "isDomain": "false",
                        "name": "transport_type",
                        "type": "string"
                    },
                    {
                        "isDomain": "false",
                        "name": "arrival",
                        "type": "string"
                    }
                ],
                "entities": [
                    {
                        "id": "ncc_estimate",
                        "isPattern": "false",
                        "type": "nccestimate"
                    }
                ],
                "providingApplication": "http://localhost:4044"
            }
        }
    ]
}

Next, run nc process at localhost on providingApplication port.

nc -l -p 4044

Once the setup is done, let's test first with an update based on the one in the question.

curl -s -S -X POST http://localhost:1026/v1/updateContext -H "fiware-service:service1" -H "fiware-servicepath:/subservice1" -H "Content-Type:application/json" -d @- <<EOF
{
    "contextElements": [
        {
            "id": "ncc_estimate",
            "attributes": [
                {
                    "name": "arrival",
                    "type": "string",
                    "value": "some_value"
                }
            ]
        }
    ],
    "updateAction": "UPDATE"
}
EOF

In this case, Orion doesn't recognized the registration and returns a Not Found response:

{
    "contextResponses": [{
        "contextElement": {
            "type": "",
            "isPattern": "false",
            "id": "ncc_estimate",
            "attributes": [{
                "name": "arrival",
                "type": "string",
                "value": ""
            }]
        },
        "statusCode": {
            "code": "404",
            "reasonPhrase": "No context element found",
            "details": "ncc_estimate"
        }
    }]
}

In other words, Orion is not forwarding the response. I don't know why in your case is forwarded and leaves a trace in IOTA log file.

Next test uses the same request but adding a type field for the entity.

curl -s -S -X POST http://localhost:1026/v1/updateContext -H "fiware-service:service1" -H "fiware-servicepath:/subservice1" -H "Content-Type:application/json" -d @- <<EOF
{
    "contextElements": [
        {
            "id": "ncc_estimate",
            "type": "nccestimate",
            "attributes": [
                {
                    "name": "arrival",
                    "type": "string",
                    "value": "some_value"
                }
            ]
        }
    ],
    "updateAction": "UPDATE"
}
EOF

In this case, the request is forwarded and I get this in the nc terminal.

POST //updateContext HTTP/1.1
User-Agent: orion/1.10.0 libcurl/7.38.0
Host: localhost:4044
fiware-service: service1
Fiware-ServicePath: /subservice1
Accept: application/json
Content-length: 179
Content-type: application/json; charset=utf-8
Fiware-Correlator: 42e75f8a-fa0d-11e7-93f1-000c29173617

{"contextElements":[{"type":"nccestimate","isPattern":"false","id":"ncc_estimate","attributes":[{"name":"arrival","type":"string","value":"some_value"}]}],"updateAction":"UPDATE"}

Note the some_value in the response. Orion seems to be progressing correctly the request in this case.

EDIT: according to user's feedback, entity type solved the problem. We are highlighting it in the documentation regarding Context Providers:

You should include entity type in the query/update in order for the ContextBroker to be able to forward to Context Providers

Orion CB doesn't update lazy attributes on IoT Agent

1 Answers