Details
-
Type: Monitor
-
Status: Closed
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:
-
HD-Chapter:IoT
-
HD-Enabler:IDAS
Description
Created question in FIWARE Q/A platform on 13-03-2017 at 11:03
Please, ANSWER this question AT https://stackoverflow.com/questions/42761660/querying-lwm2m-active-attribute-in-orion
Question:
Querying lwm2m active attribute in Orion
Description:
I have the following configuration for an active lightweightm2m-iotagent attribute (a temperature sensor value). Fiware's IoT agent turns IPSO objects into lazy attributes but I add a mapping to make it an active attribute as in the documentation:
types: {
'Type': {
service: 'service',
subservice: '/service',
commands: [],
lazy: [],
active: [
],
lwm2mResourceMapping: {
"t":
}
},
According to the documentation for the iotagent-node-lib:
NGSI queries to the context broker will be resolved in the Broker database.
However, when I query my active attribute in Orion, Orion also queries the lightweightm2m-iotagent, requesting a bogus /3303/0/0 path which doesn't even exist in the IPSO definition.
curl -H "Fiware-service: service" -H "Fiware-servicepath: /service" http://172.17.0.1:1026/v2/entities/entity1:Type/attrs/t/value
How can I set up the configuration to get the behavior stated in the documentation, resolving a query for an active attribute in the broker database and avoiding these bogus queries?
Activity
Field | Original Value | New Value |
---|---|---|
Component/s | FIWARE-TECH-HELP [ 10278 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Answered [ 10104 ] |
HD-Enabler | IDAS [ 10884 ] | |
Description |
Created question in FIWARE Q/A platform on 13-03-2017 at 11:03 {color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/42761660/querying-lwm2m-active-attribute-in-orion +Question:+ Querying lwm2m active attribute in Orion +Description:+ I have the following configuration for an active lightweightm2m-iotagent attribute (a temperature sensor value). Fiware's IoT agent turns IPSO objects into lazy attributes but I add a mapping to make it an active attribute as in the documentation: types: { 'Type': { service: 'service', subservice: '/service', commands: [], lazy: [], active: [ { "name": "t", "type": "number" } ], lwm2mResourceMapping: { "t": { "objectType": 3303, "objectInstance": 0, "objectResource": 5700 } } }, According to the documentation for the iotagent-node-lib: NGSI queries to the context broker will be resolved in the Broker database. However, when I query my active attribute in Orion, Orion also queries the lightweightm2m-iotagent, requesting a bogus /3303/0/0 path which doesn't even exist in the IPSO definition. curl -H "Fiware-service: service" -H "Fiware-servicepath: /service" http://172.17.0.1:1026/v2/entities/entity1:Type/attrs/t/value How can I set up the configuration to get the behavior stated in the documentation, resolving a query for an active attribute in the broker database and avoiding these bogus queries? |
Created question in FIWARE Q/A platform on 13-03-2017 at 11:03
{color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/42761660/querying-lwm2m-active-attribute-in-orion +Question:+ Querying lwm2m active attribute in Orion +Description:+ I have the following configuration for an active lightweightm2m-iotagent attribute (a temperature sensor value). Fiware's IoT agent turns IPSO objects into lazy attributes but I add a mapping to make it an active attribute as in the documentation: types: { 'Type': { service: 'service', subservice: '/service', commands: [], lazy: [], active: [ { "name": "t", "type": "number" } ], lwm2mResourceMapping: { "t": { "objectType": 3303, "objectInstance": 0, "objectResource": 5700 } } }, According to the documentation for the iotagent-node-lib: NGSI queries to the context broker will be resolved in the Broker database. However, when I query my active attribute in Orion, Orion also queries the lightweightm2m-iotagent, requesting a bogus /3303/0/0 path which doesn't even exist in the IPSO definition. curl -H "Fiware-service: service" -H "Fiware-servicepath: /service" http://172.17.0.1:1026/v2/entities/entity1:Type/attrs/t/value How can I set up the configuration to get the behavior stated in the documentation, resolving a query for an active attribute in the broker database and avoiding these bogus queries? |
HD-Chapter | IoT [ 10839 ] |
Assignee | Backlog Manager [ backlogmanager ] |
Resolution | Done [ 10000 ] | |
Status | Answered [ 10104 ] | Closed [ 6 ] |
Fix Version/s | 2021 [ 12600 ] |