Logical Grouping of Devices and Scenes

[matapan]

One feature of ISY I have never been comfortable with has been the separation of scenes and devices with respect to multi-way switch setups.

 

If you have a multi-way switch setup, it appears you must use the scene to toggle the multi-way switch and have all the switches in the setup toggle status at the same time. You could toggle just the device handling the actual load from the devices list, but then you'd end up with the other switches in the multi-way setup not updating their status at the device.

 

This seems really weird and counter-intuitive from a user perspective. Why not group multi-way setups with devices in a single view so that the visibility of the logical function is promoted, or comes through?

 

I use the Mobilinc Pro iPhone app, and this is where the low level grouping of Devices and Scenes really makes little sense from a user perspective. You have to go to the Devices list to toggle one thing, and Scenes for other stuff.

 

What do you think? I respect the existing organization from a computing/coding perspective and see why it was done this way.

[oberkc]

I don't see this as an ISY issue, but inherent with insteon. Scenes are part of the insteon design. ISY just makes them easier to create.

 

I am not sure that this has ever caused much confusion in my head, but many have accused me of being a little strange in my ways of thinking.

[LeeG]

matapan

 

You are absolutely correct regarding Scenes and Devices. Sending an Insteon Direct command to an individual device produces very different results from sending an Insteon Group (Scene) command to a Group of Insteon devices. The Insteon architecture does not support a Controller to Responder with the Responder than becoming a Controller to its Responders.

 

Until automation software/firmware became popular there was no Device specific (Insteon Direct command) control. When a button or paddle is pressed it always generates a Group (Scene) message to control the responder(s). As far as device to device control is concerned, a button/paddle press cannot send an Insteon Direct (Device only) message.

 

In a multi-way configuration a Scene (Group) must be used to keep all the devices in sync. Just the way Insteon works. Not something the ISY decided to arbitrarily implement. I am using the term Scene and Group to mean the same thing. The term Scene appears in all the Smarthome sales/retail level documentation because someone thought it made more sense than the term Group. Looking at things from Insteon hardware you will not see the term Scene even appear in the Insteon command document or PLM interface document. Everything is a Group from the perspective of Insteon hardware (which is a Scene in external terms).

 

If the ISY chose a different method of showing a Scene/Device relationship it would be something unique to the ISY, different from all the Smarthome/Smartlabs documentation. Not sure but that might be more confusing.

 

Hope this has not added to the confusion level.

 

Lee

[matapan]

There is an opportunity here for ISY to go beyond the physical grouping of scenes/groups and individual devices to map to a logical grouping which puts single pole and n-way switches in one group together. Maybe separate them by rooms, floors, whatever.

 

It sounds like sending a group command is a one way deal, and requires a switch to identify itself as part of a group in order to respond.

 

Smarthome describes how to set up n-way switching in their documentation, so the concept of n-way switches isn't a foreign one with Insteon. It's a matter of devising the logical wrapper around it.

[LeeG]

matapan

 

The end user makes the decision which switches should be linked and/or cross-linked. The Insteon device has no knowledge how it will be used. Linking (a Scene) is one way in its most basic form. One Controller and one or more Responders. From Insteon hardware perspective this is called a Group.

 

 

Switch A – Controller

SwitchB – Responder

SwitchC – Responder

 

If these three switches are part of a logical 3-way circuit such that they all should stay in sync with each other and all three should be able to control the load then two more sets of links (Scenes/Groups) need to be established.

 

SwitchB – Controller

SwitchA- Responder

SwitchC – Responder

 

SwitchC – Controller

SwitchA – Responder

SwitchB – Responder

 

Each of these three link combinations (Scenes/Groups) are independent as far as Insteon hardware is concerned. Put together they logically cross-link the three devices such that any switch can control the load and all three switches stay in sync regarding their status LEDs.

 

