Groups versus Scenes

[Algorithm]

Toward the end of this thread, there was a brief discussion of the difference between a group and a scene, where it was posited that "A scene has only 1 defined state, TRUE (when each member is at the exact setting defined by the scene) and all other states are considered FALSE. A group has only one defined state, FALSE, (when all members are off) and all other states are considered TRUE. [upstatemike]"

 

Finding the discussion very interesting, I've done a little searching for information on these concepts. One lighting manufacturer's (Dali) manual considered a scene to be a specific set of preset levels (and optionally, ramp rates) for a defined group. In other words, a group is a physical grouping of devices, and a scene is one particular set of levels for a group. There may be many presets (scenes) for a given group. So a scene is actually a sub-set of a group. This definition works well with the one presented above.

 

Another manufacturer's (C-Bus) manual seemed to indicate somewhat the reverse, where a group is a physical group of lights (kitchen group, dining group, etc.), and a scene is a set of preset levels for a set of predefined groups (kitchen group to 100%, dining group to 64%, etc.), thus making a scene a super-set of groups. This same manual does, however, state that a scene indicator should be on when the scene is set, but off when any member is at variance with the preset, thus concurring with the thought expressed by upstatemike in the thread linked above.

 

There were many sites which talked about the Dali components, but the number of discrete descriptions seemed to be about evenly divided between the two (super-set or sub-set) views. Still, the noise-to-signal level was high, and in digging even those out of the search results, I've only scratched the surface. It is, I think, a subject which would make for interesting discussion. What are some of your thoughts?

[sloop]

that post gave me a headache and brought back memories of my math teachers

 

but i think i understood what you said - and how i could apply it to my life

 

i'm all about scenes (well - what i call scenes in the isy) - and have 24 keypads - i have both scene controllers on the secondary buttons as well as devices (like lamplincs) assigned to secondary buttons - so when i turn on a scene (for example loft), all the corresponding buttons that control the devices come on too - not a problem with the isy

 

when i use a device controlling button to brighten a lamp or turn one lamp off, the loft scene button is still on

 

but using your first definition of scenes and groups, the devices in loft would be considered a group - when i turn it on, the loft scene = true because all the devices are at their scene levels

 

if i adjust a lamp, loft scene = false and a controller could turn the loft button off

 

i have read that some products could do that, but accepted that with insteon i would not have that capability

[MikeB]

A scene has only 1 defined state, TRUE (when each member is at the exact setting defined by the scene) and all other states are considered FALSE.

 

This is what I prefer when I setup 'scenes' on my KPL. My scene buttons are lit when activated, but the indicator light will go off if any members of my scene are adjusted at all. If the indicator light is not on, I'll know that the scene is no longer set.

[aLf]

MikeB;

 

How did you do this:

 

"if any members of my scene are adjusted at all. If the indicator light is not on, I'll know that the scene is no longer set."

 

 

I like that. I have several scenes that operate just like you have yours, but if I turn off any 1 single member the KPL is still lit. I'd like to learn how to do that.

 

Thanks,

 

aLf

[MikeB]

aLf -

 

Check out my thread here:

 

http://forum.universal-devices.com/view ... ight=#4109

 

Let me know if you still have any questions.

[Mark Sanctuary]

This is what I prefer when I setup 'scenes' on my KPL. My scene buttons are lit when activated, but the indicator light will go off if any members of my scene are adjusted at all. If the indicator light is not on, I'll know that the scene is no longer set.

 

I do want to throw this out on the table, the thing about having the LED off when one or more devices in the scene is you would be re-launching the scene when you tap on it again. I have found in most cases the next time someone goes to use the button they want to turn off the lights so I keep the LEDs on even if only one light in that scene is still on. This is especially cool for the "All Lights" scene. There is no right way though, personal preference.

[MikeB]

I do want to throw this out on the table, the thing about having the LED off when one or more devices in the scene is you would be re-launching the scene when you tap on it again. I have found in most cases the next time someone goes to use the button they want to turn off the lights so I keep the LEDs on even if only one light in that scene is still on. This is especially cool for the "All Lights" scene. There is no right way though, personal preference.

 

Good point. Everyone's preference will be different, and I think it depends on how and how often you use these scenes.

 

