'All Off' button/status -- one more twist

[Algorithm]

Most Insteon users with a network of sufficient size to warrant the use of an ISY, will likely have one or more requirements for an 'All Off' button. It could be, for example, to turn off all basement lights after going up the stairs, all theatre lights when leaving the room, or all house lights when going out the door. In addition, the typical user would like that same button's LED to display the status of the particular 'All Off' scene, with the LED being on when any of the associated lights are on, and off only when all the associated lights are off. He may even wish to have more than one button, on different keypads, for the same function, such as Basement Off both at the top of the stairs and in the kitchen, or Whole House Off at both front and rear exits, as well as in the master bedroom.

 

The traditional approach has been to use the button(s) as an ISY trigger for a scene which turns all the related loads off. Additional ISY programs monitor the status of the related loads, and keep the button LED(s) in sync. [Thanks to Mark Sanctuary (ref. All Lights Scene Programs - cool tips and tricks), Yardman 49 (Frank) and MikeB (ref. Monitoring room status), and MikeB and IndyMike (ref. keypad button to indicate status of and control entire floor).

 

This approach may look something like:

 

Scene 'Basement All Off'
   This Load
   That Load
   Another Load
   . . .


Scene 'Basement All Off LED Status'
   This Button
   That Button
   . . .


Program 'Basement All Off Trigger'
If
       Control 'This Button' is switched Off
    Or Control 'That Button' is switched Off
    Or Control '. . .' is switched Off

Then
       Set Scene 'Basement All Off' Off

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


Program 'Basement All Off False LED Status'
If
       Status  'This Load' is not Off
    Or Status  'That Load' is not Off
    Or Status  'Another Load' is not Off
    Or Status  '. . .' is not Off
   And (
            Status  'This Button' is Off
         Or Status  'That Button' is Off
         Or Status  '. . .' is Off
       )

Then
       Wait  1 second
       Set Scene 'Basement All Off LED Status' On

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


Program 'Basement All Off True LED Status'
If
       Status  'This Load' is Off
   And Status  'That Load' is Off
   And Status  'Another Load' is Off
   And Status  '. . .' is Off
   And (
            Status  'This Button' is On
         Or Status  'That Button' is On
         Or Status  '. . .' is On
       )

Then
       Wait  1 second
       Set Scene 'Basement All Off LED Status' Off

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

The 'All Off' scene must contain, as responders, all of the loads which are to be turned off. For a 'Whole House Off' scene, this number can be quite large [in my case, from 49 to 54 loads].

 

The 'All Off LED Status' scene must contain, as responders, all of the KeypadLinc buttons which are to control/report the 'All Off' scene.

 

The 'All Off Trigger' program watches for any of the associated buttons being turned off, and then turns the respective scene off. If the button should be pressed while it is already in the Off state (thus turning the LED on), the scene will not be affected, and the status programs will turn the button's LED back off within a second or two.

 

The status programs basically say, 'If any load is not off, and any keypad button LED is off, then turn the keypad button LEDs on,' and 'If all loads are off, and any keypad button LED is on, then turn the keypad button LEDs off.' The reason for testing the state of the button LEDs before changing them, is to reduce power-line traffic by not sending the LED on or off command every time a load is changed, when the LEDs are already displaying the correct status (cf. IndyMike).

 

While this approach works well, it does have some drawbacks, the most important of which are related to the use of a trigger as opposed to hard links. First, it introduces a delay between the button press and the scene activation (lights off). Perhaps as important, if the central controller (ISY) is for any reason out of service, then the 'All Off' buttons are non-operational.

 

An earlier approach did use hard links, by placing the button(s) in non-toggle off mode to avoid having all of the loads turn on (cf. MikeB). The obvious disadvantage of that approach is that the button LED does not indicate the 'All Off' scene status. A less obvious disadvantage is that should the button LED in some manner get errantly turned on, the button (being in non-toggle mode) would from that point send an On rather than an Off command when pressed, thus turning all the loads on.

 

A NEW TWIST

 

Here is another idea, which I have adopted, that attempts to address the previous shortcomings. This approach uses hard links, eliminating the added button-press to lights-out delay, and also keeping the buttons operational in the event of the central controller being out of service.

 

The twist is that the buttons are not placed in non-toggle mode, but rather left in toggle mode, meaning that they can still display the scene status. This is accomplished by placing all of the buttons in the 'All Off' scene as controllers, and all of the loads in the 'All Off' scene as responders in the usual manner, and then setting each loads' On-Level to zero.

 

The result is that should the button be pressed while it is off, thus sending an On command, the entire scene is turned on to level zero, which is another way of saying that it is turned off! This is also accurately reflected as a status of Off in ISY. So no matter what the current state, pressing the button always turns the scene Off. I have tested this with both in-wall dimmers and relays, and plug-in dimmers and relays (all Icons), along with the KPL, and it works perfectly.

 

The approach looks like this:

 

Scene 'Basement All Off'
   This Load
   That Load
   Another Load
   . . .
   This Button - controller
   That Button - controller
   . . . - controller


Scene 'Basement All Off LED Status'
   This Button - responder
   That Button - responder
   . . . - responder


Program 'Basement All Off Status'
If
       Status  'This Load' is Off
   And Status  'That Load' is Off
   And Status  'Another Load' is Off
   And Status  '. . .' is Off

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

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


Program 'Basement All Off Status False'
If
       Program 'Basement All Off Status' is False
   And (
            Status  'This Button' is Off
         Or Status  'That Button' is Off
         Or Status  '. . .' is Off
       )

Then
       Wait  1 second
       Set Scene 'Basement All Off LED Status' On

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


Program 'Basement All Off Status True'
If
       Program 'Basement All Off Status' is True
   And (
            Status  'This Button' is On
         Or Status  'That Button' is On
         Or Status  '. . .' is On
       )

Then
       Wait  1 second
       Set Scene 'All Off Follow Test' Off

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

The 'All Off' scene contains, as responders, all of the loads which are to be turned off, as well as all of the associated buttons as controllers.

 

The 'All Off LED Status' scene, as before, contains as responders all of the KeypadLinc buttons which are to control/report the 'All Off' scene.

 

There is no trigger program, but the status programs have increased to three. The first is simply a flag program which indicates the status of the scene, being True when all the loads are Off, and False when any load is On. The other two simply use that status in conjunction with the buttons' status, to set the buttons on or off as appropriate. This results in a modest code space saving within ISY, as the list of loads (which can be quite large) need only be enumerated once, rather than twice. As far as I have been able to tell, the LED response delay is about the same as using two status programs with separate enumerations.

 

One potential disadvantage of this approach as opposed to the trigger approach, is that it requires more physical links within the devices. Provided that the user's devices have the required space, this disadvantage is far outweighed by the advantages mentioned above.

[Sub-Routine]

Very good JAJ.

 

The only thing I would change is that I would not bother to check the Status of the status lights. The programs are only going to send one group command.

 

Rand

[Mark Sanctuary]

This is great! I got to try this stuff out!

 

And thanks for not using "foo" "bar" coding examples.

[MikeB]

Oooooh.. I like this. Your a smart cookie. Can't wait to try this out!

[Algorithm]

Very good JAJ.

Thanks, Rand!

 

The only thing I would change is that I would not bother to check the Status of the status lights. The programs are only going to send one group command.

Does not the ISY follow the group command with clean-ups for each group member? If it does not, or if it does and we count the group+cleanups as one command, then yes.

 

But, it will send that command every time any of the group members is turned on or off, even if the LEDs are already reporting the correct status. So the purpose of the extra status check is to reduce that unneeded power-line activity. However, if the user doesn't mind the additional activity, the status programs could be reduced to a single program using both THEN and ELSE clauses.

[Algorithm]

This is great! I got to try this stuff out!

Thanks, Mark! Please let us know how it works out for you.

 

And thanks for not using "foo" "bar" coding examples.

From the Latin fubar, meaning Fowled Up Beyond All Recognition.

[Algorithm]

Oooooh.. I like this. Your a smart cookie. Can't wait to try this out!

Thanks, Mike! Please let us know how it works out for you.

[Sub-Routine]

Very good JAJ.

Thanks, Rand!

 

The only thing I would change is that I would not bother to check the Status of the status lights. The programs are only going to send one group command.

Does not the ISY follow the group command with clean-ups for each group member? If it does not, or if it does and we count the group+cleanups as one command, then yes.

 

AFAIK, yes every group command is followed with cleanup commands. How many status lights do you have for any one group? Cleanup commands are broken off (abandoned) as soon as another direct or group command is issued or encountered. Yes group + cleanups = 1 command, AFAIK.

 

But, it will send that command every time any of the group members is turned on or off, even if the LEDs are already reporting the correct status.

 

Isn't that the quickest response in this case? Since you are continuously monitoring the statuses of the devices in the scene changing any one should change the status no matter what the status of any other device in the scene. If no device changes status the program never runs. If the program runs it means a status must have changed.

 

So the purpose of the extra status check is to reduce that unneeded power-line activity. However, if the user doesn't mind the additional activity, the status programs could be reduced to a single program using both THEN and ELSE clauses.

 

 

 

There is a discussion about that somewhere. I made the suggestion that the status light Status be checked following a Control command before the Statuses of any more devices were checked. If the status lights were already on/off when an On/Off was received that no other status checks would be necessary.

 

I'm sorry if this is a bit confusing, I have been under the influenza

 

Rand

[Mark Sanctuary]

I know what your going thru, it just just hit our little family too.

 

I am sorry to hear that, I hope you feel better soon.

[Algorithm]

But, it will send that command every time any of the group members is turned on or off, even if the LEDs are already reporting the correct status.

 

Isn't that the quickest response in this case? Since you are continuously monitoring the statuses of the devices in the scene changing any one should change the status no matter what the status of any other device in the scene. If no device changes status the program never runs. If the program runs it means a status must have changed.

Yes, that is correct. Any time any light (in the monitored group) is turned on or off, the status of that device will change, which of course changes the status of the If condition as a whole, causing the condition to be re-evaluated and the program to be run. That is the point.

 

If your group has 20 lights around the house, and as people move about turning lights on and off, the LED group ON command would get sent every time any light was changed, even though chances are that after the first time, the LED will remain on until the All Off is actuated. So these constant LED commands are unnecessary power-line traffic.

 

So the purpose of the extra status check is to reduce that unneeded power-line activity. However, if the user doesn't mind the additional activity, the status programs could be reduced to a single program using both THEN and ELSE clauses.

 

 

 

There is a discussion about that somewhere. I made the suggestion that the status light Status be checked following a Control command before the Statuses of any more devices were checked. If the status lights were already on/off when an On/Off was received that no other status checks would be necessary.

I do remember that! I hope you can find that thread and place a link to it here, because I think it is a very good question that begs an answer.

 

If I recall correctly, your point was that if, in the If condition, the test for the button(s) status was placed before the test for the load(s) status, it would save some processing because there are likely to be many more load tests than button tests. The question was whether or not ISY abandons the test as soon as the result is known, or whether it processes the entire condition regardless. I hope Chris or Michel can provide the answer.

 

I'm sorry if this is a bit confusing, I have been under the influenza

'Tis the season! I'm truly sorry to hear that Rand, and Mark also! Wishing both you and yours a speedy recovery.

[Sub-Routine]

Hey Joe,

 

Here's the link: thread.

 

It might be the same difference either way...

 

Rand

[Chris Jahn]

If I recall correctly, your point was that if, in the If condition, the test for the button(s) status was placed before the test for the load(s) status, it would save some processing because there are likely to be many more load tests than button tests. The question was whether or not ISY abandons the test as soon as the result is known, or whether it processes the entire condition regardless. I hope Chris or Michel can provide the answer.

 

When an event occurs, the If conditions for all folders, and all programs that are "allowed to run" within folders are evaluated exactly once, even if referenced multiple times.

 

There is no short-circuiting of conditions within an If statement, therefore all conditions in the If are evaluated.

 

Generally, you don't need to worry about optimizing your programs, but if you have a very large number of programs, the best way to optimize them is as follows:

 

1) If you have a large set of common conditions required by multiple programs, then put those conditions into a single program and have the other programs reference it. This will also save memory.

 

