Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with sending query context from iot broker to iot agent #20

Open
mohamedamin10010027 opened this issue Mar 2, 2018 · 5 comments

Comments

@mohamedamin10010027
Copy link

when i register entity to iot discovery i use this script

curl '130.206.121.137:8065/ngsi9/registerContext' -s -S --header 'Content-Type: application/json' -d @- <<EOF
{

"contextRegistrations": [
    {
        "entities": [
            {
                "type": "thing",
                "isPattern": "false",
                "id": "sensor999"
            }
            
        ],
        "attributes": [
            {
                "name": "temperature",
                "type": "float",
                "isDomain": "false"
		
            }
            
        ],
        "providingApplication": "http://130.206.118.50:4061/ngsi10"
    }
],
"duration": "P1M"

}

EOF


the ip of providingApplication field is the ip of iot agent

when i send a quertContext that request is heard by iot agent but dosen't return any entity

i have used the following script and i put the headers of service and service path at the following way but the element is not found

(curl 130.206.121.137:8060/ngsi10/queryContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: smart' --header 'Fiware-ServicePath:/' --header 'X-Auth-Token: null' -d @- | python -mjson.tool)<<EOF
{
"entities": [{
"isPattern": "false",
"id": "sensor999",
"type": "thing"
}],
"attributes": ["temperature"]
}

EOF

the response is

{
"contextResponses": [],
"errorCode": {
"code": 404,
"details": "Discovery response: OK (details: )",
"reasonPhrase": "CONTEXT ELEMENT NOT FOUND"
}
}

i used these parameters actually for sending query and register to discovery ,

using android app i register this script to iot agent and it have already registered to agent

"{\n" +
" "devices": [\n" +
" { "device_id": ""+"device"+"",\n" +
" "entity_name": ""+"sensor999"+"",\n" +
" "entity_type": ""+"thing"+"",\n" +
" "timezone": "Egypt/Cairo",\n" +
""attributes": [\n" +
" { "object_id": "t",\n" +
" "name": "temperature",\n" +
" "type": "float"\n" +
" }],\n" +
" "static_attributes": [\n" +
" { "name": "att_name",\n" +
" "type": "int",\n" +
" "value": ""+"656.5"+""\n" +
" }\n" +
" ]\n" +
" }\n" +
" ]\n" +
" } \n" +
"\n";
Is there incompatibility in attributes and Is this correct scripts ?

@flaviocirillo
Copy link
Collaborator

flaviocirillo commented Mar 8, 2018

Hi Mohamed,

first thing to say is that the IoT Broker does not support FIWARE Service and FIWARE Service Path. Those two things are not part of the NGSI specification neither the FIWARE architecture but specific features of the Orion Context Broker.
Nevertheless Adding those headers in the requests does not harm the correct behaving of the IoT Broker, the unknown header will be simply ignored and discarded.

Said that, I have syntactically checked your curl requests and they are fine, I have successfully tested them(with the 6.4 version of the IoT Broker standalone docker version, fiware:v6.4-standalone).

I did not fully understand the script of your IoT Agent into your android application. As far I have understood you registers your android agent to the IoT Discovery and then you make a query to the IoT Broker. Because of that the IoT Broker contacts your android iot agent which replies with the following message that needs to then be finally given as response to your original query response:

{
    "devices": [{
        "device_id": "device",
        "entity_name": "sensor999",
        "entity_type": "thing",
        "timezone": "Egypt/Cairo",
        "attributes": [{
            "object_id": "t",
            "name": "temperature",
            "type": "float"
        }],
        "static_attributes": [{
            "name": "att_name",
            "type": "int",
            "value": "656.5"
        }]
    }]
} 

Did I understand right?

The problem here is that the IoT Broker is making a new NGSI-10 queryContextRequest to the android IoT agent and it is expected an NGSI-10 queryContextResponse as response (see Query Context Handling)

I have tried to model your message with a correct NGSI queryContextResponse:

{
    "errorCode": null,
    "contextResponses": [{
        "contextElement": {
            "entityId": {
                "id": "sensor999",
                "type": "thing",
                "isPattern": false
            },
            "domainMetadata": [{
                "name": "timezone",
                "type": "timezone",
                "value": "Egypt/Cairo"
            }, {
                "name": "att_name",
                "type": "int",
                "value": "656.5"
            }],
            "attributes": [{
                "object_id": "t",
                "name": "temperature",
                "type": "float"
            }]
        },
        "statusCode": {
            "code": 200,
            "reasonPhrase": "OK",
            "details": ""
        }
    }]
}

@flaviocirillo
Copy link
Collaborator

flaviocirillo commented Mar 8, 2018

Another thing: I have seen that you are registering your agent with a duration of 1 minute:

"duration": "P1M"

That means that after the minute passes the registration will expire and it will be cancelled from the IoT Discovery, therefore your IoT agent will not be discoverable anymore by the IoT Broker.

If you want to make the registration permanent, just omit this parameter.

@mohamedamin10010027
Copy link
Author

mohamedamin10010027 commented Mar 8, 2018

thanks a lot for your response me about my problems and explain me the parameter of duration ,i had misunderstanding to that parameter
you have already understood what i mean ..
my vision in the flow of querycontext -- i have already understood the flow in sequence diagram that you mentioned above well--
i registered entity to iot agent using android app without service and service path and that registration is forwarded automatically to context broker and stored in it not in iot agent so that parameter in "providingApplication": "http://130.206.118.50:4061/ngsi10" must be ip of context broker not iot agent so when i make querycontext that request is forwarded to iot broker then discover availability is forwarded to iot discovery then return response with ip of context broker to iot broker so query is forwarded to context broker not iot agent and retrieve the data from it. i have already done that flow and is doing well.
Did i understand right the flow ? or i have misunderstanding to it?

@flaviocirillo
Copy link
Collaborator

Hi Mohamed,

so as far as I can understand you have an Orion Context Broker, an Android App (your code), an IoT Agent (your code), a FIWARE IoT Broker + IoT Discovery.
What you do is:

  1. open the app and request to send the registration with Orion Context Request address as providingApplication
  2. the app instruct the iot agent to send registration to the IoT Discovery with Orion Context Request addess as providingApplication
  3. the IoT Discovery receives and store the registration

then you request the data:

  1. you send a query to IoT Broker
  2. IoT Broker discovers context availability by requesting the IoT Discovery
  3. IoT Broker contacts the providing applications of the discovery response. In our case it contacts Orion Context Broker
  4. Orion Context Broker is contacted and responds back.
  5. IoT Broker forwards the response as response to your queryContext

This is what it happens, so it is actually correct what you have understood.

I have a question: the last JSON data of your first message, from whom is generated?

@mohamedamin10010027
Copy link
Author

mohamedamin10010027 commented Mar 8, 2018

image

image

in those images i make a graph for my project in case of query and registration

IoT Agents translate IoT-specific protocols into the NGSI context information protocol, i do not need this component if my devices or gateways natively support the NGSI API.

i want in my project to connect a device not deals with ngsi to NEConfman discovery as soon as it arrives to the system automatically without manual registration using android app so

Is there a way to do this ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants