OMA Registry Mappingd

[dmoranj]

Some decisions were taken concerning OMA Registry mapping that may be subjected to further discussion:

• All the attributes are registered as passive.
• The resource name in the DDF is used as the attribute name (but the name should be changed to reflect the instance and possible the object itself).
• No resource is mapped for the third party objects that don't provide DDF.

[dmoranj]

Currently, all the attributes included in the OMA Registry are mapped, whether they have a DDF definition or not, but making some assumptions that may or may not be acceptable: those attributes not specified in the Device or Group definition are considered lazy, and they are considered to belong to a single instance with ID '0'. For those objects lacking DDF, a single attribute is generated with the name of the object, assuming they have an instance with ID '0' with a single resource with ID '0'.

All this rules should be clarified and documented in the repository documentation.

[lilezek]

I've noticed that recently. Is there any way to avoid it? The context broker is asking for resources with /typeID/0/0 and obviously receiving a 4.04 each time.

[dmoranj]

The best way to avoid it is to explicitly declare those attributes in the device provisioning requests (using the internalattributes mapping). This is a really old issue, and we may need to rethink it, I'll have to speak with the IoT Chapter architect about it.

[lilezek]

But I already have the mapping (following this pattern):

// This JSON is in config.ngsi.types
'MexST': {
      "service": "testing",
      "subservice": "/mexst",
      "removeSuffix": true,
      "commands": [{
        "name": "Light Control",
        "type": "number"
      }],
      "lazy": [],
      "active": [{
        "name": "Temperature",
        "type": "number"
      }, {
        "name": "Humidity",
        "type": "number"
      }, {
        "name": "Luminosity",
        "type": "number"
      }],
      "lwm2mResourceMapping": {
        "Humidity": {
          "objectType": 3303,
          "objectInstance": 0,
          "objectResource": 5700
        },
        "Temperature": {
          "objectType": 3304,
          "objectInstance": 0,
          "objectResource": 5700
        },
        "Luminosity": {
          "objectType": 3301,
          "objectInstance": 0,
          "objectResource": 5700
        },
        "Light Control": {
          "objectType": 3311,
          "objectInstance": 0,
          "objectResource": 5851
        }
      }
    }

But each time I ask for an element in context broker using:

(curl http://192.168.56.2:1026/v1/queryContext -s -S --header 'Content-Type: application/json' \
 --header 'Accept: application/json' --header 'fiware-service: testing' --header 'fiware-servicepath: /mexst' \
 -d @- | python -mjson.tool) <<EOF
{
    "entities": [
        {
            "type": "MexST",
            "isPattern": "false",
            "id": "testing:MexST"
        }
    ]
}
EOF

404 happens:

As far as I understand, active attributes shouldn't trigger a request.

[dmoranj]

And you are right. They shouldn't. It seems to me there may be some bug regarding active attribute registration. I'll try to check it.