2) Use folder conditions where possible. If the Folder conditions fail then the programs within it will not be evaluated.

[Algorithm]

Hey Joe,

 

Here's the link: thread.

 

It might be the same difference either way...

 

Rand

 

Yes, that's it, thanks. For anyone interested in the point about the order of execution, it begins in the very last post of the first page of that thread, and continues onto the second page.

 

And while I was re-reading it, Chris had already posted the answer here!

 

Thanks for those great tips, Chris!

[MikeB]

Just tried this last night one my '1st Floor Off' KPL secondary button. Works well, except for 1 thing - I'm finding that I need to wait a solid 3-4 seconds before pressing another button on the KPL, otherwise that 2nd button press will go unrecognized. I believe this is due to the cleanup messages coming from all the responders in the scene.

 

I didn't see this when using a program to trigger the scene in the ISY, and I believe this is because the ISY triggers the scene in a different way.

 

Can anyone confirm seeing a difference like this?

[Algorithm]

Mike, are you seeing this only with the newer KPLs? I don't have any of the new ones to test with, but I recall that you formerly had 1.4 KPLs, and also that you were at one time using hard links with non-toggle buttons presumably with the older KPLs. Did you notice this problem in that situation?

[MikeB]

Hey Joe -

 

I didn't, but my setup was completely different back then and I had far fewer 'status' programs on my ISY. I've also been having some KPL flashing issues on a couple scene buttons within my kitchen.

 

