Patch for Color Control class (0x33)

[GoogleCodeExporter]

I made the following patch to enable support for the color control class (0x33).
It still needs to have some for for the 'get' command which i hope to test soon 
with a Fibaro RGBW node.

It can be used to control the Zipato RGBW bulb, but also the Fibaro RGBW 
supports this class.

With it, you can directly set the color (RGBW)

Attached:
- patch
- modified zipato bulb configuration file
- modified fibaro rgbw configuration file

The Zipato does not seem to react on the 'get' request:

  <!-- COMMAND_CLASS_COLOR get not supported -->
  <CommandClass id="51" getsupported="false"/>

The Fibaro could maybe work by modifying some configuration parameters but is 
not checked yet

Original issue reported on code.google.com by gizmo...@gmail.com on 30 Nov 2014 at 7:24

Attachments:

• ozwave_color2.patch
• RGBBulb.xml
• fgrgbwm441.xml

[GoogleCodeExporter]

awesome!! Got it working :)

Original comment by shivam...@gmail.com on 2 Dec 2014 at 3:37

[GoogleCodeExporter]

 * for Zipato RGBW

Original comment by shivam...@gmail.com on 2 Dec 2014 at 3:38

[GoogleCodeExporter]

I've got a Zipato RGBW bulb too and I confirm this patch is needed.
Please devs, apply this to trunk.

I don't understand though why an unknown command class is not even notified by 
OZW through the notification callback.
This would allow developers at least to find a solution to handle unsupported 
CC until they are added to the project.
Not receiving anything makes it impossible to support newer devices or to 
handle future ZWave extensions.
Do you guys agree or am I missing something in the code ?

Original comment by massimoc...@gmail.com on 11 Jan 2015 at 5:42

[GoogleCodeExporter]

its not applied yet as its not complete. The Get side still needs to be figured 
out as well as the actual interface (I'm not for a ValueRaw here - as Explained 
to Rob - ValueRaw means that the application has to know the implementation 
detail of each device - eg the Zipato RGB bulb, versus the Fibaro RGBW etc). 
OZW has always done its best to abstract device differences away from the 
application, hence, for this CC, I also need to figure out the best way to do 
that as well. 

I will be working on this soon.

As for unsupported CC - this is not the intent of the Notification interface. 
Unsupported CC's are logged in the LogFiles, which most developers should 
resort to when debugging issues :)

Original comment by jus...@dynam.ac on 11 Jan 2015 at 7:04

• Changed state: Accepted
• Added labels: Milestone-1.4

[GoogleCodeExporter]

Looking forward to this support. MERCI in advance for help in getting this 
added.

Original comment by xdealme...@gmail.com on 11 Jan 2015 at 8:40

[GoogleCodeExporter]

Just looking into the patch, it can detect the colors, but it is "hardcoded" to 
RGB only. This is something Justin also mentioned.

The code detects the capabilities:
 0=Warm White (0x00 - 0xFF: 0 100%)
 1=Cold White (0x00 - 0xFF: 0 100%)
 2=Red (0x00 - 0xFF: 0 100%)
 3=Green (0x00 - 0xFF: 0 100%)
 4=Blue (0x00 - 0xFF: 0 100%)
 5=Amber (for 6ch Color mixing) (0x00 - 0xFF: 0 100%)
 6=Cyan (for 6ch Color mixing)  (0x00 - 0xFF: 0 100%)
 7=Purple (for 6ch Color mixing)  (0x00 - 0xFF: 0 100%)
 8=Indexed Color (0x00 0x0FF: Color Index 0 - 255

The open-zwave needs to abstract this information and make it application 
"generic". Possible we need to make for each detected capability a value/label. 
Then the application can detect it, and do its magic on it - in a generic way.

Only the data seems to be written in 1 request, so splitting it into multiple 
ValueIDs gives a challenge too (we need to update each one, before we have 
"final" state). Or we can store each one in a byte (& label), and then you need 
to call the "Button" to send the info to the device?

Original comment by uAle...@gmail.com on 15 Jan 2015 at 3:51

[GoogleCodeExporter]

Most likely I'd do it as a valuestring accepting the standard #RRGGBB or 
#RRGGBBWW notation that's prevalent in HTML and graphics apps. 

There are plenty of algorithms to convert between 3 and 4 byte representations. 

I'll probably also to a ValueList with 16 predefined colors (+ 1 for custom 
when using the RGB[w] ValueString. 

A few things todo before we get there though. Get Get msgs and reports working, 
and explore the capabilities reports as well. I'm pending a packet trace from a 
home center 2 user (any other HA software supports color CC?) 

I'm not willing to commit it just yet till we know more about this CC, as I 
don't want to have to change the interface later when we discover further info. 

I know everyone is keen to see it go in. A little bit of patience is all I ask. 
( unless someone else can figure this out!)

Original comment by jus...@dynam.ac on 15 Jan 2015 at 4:24

[GoogleCodeExporter]

Hello,

I know that time is rare and not always easy to do all what we want but just 
for curiosity, any idea of the timing we are speaking about to see this pushed 
into the main stream?

Merci

Original comment by xdealme...@gmail.com on 25 Jan 2015 at 5:21

[GoogleCodeExporter]

Bonjour all,

Not sure how release planning works but I see several items being flagged to be 
in milestone-1.4 like this expected patch. Do we know when 1.4 is planned to be 
released? Will all be released on the same release or will there be branches?

my plan is to make use of 
http://www.smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.colordisc to 
control nicely the color LED band through OZW :)

