Class: ClrLighting

[Dean Roddey]

General Description

[INDENT]This thread is for the discussion of standardization of lighting systems that allow for control over the color of the lights. Currently Hue is the only supported (only existing?) system that would be of this sort, but there may be others supported over time. We want to be able to control such systems generically, so this device class defines that interface. Given that any such system is also effectively a lighting system, it will almost certainly also support the Lighting device class.

Colors are represented via the HSV (or HSB) color format, since that's most likely what will be supported. If not, the driver will convert as required. HSV defines a hue (the basic color), saturation (the purity of the color, with lower saturation meaning effectively more white mixed in), and the value or brightness (the level) of the light. The ranges of the values are:

• Hue. 0 to 359. It is typically defined in degrees, which makes it convenient to map to things like color wheels or color palettes, so this device class uses that convention.
  
• Saturation. 0 to 255, just a byte value, where 0 means highly unsaturated, i.e. almost white, and 255 means fully saturated.
  
• Value. 0 to 255, again just a byte value, where 0 means off and 255 means full brightness.
  

If the target device does not use these conventions, or does not use HSB/HSV format, then the driver MUST map these values to/from the device values.
[/INDENT]

Fields Provided
[INDENT]The field interface is very simple. Since the common lighting functionality (on/off, dimming) will be provided by the Lighting device class, all this class has to do is to provide the ability to get and set the color of lights.

It is generally assumed that the bulk of the fields of lighting systems can be renamed by the user to indicate their actual purpose in the environment, so there are no specific requirements other than they use the correct device class prefix, in the form:

CLGHT#fieldname

CLGHT# indicates that it is part of the ClrLighting interface. It MUST be a string, and it MUST at least be writeable, through hopefully it will be readable as well if the device supports that.

The form of the text in the field MUST be "h s v", i.e. the hue, saturation, and value values formatted to text, in decimal radix, separated by a space. That is how it is provided when you read the field, and how you must format it to write to the field.

Note that, though dimming would ostensibly be provided via the Lighting device class, essentially the Value (or Brightness) part of the color is doing the same thing. If the device doesn't provide explicit dim level control, writes to the dimmer level of the Lighting device class will just be translated to a change in the Value or Brightness value of the light's color. If the device doesn't provide explicit on/off commands, writes to an on/off field in the Lighting device class may just translate to setting the Value/Brightness part of the color to zero or the previous non-zero setting.

[/INDENT]

Multi-Unit Considerations
[INDENT]It is assumed that all of these fields are equal and will just be named to suit the user's needs, so there is no reason to support any multi-unit prefix. If initial default names must be assigned, then it is RECOMMENDED that they be in the form Clr_xx , where xx is a non-leading zero incrementing number, starting with 1.[/INDENT]

Backdoor Commands/Queries

[INDENT]There are none at this time[/INDENT]

Event Triggers
[INDENT]Any triggers would be handled via the regular Lighting device class, which any driver that uses this class would almost certainly also implement.[/INDENT]

[Dean Roddey]

(Reserved 1)

[Dean Roddey]

(Reserved 2)

[fcwilt]

One automation product I read about has a DMX interface and is using that to control RGB LED strips.

Perhaps there is a third party DMX interface that you could support.

[batwater]

One automation product I read about has a DMX interface and is using that to control RGB LED strips.

Perhaps there is a third party DMX interface that you could support.

That would open up a whole lot of lighting options!

[Dean Roddey]

If it's other than just setting/getting the color of individual lights, it would be beyond the scope of this device class and would either just be device specific or require some other device class. I'm not sure how many devices there are of that sort and how standard the functionality is.

[klindy]

+1 for DMX control. I currently have 4 RGB LED strip lights that are addressed individually. The protocol is pretty simple - send a value to an address - and the device knows what do to do with the value.

I'm shopping for LED pool/spa lights now and I'd like to add some under counter lights and cove lights which would be able to change colors (even if that's just through a spectrum of white).

[Dean Roddey]

Are you actually setting a color directly with the DMX protocol?

[znelbok]

There are shitloads of DMX products on the amrket. Cheap LED RGB controllers (check ebay) through to big stage production DMX controllers.

A DMX512 controller with a serial/IP interface may have its own protocol before it "converts" it into a DMX command. A DMX enabled LED driver will then take that command and change the output of the [RGB] led's to what the command instructed.

So I don't think CQC would be issuing a direct DMX command, but there is no reason why it could not if the DMX/TCP [transparent] gateway existed.

Research into this field would be required. I have done a little, but not enough to answer questions raised, only to know that I don't know a lot.