I'm in the middle of troubleshooting now, so I have my 1st/2nd floor off programs disabled, but I think what was happening was my status programs were stepping all over my scene cleanup commands - especially with large scenes and a large # of devices responding.

 

At this point I don't think it is KPL related. I no longer have any v1.4 KPLs kicking around, so I can't tell for certain - but the v1.65s have been working so well for me otherwise (knock on wood), I don't think they're the issue. I also think others would have reported the issue by now.

 

I should be re-activating my programs later today once I'm confident things are working well as-is. I'll post back my results.

[MikeB]

One issue I've found so far with this method...

 

I'm pretty anal about trying to make my lighting controls bulletproof. One thing that concerns me is if someone presses the '2nd floor off' KPL button ON. By setting the on levels for all devices to 0, theoretically that's OK - the lights will stay off and the button will turn itself back off because of the status check program.

 

However, what won't work well is any KPL secondaries that are members of the '2nd floor off' scene. KPL secondaries do not have on levels, so they will turn ON when this button is pushed. This also throws off my status check program, which I use to check the status of a coulple KPL secondaries on the 2nd floor.

 

I know this isn't a huge deal, but it's an annoyance for me....

[Algorithm]

However, what won't work well is any KPL secondaries that are members of the '2nd floor off' scene. KPL secondaries do not have on levels, so they will turn ON when this button is pushed. This also throws off my status check program, which I use to check the status of a coulple KPL secondaries on the 2nd floor.

 

