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