"Scenes" and "Groups"

[yardman 49]

Hello all:

 

I posted the following in another thread which had kind of drifted off topic. So I am reposting here under a more appopriate title:

 

______________________________________________________________________

 

Hello all:

 

This is my "take" on scenes and groups:

 

***********************************************************

 

To my limited understanding, "group" seems to be a better term for some applications than "scene".

 

Hence, I have my "scenes" named as "groups", such as "Hall Lower Light Group", "Living Room Ceiling Group", "Basement Normal Group",etc. Basically, I view a "group" as just a collection of related devices, without necessarily any respect to levels, etc.

 

Each of my groups may have one or more "controllers". Each of these controllers in turn can specify their own "levels and ramp rates" for the devices in that "group". I view these controller-specified settings as "scenes".

 

So each "group" of devices can then be members of multiple "scenes", with their own specific settings

 

Since each "group" can also have a primary "scene" setting for levels and rates ( which is used by the ISY in situations where the ISY is the "controller"), this also has to be taken into account.

 

 

So maybe an alternative to clarify things would be to change the names of "Scenes" to "Groups" in the GUI.

 

- Then the header for the name of the Group primary page could be changed to "ISY Scene Settings". So for the example of my Hall Lower Light Group", this would read "Hall Lower Light Group - ISY Scene Settings" or something similar.

 

- And each controller-device added to the group would then have it's own device page labeled as its "Scene" settings , with the header reflecting the name of the controlling device. In my example of the "Hall Lower Light Group", the page for the Hall Dimmer (one of the controllers in the Group) would read as "Hall Dimmer Scene Settings".

 

This would not require any change to the basic design of the ISY, just graphics changes to the GUI.

 

***********************************************************

 

Would this make things clearer or more confusing?

 

Does this make sense to anyone but myself? If so, I'd be interested in hearing about your opinions

 

 

Best wishes,

[yardman 49]

I'm adding to this thread some comments by Matt and Darrell (taken from the original thread):

 

______________________________________________________________________

 

 

Unfortunately, in the Insteon paradigm the only concept of a scene, is that of an Insteon group, which is wholly controller-centric.

 

I think this captures the essense of why this is such a source of user confusion and why you guys keep answering the same question over and over.

 

At the root, you have made a "contract" with the user by calling this a scene. That implies a certain type of behavior. In fact, you aren't really creating a scene at all (or mood, as Michel calls it) you are creating a grouping and calling it a scene. The user then finds ways that the scene can be really anything depending on who is controlling it, and then the confusion sets in and it seems the contract is "broken". In short, by calling it a scene when it's really just a group is the problem. To me, a scene implies a certain set of lights, each with a fixed brightnesses and ramp rate, as well as a collection of buttons and switches that can toggle the current state between off and the scene settings.

 

To ISY, a scene implies a collection of lights. No more, no less. See why calling it a scene is strange? It's really just a grouping.

 

If you hope to eventually break into mass market appeal, then the above, while it might seem like tedious wordsmithing, is very, very important. Mass market dont' read docs. Mass market hates wizards for anything except initial configuration. Mass market refuses to learn tricks and nuances. Installers are OK with all this--and in fact the thicker the doc and the more tricks you must know to work the product the better because they get paid to be an expert of something that is complicated.

 

I like ISY, make no mistake. But holy cow, I have spent an amazing amount of time to simply make the lights in my house twinkle. I'm probably $2000 into this right now, and there's no turning back. I fear that when I sell my house the purchaser will say "put in regular switches" because the care and feeding required right now is way too high. So, I have a very keen interst in making this very easy to use.

 

Hi Matt. Thanks so much for your input. I understand what you have identified as the problem, and would be very interested in any ideas you may have towards a solution, given the paradigm imposed by the Insteon protocol.

 

Also, could I respectfully ask the source of your definition of a scene? I would sincerely like to know if there is somewhere a standard definition for this concept.

 

