Uploaded image for project: 'Help-Desk'
  1. Help-Desk
  2. HELP-8791

[fiware-stackoverflow] Querying lwm2m active attribute in Orion

        Details

          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: [

          { "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?

            Activity

            Ascending order - Click to sort in descending order
            backlogmanager Backlog Manager created issue -
            Hide
            Permalink
            backlogmanager Backlog Manager added a comment -

            2017-05-22 15:07|CREATED monitor | # answers= 1, accepted answer= False

            Show
            backlogmanager Backlog Manager added a comment - 2017-05-22 15:07|CREATED monitor | # answers= 1, accepted answer= False
            backlogmanager Backlog Manager made changes -
            Field Original Value New Value
            Component/s FIWARE-TECH-HELP [ 10278 ]
            backlogmanager Backlog Manager made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            Permalink
            backlogmanager Backlog Manager added a comment -

            2017-05-22 18:05|UPDATED status: transition Answer| # answers= 1, accepted answer= False

            Show
            backlogmanager Backlog Manager added a comment - 2017-05-22 18:05|UPDATED status: transition Answer| # answers= 1, accepted answer= False
            backlogmanager Backlog Manager made changes -
            Status In Progress [ 3 ] Answered [ 10104 ]
            Hide
            Permalink
            backlogmanager Backlog Manager added a comment -

            2017-05-22 21:05|UPDATED status: transition Answered| # answers= 1, accepted answer= False

            Show
            backlogmanager Backlog Manager added a comment - 2017-05-22 21:05|UPDATED status: transition Answered| # answers= 1, accepted answer= False
            fla Fernando Lopez made changes -
            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 ]
            jicg José Ignacio Carretero Guarde made changes -
            Assignee Backlog Manager [ backlogmanager ]
            jicg José Ignacio Carretero Guarde made changes -
            Resolution Done [ 10000 ]
            Status Answered [ 10104 ] Closed [ 6 ]
            fla Fernando Lopez made changes -
            Fix Version/s 2021 [ 12600 ]
            Transition Time In Source Status Execution Times Last Executer Last Execution Date
            Open Open In Progress In Progress
            		2h 58m 1 Backlog Manager 22/May/17 6:04 PM
            In Progress In Progress Answered Answered
            		2h 59m 1 Backlog Manager 22/May/17 9:04 PM
            Answered Answered Closed Closed
            		6d 16h 11m 1 José Ignacio Carretero Guarde 29/May/17 1:15 PM

              People

              • Assignee:
                backlogmanager Backlog Manager
                Reporter:
                backlogmanager Backlog Manager
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: