Behavior around const for properties' data schema

[egekorkan]

Talking with @ektrah, the use case with constant value properties came up. There is still the need to abstract a value of a Thing as a property but that never changes. A basic solution is to put const:myValue in the property and implement a behavior in the Consumer to not look into forms if const appears in the property level. The protocol can be anything, better to make it obvious that is not used.

What do others think?

[a-hennig]

I think there are factets to this ... let me try to explain on a hypothetical control algorithm running in the device

• constant property something to expose to the world, but it will never change, e.g. the algorithm identifier and version in the devices firmware
• default value in case no value is published (or omitted to save bandwidth, e.g. the manualOverrideState property is normally "off"/no override. This could also be used for a "reset to default" operation (e.g. similar to the relinquish to defualt in BACnet)
• the current value at the time of producing the TD ... because its changing so rarely, that can go into the TDD .. .but consumers are advised to monitor value changes, e.g. the setpoint of a target temperature
• a configuration value thats normally never changed, i.e. stable to be included in TM and TD ... and just in case available as property with polling/observing, e.g. the sampling rate / noise level to filter the sensor values before applying the algorithm

first would be server by "const"
second is solved by "default"
for #3 and #4 we could have something like a "td:value" or "td:currentValue" on property level.