Class: SceneCtrl

[Dean Roddey]

General Discussion

[INDENT]This thread is for discussion of the SceneCtrl device class, which provides control over defined lighting scenes, though in reality they may be controlling other things than lighting in some cases.

There are two basic schemes that have to be dealt with, in a way that client logic can generally deal with them without having to know which type they are.

• One commonly used scheme is that there are areas or rooms, each of which can support some number of scenes, of which one can be active at any one time.
  
• The other common scheme is when there just multiple scenes, each of which is independently selectable at any time.
  

In the area/room scenario, the fields will be named after the areas or rooms, and the possible values of the field will be the available scenes that can be set in that area or room. So one scene can be active in that area/room at one time.

In the independent scenes scenario, the fields will be named after the scenes, and the possible values of the field will be Off and On values, to turn that scene off or on. It is possible that more values than Off and On are supported but Off and On MUST be among the valid values, and the only ones required.

This strategy will work with either sort of system well enough, without having to know which type it is.
[/INDENT]

Fields provided
[INDENT]It is assumed that the areas/rooms and scenes will be nameable by the user or by querying information from the device. It also assumed that there are no multi-unit naming concerns, that each area or scene is just a standalone entity whose user or device provided name indicates what it is for. So the fields will be in the form:

SCNE#fieldname

SCNE# indicates that it is part of the SceneCtrl interface, and fieldname just needs to conform to the general restrictions on CQC field names. If initial default names are assigned, then it is RECOMMENDED that they be in some way driven by device based identifiers so that the user can map them back to their original function in the device.

They MUST be string fields, with an enumerated limit. The values of the limit MUST be either be the available scenes or Off/On as per the discussion above.

The field MUST be writeable else this device class would be useless. But it MUST be readable as well. If the device doesn't allow reading of the current scene, then set an initial value that is sensible. For instance, have the first value of the limit be Unknown, and set that as the initial value on startup. After that, just let the last value written by a client become the new value.

* Note that, if a scene controller exists purely to send commands to CQC to make it invoke actions, then fields shouldn't be created for that controller. They serve no purpose and client logic cannot assume that any SCNE# fields are valid actual scenes that can be set. In some cases this may require user configuration if some scene buttons are of one sort and some of another, within the same device.
[/INDENT]

Backdoor Commands/Queries

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

[Dean Roddey]

(reserved for expansion)

[Dean Roddey]

(reserved for expansion 2)

[Dean Roddey]

As became apparent over in the lighting system class discussion, we really need a scene controller device class to differentiate scenes from individual loads. So I did what seems a reasonable first cut. They are very similar and mostly the difference will be for device and field selection filtering. Does this seem reasonable? I'm adding two new semantic field types for scene related switches and dimmers, so that we can filter for these types of things at the semantic field type level as well.

[Dean Roddey]

Actually, I changed my mind, and marked them with the same semantic field type as individual load dimmers and switches. I don't think it's worth having separate semantic field types for scene vs. individual load switches and dimmers. For the most part, when selecting fields to generate some widget or to be used in some command, there won't be any need to differentiate between them, and where there is it's easily enough done by the user by just looking at the device class prefix on the fields.

Does that make sense?

[Dean Roddey]

I updated this one slightly, now before anyone uses it, to get the field names in sync with the form of names used by the Lighting device class, for switches and dimmers. So that they will be the same except for the device class prefix. This will make it easier to deal with them generically.

As with dimmers and switches in the Lighting class, which start with a Sw_ or Dim_ prefix, this class' fields do the same now.

[Mark Stega]

Hmm... If the types are identical to Lighting isn't Scene redundant?

I would of thought that you would define a scene by a name or number,
i.e., SCNE#Scene or SCNE#Z1~Scene.

My limited work with a couple of Lutron Scene Controllers follows this kind of scheme. Setting a scene does bring dimmers & switches to predefined settings often with ramps.

I imagine you would want the switches and dimmers to be present if you had the capability of defining the scenes.

I'd define my Lutron as implementing Lighting and Scene if Scene was defined in this fashion. I happen to have 6 dimmers that can be set, but also the choice of 4 predefined scenes that 'move' the dimmers to vales with the ramp mentioned above.

[Dean Roddey]

There's good reason for client code to distinguish between them, but they could also choose not to and everything would work pretty much the same so it works out well. It would just depend on how they searched for the fields.

Some scene controllers allow you to interactively dim a whole scene and some just allow you to activate/deactivate them, and some probably allow you to do both. So having the option to have both types of fields (as with lights) means you can handle either scenario. You only have to implement what the hardware supports.

Scenes don't use the sub-unit name since it's not a situation where there are multiple scene controllers involved. They are just different named scenes. So you would just do:

SCNE#Sw_MyScene1
SCNE#Sw_MyScene2

for your various supported scenes. If a program wanted to treat those like light switches, it could do so. Or it could differentiate if it wanted to. The form of the fields after the class prefix will be the same, making it a lot easier to do that. But the class prefixes allow for easy filtering on one type or another.

For instance, if you wanted to build a scene, you only want to see real lights to choose from.

[Mark Stega]

Isn't the issue with using a switch that it is inherently boolean so if I turn on MyScene1 the driver has to turn off any previously chosen scene? It also seems harder to give good user feedback as to which is the active scene.

And what does it mean to dim/brighten a scene that isn't the selected scene?

[Dean Roddey]

I don't think most of them are limited to one scene at a time, right? Else you couldn't have a scene for different rooms being used as the same time? I thought that they generally just worked on a specific scene as indicated in the incoming command, which the field would effectively indicate.

It would be just like turning a given scene off and on, right? For a single room system, that would just be switching to a new scene I guess?

I dunno. Maybe this isn't the best way to do it. But there has to be a way to deal with multiple active scenes in different parts of the house, presumably.