Timestamp of individual sensors

[ky0on]

What is the best way to store the timestamp when a sensor value is measured in sensor objects? For instance, temperature object does not have resources to store the timestamp.

[hannestschofenig]

The best way is to include an optional resource, namely reusable resource Timestamp (5518), in the respective object. You can find all object registered here: http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html

[valensd-etc]

@hannestschofenig I was going to ask the same question as @ky0on so thanks for your answer.

I have a follow up question: If I was to follow your suggestion to add a Timestamp resource to my object then I would need to observe an object instance to get both sensor value and timestamp at the same time. Is my statement correct? Could I still apply pmin or pmax attributes to the sensor value?

I am also correct in stating that wIth the composite observe in version 1.1 of the LWM2M spec this problem gets easier to solve?

Thanks

[sbernard31]

@hannestschofenig, you propose to "include an optional resource, namely reusable resource Timestamp (5518), in the respective object".

@ky0on talked about temperature object. I suppose this is the object 3303 (by IPSO).

So do you propose :

1. to add this optional resource to this object(3303) officially, meaning registering a new version to this object at OMA ?
2. or to create a new object like temperature (with a "private id" in corresponding range) and add this optional reusable resource ?
3. or just to custom the current temperature object "privately" (keeping the id 3303) by adding a optional reusable resources ?

If this is 3. I didn't know this was something allowed by LWM2M ? It is a new LWM2M 1.1 feature or this is already allowed for LWM2M 1.0. About Interoperability, SHOULD a LWM2M server be able to understand this kind of "object customization with optional reusable resource" ?

[RadioAct]

Hi All, I am also now stuck with this issue. We wish to know the time when a measurement was made and the simplest method to me would be to add an optional resource to many of the 3200-3300 objects to hold this time value. Essentially every object that is a measurement/observation/status should have an optional timestamp resource attached, but thing is I also need sub-second resolution and 'TIME' datatype does not cut it. A data type with fractional seconds could make this easier but oh well.

Proposal: I would love two optional resource types added to the items outlines above:

1. optional 5518 Timestamp
2. optional 5507 Fractional Time

For those who care, set the timestamp. For those who precisely care, set the timestamp and set the number of ms. Add the two together to get a better resolution timestamp.

In my use case we wish to know sub-second when this measurement was made and not to make measurements on a sub second rate. Partial second errors can add up over time.

Sucky Work Around: I am going to try and create objects in the "private id" range that use objlinks to point to the "official" objects. I will add the Timestamp and Fractional Time resources to our private objects. It is going to be a task to educate our clients...

[dirtyha]

We also need Timestamp and Fractional Time reusable resources into IPSO sensor objects. This is essential even if SenML and CBOR content type already now may contain timestamp in notification messages, but that is only if observe-notify is used AND if SenML/CBOR is used AND if LwM2M server implementation is able to provide it in the north-bound API to the application.

[40Grit]

Its well and good to add a timestamp but what if I want to aquire sensor readings and then send all of them up at a particular interval. How do I maintain the history of values that have been written to the object while still respecting observation requests from the server.

In this scenario we would be trying to decrease the affects of power consumption associated with bringing a radio up and down for every measurement that is relevant for characterization of data for modeling but does not fall within the servers observation request.

[RadioAct]

AFAIK is a fundamental problem in the way LWM2M works and one of the main reasons we are no longer using it. The way I see it, LWM2M is setup so that each and every measurement is reported at the time is was made, to the point that all devices are expected to be online at all times.

My Experience from 8 months ago, things may have changed: Our device makes readings at a configurable interval and we didn't want to bring up the RF each and every time. We tried to use the observes to set the reporting interval when all the collected measurements could be sent up. Observe of an item at limits or time would have the reading made at the trigger plus all the offline stored readings sent as a group. We tried sending multiple updates back to back at the trigger point but latency between the server and our app meant that the latest received message overwrites previous messages before the app received them. The only thing that worked was to pack all the readings into a blob and transmit that along but that goes against the good things the predefined structure has going.

[dirtyha]

Its well and good to add a timestamp but what if I want to aquire sensor readings and then send all of them up at a particular interval. How do I maintain the history of values that have been written to the object while still respecting observation requests from the server.

In this scenario we would be trying to decrease the affects of power consumption associated with bringing a radio up and down for every measurement that is relevant for characterization of data for modeling but does not fall within the servers observation request.

You can use the SEND feature of LwM2M v1.1 to build a batch of measurements and then send it to the server. The batch can contain multiple sensor value samples, lets say a sample per every 10 seconds. Timestamps can be included into the batch, because it is an inbuilt feature of SenML, "Timestamp" resource is not needed here. Then you can send the accumulated batch at the optimal interval to the server, lets say every 10 minutes. In LwM2M v1.0 things are a little bit more complicated, since you need to use the OBSERVE-NOTIFY which brings in a stateful logic between the client and server and is restricted to use json message format. In theory building batches and notifying the server should work in this case too, but I think not until v1.1 and SEND this can be properly solved. Unfortunately there are not many servers that support v1.1 and SEND though. "Timestamp" and "Fractional Timestamp" resources in IPSO sensor objects are still useful for ad-hoc READs made by the server to the client. In our application area sensor values can not be timestamped at the server side, the timestamp needs to come from the client.

[40Grit]

@hannestschofenig Can you let the product team at ARM know it's time to upgrade Pelion to 1.1?

[hannestschofenig]

Both timestamp and fractional timestamp is available for the temperature object.