05-05-2013, 11:05 AM
(This post was last modified: 03-31-2015, 12:33 PM by 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.
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]
[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
Explorans limites defectum
Explorans limites defectum