Merci

Original comment by xdealme...@gmail.com on 17 Feb 2015 at 8:58

[GoogleCodeExporter]

As I'm the only one working on code at the moment, it will happen as my time 
allows. :)

Right now, I'm working through several other issues (namely the Security CC 
rewrite) which is rather intrusive to the current code, so its take its time. 

Original comment by jus...@dynam.ac on 22 Feb 2015 at 2:11

[Fishwaldo]

I figured out the Get syntax - you had to append the Color Channel to the Get Request. But Fibaro always return channel 3 when doing a report. I believe its a bug and pending them to confirm. If so, its going to make this class messy :(

[Fishwaldo]

For reference We Represent the Color as #RRGGBBWWCWAMCYPR where RR = Red GG = Green BB = Blue WW = Warm White CW = Cold White AM = Amber CY = Cyan PR = Purple with these conditions:

If the device only supports one type of White, then regardless of Cold White or Warm White, it just outputs RRGGBBWW (Assuming it doesn't support the other colors)

The minimum it will output is RRGGBB even if any of those colors are not supported (will be set to 00)

if we have somethign like a RGB + CW + PR device then it will be: RRGGBBCW0000PR or how about a RGB + CW + WW + AM RRGGBBCWWWAM and finally, say its a RGB + AM RRGGBB00AM

You can check what colors it supports with the ValueID index 254, and from that decode the string. But I suspect most devices will only ever support RGBW, so it shouldn't be overly complicated to have basic support for them.

[Fishwaldo]

pretty much working - but because the Fibaro is such a buggy piece of ****, I can't test unsoliciated reports yet. Aeon are sending me the LED bulb this week, so I should be able to confirm it very soon.... as well as update the Color Index lists.

[kkuustik]

Could you please help out a newbie here. I just got a Zipato RGBW bulb and am trying to write some c++ to handle it (I am not using open-zwave-control-panel or anything, just trying to write something on top of openzwave). As far as I understand, you have done some great work over the time and at least some of the bulb functionality should work already. I just do not know how to use the tools. Currently I am using an older version of openzwave (from February) and added Color.cpp, Color.h, RGBBulb.xml and new CommandClasses.cpp from New-CC branch. I can turn the bulb on and off (COMMAND_CLASS_SWITCH_MULTILEVEL, label "Level", using Manager::Get()->SetValue() or COMMAND_CLASS_SWITCH_MULTILEVEL, label "Bright", using Manager::Get()->PressButton()) but it is cold white. I would like to know how to turn on the bulb with warm white light. Also, If the light is on and I turn it off from the wall switch, how to know from the code that the light is not consuming electricity anymore?

Tanks for the help and patience in advance.

[Fishwaldo]

I would just use the New-CC branch instead of patching it in.

If it doesnt work, please send a full log file (after removing zwcfg_*.xml file and restarting) to the mailing list.

[Fishwaldo]

If you switch the light power off, then you cant communicate with it. It will eventually show up as a dead node in OZW. Switching it back on might not bring it out of dead mode unless it sends a message to the controller. Read about dead nodes on the knowledge base.

[kkuustik]

Is there any hidden trick to get the warm white light? Does the bulb have to be switched off beforehand (COMMAND_CLASS_SWITCH_MULTILEVEL, label "Level", using Manager::Get()->SetValue(Value ID, 0)) or should it be on? Is there a way to know that the node might be dead more quickly than just "eventually" ? For example I have a physical button and after pressing it I would like to get a list of things consuming electricity. If the light is switched off from the wall switch then that should not be reported after the button click. Thanks.

[Fishwaldo]

You have to use the COMMAND_CLASS_COLOR

Firstly, Z-Wave devices are NOT meant to be turned off.

If the light is off, as mentioned, there is no way for Z-Wave to know its off, other that it stops responding when we try to send a message to it. We only send messages either when you initiate something, or if you enable polling. But as mentioned, if the device gets into the Dead Node list, reviving it usually is "not automatic"

If your light was on, and then you switched it off at the wall switch, OZW would still think your light is on, and report it as such if you checked the ValueID's. No Power = Dead Node.

please ask further questions on the mailing list