OpenZWave / open-zwave

a C++ library to control Z-Wave Networks via a USB Z-Wave Controller.
http://www.openzwave.net/
GNU Lesser General Public License v3.0
1.05k stars 915 forks source link

COMMAND_CLASS_COLOR notification is not returning the value used in the "SetValue" cmd #2236

Closed gprintemps closed 4 years ago

gprintemps commented 4 years ago

Hi, I'm currently trying to integrate the Fibaro RGBW Controller 2 into the OpenZWave stack. When I'm setting a new RGB color through the COMMAND_CLASS_COLOR, I'm receiving a notification (updated color) but the value is different from the one I used for the set command.

As you can see in the logs, I'm setting the RGB color "#df7f01" but I'm receiving "#DF0D0100" as a new value in the ValueChanged notification. For a better analysis, I putting also in attachment, archive containing the ozwcache file and the initial XML I'm currently using for integrating this new device (I will submit it later) Regards,

fgrgbw442.zip OpenZWave.log

Fishwaldo commented 4 years ago

If you refresh the value manually after setting it, is it correct?

gprintemps commented 4 years ago

With a call to the "RefreshValue" method right after the "SetValue", I'm now getting 2 notifications but the values are not the same than the one I used in the "SetValue" method.

I follow the following step for the logs 1) I'm setting the color "#0901df" 1st notification returns "#D0012500" 2n notification returns "#A5014D00"

See OpenZWave1.log in zip file

2) I'm setting the color "#df0101" 1st notification returns "#26017000" 2n notification returns "#8A014800"

See OpenZWave2.log in zip file

3) Now, I'm stopping and restarting my software/OpenZWave Stack and surprisingly, I'm getting "#DF010100" as value for the color.

See OpenZWave3.log in zip file

4) I'm setting another color. In these step, update notifications for the color are received with some delays (few seconds after the SetValue. OZW seems on hold in term of notifications and suddenly they are realeased... Maybe another problem - Can see it also with fibaro Dimmer FGD212). Notifications are retrieving the correct value.

See OpenZWave4.log in zip file

Last step: I'm executing a "RefreshValue" 1 or 2 seconds after the strip is showing the right color. Notification is retrieving the right value for the color.

To summarise,

So, I'm thinking that we are not receiving the final value as notification when the switch from the old color to the new one is over (Switch is currently done progressively / Fading from color X tp color Y]).

SettingColor.zip

Fishwaldo commented 4 years ago

"RefreshValue" right after the "SetValue" is not providing the right value

Im gathering there is a "transition" time as the light moves to the new color? So RefreshValue (and the Automatic Get) is getting the "instant" value and not the final value.

Restarting OZW allows to retrieve the right value

Expected as I assume the light is not "Transitioning" to a new color

"RefreshValue" when strip is showing the right color provides the right value.

So you should add the VerifyChanged Compatibility flag to the Color CC. You can see a example here: https://github.com/grizzlyjere/open-zwave/blob/126fbf76de1ec0a499ef3913ec0d1ecd638a7592/config/homeseer/hs-wd100plus.xml#L42

You need to change the CommandClass ID to the Color CC, and also change the index to the Index of the Color ValueID

gprintemps commented 4 years ago

I applied your suggestion (See updated version of the configuration file in attachment) and I'm now receiving the correct value through the last notification. Thanks a lot. Can you explain a little bit the meaning of this parameter and what it is doing?

fgrgbw442.zip