Interoperability issue while writing individual resources ?

[reds71]

We're implementing LWM2M software on the device side, with minimal requirements (contiki mote) and were suprised to received PUTs on individual resources using TLV for individual resources instead of plain text or opaque formats. Of course, the specification does not forbid it, but our understanding of the 6.3 chapter is that constrained clients may not support TLV for individual resource as a corollary to Client MUST support the TLV data format for Object Instance or multiple-instance Resource requests. I think this was also your interpretation of the spec if we refer to bug #27. What's your opinion on the subject ? Note that will are considering to support TLV on individual resources if the required footprint is not too important. BR, Stéphane

[sbernard31]

I understand the spec in the same way. And I just take a look to the code and it seems that we try to do that. In case where no format is given, we use plain text for individual resources and TLV for multiple resources. If we don't know the "kind" (individual or multiple), we use TLV. On which resource URI did you test it ? Maybe it is not described in our objectspec.json model ?

[reds71]

I noticed the problem on custom resources, and you're right, I had to modidy objectspec.json and lw-resources-services.js. It seems that the behavior is not the same for standards objects and the one we added, although their metadata seem to be similar:

send plain TEXT:

  {
    "name": "LWM2M Server",
    "id": 1,
    "instancetype": "multiple",
    "mandatory": true,
    "description": "",
    "resourcedefs": [
    ...
    {
        "id": 6,
        "name": "Notification Storing When Disabled or Offline",
        "operations": "RW",
        "instancetype": "single",
        "mandatory": true,
        "type": "boolean",
        "range": "",
        "units": "",
        "description": ""
    },

and seems to send TLV:

{
    "name": "LED",
    "id": 1004,
    "instancetype": "multiple",
    "mandatory": false,
    "description": "",
    "resourcedefs": [
    ...
    {
        "id": 1,
        "name": "On",
        "operations": "RW",
        "instancetype": "single",
        "mandatory": true,
        "type": "boolean",
        "range": "",
        "units": "",
        "description": ""
    },

I do not exclude and error of diagnosis, but I succeded in updating the "standard" boolean and failed for the custom. Do you see a reason why standard & custom objects could be processed differently in Leshan (I do not known the code enough to tell this) ? Thank you!

[sbernard31]

There are no reason the behavior was not the same. For leshan there are no custom or standard object, there are just known objects (described in objectspec.json) and unknown objects.

How did you test that ? In eclipse IDE, if you just modify the file the project is not rebuild and you will not have the new file in your bin directory, so you need to clean the project to trigger a build manually !

[reds71]

We simply unzipped the jar, modified the 2 files and zipped it back... I know, it's dirty but see no reason why it could be the reason of the behavior. It did change the Leshan display with what we expected. We could also check the impact of the type field on what was send for the LED custom object (we made initially a mistake setting it to string instead of boolean and did see 0x31 arrive in the 3 bytes TLV instead of 0x01). I also just check that we receive the 1541 content type for 1/0/6 which explains why it works. If you have no idea of what's happening, don't bother: our usage may not be supported yet and I will try to debug Leshan as soon as possible (even if not used yet to git & leshan code...).

[sbernard31]

Yep, no idea ... I am longing to know what happened ! (You talked about 2 files ? objectspec.json and lw-resources-services.js that's right ?)

[reds71]

I will try not to let you in such a hangout for too long ! I would not be surprised if the error was on our side, unfortunately I'm a little busy currently to start debugging Leshan right now...

Yes we noticed that Leshan interface was not impacted by modifying only objectspec.json and we had to copy the changes in the javascript file. I guess that is was not easy to "serve" the JSON file in the jar and simpler directly in the .js. We did not check if objectspec.json at the root package is ever used by the code or simply documentary.

[sbernard31]

I currenly work on a way to simplify the additions of object specfications to leshan (#46 )

[sbernard31]

I just fix an issue about your problem. I push the new feature #46 which will avoid you to unzip and modify the jar. HTH

[sbernard31]

I thought about that and we could probably be able to find the good format even if we don't have the definition for the given object by looking at the LwM2mNode structure.

[sbernard31]

I made the changes I talked about above. If you found time, please, tell us if those changes fix your problem. We take feedbacks for #46 too. Thx :)

[sbernard31]

I close this issue. If you still meet this problem. Do not hesitate to reopen the bug.

[reds71]

Sorry, I don't have a minute to work on the subject currently. I will let you know my experience asap. Thank you for your help !

[sbernard31]

No problem :)