I try to summarize all information about timestamped in LWM2M and Leshan.
2 different Timestamp use cases :
Reading LWM2M specification, I see 2 kind of very different timestamp usage :
to express the timestamp of when a sensor measurement was performed
to express historical data in notifications when "Notification Storing When Disabled or Offline"
Sensor Measurement Timestamp
Sensor measurement use case is pretty clear. Often a LWM2M resource value of a LWM2M Object is measurement of a physical sensor. This value is measured at some time and this time is what we called sensor measurement timestamp
So if later you read a LWM2M node containing this kind of resource you could now exactly the date/time when this sensor value was measured.
Historical Data Timestamp
This use case is less obvious, LWM2M client could use "Notification Storing When Disabled or Offline".
So when client is offline and should have sent a Notification (from Observe request), it will store the whole notification value and timestamped it.
E.g. :
Server observes object location (/6/0)
Client send the whole instance 0 of object /6 which means with all resources without timestamp.
Client goes offline
An event should generate a notification, but client is offline so it store object the whole instance value and timestamp it (the whole instance must be present with all resources and all resources timestamped at same time, the time where the notification should have been sent).
More event when offline, means more timestamped instance.
6.Client goes online and send an update request then the notification with historical values. (each instance with all value and each with a different timestamp)
How they looks like in LWM2M ?
In LWM2M v1.0.x
In LWM2M v1.0.x this is pretty clear.
Sensor Measurement Timestamp is done by adding a timestamp resource to an object for sensor resource.
E.g. For object Location(id:6), a resource "Timestamp" (id:5) was added which means "The timestamp of when the location measurement was performed."
Lot of objects have this kind of timestamp resource (3302, 3318,3422,3312,3430,3450,3428,3332,3416,3320,3435 and so much more)
Historical Data Timestamp only 1 format allow to express historical data : JSON (which is based on a draft of SenML :draft-jennings-senml-10) and the LwM2M-v1.0.2 is clear at *6.4.4 JSON** :
The time fields MUST only be used when sending notifications.
...
Historical version of notifications are typically generated when “Notification Storing When Disabled or Offline” resource of
LwM2M Server Object is set to true (see Appendix D.2) and when the Device comes on line after having been disabled for a
period of time
What about Leshan API/behavior ? It just follow that specification and it just works as expected. Sensor measurement can be read in a LwM2mSingleResource. Historical Data can be get via a List<TimestampedLwM2mNode> in notification only and if both concept are used at same time there is no problem.
In LWM2M v1.1.x
In LWM2M v1.1.x this is less clear because new SenML content format chapter bring confusion ...
The SenML JSON format also includes optional time fields, which allows for multiple versions of representations to be sent in the same payload or indicating the time when the representation was created (e.g., measurement made).
Some begin to think that "time fields" could be used for Sensor measurement timestamp in LWM2M. But this is inconsistent with LWM2M-v1.0.x ideas. I would rather bet this is a mistake in this chapter which try to explain SenML RFC. Especially when you know that SenML format is just an update of previous JSON format to upgrade from draft-jennings-senml-10 to released rfc8428. From my point of view this is regrettable copy/past from RFC8428 - SenML : "... the time the measurement was made ..."
By the way later it is said about "time fields" : "Required only for historical representations." (same sentence in LWM2M v1.0.2 in JSON chapter.)
Some argue that timestamp exists in SenML, LWM2M uses SenML so you can use timestamp in LWM2M.
This argument sounds not so good because :
LWM2M have concepts. LWM2M is based on several existing RFC. LWM2M concepts should be translated in RFC concepts. Be based on a RFC does not means you will reuse all feature of that RFC. There is lot of example in LWM2M specification which illustrate that.
Even if it was a good argument. OK LWM2M uses SenML so you can use timestamp in SenML but no just anyway. For sure for Historical Data Timestamp but FMPOV not for Sensor Measurement Timestamp for reason explained above.
Is there a problem to use SenML "time fields" for "Sensor measurement timestamp" use case ?
I see at least 2.
How does it works when you are using Sensor measurement timestamp and Historical Data Timestamp at same time ?
Specification doesn't specify how to understand/use "time fields" and so this could lead to interoperability issue...
I seriously think the clear separation of LWM2M v1.0.x was good enough :
You need Historical Data Timestamp, use "time fields" !
You need Sensor measurement timestamp, create a dedicated resource in your model !
I try to summarize all information about timestamped in LWM2M and Leshan.
2 different Timestamp use cases :
Reading LWM2M specification, I see 2 kind of very different timestamp usage :
Sensor Measurement Timestamp
Sensor measurement use case is pretty clear. Often a LWM2M resource value of a LWM2M Object is measurement of a physical sensor. This value is measured at some time and this time is what we called sensor measurement timestamp
So if later you read a LWM2M node containing this kind of resource you could now exactly the date/time when this sensor value was measured.
Historical Data Timestamp
This use case is less obvious, LWM2M client could use "Notification Storing When Disabled or Offline". So when client is offline and should have sent a Notification (from Observe request), it will store the whole notification value and timestamped it.
E.g. :
/6/0)0of object/6which means with all resources without timestamp.How they looks like in LWM2M ?
In LWM2M v1.0.x
In LWM2M v1.0.x this is pretty clear.
Sensor Measurement Timestamp is done by adding a timestamp resource to an object for sensor resource. E.g. For object
Location(id:6), a resource "Timestamp" (id:5) was added which means "The timestamp of when the location measurement was performed."Lot of objects have this kind of timestamp resource (3302, 3318,3422,3312,3430,3450,3428,3332,3416,3320,3435 and so much more)
Historical Data Timestamp only 1 format allow to express historical data : JSON (which is based on a draft of SenML :draft-jennings-senml-10) and the LwM2M-v1.0.2 is clear at *6.4.4 JSON** :
What about Leshan API/behavior ? It just follow that specification and it just works as expected. Sensor measurement can be read in a
LwM2mSingleResource. Historical Data can be get via aList<TimestampedLwM2mNode>in notification only and if both concept are used at same time there is no problem.In LWM2M v1.1.x
In LWM2M v1.1.x this is less clear because new SenML content format chapter bring confusion ...
LWM2M-v1.1.1@core§7.4.5. SenML JSON says :
Some begin to think that "time fields" could be used for Sensor measurement timestamp in LWM2M. But this is inconsistent with LWM2M-v1.0.x ideas. I would rather bet this is a mistake in this chapter which try to explain SenML RFC. Especially when you know that SenML format is just an update of previous JSON format to upgrade from draft-jennings-senml-10 to released rfc8428. From my point of view this is regrettable copy/past from RFC8428 - SenML : "... the time the measurement was made ..." By the way later it is said about "time fields" : "Required only for historical representations." (same sentence in LWM2M v1.0.2 in JSON chapter.)
Some argue that timestamp exists in SenML, LWM2M uses SenML so you can use timestamp in LWM2M. This argument sounds not so good because :
Is there a problem to use SenML "time fields" for "Sensor measurement timestamp" use case ?
I see at least 2.
I seriously think the clear separation of LWM2M v1.0.x was good enough :