"Scenes" and "Groups"

[yardman 49]

Hello Mark & Darrell:

 

 

I realized that not all Controllers can function as Responders (think ControLinc, RemoteLinc), nor can all Responders act as Controllers (LampLincs, ApplianceLincs, etc). So I made modifications to accomodate this:

 

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

 

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 settings for an ISY Group. Each ISY-created Group has a minimum of one Scene associated with it (the ISY-controlled Scene). The number of Scenes per Group is equal to the number of Controller Devices in the Group (including the ISY itself as a Controller).

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

Controller Device == A device controlling 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.

 

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

[Mark Sanctuary]

Cool! The idea of naming the group as "ISY Group" solves the ghost link issue nicely. The ghost link now can exist at the lower Insteon conceptual level and be out of the ISY conceptual level.

[Mark Sanctuary]

Not sure if we need to define this one separately or not, Yardman what do you think?

 

Controlsponder Device == A device that can be a Controller and Responder at the same time.

[Mark Sanctuary]

So how about some pseudo code to analyze the connectivity of the definitions.

 

Device

Responder (Device)

Controller (Device)

ISY Group (Controller, Responder, Responder, etc.)

Scene (ISY Group)

 

I think the theory is really relating well with each of the defined components.

[Mark Sanctuary]

I am having a brain toot; Now wait a minute can a device be both a controller and responder in a group at the same time?

 

Controlsponder Device == Is a device with the potental to be both a Controller Device and a Responder Device in different groups.

 

They really can't be both in one scene at the same time. I think.

[Sub-Routine]

 

They really can't be both in one scene at the same time. I think.

 

Yes, they can, but except for a KPL the only response they could have would use the Local settings.

 

Rand

[upstatemike]

Responder is a subset of Controller. A Controller does everything that a Responder does PLUS it can control the scene. Even a ControLinc button has the properties of both a Controller and a Responder but there is nothing on it to respond so you don't think of it that way. There is nothing to prevent SmartLabs from making a future version of the ControLinc with indicator LEDs next to the buttons if they wanted to.

 

So I would argue that everything is a responder and some things are also a Controller IN ADDITION to being a responder.

[yardman 49]

I am having a brain toot; Now wait a minute can a device be both a controller and responder in a group at the same time?

 

Controlsponder Device == Is a device with the potental to be both a Controller Device and a Responder Device in different groups.

 

They really can't be both in one scene at the same time. I think.

 

 

From the way that Michel explained it to me originally, I believe that a Controller is indeed a Responder also, as long as it has the ability to "react" to a Control from another device.

 

For instance, in my example with the Living Room Ceiling Group, all three devices (Living Room KPL Load A, Kitchen KPL H, and Living Room RemoteLinc button 1) are all "Controllers". If I press the "Living Room KPL A," then the "Kitchen KPL G button" "turns on", hence it is a "Responder". The reverse is also true when Kitchen KPL H is pressed.

 

