Add support for structured attributes (needed by FIWARE Data Models)

[aarranz]

Currently, the FIWARE IoT-agents cannot be used for creating entities following the FIWARE data models as those models rely on structured attribute, that are not supported by iotagent-node-lib.

[dherykw]

Hello all,

We are currently working closely with many of this services (IDAS IoTAgents) and we have a lot of problems to represent FIWARE Data models because of the absence of this functionality.

It would be fine to try to fix it as soon as possible in order to fit with the data models.

Best

[dherykw]

Is this issue active? It should be a high priority functionality

[fgalan]

In principle, every open issue is active, waiting for some brave developer in the FIWARE community to take the challengue of implementing it ;)

[fgalan]

Currently, the FIWARE IoT-agents cannot be used for creating entities following the FIWARE data models as those models rely on structured attribute, that are not supported by iotagent-node-lib

Could you (or whoever :) elaborate in the lack of support of structured attributes in iotagent-node-lib, please? Is is a limitation in the libreary itself? Or is due to the limitation in CB described in issue https://github.com/telefonicaid/fiware-orion/issues/3162 ?

In the second case, note the issue has been recently solved (it is now closed) so the impediment is no longer exist.

@dcalvoalonso what do you think?

[dcalvoalonso]

To the best of my knowledge, at least with https://github.com/telefonicaid/iotagent-json should be possible to send structured attributes.

With https://github.com/telefonicaid/iotagent-ul and https://github.com/telefonicaid/lightweightm2m-iotagent, I think that the problem is how to represent this kind of values using Ultralight or LWM2M.

Do you have some suggestions @dherykw?

[dherykw]

Hello @dcalvoalonso

Is there any possibility of seeing the IoTJson representing a lazy attribute of a structured type?

for example the one proposed by @fgalan here :

"value": {
  "type": "StructuredValue",
  "value":   {
    "temperature": 28.5
    "humidity": 68
  },
  "metadata": {
    "units": {
      "type": "StructuredValue",
      "value": {
        "temperature": "ºC",
        "humidity": "%"
      }
    }
  }
}

maybe it can serve as a guide.

[albertoabellagarcia]

One question how do you manage when you will have the values of 7 attributes not only 2 like temperature and humidity, etc. to what extent is going to be expanded the data model.

Maybe something compact but more structured would be good. Could anybody provide an example of the current needs in an actual use case?

[fgalan]

Maybe something compact but more structured would be good. Could anybody provide an example of the current needs in an actual use case?

Do you mean for UL and LWM2M?

In the case of JSON, based on the comment from @dcalvoalonso

To the best of my knowledge, at least with https://github.com/telefonicaid/iotagent-json should be possible to send structured attributes.

I understand this issue is covered. Is my understanding correct?

[chicco785]

issue still there somehow, it is not possible to register a device with geo:json type of attribute, given that during registration the attribute won't have value and orion would bomb

[dherykw]

Hello @chicco785 if your project is using geo:json as static attribute you can skip the attribute in your device provisioning and add it directly to the OCB device (or whatever) entity.

It is not very elegant but it is the only way that we have found to provision it

Best :)

[fgalan]

Possible related issue (very recent, by the way): https://github.com/telefonicaid/iotagent-node-lib/issues/938

In addition to that, regarding

issue still there somehow, it is not possible to register a device with geo:json type of attribute, given that during registration the attribute won't have value and orion would bomb

This issue is about to support null in geo:json and DateTime, so ease this kind of scenarios: https://github.com/telefonicaid/fiware-orion/issues/3533. Maybe some brave developer in the community wants to take care of implementin it? ;)

Side-note: it seems that NGSI-LD doesn't allow nulls as attribute values (inexplicably :). In that sense, NGSI-LD is less flexible than the planned fix for NGSIv2.

[chicco785]

Probably it is much easier to fix it on the agent side, for example, during registration with proper payloads (i wonder which by the way...) or simply no "empty" attributes during registration (which I am not sure is a good choice)

[fgalan]

With regards to:

issue still there somehow, it is not possible to register a device with geo:json type of attribute, given that during registration the attribute won't have value and orion would bomb

This issue is about to support null in geo:json and DateTime, so ease this kind of scenarios: telefonicaid/fiware-orion#3533. Maybe some brave developer in the community wants to take care of implementin it? ;)

Issue https://github.com/telefonicaid/fiware-orion/issues/3533 has been solved. It will be included in CB 3.1.0 although, by the moment, it is available in :latest tag in dockerhub.

[fgalan]

Support for structured attributes in IOTA-JSON was already implemented (see also https://github.com/telefonicaid/iotagent-json/issues/697)

@dherykw @chicco785 for other independent related issues (if any) I'd suggest to open separate issues, please.