You could easily change my "cleanup" code to something like this if you prefer Mark's suggestion:

 

 
If
       (
            Status  'KitchenBar1' is Off
         And Status  'KitchenMain1' is Off
         And Status  'KitchenTable1' is Off
       )
   And Status  'KitchenControls1G' is not Off

Then
       Wait  2 seconds
       Set Scene 'KitchenBreakfastStatus' Off

Else
  - No Actions - (To add one, press 'Action')

 

Do whatever works best for you and your family. The beauty of the ISY is that you can do all these crazy things, and customize it exactly to your liking!

[Algorithm]

Thanks for the thoughts expressed so far. As some have said, it really is a matter of preference. One can adopt whichever model best suits him.

 

But I think the concept of groups has not really been discussed. Before proceeding, it might be wise to clarify the terms, since the two models seem to differ in their interpretation.

 

It seems to me that even in the C-Bus model, where the term group (because it is a physical group of devices which share a common level for a given scene) is used to represent a member of a scene, the scene itself sill consists of a number of members (groups in C-Bus terminology) which in most cases will be less than all existing groups, and therefore this collection of groups (let's call it a set) that the scene applies to is still a super-set of the scene. In other words, the scene is still a sub-set of the set, just as in the Dali model.

 

Now, I've never used an (expensive) C-Bus lighting system, so don't know whether or not they employ the concept of a 'set'. Nor do I know how granular C-Bus groups can be made. If a group can be made as small as a single device, then the C-Bus Set->Scene(->Group) becomes identical to the Dali Group->Scene(->Device); only the terms differ.

 

Since three levels of reference seem more than are needed (and as the ISY does not employ them in any case), I tend to prefer the terminology used in the Dali model (and eloquently expressed by upstatemike) of Group->Scene, where a Group is a physical set of devices, and a Scene is a defined set of levels/ramp-rates for those devices (of which there may be more than one for a given group).

[MikeB]

I tend to prefer the terminology used in the Dali model (and eloquently expressed by upstatemike) of Group->Scene, where a Group is a physical set of devices, and a Scene is a defined set of levels/ramp-rates for those devices (of which there may be more than one for a given group).

 

Makes sense to me.

[Algorithm]

Having defined the terms I prefer to use, I'd like to look a bit more at groups.

 

A group is a collection of physical devices. It may range in size from a single device, up to the total number of devices in an installation. However, the ISY has no concept of a group; or rather, the ISY's concept of a group is transient at best, being identical to a scene.

 

For example, consider a scene 1 which consists of device 4=80%, device 7=40%, and device 8=100%, and a scene 2 which consists of device 4=20%, device 7=100%, and device 8=55%. These two scenes apply to the identical collection of physical devices, or group. But the ISY does not recognize this or any relation between the two scenes; they are entirely independent. Nor am I suggesting that ISY needs to recognize this relationship (though perhaps in the future someone may request it).

 

However, at least one user did request that ISY maintain the status of a scene (ref. the thread linked to in the first post), and a query (and discussion) as to the concept of scene status ensued; hence my interest and subsequent starting of this thread.

 

At present, ISY does not maintain the status of either a group or a scene, although both can be accomplished by user programs, and examples have been posted.

 

But it seems that it would not be difficult for ISY to maintain such status internally. It could simply maintain, for each scene/group, an internal scene variable and an internal group variable, each of which would be either True or False based on the identical criteria as used in the current user programs (and as defined in the quote at the top of this thread). This would be a convenience for the user, who could reference the status in a program something like this:

 

If
   Status Scene Lower Level is On
Then
   Some actions
Else
   Other actions

and

If
   Status Group Lower Level is Off
Then
   Some actions
Else
   Other actions

 

The first would be true when every member of the defined scene was at its exact preset level, or false otherwise; the second would be true when every member of the scene was off, or false if any member was on.

 

Would this conveniently satisfy all the scene/group status needs expressed so far?

[MikeB]

I have no problem using programs to determine the status when I need to. But, if it would not take much effort, and have no downsides, I'm all for having the ISY keep track internally.

[Mark Sanctuary]

Having defined the terms I prefer to use, I'd like to look a bit more at groups...

Oh guys this stuff is getting good. Please continue I can use the final result in the Wiki for the “Glossary†and “Creating a Scene†sections.

[Algorithm]

Oh guys this stuff is getting good.

 

Hey! I resemble that remark!

 

Please continue I can use the final result in the Wiki for the “Glossary†and “Creating a Scene†sections.

 

Actually, I was hoping that upstatemike would join in, as he's obviously done much thinking on this subject! And everyone else, too, of course.

[upstatemike]

Under the established definition of groups and scenes (within the context of this discussion) I would have to agree that tracking the status of scenes might best be handled programmatically because scenes are abstract states. They can be controlled by links as a means to set the scene but the physical link is not part of the definition of a scene as evidenced by the fact that making the scene "false" through a manual change does not change the link that originally set the scene.

 

A group is not an abstract condition but is rather a physical set of devices that can have a one to one association to links and more importantly to a memory location within a PLM. It might make sense to have this tracked within the ISY by default such that when any device linked to PLM memory location x is on (at any level) then memory location x (aka group x) would be considered true or on. When all devices linked to memory location x (group x) are off then group x is false or off.

 

Envisioning a keypad using such an arrangement I might assign button C as scene 1, button D as scene 2, button E as scene 3, and button F as group X. Lets assume that scenes 1, 2, and 3 only affect the devices included in group X. Let's also assume that the group X button (button F)has been linked to all of the devices in the group with a level of 100% so it can be used to turn all devices in the group full on or full off. The scene buttons set the devices to different dim levels to achieve the desired affect.

 

My expectation of how the keypad LEDs would operate is this:

 

Press scene 1 button-

devices go to scene 1 levels

scene 1 button LED goes ON to indicate scene 1 is set (true)

group X button LED goes on to indicate 1 or more devices in group X are ON

 

Press scene 2 button-

devices go to scene 2 levels

scene 1 button LED goes OFF because scene 1 is no longer true

scene 2 button LED goes ON because scene 2 is set (true)

group X button is still lit because 1 or more devices in group X are ON

 

Manually change a dim level of a group X device-

scene 2 button LED goes off because scene 2 is no longer true

group X button is still lit because 1 or more devices in group X are ON

 

Press scene 3 button-

devices go to scene 3 levels

scene 3 button LED goes ON because scene 3 is true

group X button is still lit because 1 or more devices in group X are ON

 

Press scene 3 button again-

devices get another command to go to scene 3 levels (so no change)

scene 3 button LED remains ON because scene 3 is true

group X button is still lit because 1 or more devices in group X are ON

 

Press group X button-

all devices in group X go OFF

scene 3 button LED goes OFF because Scene 3 is no longer true

Group X button LED toggles to OFF because all group X devices are OFF

[Michel Kohanim]

Hi All,

 

I didn't want to disrupt the exchange of ideas suffice it to say that I do find this topic very interesting as well.

 

We can maintain the state of a scene internally and it has already been captured as an enhancement feature. I must add that since for ISY there's only a logical difference between a scene/device/button (they are all nodes) thus we do have the concept of implicit states. All we have to do is to make sure the implicit state is actually something useful/intuitive and not one that causes confusion.

 

Thanks again for all your feedback and please do continue!

 

With kind regards,

Michel

[Algorithm]

upstatemike, thanks for the input; good thoughts all the way around.

 

My expectation of how the keypad LEDs would operate is this:

 

Press scene 1 button-

devices go to scene 1 levels

scene 1 button LED goes ON to indicate scene 1 is set (true)

group X button LED goes on to indicate 1 or more devices in group X are ON

 

Press scene 2 button-

devices go to scene 2 levels

scene 1 button LED goes OFF because scene 1 is no longer true

scene 2 button LED goes ON because scene 2 is set (true)

group X button is still lit because 1 or more devices in group X are ON

 

Manually change a dim level of a group X device-

scene 2 button LED goes off because scene 2 is no longer true

group X button is still lit because 1 or more devices in group X are ON

 

Press scene 3 button-

devices go to scene 3 levels

scene 3 button LED goes ON because scene 3 is true

group X button is still lit because 1 or more devices in group X are ON

 

Press scene 3 button again-

devices get another command to go to scene 3 levels (so no change)

scene 3 button LED remains ON because scene 3 is true

group X button is still lit because 1 or more devices in group X are ON

 

Press group X button-

all devices in group X go OFF

scene 3 button LED goes OFF because Scene 3 is no longer true

Group X button LED toggles to OFF because all group X devices are OFF

 

Yes, I agree with your analysis, and would just like to add a couple of qualifiers.

 

When one presses scene 2 button, devices go to scene 2 levels, scene 2 button goes on, but scene 1 button goes off if, and only if, scene 1 is no longer true. That is to say, scene 1 and scene 2 could have the identical levels. I'm sure that no one would actually do that, but the point is that the buttons are not mutually exclusive, and a scene button should go off only when its presets no longer exist.

 

Manually change a dim level of a group X device--buttons representing any scenes which are no longer true, should go off; by the same token, buttons representing any scene which has become true by this action, should turn on. This same logic should apply whenever any state change occurs within ISY--all scenes and groups should be evaluated and their status set appropriately. I don't mean to imply that ISY should do a whole network query, but rather that it should use its predictive algorithms exactly as it is doing now.

 

upstate, I know you know these things; indeed your posts influenced my thinking on this. I'm just clarifying (I hope) for other readers.

[Algorithm]

We can maintain the state of a scene internally and it has already been captured as an enhancement feature.

 

Michel, that's great to hear!

 

All we have to do is to make sure the implicit state is actually something useful/intuitive and not one that causes confusion.

 

It would be great if ISY could maintain the state of both the scene and the group, but reading between the lines, it sounds as though perhaps ISY will only maintain a single state for each scene/group. If that is the case, then it must be decided whether to maintain the state of the scene (becomes false when any member varies from the preset level) or the state of the group (becomes false only when all members are off).

 

Whichever state is chosen (if only one can be maintained), the other state can be found by user programming as is done now. So what say you, fellow forum members--which state should be maintained?

[upstatemike]

upstate, I know you know these things; indeed your posts influenced my thinking on this. I'm just clarifying (I hope) for other readers.

 

Yes, I kept my examples simple to get the concept across clearly but there are a number of things implied by this definition.

 

For example:

 

If you hold the group X button down to dim or brighten the entire group then all scene button LEDs would go OFF unless your manual dimming happens to stop at a level that exactly matched a defined scene. (unlikely)

 

If you walked around and manually set all of the devices in a scene to the exact levels defined in a scene button then the LED for that button should turn ON as soon as the last device is set.

 

Since turning on any device in Group X, or any scene that has a device included in group X, will cause the Group X button LED to turn ON, the Group X button will always be in sync and available to turn the whole group OFF.

[upstatemike]

Maybe it would help folks in thinking about this if I provided a real world example of how I will apply groups and scenes if and when I am able to get an ISY.

 

In my Living Room I have 5 lamps that are controlled by an Insteon dimmer switch (with no local load) by the door, and a RemoteLinc on the coffee table. The wall switch turns all the lamps On or Off and the ControLinc operates them independently. I also have PowerHome turn on 1 lamp at a dimmed level for a few hours in the evening as a pass through light (You have to walk through the living room to get from some areas to others).

 

I consider the 5 lamps to be a group and the wall switch to be a Group button because it turns the group On and Off. Since the lamps are controlled by a link from the switch (as opposed to being a local load on the switch), I refer to the On level set by the wall switch as the default scene.

 

(NOTE: Even if the wall switch was only controlling 1 LampLinc and it turned it On to full brightness I would still call it a scene because the LampLinc was controlled by means of a link rather than being a local load on the switch. If something is controlled by a link I always consider it a scene.)

 

I'm using the term "default scene" to mean the scene set by controlling a group. You would not track the status of a default scene because it is set by a group button and that buttons LED is used to track the status of the group (as explained in earlier posts).

 

My plan is to:

 

1- Replace the SwitchLinc with a KeypadLinc

 

2- Make the Large buttons my Group control buttons; so pressing the Large Top button will turn all 5 lamps on to the default scene and and the bottom button will turn all 5 lamps Off. The top button will be lit any time any of the 5 lamps is on at any level so it will always be intuitive to press the bottom button to turn everything Off.

 

3- I will make the 4 center buttons into scene buttons for "pass through", "reading", "dimmed", and "corner desk". Whenever one of those scenes is set it will be lit in addition to the top button.

 

4- I will have the ISY turn on the "pass through" scene at sunset and turn Off the Living room Group at bedtime. If, during this "pass through" window, I turn On the living room default scene (using the top group button) or if I set a different scene using another scene button, the pass through scene LED will go off (as described in earlier posts.)

 

5- If I have any scene other than the "pass through' scene set during the pass through window and I then turn off the group (either from the KeypadLinc or from the RemoteLinc) , I will have the ISY immediately turn on the "pass through" scene again.

 

6- If I turn off the group outside of the pass through window OR if I turn off the group while the "pass through" scene is set, then the group will just turn Off.

 

(So if I have the Living Room lights at Full between Sunset and Bedtime and I turn them off as I leave the room then the "pass through" lamp will automatically come On. If I decide I am going right to bed and don't need it On then pressing the bottom keypad button a second time would shut it Off).

 

7- I will have an X-10 Hawkeye motion sensor in the Living room. When the motion sensor is triggered After Bedtime OR before Sunrise then the "pass through scene will be set for 5 minutes. The motion sensor is disabled between sunrise and Bedtime. The motion sensor is also disabled if any lights are manually turned On from the KeypadLinc or RemoteLinc (if the group is already True) and of course the 5 minute Off timer is disabled if any lights are controlled manually during the 5 minute countdown.

 

Hopefully this example is helpful in thinking through the use of scenes and groups.

[Algorithm]

upstate, great job. That's an excellent example, and should help in understanding the subject.

 

I noticed you introduced a new term, "default scene". I like it! There's another term for the Wiki, Mark.

[Mark Sanctuary]

Yeah I will have to spend some time study this post in order to add it to the Wiki, it's very detailed!

 

Actually the wife has asked me for the Holidays to keep my Wiki time light so the kids get my time. So the Wiki will have to get attention when we all get back to work after the vacation.

[upstatemike]

I think after all is said and done we really only have about five definitions to deal with:

 

GROUP – A collection of devices that are monitored and controlled together. A group is said to be On if any of its member devices is On and is said to be Off when all of its member devices are Off. Because a group is said to be on when any of its member devices is on at any level, there are many possible combinations of member device states that define the group as being on. When a button is used to control a group and turn it on, the specific combination of device states that is established is called the “default scene†for that group button.

 

SCENE – One or more devices set to specifically defined states by means of a link or command. A scene is considered to be on or True if all of the devices in the scene are set to the exact levels that are defined by the scene. Even a single device, set to turn fully on, is considered to be a scene if that control is accomplished by means of a link or command rather than by manually switching a local load. Because a scene is said to be off or false when any level setting of any of its its member devices changes, there are many possible combinations of member device states that define the scene as being off. In general you would turn ON a scene and turn OFF a group.

 

DEFAULT SCENE – The scene that is set when a group button turns on its group. A given group might be controlled by several different group buttons. Each button would be considered to have its own default scene for the group when it turns the group on. There is no association between the default scenes for different group buttons even if they control the same group. The default scene for different buttons controlling the same group may, or may not, be configured to set the group devices to the same levels.

 

GROUP BUTTON - A button or button pair that controls a group. The button or button pair will turn the group on to a default scene (defined during the button linking process) and will also turn the group off. Group buttons can also be used to dim or brighten all of the members of a group in unison if desired. The buttons on ControLincs, RemoteLincs, and KeypadLincs are considered group buttons as they are normally configured. A SwitchLinc button is also considered a group button if it is linked to control other devices in addition to, or instead of, the local load.

 

You can use group buttons to set different scenes by defining a different default scene for different buttons (on the same or different controllers) that control the same group. This works well for devices like ControLincs and RemoteLincs that do not have status LEDs associated with the buttons.

 

SCENE BUTTON - A scene button may be used when a KeypadLinc or other device employing status LEDs is used to set multiple different scenes for a given group of devices. If more than one group button is defined on the same KeypadLinc there would be confusion as to which scene was active based on the LEDs. To make the buttons more useful, a KeypadLinc can be configured with scene buttons in addtion to a "master" group button or a non-toggle off button. Scene buttons are non-toggle on buttons that always transmit a specific combination of device states to a group of devices. The status LED on a given scene button will only be lit if that scene is currently active or "true". KeypadLincs have some provision for setting up scene buttons internally and and having the status LEDs switch to the currently active scene. A better approach is to use a central logic controller to set the scene status LEDs. An external controller is more flexible and can account for manual operation of devices or commands from other controllers when setting the scene status LEDs.

[upstatemike]

In reviewing the definitions above it still feels unsatisfactory because we have two classes of things to keep track of; scenes and groups. What we really need is a Grand Unified Scene Theory to define everything with a single class.

 

I propose we eliminate the concept of 'group" as something we want to track or control and instead manage everything with Unified Scene Theory. If we were to do this, the definitions for groups and group buttons would be eliminated. The "default scene" associated with a group button would be handled as a general scene and so would "group off" which would become the "Common Off Scene".

 

The only new concept we need to introduce under Unified Scene Theory is the idea of "common off scenes" which is just another way of saying that any scen button can toggle everything to off.

 

Using my living Room KeypadLinc example above, pressing the top large button would turn on the 5 lamps as before but the scene is no longer thought of as a default scene and is in no way unique from any other scene. Likewise the bottom large button would no longer be thought of as a "group off" control but instead merely sets another scene that happens to turn everything off. We will call this the "Common Off Scene" because it turns everything off and because it can be common to many toggled scene buttons.

 

Assuming the 4 small buttons are used to set other scenes as in the previous example, we can press one of these and have the scene change and the small buttons status LED light up as before. But unlike the previous example where the top button stayed lit because it was considered a "group button" it now goes off just like any other scene button status LED would because that scene is no longer set.

 

Another difference is that the small scene button can be pressed to toggle the scene off and turn off all the lights just like the large bottom button can. This would be thought of as setting the "common off scene" which is just another way of saying that any scene button can toggle all of the lights off.

 

So we have One type of button (a scene button).

 

We have standard function that matches default behaviour of a ControLinc or KeypaLinc when different buttons on the same device are used to set different scenes. In other words any scene button can toggle the lights to off.

 

We keep the idea that as soon as a scene is no longer "true" that the associated status LED goes out. This would correspond to the logical tracking within the ISY as to whether the scene was considered ON or OFF.

 

The only down side is that if a scene is active and then a device in the scene is changed manually, then there will no longer be a status light to indicate that some devices are on (since we no longer have a group button that stays lit whenever any device is on).

 

This can be addressed as:

 

1- Who cares? as long as I have a dedicated off button somewhere on the keypad (such as the large bottom button) then this is fine. Note that in 8-button mode you would always need a non-toggle off button to turn everything off when no scene buttons were lit.

 

or

 

2- Program the status LED in the large bottom button (or a non-toggle off button) to light up whenever there are devices on but no predefined scene is set. This way there would always be a status light of some sort on whenever at least one device was still on... either a scene button light or the default status light in the non-toggle off button. (The non-toggle off status LED works like the old group status LED except it only comes on when there are no scene buttons lit).

[Algorithm]

upstate, I like your unified field^B^B^B^B^Bscene theory. One advantage of such a scheme is that there would be no need for the ISY to track two separate status (group and scene); a single scene status would be sufficient.

 

But as I was reading through your description, I found myself wondering about the former group indicator. Reaching the end of your post, I see that you have addressed that as well.

 

Option 1 - Who cares? should not be preferred because, I think, almost every user is likely to use at least one 'all off' indicator, such as 'First Floor All Off' or 'Inside Lights All Off' or something similar.

 

Option 2 is much better in that regard. One could define an 'all off' scene which included all the desired members, each set to Off. ISY could track this scene like any other, so the scene would be False if any member was Not Off, and True only if all members were off.

 

The user could program ISY to set a button's light On when the scene was True and Off when the scene was False, thus having the button lit when all members were Off (an All Off indicator). Alternatively, the user could program ISY to set the button's light Off when the scene was True and On when the scene was False, thus having the button lit when any member was Not Off (an NOT All Off indicator). Either of these would be independent of the state of other scenes/buttons.

 

Finally, the use could program ISY such that the above button indication would be mutually exclusive of other button indicators, yielding the condition you described in Option 2 that said indicator would only be on when the other scene indicators were off. The user could choose whichever type of indication he preferred.

[Mark Sanctuary]

Guys guys ... don't forget that Scene Theory states there is eleven dementions.