Zwave - FGRGBW RGBW Controller color_color control

Setup, Configuration and Use Runtime
, ,
1

Hi again,

I have noticed that the zwave RGBW controller (mine is a Fibaro) now includes the color_color control. Previously I created a rule to update the RGB dimmer levels based on a colour picker by grabbing the HSB values (as per examples on the internet). Having seen the new color_color control I decided to give it a go and it almost works perfectly.

The issue I see is that if I send the command (oldColour is an HSBType value);

newColour = new HSBType(oldColour.getHue(), oldColour.getSaturation(),new PercentType(newBrightness))

sendCommand(colourControl, newColour)

Whilst the colour seems to be correct, the brightness is always 99 percent. The brightness can be set correctly if just the dimmer value is sent to the control, e.g.

sendCommand(colourControl, newBrightness)

It seems that the color_color may not be reading the value correctly. The PercentType works for other colour changing bulbs, such as the Hue.

2

I can confirm this behavior.
The Brightness value does not do anything.
Maybe @chris can fix it ? :slight_smile:

Also, I think that still there is no way of controlling the WHITE channel from the color_color channel.
@Chris: are there plans to have a color class with 4 inputs (RGB + White)?

thanks

3

Each channel is controllable now - at least in my system it is
 Or are you after something different?

4

Hi @chris,
The current situation is as follows:
I can control the 4 channels using each single channel as a dimmer.
I can control the RGB channels with a single channel (color) using HSB
But I cannot control the 4 colors (RGBW) using a single command, i.e. SendCommand(zRGBW, “RRGGBBWW”) or SendCommand(zRGBW, “RR, GG, BB, WW”).

Like the openZwave COLOR_CC class that can set the individual levels of each channels to the device.

5

Is there a need for this? Clearly we can keep adding functionality to allow every possible option, but that would make things messy. What doesn’t the current function do that this would solve?

6

I know that it is something that can be achieved with rules, so, if it’s just me asking, then I will do it with rules.

What about the brightness problem identified by the OP and confirmed by me?

7

I think it can only be done with rules - even if the binding had an interface, there is no widget to support RGBW at this time.

I’ll look at it when I get time - part of the issue is that the ZWave spec says NOT to control brightness using color class, so it should use the multi level switch class which I thought is what is currently done?

8

Well, it’s not just a question of global brightness, but of color conversion:
Purple, #800080, (RGB=128,0,128), (HSB=300°,100%,50%)
Without proper “B” in “HSB”, we could never have Purple to work.

Maybe a stupid question, but why is the color class in HSB and not in RGB?

Because if it were in RGB I would be able to set my color intensity individually, while using HSB is much more complicated, especially if the “B” part is not working.

9

The color class does use RGB, but OH2 uses HSB which should get converted to RGB. I’m pretty sure I can get purple now (I think - it’s my partners favourite colour :wink: ).

10

I just checked the source code. The binding converts HSB to RGB - brightness is used in this conversion (well, I assume - I didn’t check this code as it’s in ESH, although I think I added it ;)). The binding then scales the values to keep the brightness of the colours at max (as ‘required’ by the standard).

To control brightness individually I would need to extract this and use the MULTI_LEVEL_SWITCH class - this can be done, but isn’t at the moment. This should not stop you getting purple though since HSB is used correctly as far as I can see.

When I get a chance I’ll do another test on this (maybe tonight or tomorrow).

11

Actually it scales to 99%
 not 100%


12

Sorry - what do you mean? Do you mean in the receive side or the command?

The command scales to a level between 0 and 255, so I guess you don’t mean the command now?

The receive side is always 0 to 99% in the ZWave protocol? In the multilevel switch converter I change this so that 99% = 100%, so it’s impossible to have 99% (but it seemed better and less confusing). I don’t do this in every class at the moment at least.

Does that answer your query, or maybe I misunderstand? (sorry).

13

Let me explain.
In the RGBW device there are 5 multilevel switch (switch_dimmers channels).
There is one global, and 4 for the R, G, B and W channels.
If you set the HSB color = 0,100,100 (RED) then the result is:
Global channel = 99 {channel=“zwave:device:controller:node7:switch_dimmer”}
Red= 100 {channel=“zwave:device:controller:node7:switch_dimmer2”}
Green= 0 {channel=“zwave:device:controller:node7:switch_dimmer3”}
Blu = 0 {channel=“zwave:device:controller:node7:switch_dimmer4”}
White = 0 {channel=“zwave:device:controller:node7:switch_dimmer5”}

Maybe you don’t set the global channel to 100?

14

In ZWave, it’s not possible to set a dimmer (ie multilevel switch) to 100% - only 99%.

Colors are different - they are scaled from 0 to 255 rather than 0 to 99.

15

But then why the RED channel dimmer is = 100?

16

Because of what I said earlier - the multi-level switch disregards 99 and sets it to 100. 99% anoyed people so as I said, if the value = 99, then I set to 100.

It’s worth noting that the binding doesn’t use the multilevel switch for setting colours - it uses the color command class. This sets a value between 0 and 255. The RGBW then sends a message for each channel using the multi-level switch class which is why the value gets updated to 100% in the individual channels.

17

Sorry to insist, but that’s exactly the point.
The {channel=“zwave:device:controller:node7:switch_dimmer”} (global channel) is not set to 100 but it’s left to 99. So what I was suggesting was to set also {channel=“zwave:device:controller:node7:switch_dimmer”} to 100 when it reaches 9 in order to avoid confusion.

Sorry if I am not clear


18

Try this example:
http://192.168.1.6:8080/classicui/CMD?zcRGBWtest=0,100,100

and then check the state of:

  1. {channel=“zwave:device:controller:node7:switch_dimmer”}
  2. {channel=“zwave:device:controller:node7:switch_dimmer2”}
  3. {channel=“zwave:device:controller:node7:switch_dimmer3”}
  4. {channel=“zwave:device:controller:node7:switch_dimmer4”}

this should clarify what I mean.

1 Like
19

I’m sorry - as I’ve said, in ZWave, it is not possible to set a dimmer to 100% - only 99%. This is the protocol.

If you mean simply that the dimmer for the main channel only shows 99%, then ok, we can change that, but it’s only a visual thing - I change it so that 99% displays as 100% - nothing else.

Is that what you mean? So, I’m having trouble understanding what your problem is as we seem to have changed topic from not being able to set the level, to now the display showing 99% instead of 100 and I assumed that we were still talking about the initial problem.

20

Hi, that’s exactly what I meant.

Actually the “99%” problem was part of the original topic, this is why I have insisted.

The brightness level issue still remains.

Anyway, thanks for looking into this.