HSB Colour + White channel in KNX: What's the "right" way?

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:

I now have the following objects:

and added the objects to group addresses as follows:

Group name Address Central Unfiltered Description DatapointType Security
On/Off - switch 5/1/68 true DPST-1-1 Auto
Dimming Brighter/Darker - relative 5/1/69 true DPST-3-7 Auto
Dimming Brighter/Darker - absolute 5/1/70 true DPST-5-1 Auto
Dimming Brighter/Darker - speed 5/1/71 true DPST-225-1 Auto
On/Off - status 5/1/73 true DPST-1-1 Auto
Dimming Brigher/Darker - status 5/1/74 true DPST-5-1 Auto
Failure Status - alarm 5/1/75 true DPST-1-5 Auto
Converter Fault Statistics 5/1/76 true DPT-12 Auto
Failure Exceeds Threshold - alarm 5/1/77 true DPST-1-5 Auto
Colour (HSV) Hue - absolute 5/1/79 true DPST-5-3 Auto
Colour (HSV) Saturation - absolute 5/1/80 true DPST-5-1 Auto
Colour White Dim - absolute 5/1/82 true DPST-5-1 Auto
Colour (HSV) Hue Fading - relative 5/1/83 true DPST-3-7 Auto
Colour (HSV) staturation - relative 5/1/84 true DPST-3-7 Auto
Colour White - relative 5/1/86 true DPST-3-7 Auto
Colour (HSV) Hue - status 5/1/88 true DPST-5-3 Auto
Colour (HSV) Saturation - status 5/1/89 true DPST-5-1 Auto
Colour (HSV) White - status 5/1/91 true DPST-5-1 Auto
operating hours - reset 5/1/92 true DPST-1-15 Auto
operating hours - time 5/1/93 true DPST-13-100 Auto
operating hours - alarm 5/1/94 true DPST-1-5 Auto

What I’m not really sure about though is how to wire up the openhab things file for the HSV + W(hite) channels.

So as far as I can tell one needs to 4 define values:


  • switch= for on/off
  • hue using hsb= (DPT=5.003)
  • saturation (unsure) position=???
  • brightness = ???
Type color  : KitchenNicheColor   "RGBW - kitchen niche color" [ switch="1.001:5/1/68+<5/1/88", increaseDecrease="3.007:5/1/69", position="5.001:5/1/70<5/1/74", hsb="5.003:5/1/79+<5/1/88" ]

And I’m going to assume for the white channel I would create a new thing of Type dimmer and reuse the brightness from the colour definition:

Type dimmer : KitchenNicheWhite   "RGBW - kitchen niche white" [ switch="1.001:5/1/68+<5/1/88", increaseDecrease="3.007:5/1/86", position="5.001:5/1/82<5/1/91" ]


  • 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.

Thanks @J-N-K that makes me feel a little better for not getting it working/unable to find a sensible example on different forums.

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.

1 Like

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.

Type dimmer : LightStudyCeilingDimmer      "Study Ceiling Dimmer"              [ switch="6/1/41+<6/1/45", position="5.001:6/1/43+<6/1/46", increaseDecrease="3.007:6/1/42" ]                       
Type dimmer : LightStudyCeilingColourTemperature "Study Ceiling Colour Temperature"         [ position="5.001:6/1/51", increaseDecrease="3.007:6/1/52" ]                  

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.


Which openHAB version are you using?

I’m on 3.2.0-SNAPSHOT - Build #2532

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.


Documentation is still missing. Use the hsb Parameter and specify DPT before GA: hsb="251.600:2/7/1"

@imaginator Did you have the chance to test?

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?


That’s really strange, because that should never happen and does not happen in my test setup. Can you do list -s | grep -i knx and show the result?


258 x Active x  80 x    x org.smarthomej.binding.knx
259 x Active x  80 x    x org.openhab.binding.knx

Wondering, that the 3.2.0 is active (again?)
Oh, damn: Maybe it got reinstalled after a restart, because i’ve it in the addons.cfg

Yes, that’s probably the case. Probably you can stop 259 and restart 258.

258 x Active   x  80 x    x org.smarthomej.binding.knx
259 x Resolved x  80 x    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.

I made a new build, can you try with

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.

So you want the 232.600 to use hsv instead of rgb, so the field for r carries h, g carries s and b carries v?