Payload for device provisioning

[gabrieledeluca]

If I add a new device with iot/devices POST request, I receive an error (WRONG_SYNTAX) when I use "forbidden" chars inside value of _objectid field (patterns are defined into createDevice.json and updateDevice.json file). Why? Whereas I understand this pattern on other fields (such as name and type) linked with NorthBound world (and OCB forbidden characters), the _objectid should be linked to the SouthBound world so I expect to not have constraints (pattern) over _objectid value.

What do you think?

[fgalan]

Northbound has a direct mapping to southbound with regards to attribute/measures. For instance, for active attributes, the measures IOTAgent gets in the southbound in an object_id are directly mapped to CB attributes in the northbound (in particular, to the attribute name associated to that object_id). So I think it makes sense that the restrictions in the northbound are applied also to northbound.

Or maybe I'm missing something... :)

[gabrieledeluca]

In my opinion the OCB restrictions has not to be applied about the Southbound world: _objectid is the identification field of a Southbound thing and the library cannot know anything about Southbound restrictions (this is a "vertical" problem, so it has to be manage by a specific agent implementation).
For example, if I have a Southbound stuff identified with this ID: "thing=1" I'll not be able to use this value as _objectid (without a workaround), why?

Instead, it is clear that there are some restrictions over name field (as you have written above) because this field will be the entity attribute name in the Northbound.

Thanks in advance :-)

[fgalan]

So your concern is related only with values of the measures/attributes (not the names). Is this correct? (just to undersatnd correctly the scope of the issue we are discussing here ;)

[gabrieledeluca]

Yes, now there are restrictions over object_id that there should not be, so my concern is about don't have restrictions over the southbound world. This is a snippet from the createDevice.json file:

"object_id": { "description": "ID of the attribute in the device", "type": "string", "pattern": "^([^<>();'=\"]+)+$" },

I don't understand why there is a pattern for an unknown (for the lib) device :-)

[fgalan]

Let's try to clarify with an example. Let's suppose the following device has been provisioned:

{
  "devices": [ 
    { 
      "device_id": "DevID1", 
      "entity_name": "TheDevice1", 
      "entity_type": "DeviceType", 
      "attributes": [ 
        { "object_id": "t", "name": "temperature", "type": "Text" },
      ],
      "transport": "MQTT"
      }
  ]
}

Let's suppose now that there isn't any restriction in the southbound, so a device can send a measure like this (for instance, using the UL payload)

t|23.1(C)

object_id "t" is mapped to attribute "temperature" at CB. Thus, IOTAgent should update "temperature" attribute using the "23.1(C)" value... which will produce a 400 Bad Request error given that Orion will not accept ( in an attribute value (the list is here: https://fiware-orion.readthedocs.io/en/master/user/forbidden_characters/index.html).

How do you propose to solve this case?

[gabrieledeluca]

I was only referring to the _objectid field, I agree with you that value, name, type, etc. should have restrictions as they will arrive on OCB (as you have told, because there are forbidden chars) :-)

[fgalan]

Ok. I think I now see your point...

I agree in that the restriction would not be mandatory for object_id literals. However, note this object_ids use to be short (usually, one letter), with the aim of saving bandwidth in measures sent on the southbound interface (for instance, "t", "p", "h", etc.). We are assuming that they are so simple that they will follow the restrictions.

Could you provide a particular example of object_id that you were trying to use in a real case, please?

[gabrieledeluca]

For example in the OPC UA domain, some examples of NodeId here:

• ns=2;s=MyTemperature --> namespace index 2, string identifier
• i=2045 --> namespace index 0, numeric identifier
• ns=1;g=09087e75-8e5e-499b-954f-f2a9603db28a -->namespace index 1, GUID identifier
• ns=1;b=M/RbKBsRVkePCePcx24oRA==' --> namespace index 1, Opaque/ByteString identifier

Anyway, at the moment there isn't a restriction about the size of _objectid.

[taliaga]

I agree in that the restriction would not be mandatory for object_id literals

I also agree here with you and @gabrieledeluca, particularly for the freedom in the name of the attribute (the 'object_id' string). We have real life examples of devices sending measurement (via LoRaWAN) with an attribute name like "Number of valid samples". It's not always a short single character, we need to get such restrictions removed.

[chicco785]

i think the actual issue is here: https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/devices/deviceService.js#L522

easy solution is to come up with a translator that when object_id breaks the orion supported attribute names, create a valid name out of object_id