It occurred to me that ISY could, as much as is possible within the constraints of Insteon, simulate the elementary scene of other protocols, by making the ISY-controller-view of the scene the master, and then whenever another controller was dropped into the scene, giving it the same settings as the master by default. After that, the user could change them as desired. [And I see that the same idea occurred to Rand. ]

 

This immediately brings to mind the question of what happens to individual controller settings when the master settings are changed, given that the user may have altered some, but not all of them?

 

One answer could be to give each controller in the scene a 'Sync to Master' checkbox which, in accordance with the 'simulate elementary scene' philosophy would be checked by default. If the user wished to change the settings for an individual controller, he would first uncheck that box. If the box were later checked again, the settings would automatically shift to those of the master. When the master settings were changed, those controllers with the box checked would change in sync, while those with the box unchecked would retain their custom user settings.

 

_______________________________________________________________________

 

I like Darrell's idea of the "Sync to Master" check boxes which would keep all of the "Scenes" that are part of the same "Group" synchronized. We already almost have this feature with the "Copy Scene Attributes from...." buttons. A "Sync" checkbox would just make it slightly easier, as it could be left in the activated state.

 

As long as the ability to select controller-specific scene attributes remained (by unchecking such a box), this could be a desirable change.

[upstatemike]

...Since each "group" can also have a primary "scene" setting for levels and rates ( which is used by the ISY in situations where the ISY is the "controller"), this also has to be taken into account.

 

 

So maybe an alternative to clarify things would be to change the names of "Scenes" to "Groups" in the GUI.

 

- Then the header for the name of the Group primary page could be changed to "ISY Scene Settings". So for the example of my Hall Lower Light Group", this would read "Hall Lower Light Group - ISY Scene Settings" or something similar.

 

- And each controller-device added to the group would then have it's own device page labeled as its "Scene" settings , with the header reflecting the name of the controlling device. In my example of the "Hall Lower Light Group", the page for the Hall Dimmer (one of the controllers in the Group) would read as "Hall Dimmer Scene Settings".

 

This would not require any change to the basic design of the ISY, just graphics changes to the GUI.

 

***********************************************************

 

Would this make things clearer or more confusing?

 

Does this make sense to anyone but myself? If so, I'd be interested in hearing about your opinions

 

 

Best wishes,

 

This is a good attempt to match terminology to the realities of Insteon protocol structure. I am trying to picture how it might be applied in different situations. Example:

 

If you have 3 lamp modules and a Keypadlinc button to control them this would become a group with two scenes; the keypadlinc button scene and the ISY "primary" scene.

 

Now suppose you create an "evening scene" with the same 3 lamp modules plus the keypadlinc button as a responder, but the lamps are set to different levels. This would be a different "group" under the new naming scheme with a different ISY "primary" scene.

 

Will it confuse folks to think about multiple "groups" that contain the exact same devices?

[yardman 49]

 

This is a good attempt to match terminology to the realities of Insteon protocol structure. I am trying to picture how it might be applied in different situations. Example:

 

If you have 3 lamp modules and a Keypadlinc button to control them this would become a group with two scenes; the keypadlinc button scene and the ISY "primary" scene.

 

Now suppose you create an "evening scene" with the same 3 lamp modules plus the keypadlinc button as a responder, but the lamps are set to different levels. This would be a different "group" under the new naming scheme with a different ISY "primary" scene.

 

Will it confuse folks to think about multiple "groups" that contain the exact same devices?

 

Hello Mike:

 

Perhaps you could provide some extra detail:

 

As I understand it, you have a group where the 3 lamp modules are responders, and a KPL button is the controller. You have the two scenes associated with this (the "ISY" scene, and the one for the KPL button).

 

Now you want to have another scene, the "evening" one, but the KPL button is now only a "responder". I then have to ask, "where is the controller for the scene"? Is it a different KPL button, or is the only controller the ISY itself?.

 

If another switch or button is the controller, then the "evening" settings would come from that controller. So you would have to make another "group". This group would have the 3 lamp modules and the KPL button from the first group all as responders, and the yet unnamed button/switch as the controller.

 

