Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Class: Lighting
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
General Description

[INDENT]This thread is for the discussion of standardization of Lighting type devices. This one is complicated by the fact that many devices that are ostensibly 'Lighting' actually over time have grown to become generalized controllers for a hodge podge of module types. So, there may be overlap here with other types of devices in some cases, and that overlap has to be dealt with very carefully, else it would be impossible to toss out such a device and move that functionality cleanly over into a Lighting type device. See the sticky thread "General Concerns" for a discussion of this overlap problem.[/INDENT]

Fields Provided
[INDENT]Given the above discussion of overlap and the hodge podge nature of some of these types of devices, it is likely that a driver that purports to be a lighting system may also implement various other device classes, such as:
  • AIO
  • ContactClosure
  • DIO
  • MotionSensor
  • Relay
  • ThermoStat

All we discuss here are those fields that are considered to be specific to the Lighting device class. 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, and indicate switches vs. dimmers, in the form:


or, if the device provides multiple banks of identical sets of lights, it may use the sub-unit prefix:


LGHT# indicates that it is part of the Lighting interface, Sw_ and Dim_ indicate the specific type of light, and fieldname just needs to conform to the general restrictions on CQC field names and is generally user configured.

It is assumed that generally each light will be nameable by the user (or via the device) and all will be equal. But, some devices may provide identical banks of lights, in which case the driver MAY use a sub-unit naming convention. In that case, each sub-unit MUST provide identical sets of fields, since that is a fundamental requirement of sub-unit naming.

The fields that are specific to Lighting devices fall into these general categories:
[INDENT]Non-Lighting Switches. These are binary switches that control the off/on state of non-lighting loads. These MUST be marked with the BoolSwitch semantic field type and conform to the restrictions of that semantic type. These MUST use the Sw_ prefix.
Lighting Switches. These are binary switches that control the off/on state of lighting loads. These MUST be marked with the LightSwitch semantic field type and conform to the restrictions of that semantic type. These MUST use the Sw_ prefix.
Lighting Dimmers. These are level controls for dimmer loads. Typically they would be lights, but of course no one would be the wiser if one controlled something else. These MUST be marked with the Dimmer semantic field type and conform to the restrictions of that semantic type. These MUST use the Dim_ prefix.
For all of these types, this device class imposes the extra requirement that they MUST be both readable and writeable. Write-only fields are not supported because of touch screen interface portability requirements.

It is quite possible that a single load has both a dimmer and a switch field, since some lighting systems support that sort of scheme. This allows you to turn lights off and on without losing their dimming level. They would be the same except for the Sw_ and Dim_ prefixes to differentiate them.

Backdoor Commands/Queries

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

Event Triggers
[INDENT]Lighting devices must support some standard event triggers, which are used to invoke triggered events in response to changes in the Off/On state of lighting loads. If the device supports more than a fairly small number of lights, it is REQUIRED that the sending of these event triggers be configurable on a per-light basis. This is used to avoid undue numbers of unneeded triggers being generated.

LoadChange. Any time the Off/On state of a switch field (not a dimmer field) changes, the driver MUST (if configured to do so) send out a standard Load Change event trigger. Dimmers are not supported in this way.[/INDENT]
(reserved for expansion)
(reserved for expansion 2)
Took another shot at this one. Does this seem sufficient? Are there any fields that might be related to a Lighting system that is about the system itself, as opposed to switches and dimmers or other things covered by other device classes?
A lighting system driver needs to support scenes. I may have a scene that implements dimming levels for two to twenty (or more) dimmers with associated 'rate of change' characteristics that I couldn't easily implement with individual dimmer controls.
Thinking about it, scenes maybe should be a device class, since there are also scene controllers that provide control of scenes but are not the lighting system themselves? A Scene Controller device class could abstract that functionality whereever it existed.
I added a scene controller device class.
In my lighting control system, apart from switches and dimmers, there are tri-state devices for controlling window blinds or motorised screens etc. So you have three commands Off, MoveUp and MoveDown. Interrogating the device gives you three states - Off, Moving Up and Moving Down.

Given that it's not a requirement, only there if supported, it's probably reasonable enough to add that. It would also require a semantic field type to support this and other tri-state values.
Updated to mention the required sending of load change event triggers. And to tighten up field naming requirements.
Pages: 1 2