I know this isn't a huge deal, but it's an annoyance for me....

 

Mike, good catch--that's an excellent point! Always room for improvement!

 

The only thing I can think of off hand to address this, is to include those KPL secondaries in the status programs. They would not have to be individually controlled sequentially; rather for each such situation one could create a group containing all of the secondaries, then simply turn the group off. This would add one additional command to the control sequence, which may still be preferable to the previous method, for the advantages it gives. It you're game to give this a try, please do let us know how it goes.

[MikeB]

The only thing I can think of off hand to address this, is to include those KPL secondaries in the status programs. They would not have to be individually controlled sequentially; rather for each such situation one could create a group containing all of the secondaries, then simply turn the group off. This would add one additional command to the control sequence, which may still be preferable to the previous method, for the advantages it gives. It you're game to give this a try, please do let us know how it goes.

 

 

Thanks for the reply, Joe. I read your post a few times, but I'm not sure I follow.

 

I do have these KPL secondaries in my status check program, which is actually how I noticed the issue. I was racking my brain on this for a while, because what would happen is I would press my '2nd floor off' button ON, and it would stay on, and the status check program would stay true! A scan through My Lighting showed that all my 2nd floor lights were OFF, which meant the program should show false. After a while of playing with it, it finally dawned on my that the KPL secondaries don't show in My Lighting, and those were the devices that showed as ON.

 

