Property class and conversion attributes

[ThomDietrich]

From #27 (comment)

Hey guys, great progress so far!
I did a little brainstorming with a colleague today and we found room for two improvements I'd like to discuss with you:

1. Property class/category: A property is a distinct reading or characteristic value produced by a node of a device. The other side of the network, the discovering entity, needs to know about the nature of this value (e.g. to show a thermometer in a GUI). We are already providing attributes to characterize its unit, range, pretty name and "set'ability" but not a clear type.
   A not-settable property with the unit "°C" does at best imply that the property is a temperature reading of a thermometer, not e.g. a thermostat or a nominal temperature. The discovering entity should not have to resort to guessing and interpreting of the other attributes.
   I propose a counted number of property classes to characterize the nature of a property. The $class or $category attribute is required but can be "Unspecified"/"Other"/"" for special non-trivial properties. The classes list can be extended over time and the discovering entity is allowed to ignore the provided class if unknown.

2. Conversion Attribute: When working with embedded systems or low-energy micro controllers, we can not expect the device to be capable to convert a raw sensor reading into a final human-comprehendible value. An example would be a temperature sensor reading between [0..255] which would map onto a degree Celcius value with decimal places.
   I propose the introduction of a $conversion property attribute. The published String value is either "x"/"" for no conversion or the right hand of an f(x) formula, e.g. x / 255 * 50 - 20.

Both points are of course open for discussion. What do you think?

[ThomDietrich]

Answer by @marvinroger

@ThomDietrich I see a problem with property classes. Imagine you have an heater node, with two properties: mode (off,comfort,night), and temperature. How do you assing a "class" to mode, for example? The most logical thing to do would be to assing classes to nodes, not properties. Therefore we would have heater, light, weatherstation... But this would introduce another problem: for the UI to be able to show a thermometer with the temperature embedded in the picture, we would have to define a standard set of properties for each class. Which defeat the flexibility of the homie convention, right?

For the conversion attribute, I am not that sure. It's rather complicated, and I don't see in practice what kind of value can't be computed directly on-device. I mean, even a 3$ chip is able to read a temperature in °C, °F.

[ThomDietrich]

Regarding property classes:
I don't think classes for nodes are meaningful. Nodes can consist of any number of properties and can represent a very special device with a special use case. We can't assign a class to that and even if we could (e.g. "generic weather station") what would be the use case for it?
On the other hand properties are basic properties of a device, represented by a number or other simple datatype. We've already agreed to add a unit and other things to educate the controller about the nature of this property.
However here's my issue with this: A property with [not settable, float, range [-100..200], unit "°C"] is clearly the reading of a thermometer.... clearly in the eyes of a human, a computer would apply some pretty wild guessing to come to that conclusion.
The key question is "How much does the controller need to know about the property?" (same question can be asked about the node)

I'll give an example from the openHAB world. A temperature "Item" (openHAB Items are nothing other than Homie properties) in my setup has a "fancy name", format (float) and a unit. So far so good! The Item furthermore has a "thermometer" icon and is part of the "ActualTemperatures" management/status group. I've got a rule in my setup checking all "ActualTemperatures" Items against a certain threshold to warn in case of frost. Similar things apply to other abstract categorizations of Items i.e. property classes.

In openHAB/ESH a similar idea is addresses in Channel Categories.

I'll leave this question open for others to think about. @marvinroger @Kwave @euphi

Regarding property conversion:
I think this is a very important aspect in the IoT world. Most µC might indeed be capable to convert values but is that always the way to go? Conversion introduces error, doesn't indicate resulting precision and a second conversion might still be needed (e.g. to present the temperature reading from above in °F).
On top of that I'd like to mention that the idea for a conversion attribute came from a colleague from the communication networks department at my university. Conversion costs time and energy. I have to admit, that you might not use MQTT and Homie when every Joule per bit counts but I learned, that MQTT (and CoAP) are becoming quite interesting in the area of wireless sensor networks (WSNs).

Besides, the conversion argument should of course be an optional one. It will not hurt to define the option for use cases where a conversion is needed and 95% of potential users can simply ignore it.

[marvinroger]

Well, indeed, it doesn't hurt
If classes for nodes aren't meaningful (and, with the discoverability introduced, it's not necessary anymore, in the past, I used it to know that a "shutters" node had a "level" property for example), do you think we should strip the $type node attribute?

[marvinroger]

@ThomDietrich ?

[ThomDietrich]

Too many ideas and todos, too little time 😅
I've not forgotten about this (and other) ideas and will add my PR soon!

[ThomDietrich]

@marvinroger for the sake of other improvements, let's not have this one in 2.1.0.

[marvinroger]

Agreed.

[davidgraeff]

Because there is $type for nodes, I have extended the idea in #92. Would also help with the ESH implementation where the UI interprets channel hints like <category>light</category>.

[kollokollo]

I seesome pro's having a conversion parameter. One can implement fixed-point values this way. Have an integer Number (e.g. coming directly from an ADC) + a conversion factor, gives a fixed-point number. You will not loose precision, if converted a second time (because you just use a different conversion number). This, of course, works only for linear conversion, basically for scaling. If you want to allow more complex conversions, then a whole formula needs to be defined.

Basically all values produced by measuring (digital) devices are integer or fixed-point values. I can hardly think of a real floating point measurement value...

And: linear conversion is the most common case: Have an offset plus a factor.

[mjcumming]

I am going to close this so we can keep all discussion in this thread.

#205