telefonicaid / iotagent-node-lib

Module to enable IoT Agent developers to build custom agents for their devices that can easily connect to NGSI Context Brokers
https://iotagent-node-lib.rtfd.io/
GNU Affero General Public License v3.0
60 stars 86 forks source link

Payload for device provisioning #671

Open gabrieledeluca opened 6 years ago

gabrieledeluca commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

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

taliaga commented 5 years ago

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 commented 5 years ago

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