Please take a look at the PR -:
I’m not sure I can comment on this as I don’t know what you are doing. I can really only comment on what the binding does and there are tests in the binding to ensure this is working each time it is compiled.
I just had a look at the database - maybe I’m not looking at the right device, but from what I can see there is no channel (still!) that uses this colorMode. Someone needs to actually add this to the database if it’s not there (I might be looking at the wrong device of course).
This is the payload
red=50,level=10
which I am sending to the color_control channel of a Fibaro RGBW 2.
I understood that post in a way that this this was an extension of the exiting color_control channel.
But that made things more clear:
Shouldn’t every device that have the color_control automatically have the the colorMode, too?
My understanding was that internally this uses the same endpoint.
I dont really know what is causing your error. As I said, I can really only comment on the binding side.
No - as always, this channel must be added. There are a number of channels available, and each channel must specify the colorMode.
Just to add that I did say a few weeks back that the database needs this adding,
I’ll summarize what my idea of this is so please check if I understood it correctly:
The colorMode is not a new channel but rather an “extension” of an existing channel.
It has to be specified in the database that the color_control channel supports the colorMode.
Not really.
All colour channels have to have a colorMode specified. This specifies if it is a white balance, colour (RGB) or whatever. Each channel must specify the mode and a channel can have only one mode.
I hope that makes sense? I implemented this quite a long time back now (about a year I think) and I’d assumed it had been tested - I’m not able to test it myself other than with the static tests in the binding test classes as I don’t have any colour devices at the moment.
So we need a new color channel on the device that does have the colorMode set to String?
Sorry - It took more time than estimated to move over to OH3. 
I’ve now changed the way this works so that any String will be treated as this raw format.
However, I don’t believe that this is going to help your problem since the handleCommand method in the binding doesn’t return an error and as there is no exception thrown I don’t think the error you are getting is coming from the binding.
I’m still not really sure what you are doing and what you are sending to the REST interface. I’ve not seen any logs either so it’s hard to comment on what is happening, but hopefully you can work it out from here.
I go to developer tools → API Explorer → select “items” → select POST so send a command.
Then I enter the item name and as a payload I use red=50,level=10 .
The API generates the following curl call:
curl -X POST "http://IP:PORT/rest/items/MyRGBW2Item" -H "accept: */*" -H "Content-Type: text/plain" -H "Authorization: Bearer XXXX" -d "red=50,level=10"
Item definition of the Fibaro RGBW2 item
Color MyRGBW2Item "RGB" {channel = "zwave:device:controller:node44:color_color1", autoupdate="False"}
If I use “OFF” as a payload it works as expected so it seems openhab is somehow not accepting the string with the multiple values as a valid command.
There is nothing in the openhab.log and I don’t see anything in the zwave.log so unfortunately I can’t provide anything.
So with the new binding version this should work for every color channel?
Thanks. Given there is nothing in the zwave log, my guess is that something in the core is preventing this command from getting through to the binding - otherwise the binding would log the command it receives before it does anything else. Possibly this is to do with your item definition - if this is an RGB type, then probably the core is trying to convert your string to something (either On/Off, a level, or an HSB) and if this fails (as it will) then it is likely throwing this error.
I would suggest a new item that is defined as a StringType and see what that does.
I created the item:
String MyRGBW2Item "RGB" {channel = "zwave:device:controller:node44:color_color1", autoupdate="False"}
The binding creates the following entries:
2021-10-24 09:21:15.852 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Channel zwave:device:controller:node44:color_color1 linked - polling started.
2021-10-24 09:21:16.881 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Channel zwave:device:controller:node44:color_color1 linked - polling started.
2021-10-24 09:21:59.668 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'MyRGBW2Item' received command red=50,level=10
2021-10-24 09:22:42.391 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'MyRGBW2Item' received command red=50,level=10
2021-10-24 09:23:12.152 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'MyRGBW2Item' received command REFRESH
2021-10-24 09:24:54.121 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'MyRGBW2Item' received command red=50,level=100
The item gets the command but the z-wave binding does not log anything except for these two lines.
Do I need to use an experimental version of the binding?
Ok, so that was your problem then 
You need then to wait for the next version of the binding. At the moment I can’t merge this as CI seems to be broken and until this is resolved and the build and tests succeed I can’t really merge.
1 Like
Has the new implementation already been merged?
I believe it was merged and included in 3.2.0.M5.
I haven’t had success in getting this to work though… probably I’m doing it wrong.
I’m having some weirdness with the zooz rgbw controller and want to create a rule to help overcome
If anyone has some guidance on how to apply this, I’m happy to help verify.
I create a String type item and linked it to the color channel. I tried sending commands like the following to the String item but it didn’t control the light at all
red=0,green=0,blue=0,warm_white=100
1 Like
I turned on zwave logging and am not seeing any logs from the zwave binding after the item receives the command… same as @Spaceman_Spiff. I’m running 3.2.0.M5
@chris - Looking for your feedback. I was able to come up with a solution though possibly not the best solution.
I added new channel type, color_raw to the zwave binding and then added a new channel to the zooz zen31 thing definition using this channel type. I was then able to add a String type item and link it to the new channel and control the light.
I’m happy to open a PR with these changes if it makes sense. Please let me know your thoughts.
1 Like
That sounds exactly right 
The best thing to do is to add this to the database so that it is added to the binding.
Thanks Chris. I created a PR to add the channel type for color_raw. I think this is necessary before I can update devices in the database.
Thanks - that’s now merged.
@jjlauterbach Did you get it working?
I linked a String item to zwave:device:controller:node44:color_raw1 and can send the appropriate commands through the rest api:
[INFO ] [openhab.event.ItemCommandEvent ] - Item 'RGB_Raw' received command red=255,green=255,level=255
The device however does not turn on and not report an energy change