How to know the age of the information

[ghost]

When connecting a client, the the last known retained properties are send to the client. How does a client know how old this information is?

The convention contains an attribute uptime, but I can't find an attribute that describes the timestamp of this uptime.

Use cases where a timestamp is useful:

• A node is down. A client connects and can see this from the $state and likes to indicate how long the node was down for.
• A node reports very infrequently. How to tell when the information was last updated?
• Uptime is the time since the last time a sensor updated its information. How to know when that was?

Any insights would be greatly appreciated.

[timpur]

Timestamp is hard because we don't want to force devices to have to get the time just to be homie compliment.

Your probs best using a node red flow to publish the timestamp for you as the last sent value of the device or something.

Or probs best to make a node or something (hack the device attributes) to post your own timestamp.

[ingoogni]

By having Homie publish an $interval at witch the data should arrive. #53 is a proposal, though with the current ESP8266 it can be done already this way even if it's not specified in the convention. Infrequent data transmissions are always "cumbersome", but an interval with a reasonable $property attribute $format from:to for $interval could be used. Just a time stamp without an interval is generally meaningless for such purposes, as it tells us nothing without the above mentioned interval. If an interval is known a time stamp from the / a broker suffices.

@timpur, a time stamp is no different than a (geo)location, it is just a location on the time axis instead of on a location vector in an n-dimensions space. There are (naive) ways to implement it with generally sufficient accuracy but it is not done because of the burden on the tiny processors we use.

[ghost]

Thank you for the feedback.

As an FYI, I'm working on a openzwave binding (in golang, using goopenzwave) that is (hopefully) homie compliant. There can be lots of nodes and it is important to identify the ones that are offline, for example when the battery ran out.

It is tricky indeed to do this right. It can't be required for the reason @timpur points out. Yet there are cases where the information is useful. Node red looks awesome but it its quite the dependency to add just to identify when a node went offline.

I don't quite understand how using interval solves this but I disagree that a timestamp without an interval is useless. The interval makes it more useful as it can be used to determine if the last update time is overdue. The use-cases listed revolve around clients that just connected and don't have a history, eg they depend on information provided by 'retained' to obtain state.

Using an attribute for timestamp is not ideal either as it requires a separate message which increases the number of messages significantly. Yet it seems to be in line with the philosophy for this convention. What I'll do is create a node attribute called 'updated' to indicate when it was recently updated. eg /home/deviceID/nodeID/updated = "2018-05-07T02:47:01Z"

I propose to make this a convention, eg $updated as an optional attribute, but being new to this project this might be out of line, so take it as a suggestion of a noob please :)

Thanks again,

[timpur]

@hspaaij, if your building a binding, id just show the last received message for that device. Just build it into the binding, i know its not nice, but i don't see timestamps becoming part of homie as a required thing for the reason that its not available to microcontrollers and should be forced to be required.

I am also building a autodiscovery binding for homie atm in python for HA, my recommendations to you any anyone else building a autodiscovery binding, are read the doc im about to publish 'recommendations when building a autodiscovery binding' :P also build the Homie binding logic as a separate lib that is not dependent on anything but the mqtt lib. This allows for others to use the binding directly in their own projects and any new platforms.

Not sure how you do this over z-wave, but interested to hear :)

[davidgraeff]

timestamp = currentHostTimeInS() + ( homie/device/$stats/uptime / homie/device/$stats/interval * 60) which works as long as the device is online.

As long as there is no fixed time reference on the client device, you can't get a more detailed information. Fixed time references are impossible without internet access or a DCF77 receiver or a battery powered stored time counter. It would be a burden to require this for Homie.

[ingoogni]

Sorry, my answer was completely off, misunderstood the question completely.

Can you tweak a broker to publish a 'recived' timestamp along with retained messages?

[ghost]

@ingoogni, Yes ideally the broker could track it as part of retained messages. That would be ideal but probably a bit harder to standardize on. @davidgraeff Understood, it can't be a required attribute as not all devices have a timer. Although I wonder how many small devices without timer would be able to run an IP stack.

In my case where a computer runs a binding that connects via a hub of some sort (like for example a Z-Wave stick), the node (Z-Wave sensor) also doesn't have a timer. The binding adds the timestamp when receiving node sensor data from the hub. It would be nice to have some sort of standard rather than roll my own convention for timestamp.

Thanks for the discussion. Appreciate the feedback.

[ingoogni]

To keep the broker untouched, another option could be to write a small client that listens to the original message and either inserts a TS at a certain point in the topic string and your client only listens to the modified topic. Or that small client just creates an extra topic with the TS as if it were coming from the Homie device .

Sensor+Homie --> broker ---> TS_client ---> broker ---> your client

@davidgraeff 's solution is the simplest if it fits your needs.

[timpur]

@hspaaij, sadly i don't think this will be considered to be added as part of the convention, at lest not as a required field, you can push for it to be added as non required but for now i'm just going to close this.

[ghost]

Thank you all for the feedback. Again, it is appreciated. I'll experiment with the suggested options. Cheers