Incorrect conversion from HSB to RGB

Expected Behavior Send command “0,100,100” to COLOR item. RGB values should be (255,0,0) meaning (100%, 0%, 0%)

Current Behavior Send command “0,100,100” to COLOR item. RGB values will become (100,0,0) which is (39%, 0%, 0%)

Steps to Reproduce

1. Open REST API UI (misc-restdocs - 2.3.0)
2. Go to Item --> post /items/{itemname} (Sends a command to an item)
3. Fill parameters: itemname = {the color item}, body = 0,100,100
4. Click “Try it out”
5. Check the status of the RGB channels (on any OpenHAB UI)

Detailed Description The current implementation for receiveCommand uses HSBType to convert from OpenHAB color item HSB (this is actually an HSV not to be confused with HSL) to Z-Wave RGB color components. The Z-Wave command expects each component to be a value between 0 and 255 But HSBType actually returns a value between 0 and 100 for each of getRed(), getGreen(), getBlue() public PercentType getRed() { return byteToPercentType(toColor().getRed()); }

Possible Solution Quick solution: At line 135 rawMessages = commandClass.setColor(color.getRed().intValue(), color.getGreen().intValue(), color.getBlue().intValue(), 0, 0); Multiply each RGB component by 2.55
But double conversion from 255 to percentage and back means we’ll lose some precision. Better solution: Do not use HSBType for the conversion (maybe use java.awt.Color)

Also the IF statement at line 132 if (color.getSaturation().equals(PercentType.ZERO)) Should be removed. There is no special case for saturation 0. the result should be RGB(255,255,255). Setting RGB to 0 and assuming there is a WHITE channel and also assuming that the RGB LED light strip has White LEDs is not always valid. If the user is using normal RGB LED strips (not RGBW led strips, the white channel from the RGBW controller will not be connected to anything) When processing an HSB command the RGB channels should be set. the W channel should either be set to 0 (which is the current implementation for all HSB values except ,0,) or even better not set at all (left as-is).

Also regarding the comment at line 22 // Since we get an HSB, there is brightness information. However, we only deal with the color class here // so we need to scale the color and let the brightness be handled by the multi_level command class We get an HSB and the color class takes RGB. HSB can be converted to RGB and vise versa. RGB has all the components including the brightness. Nothing needs to be scaled, and nothing needs to be handled by the multi_level command.

ULTRA ideal solution: Do not use HSL. A new channel type / item type should be created for RGBW values. (the value could be integer 0xwwrrggbb or just a string W,R,G,B)

Context (Environment)

• OH2 Version: 2.3.0
• Binding Version: 2.3.0
• Device name: Fibaro RGBW Controller
• Device version: 25.25
• Link to [database]:https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/131

[cdjackson]

Please can you take a look at the development branch as all changes are going in to that branch and this may be fixed already.

On 14 Jul 2018, at 19:04, fh-eureka [e-mail] wrote:

Expected Behavior Send command “0,100,100” to COLOR item. RGB values should be (255,0,0) meaning (100%, 0%, 0%)

Current Behavior Send command “0,100,100” to COLOR item. RGB values will become (100,0,0) which is (39%, 0%, 0%)

Steps to Reproduce

Open REST API UI (misc-restdocs - 2.3.0) Go to Item --> post /items/{itemname} (Sends a command to an item) Fill parameters: itemname = {the color item}, body = 0,100,100 Click “Try it out” Check the status of the RGB channels (on any OpenHAB UI) Detailed Description The current implementation for receiveCommand uses HSBType to convert from OpenHAB color item HSB (this is actually an HSV not to be confused with HSL) to Z-Wave RGB color components. The Z-Wave command expects each component to be a value between 0 and 255 But HSBType actually returns a value between 0 and 100 for each of getRed(), getGreen(), getBlue() public PercentType getRed() { return byteToPercentType(toColor().getRed()); }

Possible Solution Quick solution: At line 135 rawMessages = commandClass.setColor(color.getRed().intValue(), color.getGreen().intValue(), color.getBlue().intValue(), 0, 0); Multiply each RGB component by 2.55 But double conversion from 255 to percentage and back means we’ll lose some precision. Better solution: Do not use HSBType for the conversion (maybe use java.awt.Color)

Also the IF statement at line 132 if (color.getSaturation().equals(PercentType.ZERO)) Should be removed. There is no special case for saturation 0. the result should be RGB(255,255,255). Setting RGB to 0 and assuming there is a WHITE channel and also assuming that the RGB LED light strip has White LEDs is not always valid. If the user is using normal RGB LED strips (not RGBW led strips, the white channel from the RGBW controller will not be connected to anything) When processing an HSB command the RGB channels should be set. the W channel should either be set to 0 (which is the current implementation for all HSB values except ,0,) or even better not set at all (left as-is).

Also regarding the comment at line 22 // Since we get an HSB, there is brightness information. However, we only deal with the color class here // so we need to scale the color and let the brightness be handled by the multi_level command class We get an HSB and the color class takes RGB. HSB can be converted to RGB and vise versa. RGB has all the components including the brightness. Nothing needs to be scaled, and nothing needs to be handled by the multi_level command.

ULTRA ideal solution: Do not use HSL. A new channel type / item type should be created for RGBW values. (the value could be integer 0xwwrrggbb or just a string W,R,G,B)

Context (Environment)

OH2 Version: 2.3.0 Binding Version: 2.3.0 Device name: Fibaro RGBW Controller Device version: 25.25 Link to [database]:https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/131 https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/131 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/959, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQwEvSUoOKPmv9i5SsyrO1P0a0vrFks5uGjKlgaJpZM4VP8ah.

[cdjackson]

Sorry - I forgot to change to using floats before merging this. I have changed it though and it will flow through in the coming days.

Cheers Chris

On 15 Jul 2018, at 16:24, fh-eureka [e-mail] wrote:

It matters if someone is creating an app and using the REST API. So if the app needs to send a color to OpenHAB, the app has the RGB value, then convert that to HSV send it to OpenHAB, then Z-Wave binding will convert that back to RGB. If you are using integers instead of float the resulting RGB will not be the same as the source RGB in some cases. So the value we send and the actual value we get are not the same (close but not the same). This could cause an issue or just a strange behavior. And it can be easily avoided. (As you can see from the HSBType implementation, they had this in mind when they implemented convertPercentToByte function)

Thank you very much Chris.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/959#issuecomment-405099009, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ25IyQIZH_hVU_O-tedmQ5vMAWklks5uG16_gaJpZM4VP8ah.