If, however, the "evening" scene is instead only controlled by the ISY itself (as say, a timed event or an event triggered by some other program conditiional), then the "ISY Scene" from the first group would dictate the settings, and it would not be necessary to make another group.

 

************************************************************

 

Here's an example: I have a group for my Living Room Ceiling light. I call it "Living Room Ceiling Group". I have 3 "controllers" in that group (note that there are no responders in this case):

 

- Living Room KPL Button A (Load)

- Kitchen KPL Button F

- Living Room RemoteLinc Button 1

 

 

Note that all these are controllers. If you count the three scenes from the controllers, plus the primary "ISY" scene, there are four possible total scenes. They can all have different levels and ramp rates.

 

Since the ISY controls one of those "Scenes", when my evening timers fire and turn on the house lights, I can have the ISY scene set the ceiling light to a suitable "evening" level (which I do). I can also have another controller (such as the RemoteLinc) specify the same level through its scene. But I can have different levels set at the Living Room Button A Load and my Kitchen KPL button F. In this case, I may want that living room Ceiling light to come on more brightly, for example, when I press either the main load button or the kitchen button.

 

***********************************************************

 

This same concept can be extended to groups that have many responders, and multiple controllers. In such a group, each controller has its own "Scene", and yet is still part of the "Group". You can even have some scenes in that group "turn off" selected responders (or other controllers) when the "on" command is sent. Thus you achieve the idea that a scene can specify some devices to be off, some on, and some faded. So you would then have only one group, but many scenes (only dictated by the number of controllers in that group).

 

I use many such "groups" in my setup very successfully.

 

************************************************************

 

There is a limitation to Insteon that I'm sure that you're aware of (but others may not be): a device cannot be a controller in more than one group, but it can be a responder in many groups. I believe that this is an Insteon limitation, not an ISY limitation (but I could be wrong).

 

So my living room Ceiling light (KPL Button A Load) is also a member as a responder in many, many other groups and scenes in my house. But the Living Room KPL Button A Load is a controller in only one group (and scene).

 

The only way around this limitation would be to use this KPL A to trigger an ISY program. Then I could have something where the conditional would be something like this:

 

If

Control Living Room Ceiling KPL A is switched ON

AND

Time is some range (say sunset to midnight)

 

Then

Wait 2 seconds

Turn on some group that has KPL A as a responder set to the desired level.

 

Likewise, Insteon "FAST ON" can be used to trigger a program that would set a different level for KPL A.

 

 

Whew! Sorry for being so long winded.

 

 

Thanks for the response.

[Mark Sanctuary]

So in the simplest terms is this what you guys are saying:

 

Group == two or more linked devices

Scene == lamp level and ramp rate data for a group

[yardman 49]

So in the simplest terms is this what you guys are saying:

 

Group == two or more linked devices

Scene == lamp level and ramp rate data for a group

 

Hello Mark:

 

Precisely. And thus each group would have the number of scenes equal to the "number of controllers + 1", where the extra scene is the "Group Scene" itself, a.k.a., the "ISY Scene".

 

Thanks!

[Mark Sanctuary]

Added more to this list.

 

Device == ungrouped device

Responder Device == grouped device, listening to a scene

Controller Device == grouped device, in charge of a scene

 

Group == two or more devices

Scene == lamp level and ramp rate data for a group

[Mark Sanctuary]

Look how interconnected this concept is.

[yardman 49]

Added more to this list.

 

Device == ungrouped device

Responder Device == grouped device

Group == two or more devices

Scene == lamp level and ramp rate data for a group

Controller Device == A device in charge of a scene

 

 

Wow Mark, you are on a roll here! Could I then suggest the following modifications:

 

 

 

Group == two or more devices

Scene == level and ramp rate data for a Group. Each Group has a minimum of one Scene associated with it.

Responder Device == a Grouped device

Controller Device == A device in charge of a Scene within a Group. A Controller Device can only function as a Controller of one Scene in any Group. Controller Devices also function as Responder Devices.

