No - all colours are the same. From memory there are 7 or 8 colours that can be set - RGB, WW, CW and a couple of others. They are all the same. The (so called) master channel then sets the level of all colours.
When in RGB mode, the binding sets the white colours (CW and WW) to 0 as some bulbs get upset when setting a W channel, and another colour.
The ZWave spec clearly states that the master channel (multilevel switch) is to be used to set the level of all channels, and therefore to turn it off.
You certainly can’t use the multilevel switch (ie dimmer as you called it here) to set just the white channel.
Can you point me to the manual you got this image from please? This seems to contradict the ZWave specs which states that all colour components are adjusted together.
I’m a bit confused - sorry. What is this W channel? Is it the same one that I’m referring to as WW or CW - ie the different colour channels in the ZWave device?
It is basically WW or CW, depending on what one actually connects to that channel physically. It is intended for a white light, hence the “W”.
As far as I see it, the W channel is NOT independent from the channels R, G and B as the switch multilevel in the picture shows: the multilevel switch affects all 4 channels in the same way. That matches the specification you mentioned, Chris, and it matches the behaviour we see.
It is a bit confusing as a users expectation would be different. But for that independence the vendor would have to implement a completly seperate endpoint with a multilevel switch for the W channel, which is not the case here.
The only way to meet the expectation from my p.o.v would be to take the setting for the RGG/HSB mode into consideration:
if set to HSB one could use HSB color controls, accepting that the white channel is affected in its brightness as well
if set to RGB mode one could only use the 4 dimmer channels to set brightness independently and the HSB color control would be ignored
It’s a bit strange to define it like this - many devices have both warm and cold, and allow the colour temperature to be adjusted by changing the levels of each. As I’ve already said, the colour channels (however many there may be) are all treated the same - be they CW, WW, R, G, B Purple or whatever.
What is this setting you mention? Is that something in the device, or in OH? I’m not aware of this?
@chris:
Imho we are still talking about different things:
I am talking about the physical device output named “white” or “w”.
You talk about the white (WW/CW) information of the color control message.
I asked further up if it is possible to use the color control channel to command the device outputs rgb and still use the switch multilevel channel to control device output w.
So even though the color control contains a WW and CW information it is my current understanding that it only affects the device outputs rgb.
To control the device output w I have to use a switch multilevel which seems to be independent of color control.
Let’s assume the device behaves as described. If you would change the master dimmer when sending a color control you will also make changes to the device output w even though that is not intended.
@stefan.oh
Could you confirm that the device output w is not controlled by the color control but only by the switch multilevel?
We’ll, I really don’t know, and I don’t have this device. I think neither of us know what this specific device does - maybe you are right and this is a special device that is different to others, but we’re really just guessing.
All I can go on is what the ZWave spec says. As @stefan.oh stated above, if the white channel was to be controlled separately, I would expect this to be a completely different endpoint so that it is a logically separately function. If everything is in one endpoint, then they are considered a single function, and the ZWave spec states they should be controlled together.
Yes, agreed, but this is what the ZWave spec says to do.
As I see it there are only 2 options available to me - leave it as it is, or change it so that when a colour command is used, the brightness is set. This seems the correct thing to do. The HSB command extends from the Dimmer, which extends from the OnOff - they are all part of the same channel, so when we receive an HSB, this brightness is for the channel - it’s not there just for colour, and if you send a dimmer command it’s for something completely different.
I still don’t know what the “RGG/HSB mode” is that was mentioned by @stefan.oh - do you know?
Technically we have a thing with 4 PWM controlled output channels. The controller operates in RGB(W) mode on the physical side, just changing the PWM output to the 4 output channels. The white channel is merely a fourth PWM channel, nothing more. HSB is only implemented in software, grouping the first three channels (meant for RGB) to be controlled differently. BUT: the “B” of HSB controls the brightness itself. For ALL OUT-channels, including the fourth (aka white) channel.
Hence:
No, I can’t. I found an illustration by Fibaro on their website. Unfortunately I cannot link directly to the illustration. When you open the online documentation and scroll down to “Operating the device” you will find two illustrations beneath that: one named “Operation in RGBW mode” and another named “Operation in HSB mode” (to see the illistrations you have to click on the blue title).
Both illustrations show that the brightness channel is applied to the white channel as well. In RGB mode if you have 50% red, 50% green, 50% blue, 100% white and set brightness to 50% you will have 50% PWM signal on OUT4.
In HSB mode hue and saturation are being converted to RGB values and brightness controls brightness (=switch multilevel), even for the 4th channel.
It is one of the parameters that can be changed, affecting the way hardware switches connected to the 4 input channels control the lights. It does not change the way you can control the lights by software.
As the dependency between brightness control and all 4 channels is part of the hardware design, I don’t think there is a feasible way to circumvent that by software. Seeing the diagrams I withdraw my suggestion from yesterday to take the RGB/HUE setting into consideration within the binding, it doesn’t make sense
I agree - all channels are treated the same as far as I can tell.
So it’s a device parameter? Can you point me at this please as I can’t see something like this in the database at least.
The device doesn’t know about HSB at all does it? It’s simply getting the colour levels via the color control class - it doesn’t get HSB (well, it gets B from the dimmer, but H and S come through the individual colours). Sorry - I’m still a bit confused about what this refers to.
If this is a setting in the device, then it’s not something the binding can use anyway as that would make the converter specific to this device.
There is a possibility to attach 4 switches to this device. In normal mode each switch controls the dimmer for the corresponding output (e.g. 1 -> r, 2 -> g). It is possible to set HSB mode, then input 1-3 will be used to set Hue, Saturation and Brightness.
Bit this setting does not change the behavior how is reacted to commands but rather how the output changes when the input changes.
So this can be ignored here
That parameter doesn’t seem to have anything to do with the way commands are sent to the device - it states that this is how the switches are interpretted if using local control - not how commands are sent to the device by remote control…
Brightness stays at 100% in this case. That means that the controller only works with hue and saturation to control the first 3 channels, which does not match Chris assumption:
The controller obviously does not receive a brightness information, only H and S, not B.
Changing the test case: switching RGB to 0% (switch_dimmer2 to 4 at 0%), I can control the brightness of OUT4 both by changing switch_dimmer5 (which controls OUT4) and switch_dimmer1 (or switch_dimmer, as one follows the other). Setting both to 50% results in the same brightness as having one of them at 25% and the other one at 100%.
Sorry, but it is 100% inline with my expectation and I think you’re getting mixed up with the quote you made.
The device DOESN’T know about HSB - only the binding knows about this. The binding converts HSB into the individual colour channels and sets them. It does not send the brightness (yet). This is fine and inline with my earlier statements and expectations.
What is “controller”? Do you mean the device? If so, that is correct as I have said above - currently I do not send the B - I only send the H and S. I have a PR ready to also send the B, but this is what is being discussed here.
Please let’s go back to what @Spaceman_Spiff originally asked.
Please can you advise what happens to the WHITE channel only. Does it change? I would expect it to go to 0% because when the binding is sending RGB, it also sets CW and WW to 0 (if they are supported by the device) since some devices do not like having both RGB and W channels powered at the same time. Please also provide the debug log in this case.
Just one other general point - I think we should recognise that this device is not a standard light bulb - it is a bit more “DIY” and provides separate channels to control individual colours if you want to work “outside the box”.
The general implementation in the binding should cater for a standard implementation, inline with the specs, and where possible provide the individual channels to control things in a more custom way if needed - this (I think?) we have?
Please provide the debug log so I can see what is happening. Maybe the device doesn’t report that it supports W channels, so the binding might not send these commands, or maybe the device ignores W being set to 0 if it was manually set to a value before the colour commands were sent. I know from the log from @Spaceman_Spiff yesterday that the binding was setting the W channel to 0 -:
It’s a bit strange to define it like this - many devices have both warm and cold, and allow the colour temperature to be adjusted by changing the levels of each. As I’ve already said, the colour channels (however many there may be) are all treated the same - be they CW, WW, R, G, B Purple or whatever.
