Using timestamped value in Send Operation.

[sbernard31]

Leshan contributor would like to know if it's possible to use timestamped Value in Send Operation with SenML format.
(see eclipse-leshan/leshan#1192)

I see nothing if the specification which talked about this. So my first guess was this is not allowed.

This little hint 👇 could confirm this idea (but it could be just a restriction of this new format):
In LWM2M v1.2 a new format was added LWM2M CBOR which can be used with Send Operation and I understand there is no way to add timestamped value. See http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/HTML-Version/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.html#7-4-4-0-744-LwM2M-CBOR

Currently Leshan API does not allow this.

Could you clarify this, please 🙏

[hannestschofenig]

Timestamped data can be used with SenML. Since SenML encoded data can be sent in the Send operation, it is possible to send timestamped data via the Send operation.

[sbernard31]

Thx for the quick answer. 🙏

I guess we need to change the Leshan API to allow this.

I'm not sure maybe I'm the only one, but as I said reading the spec I understood that was not allowed. Maybe some clarification should be added about that in the specification ?

[sbernard31]

@hannestschofenig, I think a bit more about it.

You say :

Timestamped data can be used with SenML. Since SenML encoded data can be sent in the Send operation, it is possible to send timestamped data via the Send operation.

SenML allows to send same resource with different timestamp in the same payload.
Reading your comment, I understand : if the encoding format allows something then it is allowed to used it.
So I guess this is also allowed to do that for send operation ?

But does that mean that I can used timestamped value with SenML using a classic request like Read Or Write request too ?

I guess sometime LWM2M bring some restriction to the used encoding format.
I supposed on a Read on 3/0/9 using SenML this was not allow to return different timestamped value for this resource.
I think maybe this need some clarification in the specification :

• where timestamped value can be used ? (E.g : [{"bn":"/3/0/","n":"9","v":80, "t":1643356835}]
• where multiple timestamped value can be used ? [{"bn":"/3/0/","n":"9","v":80, "t":1643356000}, {"n":"9","v":75, "t":1643357000 }]

Until now, I was thinking that timestamp was used ONLY for stored notification feature. (and so relative to observe)
(Resource : Notification Storing When Disabled or Offline (1/0/6) )

[sbernard31]

Another Leshan user ask for clarification about using timestamp on Read request : eclipse-leshan/leshan#1479.

It would help a lot to have clarification from OMA to be able to do right implementation choice 🙏

[sbernard31]

Another Leshan user ask for clarification about using timestamp on Read request : eclipse-leshan/leshan#1553.

Please could you clarify this 🙏

[sbernard31]

Every time the specification talks about SenML timestamp this is to refer to Historical representations. (Notification Storing When Disabled or Offline mode resource id:6 of Server Object)

So I think this is strong hint to not used timestamp in other case OR at least authors doesn't really think about that use cases ?

All point that I found in the specification :

At LWM2M-v1.2.1@core§7.5.6. SenML JSON :

Note: SenML time values (Base Time and Time) are represented in floating point as seconds and a missing time attribute is considered to have a value of zero. Base time and time are added together. In general, positive time values represent an absolute time relative to the Unix epoch, while negative values represent a relative time in the past from the current time. For details see [SENML].

Historical version of notifications are typically generated when "Notification Storing When Disabled or Offline" resource of the LwM2M Server Object is set to true (see Appendix E. LwM2M Objects defined by OMA (Normative)) and when the Device comes on line after having been disabled for a period of time.

And time description at LWM2M-v1.2.1@core§Table: 7.5.6.-1 SenML JSON format and description:

The time of the representation relative to the Base Time in seconds for a notification. Required only for historical representations.

(we same kind of sentence for old json format : (application/vnd.oma.lwm2m+json, 11543)

The only example is also about Historical representation (LWM2M-v1.2.1@core§Table: 7.5.6.-3 SenML JSON payload from example notification about a Resource containing multiple historical representations of a Temperature Resource:

For example, a notification about a Resource containing multiple historical representations of a Temperature Resource (ID:2) (e.g. Instance ID:1 of hypothetical Object ID 72) could result in the following SenML JSON payload:

[{"bn":"/72/","bt":25462634,"n":"1/2","v":22.4,"t":-5},
{"n":"1/2","v":22.9,"t":-30},
{"n":"1/2","v":24.1,"t":-50}]

---

Another hint, lot of LWM2M object has a Timestamp resource (E.g. /3303 or /5) :

The timestamp of when the measurement was performed.

We could imagine if this was added this is to have measurement time in other case than historical representations.

[sbernard31]

Some clarification about what I think of timestamp usage in LWM2M : eclipse-leshan/leshan#1623

[mkgillmore]

OMA agrees that timestamp should be allowed for READ and SEND opererations and will be addressed in v1.3

[sbernard31]

@mkgillmore,

• for SEND this probably makes sense.
• for READ and OBSERVE this is less obvious to me.

If OMA allow decide to make it usable for READ and OBSERVE, I hope OMA will clearly define how it should be used. (especially how it works with notification history)
I try to summarize my thought about timestamp for READ/OBSERVE at eclipse-leshan/leshan#1623
Maybe this could be useful to OMA when you will work on that.

If you want feedback from me to not hesitate to share your thought about that before the official release.