Nested scenes

[andrewm]

I've often thought that nested (or virtual) scenes would be a good idea to reduce the complexity of managing & maintaining scenes. This is not something Insteon can do, but I think ISY could achieve it.

 

I have several scenes that control devices that also exist in other scenes. For example I may have 2 scenes for outside FRONT lights & outside REAR lights controlled from various keypads. Keypad buttons would effectively indicate the scene status. I may then have an ALL OUTSIDE ON scene, that would turn on all the devices in both scenes, and all their associated status buttons. Setting this up requires me to effectively duplicate the contents of both component scenes into my master ALL scene. Changes I make to my component scenes must also be manually made to my master scene. It takes quite a bit of effort to get this working right with all the status lights correctly indicating current state. Subsequent maintenance is a real PITA.

 

I believe the ability to nest scenes in the ISY UI would help this. When a scene is nested within another master scene, then at the Insteon level, all the nested scenes devices would become responders in the master scene, using the original attributes of their nested scene. Changes to the nested scene would be automatically reflected in the master scene.

 

Taking this a level further, a more complex case would be to allow the master scene to override the nested scene attributes (eg ALL OFF). That'd help me no end, but I can't visualize how to implement that one in a general form - but I thought I'd include it!

[Michel Kohanim]

Hi Andrew,

 

Is this something that ISY does in the UI or does it create programs under the covers?

 

In short, what is a nested scene from ISY's perspective?

 

With kind regards,

Michel

[andrewm]

This is something ISY would do in the UI - under the covers it would all map back to regular Insteon groups, which have no concept of nesting. Programs shouldn't be used or impacted by this.

 

Another way to think of it may be in terms of a Unix file system; a nested scene would just be a symlink to another existing directory somewhere.

 

Visually this really wouldn't be that far from where you are now; it would just mean that scenes can contain other scenes (just as folders can contain other folders). So you have all of the building blocks in place. It wouldn't add any more UI complexity from the user perspective, because if you didn't want to nest you wouldn't have to - in which case your device tree would be unchanged from present. The ISY would have to do more work behind the scenes to unravel the nested scenes into the equivalent Insteon groups.

[Mark Sanctuary]

Are you trying to describe "virtual controller nodes" so you can have more than one look without having a separate scene?

 

Thanks,

[andrewm]

I haven't heard of a virtual controller node, and a quick search didn't return anything, but I can imagine a connection. Without knowing anything about them, I'd imagine a VC node would address that more complex case I mentioned in my original post - I knew that'd require a different conceptualization than pure nested scenes, and VC's would seem to fit that.

 

I would think that nested scenes are simpler, in that the scene attributes of the nested scene wouldn't be changed when incorporated into a master scene. With Virtual Controllers I'd imagine you could change attributes - that'd be much more flexible and useful, but at the cost of increased complexity in the UI and under the covers.

[Michel Kohanim]

Hi Andrew,

 

Thanks so very much. We do have a design for virtual nodes but it seems that we never find enough time to implement them (that goes for variables too).

 

With kind regards,

Michel

[andrewm]

I completely understand!

[Michel Kohanim]

Hi Andrew,

 

First of all, thank so very much for your input as they are quite invaluable (we did change the address/name fields in 2.8.3 as per your suggestion).

 

I would like to know the status of your unit using DHCP since that seems to be quite serious. I would appreciate your input.

 

With kind regards,

Michel

[andrewm]

I noticed in the release notes for 2.8.3 that you'd made the changes I'd suggested - thanks!

 

I have guests staying at the moment so I shouldn't make firmware changes. Also I'll need to leave it running for quite a while before we can really decide if the network problems are gone... proving negatives are hard!

[gogogadgetscott]

I second the request for nested scenes. It would be great to have the option of using the tree to drag one scene into another. This way setting the parent scene on would also turn the child scene on.

 

It seems that a program could setup this functionality but using the tree seems like a clearer option.

 

For example...

 

Having a scene called "Entrance Light". The responder is a ground level keypad main button connected to the ground level, overhead light. The controller is the first level keypad B button. This works as a three-way.

 

Also having scene call "Light Path" that turn on all overhead lights from the forth level to the ground level. Currently we have to add both the responder and controller from "Entrance Light" to "Light Path". It would be so easier if we could just drag and drop "Entrance Light" to "Light Path". This way if we change or add a controller and/or responder to "Entrance Light" than "Light Path" would be updated automatically.