Number of Scenes per Group == number of Controller Devices in the Group plus 1.

 

 

 

 

 

Device == ungrouped device?

 

This may be a little confusing. Since a Device can be ungrouped, or functioning in a group as a Controller or Responder, it may be better to not limit it by calling it "ungrouped".

 

Thanks again.

[yardman 49]

I just thought of something else: Some Insteon devices have multiple buttons. Hence each button thus becomes a Device. Thus I make the following modifications.

 

 

 

Device == an individual Insteon module; or, in the case of a module with multiple buttons, each button functioning as a Device.

Group == two or more Devices

Scene == level and ramp rate data for a Group. Each Group has a minimum of one Scene associated with it.

Responder Device == any Grouped device

Controller Device == A device in charge of a Scene within a Group. A Controller Device can only function as a Controller of one Scene in any Group. Controller Devices also function as Responder Devices.

Number of Scenes per Group == number of Controller Devices in the Group plus 1.

[Mark Sanctuary]

I am good at logic and code, but poor at forum etiquette skills. Can you tell I think in code most of the time with my simple definition list?

 

Don’t you think we need a definition for the lonely device that is not connected?

[yardman 49]

I am good at logic and code, but poor at forum etiquette skills. Can you tell I think in code most of the time with my simple definition list?

 

Don’t you think we need a definition for the lonely device that is not connected?

 

 

Your "simple definition list" really got my brain cells firing!

 

We are crossing paths here, so I actually just did define a "Device" (sort of).

 

Now see my next post for a new wrinkle

[yardman 49]

I just thought of another permutation: you can create a Group with just one Insteon Device in it (useful for changing the state of a single KPL button via a program, for example). But that Device is really not "alone" in the Group: the ISY is also part of that same Group (as a Controller).

 

So here's the latest permutation of our evolving "definitions" list. I've made a few additional clarifications:

 

 

Device == an individual Insteon module; or, in the case of a module with multiple buttons, each button functioning as an individual Device.

Group == two or more Devices. (Note that the ISY itself counts as a Device in each Group that it is used to create).

Scene == level and ramp rate data for a Group. Each ISY-created Group has a minimum of one Scene associated with it (the ISY Controlled Scene).

Responder Device == any Grouped device

Controller Device == A device in charge of a Scene within a Group. A Controller Device can only function as a Controller of one Scene in any Group. Controller Devices also function as Responder Devices.

Number of Scenes per Group == number of Controller Devices in the Group (including the ISY itself as a Controller).

[Mark Sanctuary]

I would say that the “device link to the ISY†should be considered a ghost link, which does not exist in the realm of the living ISY-Insteon network, but really just in the background workings of the network. Something like, “ignore the man behind the curtainâ€. It really messes with the solidness of the definition.

[yardman 49]

I just thought of another permutation: you can create a Group with just one Insteon Device in it (useful for changing the state of a single KPL button via a program, for example). But that Device is really not "alone" in the Group: the ISY is also part of that same Group (as a Controller).

 

So here's the latest permutation of our evolving "definitions" list. I've made a few additional clarifications:

 

 

Device == an individual Insteon module; or, in the case of a module with multiple buttons, each button functioning as an individual Device.

Group == two or more Devices. (Note that the ISY itself counts as a Device in each Group that it is used to create).

Scene == level and ramp rate data for a Group. Each ISY-created Group has a minimum of one Scene associated with it (the ISY Controlled Scene).

Responder Device == any Grouped device

Controller Device == A device in charge of a Scene within a Group. A Controller Device can only function as a Controller of one Scene in any Group. Controller Devices also function as Responder Devices.

Number of Scenes per Group == number of Controller Devices in the Group (including the ISY itself as a Controller).

 

 

Hmmm....the more I think about my last comments, I realize that even an "UnGrouped" device is sort of in a "private" Group with just the ISY. For instance, when you add an Insteon device to the ISY, some sort of link is created between the ISY, PLM, and the Device. So the ISY/PLM then becomes a Controller for that Device, and also Responds to status changes signaled by the Device. Interesting.

 