However, the "Living Room RemoteLinc Button 1" is only a controller. It cannot "respond" to the group on commands from the other devices. It can only send a command. (This is also the reason why RemoteLincs and ControLincs cannot be added to the ISY via the standard "Add Insteon Device" wizard, but have to have their own "special" wizard.

[yardman 49]

Even a ControLinc button has the properties of both a Controller and a Responder but there is nothing on it to respond so you don't think of it that way. There is nothing to prevent SmartLabs from making a future version of the ControLinc with indicator LEDs next to the buttons if they wanted to.

 

Hello Mike:

 

I don't know enough to confirm whether this is accurate or not. With the Controlinc and Remotelinc firmware as it currently stands, I would say "no". Michel would know, I'm certain.

 

I say "no", because Controlincs and Remotelincs are added to the ISY network differently than all other Insteon devices. I don't believe that they send out an ACK response, which I believe would be required of a responder. But I could be wrong.

 

Please enlighten me if I'm in error here.

 

 

Best wishes,

[yardman 49]

I am having a brain toot; Now wait a minute can a device be both a controller and responder in a group at the same time?

 

Controlsponder Device == Is a device with the potental to be both a Controller Device and a Responder Device in different groups.

 

They really can't be both in one scene at the same time. I think.

 

 

Certainly a vaild concept. Not certain that I like the name itself!

 

Although I wonder if this just introduces more complexity than needed. In the last proposed Controller definition, I state that many Controllers can also function as Responders. Although the distinction between "Controller/Responders" and "Controllers only" changes the way that the Insteon protocol handles the communications, I'm not certain that it is something that will not already be obvious to a user, since devices like the Controlincs and Remotelincs don't have any changeable states that need to be acknowledged back to the group.

 

Maybe Michel or Chris or Darrell can enlighten us.

 

Best wishes,

[upstatemike]

I don't think for the purposes of setting up scenes in an ISY that it would be useful to distinguish a "controller only" from a "controller/responder". The GUI already prevents obvious mistakes like making a RemoteLinc button into a responder in a scene or assigning an ApplianceLinc as a controller, so additional terms are not really useful.

 

The GUI icons already show which devices are "responder only" and which ones have the potential to also be "controllers". Any further terms or icons will be more likely to add confusion than to reduce it.

[Algorithm]

Thanks so much everyone for your contributions.

 

Now that you have defined a set of terms, can you describe how this will impact the ISY implementation, and how it will affect the user experience?

[yardman 49]

Thanks so much everyone for your contributions.

 

Now that you have defined a set of terms, can you describe how this will impact the ISY implementation, and how it will affect the user experience?

 

Hello Darrell:

 

What I had envisioned was that the terms be adopted into the the ISY GUI and the User Manual. Here are some ideas:

 

1- the "Make New Scene" command could be changed to "Make New ISY Group

2- the main Group view (currently called a Scene) would have the title changed to say something like "XXXXXX Group - ISY Scene"

3- the Controller views within an ISY Group would then have their titles changed to "XXXXXX Group - YYYYYYYY Scene", where "YYYYYYYY" is the name of the Controller Device that governs that Scene.

4- as mentioned by youself and others in the original thread, Scenes would by "default" inherit the ISY Scene properties, with the Insteon controller device properties being greyed out. But you could uncheck a box to allow for Insteon controller device Scene properties.

 

I haven't really given much thought to the specifics of the user interface. But these are some of the ideas.

 

Maybe you could find someone new to Insteon (maybe already has a few modules, and has been doing manual linking), as well as someone who has never used Insteon (but is interested), and then run some ideas by them to see what appears to be the most "user intuitive" approach. For those of us who have been using these technologies for a while, sometimes we are so used to the concepts that we cannot see "the forest for the trees".

 

Best wishes,

[Algorithm]

Hi Frank and All,

 

So then the definitions presented are intended primarily as a modification to the terminology, with a view to making the UI more intuitive for new users, is that correct?

[yardman 49]

Hi Frank and All,

 

So then the definitions presented are intended primarily as a modification to the terminology, with a view to making the UI more intuitive for new users, is that correct?

 

Yes, that is correct.

 

 

Best wishes,

[Mark Sanctuary]

Precisely!

 

The definitions are the framework that every bit of the GUI labeling can match. This is one of many things that can be done to clear up confusion.

[Mark Sanctuary]

So I am working on adding visuals to the wiki. This is the first one I have come up with. This should follow the discussion we have had in this thread. With a "scene being the holder of the data" and "groups being the holder of the links" this was what I came up with. And with the ISY the groups always having scene data that makes them controllers too.

 

Group/Scene == is both a group of devices and scene data, also known as a controller.

Device/Scene == is both a device and scene data, also known as a controller.

 

[Mark Sanctuary]

Also I am looking for all the major threads that have discussed scenes and groups. This is what I found so far.

 

"Scenes" and "Groups"

Groups Versus Scenes

Scenes 101 for a Nooblinc