Hi guys - I searched for other threads in the forum re turning every device off using a single button. It seems the prevailing recommendation is to use a scene, which I agree. I also like someone's idea of a program to indicate the status of the "All Off" lights by checking if the status is "not off."

I made an "All Off" scene and added all of the items I want to turn off as responders. Added a keypad button (set to toggle off) as the controller. Then Set those devices to 0% for that button within the scene.

Two things:

1. I have some other keypad buttons that do not turn off when the "All Off" scene is triggered. This is mainly because those buttons are in a different scene and trigger microcontrollers. One simple example is I have a light scene called "Garage Hall Accent Light Scene." This scene has one keypad button and one microcontroller that's tied to under cabinet lighting. If I add the microcontroller to my "All Off" scene it will turn off the microcontroller but the button on that keypad remains lit. Do I need to keep adding those additional trigger buttons as responders to my "All Off" scene and set them to "Off"? My concern is that it's creating a super-bloated scene. Is there performance issues to consider? A better way?

2. I want to have multiple "All Off" buttons throughout the house (eg. one at each door, a remote for the car, etc.). Is there a way to add another controller to my "All Off" scene without having to re-do all of the "Insteon -> 0%" settings for each device within that scene for the new controller? (Like... copy default settings from controller A to controller B within this scene.)

Thank you!
Peter.

Edited Friday at 08:58 PM1 day by PeterP
Clarifying

1 hour ago, PeterP said:

Do I need to keep adding those additional trigger buttons as responders to my "All Off" scene and set them to "Off"? My concern is that it's creating a super-bloated scene. Is there performance issues to consider? A better way?

No better way. The performance might be felt only when managing the scene.. adding, modifying or removing scene members. Especially if any of them are wireless sensors, which doesn't sound like the case. The scene itself is a single group # programmed into all the scene members. They all wait for that one group number so, no, run time performance is not a factor.

What can be a factor is that the PLM can handle 1000 links and large scenes can affect the approaching or exceeding that.

1 hour ago, PeterP said:

I want to have multiple "All Off" buttons throughout the house (eg. one at each door, a remote for the car, etc.). Is there a way to add another controller to my "All Off" scene without having to re-do all of the "Insteon -> 0%" settings for each device within that scene for the new controller? (Like... copy default settings from controller A to controller B within this scene.)

No sure I'm following. Each new controller in a scene activates the scene... that's it. A controller activating the scene tells each group member to do whatever it's been told to do for that scene.

A follow up is that scenes are a one time, fire-and-forget Insteon moment. Large scenes increase the odds that one or more member doesn't hear it.

Insteon scenes are one of it's biggest features. Turning off a bunch of lights is just one wonderful application for a scene. I have scenes like that which are only used for turning off devices (those scenes are never "turned on"). And you can have multiple controllers for the same scene, or use programs.

Thanks guys. I agree managing the scene seems painful with so many items.

@paulbates what I was referring to is that once I have my scene with all of the items I want turned off as responders and I add a new controller (let's say I add a remote I also want to trigger "All Off") then I need to select that controller in the scene and individually set each responder item to 0%. Was wondering if there's a way I can just say "apply all settings from another controller" within the scene.

1 hour ago, PeterP said:

Thanks guys. I agree managing the scene seems painful with so many items.

@paulbates what I was referring to is that once I have my scene with all of the items I want turned off as responders and I add a new controller (let's say I add a remote I also want to trigger "All Off") then I need to select that controller in the scene and individually set each responder item to 0%. Was wondering if there's a way I can just say "apply all settings from another controller" within the scene.

No, you can't. But you don't need to set the on level to 0, just use the controller off button. Of course if you want it so that no matter what action you take at the controller, the scene turns off, then you would need to set on level to 0 for all devices. If it is a kpl, you can set it to non-toggle off instead.

Isy used to let you propogate the settings for one controller to all of them, but they got rid of that many moons ago when they added non-insteon products. Apparently the logic broke when applying to node server devices.

For non-automation controls ie: manually (human) operated, trigger a program to operate the scene in ISY.

With manual operations a few milliseconds of delay is not perceptible.

1 hour ago, PeterP said:

Thanks guys. I agree managing the scene seems painful with so many items.

@paulbates what I was referring to is that once I have my scene with all of the items I want turned off as responders and I add a new controller (let's say I add a remote I also want to trigger "All Off") then I need to select that controller in the scene and individually set each responder item to 0%. Was wondering if there's a way I can just say "apply all settings from another controller" within the scene.

If you are using your KPL button as a "Non-toggle OFF", you shouldn't need to worry about the individual devices On level. You may want to adjust ramp rates.

A couple of differences in how "scenes" are implemented for devices vs the ISY:

• The ISY will execute a scene with no follow-up. It does not verify that devices heard or responded to the scene command (it assumes).

• Insteon devices will execute "cleanup" requests to each scene member to determine whether the command was received/executed. The device may retry commands. This is really very reliable.

The upshot here is that Large scenes require a LOT of communication and significant time. If another device begins transmitting in the middle of this process the device can/may abort the verification. With this in mind, you want to prevent programs from being triggered by the all-off and jumping in during the verification process.

Broadcast "All Link" messages are standardized at 3 Hops. Cleanup requests/responses use 1 Hop. Each standard length message (or hop) requires 0.05 Seconds. The table below shows how this can quickly add up. I have a 17 device basement scene that requires 0.2 seconds when executed by the ISY (no cleanups). It requires 3.4 seconds when operated from my KPL.

Once you have your scene configured, you can test the operating (to a degree) by using the ISY scene test function. The scene test will turn all of the scene devices ON using an Insteon standard message (02 62) to your scene (no verification). If will then turn the scene on using the Insteon "All Link Command" (02 61) to the scene. The PLM will then interrogate each scene member to determine if it received/operated on the command (cleanup messaging). The results of my basement scene test (17 members) are shown below.

The test below took 4 seconds to execute from the ISY. Note that if the PLM does not receive a response from a member, it will re-try the cleanup command with an additional HOP added. The PLM can re-try up to 5 times. If you see a response with Max Hops > 1, the message has been re-tried by the PLM. This will add a lot of variability to the timing of the response.

Using this tool, you should also be able to look for undesirable interactions with programs.

Edit: Corrected cleanup Hops start at 1.

Edited 13 minutes ago13 min by IndyMike

That's the most detailed explanation I've seen about Insteon communications during scene commands. Thanks for that.