Taking the concept a little further, the ISY is really the only "Controller Device" than can be part of more than one Scene. Even more interesting.

 

So Groups rule everything!

 

[yardman 49]

I would say that the “device link to the ISY†should be considered a ghost link, which does not exist in the realm of the living ISY-Insteon network, but really just in the background workings of the network. Something like, “ignore the man behind the curtainâ€. It really messes with the solidness of the definition.

 

Agreed! But then what do you do with the fact that you can create a Group in the ISY that actually is "empty" (if you never add any devices into it)?

 

Should I then change the definition of a Group to be "one or more Devices"? Or, if we consider the ISY to be a "ghost" link, then "zero or more devices"?

 

I guess that there a few more conventions to nail down. We are getting close, but not quite there yet

[Mark Sanctuary]

The ghost link is just that; don't consider it in the definitions at all. Pretend its not there, or else this string theory will fall apart. Remember 11 dimensions man!

 

A single device in the ISY is a ungrouped device.

[Mark Sanctuary]

Wait are you talking about when you create a group and only drop one device in it?

[Mark Sanctuary]

If you never add any devices to a group its nothing but an empty group.

 

Yeah the "zero or more devices" is correct then. Append a note saying a group can be created empty so hence the zero.

[upstatemike]

I think I am getting lost in the definitions and have come full circle to agreeing with the existing paradigm:

 

Group - A controllable device within an Insteon module or switch. ( A lamp module has one device, the module itself. A ControLinc has 5 devices, the buttons. A PLM has 512 or or more devices, already called groups.) By convention all devices are listed as available to participate in Scenes except the PLM groups which are too numerous to display and are therefore hidden from the GUI interface.

 

Scene - One or more devices (groups) placed into association with each other and givin a specific set of roles and settings defined for that association. Devices may participate in multiple associations (scenes) but may not assume a controller role in more than one of those associations. A single device (still called a group) may be placed into a scene by itself as a mechanism to define a particular set of parameters for that device. The same device may also be placed into a different association (scene), either by itself or with other devices, as a means to define a different set of parameters.

 

If you are uncomfortable with "group" and "scene", how about just changing to "device" and "association" and otherwise leaving things as they are?

[yardman 49]

Wait are you talking about when you create a group and only drop one device in it?

 

Yes, exactly.

[yardman 49]

If you never add any devices to a group its nothing but an empty group.

 

Yeah the "zero or more devices" is correct then. Append a note saying a group can be created empty so hence the zero.

 

Ok.

[Algorithm]

This same concept can be extended to groups that have many responders, and multiple controllers. In such a group, each controller has its own "Scene", and yet is still part of the "Group". You can even have some scenes in that group "turn off" selected responders (or other controllers) when the "on" command is sent. Thus you achieve the idea that a scene can specify some devices to be off, some on, and some faded. So you would then have only one group, but many scenes (only dictated by the number of controllers in that group).

 

Hi Frank.

 

I do like the concept of 'Groups', and we have had some discussion along those lines before.

 

One possible drawback is that the term 'Group' is a major part of the Insteon protocol, and as such there is great potential for confusion between an Insteon Group and an ISY Group.

 

So in your ISY Group, each controller has it's own Scene, but is part of a common ISY Group. Yet each controller by definition is a different Insteon Group.

 

My wish is that we could find an industry-standard definition of 'Scene' with which to work.

[yardman 49]

Mark & Mike:

 

Here's my newest attempt. I've incorportated some of Mark's latest points.

 

I do think that these definitions could be useful (if Michel chooses to adopt them), especially in the context of the User Manual. I prefer to stay with Mark's initial idea, where the concepts can be expressed as a collection of somewhat simple definitions. Small bites are easier to digest and remember, sometimes.

 

 

Device == an individual Insteon module; or, in the case of a module with multiple buttons, each button functioning as an individual Device.

