Question regarding LWM2M, SenML and grouping records together

[kipusoep]

Hi ther!

Just a quick question regarding the LWM2M temperature object (3303). It has a resource 5700 for the Sensor Value and a resource 5518 for the Timestamp. So how do I group those together, if they are seperate records in a SenML pack?

Example:

[
    {
        "0": "0/5700",
        "2": 22,
        "-2": "/3303/"
    },
    {
        "0": "0/5518",
        "2": 1725011800
    },
    {
        "0": "0/5700",
        "2": 23
    },
    {
        "0": "0/5518",
        "2": 1725011810
    }
]

The 1st and 2nd records belong together and the 3rd and 4th as well. Should it be interpreted like 'group records together until a resource is encountered that we already had before'? Using the SenML time property instead could help (group records by object, instance and timestamp), but is that the right thing to do?

Thanks in advance.

[akeranen]

Yes, typically with SenML you would use the name, unit, and time fields to group records together. Here moving the Timestamp value to the SenML time field when sending the data forward seems like a good solution, unless you need to retain the information about the specific Resource ID for Timestamp.

The LwM2M spec also discusses this option for sending multiple historical representations.

[kipusoep]

Thanks for clearing that up @akeranen! We had a discussion with the hardware team and they brought up that SenML is just the transportation layer. So if we would use TLV or whatever instead, it would be better to use the LWM2M timestamp resource (5518) instead of the SenML timestamp property. So now we decided to group by object and instance and then add further grouping when multiple duplicate object/instance/resource combinations are found. So in the example above 2 groups would be created and parsed.

[akeranen]

Indeed, if you are exchanging the data in LwM2M context and keeping feature parity with the TLV format is important, then yes, that makes sense. I don't now recall if the LwM2M spec says anything about the order of the records in this case so you might want to check if you can rely on this. For communicating with external systems the time field might be a safer bet.