What’s the “right way” to get RGBW (from an MDT DaliControl32) channels defined in OpenHAB. I realise that DPT 251.600 for RGBW colour isn’t native to OpenHAB. So I guess I want to understand how others have worked around this.
The MDT DaliControl32 has different colour control options:
RGB
HSV
RGBW (seperate channels)
RGBW (DPT 251.600)
XY (DPT 242.600)
Based on my understanding of how OpenHAB handles colours, it seems to make sense to setup the the controller to work in HSVW mode:
Is this the “right way” to deal with RGBW definitions in OpenHAB?
what would I use for saturation and brightness values in the things definition?
I sometimes see the HSB value as a DPT of 232.600 but in my setup the hue value is 5.003 (degrees). But looking in the source code it seems that OH checks for this and acts accordingly.
what am I defining wrong in my .things definition?
there’s no example of Type color on the knx documentation? Any idea why?
The reason there is no example is most probably that this is totally broken. There is no code that could separate saturation from HSB. I‘ll have a look in the next days if this can be fixed.
The only workaround I know that works here is to have 4 separate dimmer items for H, S, V and the White channel. It’s not nice, because you cannot use the colorpicker in the sitemap, i.e., you don’t see the color you are choosing. I would also hope that somebody who is familiar with the dpt types implements a way to read in DPT 251.600 and split it up into an HSB item and a Dimmer item for the white channel. It seems, this exists already for OpenHAB, but not for the KNX binding.
Btw, I tried to recombine the 4 separate items into HSB and a dimmer via rules. But this did not work due to delays between the action and the status message in KNX. The values were drifting. The problem must be solved at the root by using DPT 251.600 with a single group address.
Interestingly enough I observe that for colours lights we create one thing. However for lights that switch between cold white and warm white one must create two things.
One could imagine that the colour tunable component is just a colour function of the thing and somehow have it as HSB or as a new element inside a Type color thing.
If you uninstall the KNX binding, download you should have a version installed that allows using DPT 242.600 and DPT251.600. The latter can be used on color channels (RGB component) and dimmer channels (W component). I don’t have any such device, so I can only test by sending command from/to the ETS but that works.
Hi, as I’m also dealing with this topic, I’m jumping in:
I installed your version (uninstalled the original one, before). But in the log, i’m getting the following warning:
[WARN ] [.internal.handler.DeviceThingHandler] - DPT ‘251.600’ is not supported by the KNX binding
As awaited, no data is sent to the KNX.
The thing is defined as follows:
Type color : OG_WohZi_Li_RGB1 "LED Farbe" [ hsb="251.600:11/3/141+<11/4/141", switch="1.001:1/0/142+<1/1/142", position="5.001:11/3/145+<11/4/145" ]
I’m unsure about your implementation. But I understood it that way, that there’s no translation from HSB to RGBW values, e.g. when using the color-picker. It just allows control the white component via separate channel by support DPT 251.600, is that correct?
258 x Active x 80 x 3.2.7.202110290334 x org.smarthomej.binding.knx
259 x Resolved x 80 x 3.2.0.202110290514 x org.openhab.binding.knx
Ok, looks somehow more plausible in the log, now:
[WARN ] [ding.knx.internal.channel.KNXChannel] - Configured DPT '251.600' is incompatible with accepted types '[class org.openhab.core.library.types.HSBType, class org.openhab.core.library.types.OnOffType, class org.openhab.core.library.types.IncreaseDecreaseType, class org.openhab.core.library.types.PercentType]' for channel 'knx:device:bridge:rgb:OG_WohZi_Li_RGB1'
Looks, as if i need to adjust/play around with my thing definition, now.
That’s also strange. I tried configuring the same via GUI and I don’t see that. And in fact it’s wrong. 251.600 supplies HSBType.class which is in the list.
And yes, you need a second channel with type dimmer for the white-part of RGBW.
Okay, I’ll try that. I’ll discard my playground installation and create a new one from scratch to do more testing. Just to be sure, that there are no other side-effects.
Would it be possible to implement some kind of translation from HSB to RGBW, as for DPT 232.600, which translates from HSB to RGB (loosing the white-channel)?
The most interesting way (and maybe easiest) to preserve control over the white-channel with a color picker would be, to set DPT 232.600 to an optional HSV mode, which allows to use the MDT actuators directly. But this does not match the specs of the DPT and I’m wondering that MDT is allowed do that with their certified product.
I don’t get what you are requesting. If you use a color channel, you can control RGB, if you use a dimmer channel, you can control W. Isn’t the color channel exactly what you want? It ignores the W part.
Edit: Oh. 232.600 is RGB only, what has the W channel to do with it? I was thinking of 251.600.
Well, it’s at least a compromise between the available solutions. The interesting part on that is, especially with the modern 4 and 5 channel actuators/strips, to get a bigger color range and more natural white (better color rendering) while using the color picker.
The HSV color model (or similar) brings this along out of the box, and a couple of 4/5 channel actuators of today support HSV input (as the MDT products do). Beside that, color pickers very often work with a HSV based color model internally.
In fact, I actually control my stripes by splitting the HSB object of OpenHAB into it’s components and feeding the actuator with each single (one byte) H, S and V object, instead of using the HSV combo-object, as DPT 232.600 would automatically translate to RGB for KNX.
But this has a drawback for the status feedback from the actuator to the color picker: I again have to use the single components, which arrive serialized and cause some headaches with regard to the rule triggers.
There are algorithms to calculate a white channel from RGB and at least one new KNX actuator has this as built-in feature.
Of course, all this only works fine, when the luminosity of the r, g, b and w LEDs is balanced and I’m talking only for KNX.
