Device Streams allow driver to set timestamp.

[AdamMagaluk]

In drivers today a device driver implementer has no control over the timestamp in the streams on streams. The timestamp is generated when stream.write() is called.

For example:

config.stream('stream1', function(stream) {
   // The timestamp is generated when stream.write() is called.
   stream.write("some-data-value");
})

This would be helpful in a few cases where you're receiving events from your device with a timestamp set on the physical device.

Some possible options for implementing:

// Input an array with 2 elements, [timestamp, value]
stream.write([new Date(), "some-data-value"])

// Input an an object with timestamp and data element.
stream.write({ timestamp: new Date(), data: "some-data-value" })

[mdobson]

I like #2.

-Matt

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472 |
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee | Apigee Community
http://community.apigee.com/ for answers, ideas and support!

On Tue, Mar 1, 2016 at 12:21 PM, Adam Magaluk [email protected]
wrote:

In drivers today a device driver implementer has no control over the
timestamp in the streams on streams. The timestamp is generated when
stream.write() is called.

For example:

config.stream('stream1', function(stream) {
// The timestamp is generated when stream.write() is called.
stream.write("some-data-value");
})

This would be helpful in a few cases where you're receiving events from
your device with a timestamp set on the physical device.

Some possible options for implementing:

// Input an array with 2 elements, [timestamp, value]stream.write([new Date(), "some-data-value"])

// Input an an object with timestamp and data element.stream.write({ timestamp: new Date(), data: "some-data-value" })

—
Reply to this email directly or view it on GitHub
#292.

[kevinswiber]

Timestamps are, always have been, and always will be problematic. The biggest problem is that there are too many events for which you could grab the time.

Relating to device data:

• Time the event occurred on the physical device.
• Time the event was published to the event stream.
• Time the event was received by an intermediary, such as when Zetta is acting as a proxy in a peering scenario.
• Time the event was forwarded to the client.
• Time the event was placed in long-term storage.

And if we really tried, we could probably find 5 more.

Some questions:

• Should Zetta, by default, always include the timestamp of when the event was published to the stream? This is one of the few timestamps we know reliably.
• Could a device driver include its own timestamp in the published data? This would leave it up to the driver implementor to make that decision.

This would make the timestamp on events standard, reliably the time the event was published to the stream, always. The idea of changing this based on a driver implementor's whim makes me a little uncomfortable. It changes the reliability promise.

[AdamMagaluk]

I agree there is a number of events you could get the time from but I think in most cases what the consumer of the api is going to want is the time closest to the event happening whether that's provided by the physical devices or supplied by the zetta hub that it's connecting through in cases where the physical device doesn't have a RTC.

I think all the other timestamps you refer to are things we might/probably want in the internals of zetta and potentially used as someone who hosts zetta but not as the timestamp that's important to the consumer.

[kyork-cl]

Zigbee has a device type called an IAS Zone, which deals with security devices like door and motion sensors. One of the features of this type of device is that it can implement "guaranteed delivery" of messages. This means that when it sends an event to the network coordinator, it will save a copy of the message until the coordinator acknowledges it. If the message is not acknowledged, it will resend the message until it is, buffering any new messages.

Whenever a buffered message is resent, it includes a time delta since it was originally recorded. The network coordinator can look at this time and realize this is a "past" event and not a real-time notification.

In this case, it would be nice to be able to override the timestamp of the stream to match that of the delayed events actual time of happening.