RGBW: Setting White Channel Value Should Not Change Value Of Color Channel

[fh-eureka]

Expected Behavior Changing the value of an Item linked to White channel should not affect the value of the item linked to Color channel.

Current Behavior Changing White channel value could affect the value of Color channel (increases brightness).

Steps to Reproduce From REST UI: Get Color Item -> "0,0,0" Get White Item -> "0" Post White Item -> 50 Get Color Item -> "0,0,50"

Detailed Description The Color channel should be independent of the White channel. It should represent the value of R,G,B channels. Currently if you set the Color channel (let's say to "0,0,100") it will not affect the White channel (it will remain "0"), which is the expected behavior. But the if you set the White channel (let's say to "50") it will affect the value of Color channel (if Color was "0,100,20" it will become "0,100,50")

Context (Environment)

• OH2 Version: 2.3.0
• Binding Version: 2.4.0.201809261735

[cdjackson]

Changing the color temperature will clearly change the color - they are the same set of data and commands. Color is another view on color temperature.

It would not be easy to separate the two.

[fh-eureka]

If the W channel is part of the color (IMO it should not be) then setting the color to "0,0,50" should change all channels R, G ,B and W to to 50%. Currently it does not. It only changes R, G and B to 50%. W remains 0%. (Actually all channels in OpenHAB remain 0% but I guess that's another bug, BUT the LED lights on the device itself change to R=50%, G=50%, B=50%, W=0%)

My point is: currently the effect is only in one direction! So it should either be in both directions, or there should be no effect. I think Color and White should be completely independent. (and that's how it is in Fibaro HC)

Consider the following scenario: Device is OFF. Set W to 50 --> Color becomes "0,0,50" and LED (R=0, G=0, B=0, W=50) Then Set Color to "0,0,50" --> Color remains "0,0,50" but LED (R=50, G=50, B=50, W=50) So we changed the actual device state without changing any value (just by applying the current value again)

[cdjackson]

setting the color to "0,0,50" should change all channels R, G ,B and W to to 50%

Generally, it is not possible on most devices to control both color and the white channels at the same time. Most devices will only allow either the color leds to be on, OR the white leds. The binding therefore works like this, otherwise most devices will fail to work.

I think Color and White should be completely independent. (and that's how it is in Fibaro HC)

As above, this isn't possible. If we set the color control, then we have to disable white and vice-versa.

[fh-eureka]

Generally, it is not possible on most devices to control both color and the white channels at the same time. Most devices will only allow either the color leds to be on, OR the white leds.

Ok. Then that's another reason to separate W from Color channel.

I think Color and White should be completely independent. (and that's how it is in Fibaro HC)

As above, this isn't possible. If we set the color control, then we have to disable white and vice-versa.

Not possible to make them independent?! I don't see why!

I think the main confusion here is that you think the color channel value should represent the entire current state of the device. It should not (and it can not). The color channel should be a logical representation of RGB channels (not RGBW channels).

[cdjackson]

Not possible to make them independent?! I don't see why!

They are all linked. When you change white, you have to disable color. They are not separate in the ZWave command class - they re intrinsically linked.

[fh-eureka]

They are all linked. When you change white, you have to disable color. They are not separate in the ZWave command class - they re intrinsically linked.

Which command class? Color Switch Set Command? According to the Z-Wave specification: "This command is used to control one or more color components in a device." I can see that it can be used to set the W channel (they call it color component), and it will not affect the current values of other components (such as R, G, and B). So the components are completely independent they are not linked. Changing the W component should not change the RGB values.

Anyway I see in the Fibaro RGBW xml file "fgrgbw_0_0.xml" that the W channel is not linked to COMMAND_CLASS_SWITCH_COLOR. It is linked to COMMAND_CLASS_SWITCH_MULTILEVEL:5 Correct me if I'm wrong, this means that when we change W channel we are not sending COMMAND_CLASS_SWITCH_COLOR (with W component) we are sending COMMAND_CLASS_SWITCH_MULTILEVEL?

So I don't think the issue is related to how we are sending the W value. It is related to how we're processing the REPORT commands.

From the attached log file: NODE 14: Color report RED 0 NODE 14: Color report finished {GREEN=0, BLUE=0, WARM_WHITE=121, RED=0} NODE 14: Got an event from Z-Wave network: ZWaveColorValueEvent NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_COLOR, value = 0 NODE 14: Updating channel state zwave:device:32303136-3131-3033-3030-303031353434:node14:color_color to 0,0,0 [HSBType]

This is working as expected. After setting W to 121 (using COMMAND_CLASS_SWITCH_MULTILEVEL:5 = 50%) the device reported the values WRGB = 121,0,0,0 The COLOR channel was updated correctly to HSB=0,0,0 (Because the color channel is linked to and represents the values of RGB only. Not WRGB)

Then after that: NODE 14: Received COMMAND_CLASS_SWITCH_MULTILEVEL V1 SWITCH_MULTILEVEL_REPORT NODE 14: Switch Multi Level report, value = 47 NODE 14: Got an event from Z-Wave network: ZWaveCommandClassValueEvent NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 47 NODE 14: Updating channel state zwave:device:32303136-3131-3033-3030-303031353434:node14:switch_dimmer to 47 [PercentType] NODE 14: Updating channel state zwave:device:32303136-3131-3033-3030-303031353434:node14:color_color to 47 [PercentType]

Here I think we are incorrectly changing the COLOR channel. Because in the device xml file the COLOR channel is mapped to both COMMAND_CLASS_SWITCH_COLOR and COMMAND_CLASS_SWITCH_MULTILEVEL.

I'll change the xml file and do some testing.

openhab-color-report.log

[cdjackson]

"This command is used to control one or more color components in a device."

Yes, but in general, bulb implementations do not allow both color and white modes to be used at once. The binding therefore implements such modes.

I can see that it can be used to set the W channel (they call it color component), and it will not affect the current values of other components (such as R, G, and B).

Some bulbs may implement this, but most I have come across WILL NOT allow white to be set when color is set.

The discusion that has been had elsewhere (I don't recall where) is that color temperature should be reflected in the color channel - this was a discussion with @kaikreuzer some time back, and I believe was meant to be reflected in all ESH devices to provide a common implementation. I believe the idea was that at the end of the day, white is still a color, and it can therefore be reflected in the color channel.

[fh-eureka]

Some bulbs may implement this, but most I have come across WILL NOT allow white to be set when color is set.

That's a device limitation, not a Z-Wave specification. So I think it should be a setting parameter / flag in the device xml file to specify if this device support W+RGB at the same time or not.

The discusion that has been had elsewhere (I don't recall where) is that color temperature should be reflected in the color channel - this was a discussion with @kaikreuzer some time back, and I believe was meant to be reflected in all ESH devices to provide a common implementation. I believe the idea was that at the end of the day, white is still a color, and it can therefore be reflected in the color channel.

But that's not how it is currently implemented in the Z-Wave binding! (as you can see in the attched log above). And if that needs to be changed please make it optional. For example two binding modes that we can chose between: <property name="binding:*:HSBType">COMMAND_CLASS_SWITCH_COLOR;colorMode=RGB</property> AND <property name="binding:*:HSBType">COMMAND_CLASS_SWITCH_COLOR;colorMode=RGBW</property>

BTW. Can you please provide a way to override internal device xml file by providing external xml file. That will provide more flexibility, and allow support custom devices (such as Z-Uno).

[cdjackson]

And if that needs to be changed please make it optional.

If this is how ESH defines a channel, then it should not be optional. In order to make the system work properly, I believe all bindings should implement channels in a consistent way. Otherwise we end up in a state where someone with a Hue binding needs to know that it will work one way, and ZWave binding will operate differently.

Can you please provide a way to override internal device xml file by providing external xml file.

Sorry - that’s not possible. This is a limitation of ESH (short of writing a custom system to implement a new provider - ie not using the standard provider)

[giig1967g]

With the Fibaro RGBW controller controlled by OH2 I can have switched on at the same time the color leds and the while leds. Of course I need to send two consecutive commands to achieve that, but it works.

[codyrickmanvessel]

Hello, I am having an issue with the Qubino RGBW Dimmer. Specifically with the White Channel. Whether I update the _color_temperature channel via paperui or via rest api the light turns on properly, but the item value immediately goes back to 0. This is an issue since I need to be able to read the white channel brightness when someone physically changes it via a switch on the input.

When the item value goes to 0, the physical light remains on the specified brightness.

Based on my observations, the only item/channel that changes based on real world control of the dimmer is the _color_color channel. The On/Off switch and standard dimmer values do not change at all. Is this a limitation of the database definition?