fix: attribute loss when updating entity

[GuillaumeOd]

related to #1660

[AlvaroVega]

As a commented here #1660 (comment) a test case about his issue is needed.

[fgalan]

@GuillaumeOd please have a look to documentation in the case it has to change to describe the new behaviour with this PR.

[AlvaroVega]

This PR is reverting this commit: 166f771

[fgalan]

@GuillaumeOd not sure if I'm getting the point...

You want to send measures like this:

{
  "fireDetectionThreshold": 10
}

and get corresponding attribute at CB this way:

                    "fireDetectionThreshold": {
                        type: "Number",
                        value: 10
                    }

is my interpretation correct?

[GuillaumeOd]

@fgalan Yes, exactly! Regarding the type, I'm not entirely sure if it should be Number or Text, but your interpretation seems spot on.

Could you try running the test locally without my fix to confirm it fails as expected?

[fgalan]

@fgalan Yes, exactly! Regarding the type, I'm not entirely sure if it should be Number or Text, but your interpretation seems spot on.

In that case, why don't use at provisioning time

                            {
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

instead of

                            {
                                object_id: 'f_dt',
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

?

[tzzed]

@fgalan we already send data like this

{
    "fireDetectionThreshold": 10
}

or by using the oid:

{
    "f_t": 10
}

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality?
We really need this fix? In case of devices that use oid the iot agent does not support it anymore.
You can see the test of @GuillaumeOd and try it without the fix.
Thank you again.

[fgalan]

@fgalan we already send data like this

{
    "fireDetectionThreshold": 10
}

or by using the oid:

{
    "f_t": 10
}

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality? We really need this fix? In case of devices that use oid the iot agent does not support it anymore. You can see the test of @GuillaumeOd and try it without the fix. Thank you again.

So, you mean that you have some devices that are sending like "f_t": 10 and at the same time you have some other devices that are sending like "fireDetectionThreshold": 10.

Is my understanding correct?

[tzzed]

Yes exactly. Somes use object_id and othes use the name.

[fgalan]

OK. Much clearer now :) Thanks!

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality? We really need this fix? In case of devices that use oid the iot agent does not support it anymore. You can see the test of @GuillaumeOd and try it without the fix. Thank you again.

It was not an intentional change (but not within our use cases, so it was not noticed by us).

Thus, the PR is ok, as long as:

1. Merge master on this PR's branch to check all test keep working
2. This patch on the library has to be checked with IOTA-JSON, IOTA-UL and IOTA-Manager unit test. I'll take care of it, once you complete step 1

What do you think?

[tzzed]

Great thank you! that's work, @GuillaumeOd it's in your hands.

[GuillaumeOd]

thanks @fgalan ! I just merged master to the branch. Please notice that the test I added was failing because of a type error. The expected is:

fireDetectionThreshold: { type: 'Number', value: 10 }

but for some reason we receive:

fireDetectionThreshold: { type: 'Text', value: 10 }

Is this the normal behavior ?

[fgalan]

thanks @fgalan ! I just merged master to the branch. Please notice that the test I added was failing because of a type error. The expected is:

fireDetectionThreshold: { type: 'Number', value: 10 }

but for some reason we receive:

fireDetectionThreshold: { type: 'Text', value: 10 }

Is this the normal behavior ?

Given the provision is

                            {
                                object_id: 'f_dt',
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

I guess that the correct one is

fireDetectionThreshold: { type: 'Number', value: 10 }

@AlvaroVega what do you think?

[AlvaroVega]

@AlvaroVega what do you think?

I think both branch and test were aligned.

[GuillaumeOd]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

[fgalan]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

It should be Number, as it is in the current test. Thus, I guess that the code needs some extra fix to align with the tests.

[GuillaumeOd]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

It should be Number, as it is in the current test. Thus, I guess that the code needs some extra fix to align with the tests.

I agree, shall I investigate it by myself ? The link with my PR is unlikely but I can try to find the fix and add it to this PR

[fgalan]

I agree, shall I investigate it by myself ? The link with my PR is unlikely but I can try to find the fix and add it to this PR

It would be great :)

not apply