add functional test case about how use special word valueas a name of attribute

[AlvaroVega]

IMHO this test case demostrates which #1660 is working

[fgalan]

CC @tzzed @GuillaumeOd what do you think?

[GuillaumeOd]

Thanks for the test, @AlvaroVega. It’s working fine on my end as well. However, in some cases, we’re sending attr_name as a JSON value instead of object_id.

For example:

{
    "a": false,
    "value": 10
}

As expected, this change causes the test to fail. It doesn’t seem to be related to the "value" string itself, as I tested with other random words, and it still doesn’t work. From what I understand, this change appears to remove the capability to update a device attribute by name.

What are your thoughts?

[AlvaroVega]

Then maybe you can define your attribute with a conditional expression:
"expression": "value? value : t"

[GuillaumeOd]

I suppose the core question from my previous comment is this: should we only be updating an attribute using its object_id, or should we still have the option to update it by its name, as was possible before this change ?

[AlvaroVega]

I suppose the core question from my previous comment is this: should we only be updating an attribute using its object_id, or should we still have the option to update it by its name, as was possible before this change ?

measures should use object_id

[GuillaumeOd]

The doc is still showing examples of measures sent by attribute names.

https://iotagent-node-lib.readthedocs.io/en/latest/api.html

You can find examples at "Multimeasure support" and "Measurement transformation" sections.

Please consider the test added to my PR and reproduce it in local without my fix in order to demonstrate this.

[AlvaroVega]

The doc is still showing examples of measures sent by attribute names.

https://iotagent-node-lib.readthedocs.io/en/latest/api.html

Regarding with Device to NGSI Mapping section:

• object_id (optional): name of the attribute as coming from the device.
• name (mandatory): ID of the attribute in the target entity in the Context Broker. Note that id and type are not valid attribute names at Context Broker. Thus, although a measure named id or type will not break the IoT Agent, they are silently ignored and never progress toward Context Broker entities.

[tzzed]

@AlvaroVega I am not sure to understand what you say.
Do you mean that if the entity contains an attribue:

temperature: {
            value: 10,
            type: 'Integer',
            creDate: 1730990416.543879,
            modDate: 1730990416.543879,
            mdNames: []
        },

the iotagent cannot send

{
 "temperature": 42
}

What about real life? you mean only the oid works? What about the previous behavior?

[AlvaroVega]

What about real life? you mean only the oid works? What about the previous behavior?

Of course you can send as a measure an attribute name which will be part of entity, but then do not include it in device attribute mapping, like ac3f194, or simply put the same name in object_id and name attribute, or even more do not define object_id, just name attribute 10167df