So, basically what happens in my system is if someone accidentally presses the '2nd floor off' button ON, the KPL secondaries go ON, and the status button stays ON as well, until it's pressed OFF.

 

So, sorry for being dense, but could you explain your suggested workaround with a bit more detail?

 

Thanks!

[Guest]

So, basically what happens in my system is if someone accidentally presses the '2nd floor off' button ON, the KPL secondaries go ON, and the status button stays ON as well, until it's pressed OFF.

 

So, sorry for being dense, but could you explain your suggested workaround with a bit more detail?

 

Thanks!

 

I use KPL buttons as status indicators with no issues you described by keeping KPL status lights separate from the scenes they control. For instance, most of my KPLs are in 8 button configuration with the 6 button plates. In simplified example the top button (AB) toggles main scene, and the bottom (GH) acts as status light for larger area and turns area lights off. Function of GH is controlled through ISY.

Light scenes:

 

1. KPL AB (devices KPL-A, KPL-

2. KPL GH (devices KPL-G, KPL-H)

3. Area lights A (devices dev1 and dev2)

4. Area lights B (devices dev3 and dev4)

 

Programs:

(kpl GH status)

If 
       Status  'dev1' is not Off
   Or  Status  'dev2' is not Off
   Or  Status  'dev3' is not Off
   Or  Status  'dev4' is not Off

Then

   Set Scene 'KPL GH' On 

Else 

   Set Scene 'KPL GH' Off

 

This program will correctly turn on and off both GH buttons following statuses of the area devices. If button G or H is off and gets pushed on, ISY will turn it off. If button G or H is pushed off when on it triggers this ISY program:

 

(kpl GH is pressed off)

  
If 
          Control  'KPL-G' is switched Off
       Or Control  'KPL-H' is switched Off

Then


          Set Scene ‘Area lights A’ Off 
          Set Scene ‘Area lights B’ Off
          Set Scene ‘KPL AB’ Off

Else 

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

 

I implemented this scheme on several KPLs with much more complicated schemes than above, and it works well. I only need to tolerate slight delay before buttons G and H get synchronized by ISY.

 

To recap, I monitor status of the individual devices to set KPL buttons on or off, and use ISY to turn off all area lights through ISY scenes.

 

Mark

[MikeB]

Hey Blue -

 

Thanks for the reply. I was doing that as well for KPL secondary 'scene' buttons, but since I've upgraded to v1.65 KPLs I am now using the KPL secondary as a controller of the scene, but run ISY programs like to to turn the KPL secondary off when the scene is no longer true.

 

However, the KPL secondaries I'm having issues with are not 'scene' controllers - they are linked 1 to 1 to control individual lamp modules, so I don't use any programs to control their status.

 

I could write a program to 'fix' their status if they get out of sync however.. I'll have to put some thought into that.

 

Thanks!

[Algorithm]

However, the KPL secondaries I'm having issues with are not 'scene' controllers - they are linked 1 to 1 to control individual lamp modules, so I don't use any programs to control their status.

 

Oh! Now I'm confused--sorry Mike. Could you describe the problem again with some examples, please?

[MikeB]

I'll try to explain...

 

For example, in my son's bedroom I have a KPL at his bedside in a tabletop enclosure. 2 of the secondaries on that KPL are linked to 2 LampLincs in his room so he can control each of his lamps from his bed.

 

Both the KPL secondaries and both LampLincs are members of my '2nd floor off' scene. The LampLincs are set with an 'on level' of 0 - that way, if my '2nd floor off' KPL secondary control button is off (becuase all the lights are off), and someone accidentally presses it ON, my lights will not go on. However, KPL secondaries do not have 'on levels', they will go ON when my '2nd floor off' scene is pressed ON.

 

So, I have 2 problems if that '2nd floor off' button is pressed ON:

 

1 - Because my '2nd floor off' status program checks the status of those KPL secondaries, it shows as 'true'. This is easily fixable - I can simply not check the status of those secondaries, but check the LampLincs instead.

 

2 - The KPL secondaries controlling the lamps are left on, even though the LampLincs are off. I could write programs to say 'if LampLincA is off, and KPLSecondaryA is not off, then turn KPLSecondaryA off'. This should 'fix' the issue, but create some extra traffic and complexity.

 

Does this make more sense?

[Guest]

1 - Because my '2nd floor off' status program checks the status of those KPL secondaries, it shows as 'true'. This is easily fixable - I can simply not check the status of those secondaries, but check the LampLincs instead.

Exactly what I was advocating. Do not check KPL secondaries. Check only devices with the load.

 

Both the KPL secondaries and both LampLincs are members of my '2nd floor off' scene.

No problem there.

 

The LampLincs are set with an 'on level' of 0 - that way, if my '2nd floor off' KPL secondary control button is off (becuase all the lights are off), and someone accidentally presses it ON, my lights will not go on.

This is your problem. Get rif of the 'ON level 0' set of mind. (BTW, this is left over from PH, right? )

Your '2nd floor off' scene level are not really relevant (I set mine to some usable "dim" levels for reuse), as long as you call your trigger with OFF statement, instead of calling it the way you do now (with 'ON, level 0').

 

Mark

[Algorithm]

Hi Mike,

 

Thanks for taking the time to write out the explanation... I now better understand what you are getting at!

 

I'll try to explain...

 

For example, in my son's bedroom I have a KPL at his bedside in a tabletop enclosure. 2 of the secondaries on that KPL are linked to 2 LampLincs in his room so he can control each of his lamps from his bed.

 

Both the KPL secondaries and both LampLincs are members of my '2nd floor off' scene. The LampLincs are set with an 'on level' of 0 - that way, if my '2nd floor off' KPL secondary control button is off (becuase all the lights are off), and someone accidentally presses it ON, my lights will not go on. However, KPL secondaries do not have 'on levels', they will go ON when my '2nd floor off' scene is pressed ON.

 

So, I have 2 problems if that '2nd floor off' button is pressed ON:

 

1 - Because my '2nd floor off' status program checks the status of those KPL secondaries, it shows as 'true'. This is easily fixable - I can simply not check the status of those secondaries, but check the LampLincs instead.

Right.

 

2 - The KPL secondaries controlling the lamps are left on, even though the LampLincs are off. I could write programs to say 'if LampLincA is off, and KPLSecondaryA is not off, then turn KPLSecondaryA off'. This should 'fix' the issue, but create some extra traffic and complexity.

If you remove the secondaries from the '2nd floor off' scene as in point 1 above, they should no longer turn on when '2nd floor off' button is turned on.