2

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.

F. Aragona
  • 79
  • 7
  • 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 https://fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv1/index.html#convenience-discover-context-availability to see how to discover existing registrations at CB) and edit you question post to include it. Thx! – fgalan Jan 10 '18 at 12:55
  • I've added what you asked for, hoping it can help. Thank you. – F. Aragona Jan 10 '18 at 13:31
  • 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 Jan 10 '18 at 14:40
  • In addition it would be great if you add to your question post information about the IOTA and Orion version being used. – fgalan Jan 10 '18 at 14:41
  • I've added what you asked for. As you can see no values are sent from Orion to the IoT Agent. – F. Aragona Jan 10 '18 at 15:07

1 Answers1

1

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

fgalan
  • 11,732
  • 9
  • 46
  • 89
  • Please have a look to the test that I have done described in the answer post, which mimics your case. However, the result I have got is not exactly the same. I'd recommed: 1) run the same "script" of testing steps in your CB (clean database first), 2) try adding entity type to the update (in the CB-IOTA setup). – fgalan Jan 15 '18 at 16:20
  • 1
    Thank you, introducing the 'type' field in the update request solved the problem. – F. Aragona Jan 18 '18 at 08:26
  • Thanks for the feedback! We have modified the documentation in order to make it clearer (see bottom at https://fiware-orion.readthedocs.io/en/master/user/context_providers/index.html). – fgalan Jan 18 '18 at 10:46