Group == two or more linked Devices. (Note that the ISY itself counts as a Device in each Group that it is used to create.). When initially creating a group in the ISY environment, it will be an "empty" group until Insteon devices are added to it, thereby establishing a new Group link between the ISY and each Device. Thus the smallest ISY Group can consist of just one Insteon Device.

Scene == level and ramp rate data for a Group. Each ISY-created Group has a minimum of one Scene associated with it (the ISY Controlled Scene).

Responder Device == any Grouped device

Controller Device == A device in charge of a Scene within a Group. A Controller Device can only function as a Controller of one Scene in any Group. Controller Devices also function as Responder Devices.

Number of Scenes per Group == number of Controller Devices in the Group (including the ISY itself as a Controller).

[yardman 49]

Hi Frank.

 

I do like the concept of 'Groups', and we have had some discussion along those lines before.

 

One possible drawback is that the term 'Group' is a major part of the Insteon protocol, and as such there is great potential for confusion between an Insteon Group and an ISY Group.

 

So in your ISY Group, each controller has it's own Scene, but is part of a common ISY Group. Yet each controller by definition is a different Insteon Group.

 

My wish is that we could find an industry-standard definition of 'Scene' with which to work.

 

Hello Darrell:

 

I've been enjoying the ISY so much that I'd forgotten how much more I prefer the ISY universe to the basic Insteon construct. So how about the following refinements?

 

*********************************************************

 

Device == an individual Insteon module; or, in the case of a module with multiple buttons, each button functioning as an individual Device.

ISY Group == one or more ISY-linked Devices. (Note that the ISY itself counts as a Device in each Group that it is used to create.). When initially creating a Group in the ISY environment, it will be an "empty" Group until Insteon devices are added to it. The smallest functional ISY Group can consist of just one Insteon Device.

Scene == level and ramp rate data for an ISY Group. Each ISY-created Group has a minimum of one Scene associated with it (the ISY Controlled Scene).

Responder Device == any Grouped device that can react to an Insteon control command.

Controller Device == A device in charge of a Scene within an ISY Group. A Controller Device can only function as a Controller of one Scene in any ISY Group. Many Controller Devices can also function as Responder Devices.

Number of Scenes per ISY Group == equal to the number of Controller Devices in the Group (including the ISY itself as a Controller).

 

 

************************************************************

 

I just added "ISY" to "Group" to clarify that it is the ISY concept in use here, rather than the Insteon concept. Since UDI is already calling Insteon "Groups" as "Scenes", some degree of confusion already exists. But it just seems more intuitive that collections of devices should be called "Groups", especially to those who are new to Insteon and the ISY.

 

************************************************************

 

Here's some additional rationization:

 

Prior to starting out on my "adventure" to adopt the Insteon technology, I used to have several "3-way" circuits in my home, some of which had dimmers incorporated.

 

When installing my first Insteon devices, and starting to program them using "HouseLinc", the term "Group" was very intuitive. This was because at first, I was just using two Insteon devices to replace a 3-way dimmer switch configuration. Anyone new to HA would not necessarily "relate" to the idea of their former 3-way now being called a "Scene". At least to me, it seemed that "Group" was more natural: for instannce, my lower hall lights, which used to be controlled by two switches in a three-way, now became my "Hall Lower Lights Group". "Hall Lower Lights Scene" would have seemed too obtuse. After all, I didn't care so much to identify the devices by what "mood" they produced, but by the "set" of devices tp which they were related.

 

When I switched to the ISY, it took a while for to grasp the power of "Scenes". Once I did, it opened up new areas for me. However, I still found it easier to consider my "Devices" to be parts of "Groups" (hardware), which could then be involved in multiple "Scenes" to produce the desired "ambience" as the need arose.

 

Hence, I named all of my ISY "Scenes" as "Groups". And when I expand a "Group", I can then view all of the "Controllers" and the individual "Scenes" that they control.

 

 

Thank you for continuing Michel's fine tradition of soliciting your customer's feedback!

 

 

Best wishes,