The ISY makes this definition very easy. From an ISY perspective define one ISY Scene. Make SwitchA, SwitchB and SwitchC Controllers in that one ISY Scene. That is all that is necessary for the end user to do when using the ISY. When that one ISY Scene definition has been rolled out to the three switches, from the Insteon hardware perspective, three independent Controller/responder Scenes/Groups have been established. Just one of the ways ISY simplifies link management. In some software packages it would be necessary to define three separate link (Scene/Group) definitions.

 

Hope this helps.

 

Lee

[oberkc]

There is an opportunity here for ISY to go beyond the physical grouping of scenes/groups and individual devices to map to a logical grouping

I must be missing the point here. I am failing to understand what problem you are trying to solve. N-way switches are easily handled in a "logical grouping". It is called a "scene", with all devices defined as controllers.

 

single pole and n-way

In case you are interested, most three-way switches are "single pole" (they are typically "single pole, double throw"). According to wikipedia, this type of switch may also be known as "single pole changeover". By comparison, a standard switch is a "single pole, single throw". I also found it interesting that three-way switches are known as two-way switches in the UK and Europe (this makes more sense in my mind).

[mikewu99]

I think the OP is discussing the default web interface. With the default interface "Devices" is one sub-window and "Scenes" is a different sub-window. He would like to have his devices and his N-way scenes in the same sub-window.

 

The solution would be for him to modify the web interface to suit his preferences.

 

Of course, I could be completely misunderstanding the OP.

[matapan]

Thanks for the responses.

 

MikeWu is correct in the original intent of the post. It would be helpful to be able to set up a logical grouping of switches and scenes in one view instead of separating them. I understand the physical setup and the Insteon Group command and what it does. But I think most non-Insteon users like to view their switch organization in the traditional single pole, n-way setups.

 

Here's an example, to illustrate the point:

 

I have a scene consisting of 4 switches that control one load.

If I want to turn on that load, I have to know which switch actually handles the physical load and toggle it. If I turn on any of the other 3 switches, the switch state is on, but the load turns turn on from the web interface or from Mobilinc Pro. I have to go down to the list of scenes, and toggle the scene to turn the load on or off.

 

The physical abstration of separating devices and scenes as it applies to single pole and n-way switches is particularly intrusive when you use the Mobilinc Pro iPhone app. Instead of looking at loads, you are looking at a list of devices in one view and a list of scenes in a separate view. Wouldn't it be useful to look at a list of loads in a single view and have the ability to control it there, without going in and out of device and scene views?

 

I know the uses for scenes/groups go well beyond the scope of n-way switches. But I wager that the most common use for scenes/groups is to set up n-way switching. Nice to know Insteon does more than this with groups. I use groups for several other things too.

[oberkc]

If I want to turn on that load, I have to know which switch actually handles the physical load and toggle it. If I turn on any of the other 3 switches, the switch state is on, but the load turns turn on from the web interface or from Mobilinc Pro. I have to go down to the list of scenes, and toggle the scene to turn the load on or off.

This sure goes beyond the trivial suggestion, given the construct of insteon. Short of additional logic within the ISY to force scene response consistent with local control, I am having trouble visualizing how one would do this. I suspect solutions would also force the user to input much more data (Naming of loads? Device wired to load?)

 

Have you put any thought into how you would display it if you were king for the day?

[matapan]

Sure, I've thought about it. An abstraction layer would be required to handle the logical grouping of load circuits. If the console or app handled the creation of the n-way switch, it could manage the supporting scene/group and all the links required.

 

Working in the physical abstraction reminds me of the days when apps used to have to manage read/writes to a floppy disk device - too device/implementation-dependent, not user-friendly.

[mikewu99]

Still seems to me all you are looking for is a page in the web interface which contains a combination of devices and scenes, preferably only those devices and scenes which you select. You should be able to do this yourself with some hacking of the html code from the default web interface.

 

I made a custom home page which contains a subset of my scenes - basically I took the source html from the "scenes" page (generated by the isy), edited out the parts I didn't want, changed some text, and saved the resulting html to the /USER/WEB directory of the isy. You should be able to do something similar by cutting and pasting from both the "scenes: source and the "devices" source.

 

More elegant solutions are possible using the REST interface, but my html skills are quite limited...