fix: color encoding and brightness

[Tieske]

replaces #297 fixes #296

[Tieske]

@schaze @Thalhammer any chance for a review? Once this is merged I'd be up for releasing the v5 version.

[schaze]

Sry, I am on vacation currently. I not sure I understand the recommendation regarding RGB. So far I always adjust the brightness value in addition to the color when an hsv or RGB color was set. Does your recommendation mean that device developers should ignore the brightness in the color value and only focus the color representation of it?

[Tieske]

thx, so that tells me it wasn't clear. Rewrote the text. Please have another look.

I'm a bit in doubt though. The color systems are complex, so an alternative could be to add a paragraph to the "Implementation notes" chapter specific to the color schemes, where there is more room for a longer explanation. Wdyt?

Does your recommendation mean that device developers should ignore the brightness in the color value and only focus the color representation of it?

Depends on the usecase, but at least when using xyz, then brightness should be a separate property anyway (since it cannot be part of xyz). In those cases, I think it should also be ignored if an HSV or RGB value is set.

The type is scoped to a single property. So if you set the color property to an RGB value which then also changes another property for the brightness, that would be outside its scope.

So imho the developer should choose: color only, or color+brightness, and then act accordingly.

[jacoscaz]

Hi all. First comment here, after learning about Homie and digging into it over the last few months. Take my words for what they're worth at this point - very little.

From a device implementor standpoint and insofar as I can understand, rgb, hsv and xyz are mathematically equivalent representations (minus brightness) and so should be easily converted into whichever format the hardware requires (again, minus brightness).

From the perspective of a control system implementor, however, the best choice is, IMHO, no choice at all and I think the most flexible option to settle on would be rgb and a mandatory brightness property that is kept in sync with the former (changing one affects the other and vice-versa) or always set to 100% (settable: false) for devices that do not support brightness.

This would make color control uniform across all devices, even those that only support a subset of it (color only, no brightness).

[Tieske]

In Homie 4 (see https://homieiot.github.io/specification/spec-core-v4_0_0/) we had hsv and rgb which are equivalent because they both convey brightness and color.

Iirc xyz was added (by @schaze) because many devices use xyz as format, and the conversions are hard to get right. This however introduced the problem, of xyz carrying less information than the other two.

There are use cases for both cases; color+brightness in one property (in html, or status lights like LEDs), as well as for separate brightness and color properties (color-light bulbs).

So the current text might give the impression that it is either one or the other, and leave no option for a device designer to create two coupled properties. I have adjusted that.