Added initial version of last-updated extension

[maxberger]

See https://github.com/homieiot/convention/issues/191 for discussion.

[maxberger]

Sorry for the late reply, my life kept me busy. I am now back and trying to get this into good shape.

I do see a strong push for consistency from multiple side, and I would like to propose yet another alternative.

Option 1: Keep the proposal as-is, addressing the comments above.

Option 2: Completely re-think the prosposal and provide both the value and the last-updated in the same property. So here is what we could do:

• The extension would be a more generic "value-with-metadata" extension.
• The original value would always be published as normal, but
• An additional "extended" value would be written. This value would follow a common format (probably JSON), and would contain additional meta information, which combines both the value AND the last-updated, and possible other things in the same update

Example:

• homie/super-car/wheels/pressure/ → 32
• homie/super-car/wheels/pressure/$ext → "{value: 32, last-updated: 123456}"

Of course, here we could run into the same consistency issues, but at least a client could look at either one of the two values. It would also eliminate the need for a "0" timestamp.

Pros:

• Extensible
• In it self consistent
• Writing JSON is cheap.

Cons:

• Duplication of values
• clients which would need the extended data would need to parse JSON

wdyt?

[davidgraeff]

Writing JSON is cheap.

Homie has deliberately not used JSON anywhere. For extensions this should be fine, especially if multiple values need to be kept in sync. It if is a fixed known amount of values, CSV could be an option as well though.

[ThomDietrich]

Hey all, I see how option 1 is flawed (https://github.com/homieiot/convention/issues/191#issuecomment-580298368) but option 2 I would avoid as well.First of all as @davidgraeff said, we decided to stay clear of JSON and we should try to uphold this principle for consistency. Furthermore, an extension for "value with metadata" feels too far fetched. Remember that one can always implement additional topics with arbitrary complexity in parallel to what is defined by Homie. The Homie convention is here to aid automatic discovery of devices. An extension to process a last-updated makes sense, some generic metadata does not so much.

Following my interpretation of use cases for this extension (@maxberger this should be part of the intro) I propose a third option: The extension defines two topics:

• $last-updated - epoch time as defined so far, e.g. "1579965965"
• $last-value-updated - A combination of value and epoch time, e.g. "12.5;1579965965"

This combination offers a dateime-only topic to directly get a timestamp for keep-alive use cases, and an atomic value-datetime pair for instrumentation/monitoring use cases. Justification for having both would be the ease of processing on both the client and controller side.

Does this cover all use cases? Does anyone dislike the redundancy?

[maxberger]

Like the idea; added this to the extension as well.

[ThomDietrich]

There is one further design issue we need to discuss. @davidgraeff please add your two cents.

In the Homie convention dollar topics are used to provide metadata for controller-side feature discovery of a device. Your "last-updated" topic communicates data. This is clearly not in line with the convention. Therefore, I think we need to discuss one further change to the topic structure of this extension. Wdyt?

[mjcumming]

@maxberger to get around this problem I created a jython script

https://community.openhab.org/t/asynchronous-events-to-synchronous-event/95198

[mjcumming]

@maxberger and @ThomDietrich

see http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718105 from @Thalhammer in #200 There is ordering of MQTT messages of the same QoS.

Would adding a property attribute $lastupated and specifying that this attribute must be updated after the value has been set solve this is?

[Thalhammer]

@maxberger and @ThomDietrich

see http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718105 from @Thalhammer in #200 There is ordering of MQTT messages of the same QoS.

Would adding a property attribute $lastupated and specifying that this attribute must be updated after the value has been set solve this is?

While acording to the rfc MQTT should be ordered withing one qos value, I don't think we should rely to badly on it. Not all brokers might follow the spec that closely.

[maxberger]

I no longer have the time to follow up with this.