Here you go. Hope it covers the information needed. Node49 is the relevant one
debug.log (62.8 KB)
Thanks, but unfortunately there are no commands (ie setting HSB/Level etc) in this log, and nothing much sent to node 49 (just a parameter request).
If you want to view the logs, you can use the viewer -:
I’m making myself familiar with producing debug logs as I had no need to do that yet. So please take my apologies for my mistake.
It should now cover what you are looking for, containing a few HSB commands.
debug2.log (633.2 KB)
1 Like
No problem - thanks…
So, for your device it’s different than with @Spaceman_Spiff. For some reason, the binding does not set the W channel -:
The binding only sets the W channels (WW / CW) if the device has reported that they are supported, so maybe your device has not reported this - I’ve no way to know from this, although it should be indicated in the XML file for the device. Anyway, this is why the white remains unchanged in the above test - I just don’t know why it’s different than from @Spaceman_Spiff…
I think I will make the change to the binding to set the multilevel switch using the brightness - at least this should then be inline with what the protocol docs state. Let’s see how that looks and we can continue to discuss as needed…
If I can assist with testing (as long as I have the time to do it) I’m game. Just let me know…
1 Like
Thanks. I’ve made the change already - I’ll try and submit the PR later today and I’ll post back here… I’d appreciate the feedback - hopefully a) it works, and b) it’s no worse than the current system, even if it might be different
extract from .xml shows warm white as supported
<entry>
<commandClass>COMMAND_CLASS_SWITCH_COLOR</commandClass>
<COMMAND__CLASS__SWITCH__COLOR>
<version>3</version>
<instances>1</instances>
<control>false</control>
<versionSupported>3</versionSupported>
<supportedColors>
<colorType>GREEN</colorType>
<colorType>RED</colorType>
<colorType>WARM_WHITE</colorType>
<colorType>BLUE</colorType>
</supportedColors>
<refreshList/>
<colorMap>
<entry>
<colorType>GREEN</colorType>
<null/>
</entry>
<entry>
<colorType>RED</colorType>
<null/>
</entry>
<entry>
<colorType>WARM_WHITE</colorType>
<null/>
</entry>
<entry>
<colorType>BLUE</colorType>
<null/>
</entry>
</colorMap>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__SWITCH__COLOR>
</entry>
Imho it comes down to this:
If the device has additional outputs that are not controlled by the color control the binding may not use the master dimmer to set the brightness. It then has to map the brightness part of the HSB command to the individual values (e.g. ww, cw, r, g, b, amber, cyan, purple)
If all outputs are controlled by by the color control the binding should (as the z-wave spec suggests) use the master dimmer.
But what does that mean? I don’t think it’s possible to know what this is?
If a bulb supports (for example) Red, Green, Blue, Warm White and Cold White, are you saying it should not use the level control command to set the levels? Even though the ZWave spec says it should be done this way, and even if a user of such a bulb is now unable to use the bulb?
Again, there is no way to know this - the device simple reports all the colors it supports and they are all controlled by the color command class.
I have connected a white led strip the my device output w and I can confirm that every time I send ca HSB command to the color control endpoint the white led strip turns off.
So now I am asking myself how I can controll all outputs with one command or at least keep output w constant.
@chris:
Is it possible to post a command with the 7 tuples (from the z-wave spec) through a string item to control all outputs simultaneously?
Nope - never said that.
As I said earlier, this is expected. It is done this way as some devices don’t work at all if white is on, and you set RGB. Sorry - but I end up struggling with everyones different devices - someone wants something done way way, while if I do that it will stop something working for someone else.
All I can think of is to add a new mode to the binding to support RGBW rather than just RGB. It could be a string as you suggest.
But you said “the binding may not use the master dimmer to set the brightness”, and I assume that this means the level control command as we’ve been previously discussing.
As I said, there’s no way to detect if a device “has additional outputs” - it reports ALL outputs, and I don’t know if it’s a kind of DIY device like this, or a lightbulb that supports RGB.WW.CW. For the latter, we need to support different modes - RGB, color temperature (fading between WW and CW) and for some bulbs, if we operate the white channel while operating RGB, it will not work.
I somehow need to juggle everything here in the impossible task of making everyones devices work in the way that each individual wants - it’s not easy when there are thousands of different devices and ZWave is a really messy protocol that is quite ill defined in some ways (ZigBee has a much cleaner definition that mostly avoids wierd use cases).
Instead of using the master dimmer one could transform the HSB values to rgb and just set the values in the z-wave message accordingly. E.g. HSB 0,0,100 → 127,127,127 instead of 255,255,255 and master dimmer 50%. But these are internals and don’t matter in the end.
I just wanted to confirm that the device is working as you assumed.
My whole intention here was to
- first clearly describe how everything behaves
- discuss how it should behave
- discuss if there need to be changes.
I never wanted you to change anything (yet) and certainly not so fast.
If a device reports all its outputs my previous argument is void and there is nothing wrong with using the master dimmer. I was not aware of that.
Couldn’t you derive the required tuple from the reported device information?
E.g. my device would require 4 value pairs (25,33,45,99) and the device from stefan only three?
That way the channel would be generic and work with all dimming devices.
Also is the max value passed in 100 or 255? I tend to 255 since this is more advanced.
Except that’s not how the protocol definition says it should be done. It also makes it extremely complex to manage in the binding as we now have different commands that are doing different things. As I said earlier, the B, in HSB is overriding the Dimmer - if you just send a dimmer command to the color channel (as you also do in your log) then how do I do what you suggest? I could of course remember the state of the RGBW values, or try and read them back and then scale them in some way, but it’s not very easy and I think it will not result in a consistent, or compliant, implementation.
No - I think that’s getting complex - how do I (or more importantly, you) know what the numbers mean if we have to rely on the device? You’d need to check the XML to find the colours that the device has reported, and then what order are they in. As I presented earlier, there are 7 possible colours defined in the spec, so I think this is too messy.
Instead I propose something like this -:
A String that is formatted as RED=xx,GREEN=yy,WARM_WHITE=zz etc. The names are the names as defined in the spec (or at least as defined in the binding -:
WARM_WHITE(0, "Warm White"),
COLD_WHITE(1, "Cold White"),
RED(2, "Red"),
GREEN(3, "Green"),
BLUE(4, "Blue"),
AMBER(5, "Amber"),
CYAN(6, "Cyan"),
PURPLE(7, "Purple"),
The user can set whatever they like, and the binding would send the commands for supported colours. On top of this I would add another “colour” which is LEVEL=aa to allow the master channel to be set.
Any channel (including LEVEL) that is not defined will not be changed. All values are 0-255 - not percentages.
How does that sound? I think this gives the user maximum control and flexibility?
Sounds great, but even better would be to allow the name and the abbreviation (ww, cw, r, g, b, a, c, p).
Also my personal preference would be colon but that’s just eyecandy and I don’t have a strong opinion about it.
e.g.
red:255,green:255 would be equal to r:255,g:255 or
red=255,green=255 would be equal to r=255,g=255
Would it be level or master? The latter might be more “speaking”.
I think it sounds great. It’s generic, flexible, can be understood easily and doesn’t require much documentation.
1 Like
I was thinking of using the enum that is already defined in the binding. This means that everything is consistent - ie the XML will also say the same thing, and any database additions that might one day be required would also use the same enum. If we use different names in different places, there’s the potential for confusion, and if ZWave add more colours, we could end up with conflicts.
Fine - no problem with that 
I would suggest level, since that is what is being set - it’s the “multilevel - level” that we are setting. Maybe in your device Fibaro have called this “master” but that may not mean a lot for other devices.
Cool - thanks. Hopefully we’re nearly there
I’ll take a look at this in a day or two - it’s not too much work to add.
Hmm, I’d really like some kind of short notation.
How about positional support?
e.g.
10,,50,100,150,,, would be the same as
warm_white:10,red:50,green:100,blue:150
No hurry - I have a workaround in place so everything is working well on my side.
How do you envisage using this? Will it be a rule and if so, does it matter if the notation is a little long? You’re not expecting a user to type this in manually I assume are you, and IMHO using red=1,green=2,purple=4 is a lot easier to understand what you’re doing than 1,,2,,,3,,. We don’t need to go back to the days where variables in programming languages were single letters 
Again, this relies on “secret knowledge” - people need to get the right number of commas in the right place. I would prefer something more foolproof.
The other option we’ve used a lot in the ZWave binding is json, so we could instead use that rather than the colon delimited notation.
Yes - it will be from a rule. You’re propably right - i was just thinking about readability in the logs.
hm, json would be like this:
{"warm_white":50,"red":100,"green":150,"blue":200}
vs
warm_white:50,red:100,green:150,blue:200
I like the latter batter because it’s more readable.
Hi there,
I have purchased two FGRGBW-442 RGBW Controller 2 devices, too. I’m experiencing the exact same behavior as @KlausStoertebeker described in his topic start: Both devices turn on the red color on the RGBW led strip, but it seems that I cannot change the color when using the Color_color1 channel from the openhab Control panel in paperUI. I did not notice a difference in behavior when switching parameter 150 from 0 to 1 (RGB/HSB mode): red remains red.
I started reading all posts from the beginning and it is a fascinating read. I definitely learned a thing or two about the interaction of a device and a binding. However I’m not convinced that the problem @chris, @Spaceman_Spiff and @stefan.oh are resolving is actually going to solve the problem as described in the start of the topic.
If someone could summarize how the reported problem was traced back to a root cause with an apparent solution (that is not yet available) then that would be great, for my understanding. At the moment I’m somewhat lost and to me it seems that the topic has a little bit been hijacked. However this could also relate fully to the lack of knowledge I’m suffering from.
It is not - I kind of hijacked the thread - sorry.
Because this parameter is only relevant if you connect a physical input switch to the device.
These are the item definitions.
Dimmer RGBW2_All {channel = "zwave:device:controller:node44:switch_dimmer", autoupdate="False"}
Color RGBW2_RGB {channel = "zwave:device:controller:node44:color_color1", autoupdate="False"}
Dimmer RGBW2_W {channel = "zwave:device:controller:node44:switch_dimmer5", autoupdate="False"}
First send command 100 to RGBW2_All, then you can send HSB Commands to RGBW2_RGB.
Just make sure to never send ON or OFF until Chris provides a fix.
Then the device should work as expected.
If it doesn’t then there might be another issue we need to look at.
I created the items and they appear fine in the paperUI control panel. when I set the
RGBW_All item to 99 (yes I know, clicking on a slider is not my thing) I see that also in the eventlog. It seems that it triggers a chain of events:
2020-10-20 22:45:21.001 [ome.event.ItemCommandEvent] - Item 'Erker_RGBW_All' received command 99
2020-10-20 22:45:22.632 [vent.ItemStateChangedEvent] - Erker_RGBW_All changed from 0 to 45
2020-10-20 22:45:22.704 [vent.ItemStateChangedEvent] - Erker_RGBW_Consumption changed from 0 to 0.4
2020-10-20 22:45:22.780 [vent.ItemStateChangedEvent] - Erker_RGBW_RGB changed from 0,0,0 to 0,0,49
2020-10-20 22:45:23.068 [vent.ItemStateChangedEvent] - Erker_RGBW_RGB changed from 0,0,49 to 276,45,60
so then I changed the color item to blue-ish, and again a chain of events is logged:
2020-10-20 23:08:42.966 [ome.event.ItemCommandEvent] - Item 'Erker_RGBW_RGB' received command 187,45,60
2020-10-20 23:08:43.500 [vent.ItemStateChangedEvent] - Erker_RGBW_RGB changed from 276,45,60 to 273,44,60
2020-10-20 23:08:44.806 [vent.ItemStateChangedEvent] - Erker_RGBW_All changed from 45 to 100
2020-10-20 23:08:44.959 [vent.ItemStateChangedEvent] - Erker_RGBW_RGB changed from 273,44,60 to 273,44,100
2020-10-20 23:08:45.240 [vent.ItemStateChangedEvent] - Erker_RGBW_RGB changed from 273,44,100 to 224,34,60
… and my LED strip end up being red again. I’m lost as the input never seems to be forwarded to the device and I doubt 224, 34, 60 is the color code for red