Do something if device is on for X minutes?

[pilot]

I'm brand new to the ISY and learning how to program it.

 

A first program I want is to do something if someone leaves an insteon light on for more than 2 minutes. 

 

Basically:

Trigger:Light On

 

Action:

Wait 2 minutes, If light ON Then, ACTION

If during two miutes, light off, then cancel program

 

I need the cancel program, as I don't want it to happen if someone turns the light on, then off, and then back on and two minutes after the first action the action occurs because it's on after two minutes even though it went off before. I'd want the two minutes to re-start at the second turn on.

 

I can't see how to do this. Any hints or pointers to a discussion of this before? I looked but didn't find it.

 

Thanks!

[stusviews]

If

Light on

And Light is not off

 

Then

Wait 2 Minutes

Set Light Off

 

Else

Cancel program

[oberkc]

A little elaboration on stusviews suggestion: use "control" rather than "status" for conditions.

 

if

control light is turned on

and

control light is not turned off

then....

[pilot]

Thanks guys! I tried it and it worked. I never would have guessed that the logic worked that way, but I'm glad it's possible and it gives me a good start on programming my system.

[tjkintz]

Responding to oberkc's suggestion: There are pros and cons to testing status or control. If testing control and the user is a little slow or heavy fingered then instead of seeing On or Off, you might see Fast On/Off, Fade Up/Down/Stop or Bright/Dim. You really need to test all cases which I consider a PITA. That is why I normally test for "status is not off" which covers all cases. On the other hand I just had a weird situation where a status inexplicably changed from 0 causing a program that test for status changes to execute the Then clause of the program. Inexplicable status changes have never happened before and I am about create a post about it.

[larryllix]

Responding to oberkc's suggestion: There are pros and cons to testing status or control. If testing control and the user is a little slow or heavy fingered then instead of seeing On or Off, you might see Fast On/Off, Fade Up/Down/Stop or Bright/Dim. You really need to test all cases which I consider a PITA. That is why I normally test for "status is not off" which covers all cases. On the other hand I just had a weird situation where a status inexplicably changed from 0 causing a program that test for status changes to execute the Then clause of the program. Inexplicable status changes have never happened before and I am about create a post about it.

Status is easy to implement if both conditions are wanted.

 

Keep in mind, with  a Switchlinc wall switch, "control / switched" monitors the paddle of the switch. "status" monitors the dimmer electronics as two separate parts of the device.

 

 

For most purposes these serve the same purpose, one watching the up/ and down taps of the paddle and one watching the dimmer electronics...

 

• If
• ....status of Switchlinc is 'On'

 

• If
• ....control SwitchLinc is switched 'On'
• and
• ....control SwitchLinc is NOT switch 'Off'

[oberkc]

Responding to oberkc's suggestion: There are pros and cons to testing status or control. If testing control and the user is a little slow or heavy fingered then instead of seeing On or Off, you might see Fast On/Off, Fade Up/Down/Stop or Bright/Dim. You really need to test all cases which I consider a PITA. That is why I normally test for "status is not off" which covers all cases. On the other hand I just had a weird situation where a status inexplicably changed from 0 causing a program that test for status changes to execute the Then clause of the program. Inexplicable status changes have never happened before and I am about create a post about it.

 

One unspoken benefit of CONTROL over STATUS, however, is that status triggers only upon CHANGE.  Control, however, will trigger upon receipt of and specified command.

 

In this case, if the light is already on and one wanted to extend the 2-minute timer, tapping it on (again) would restart the countdown.  This would not work with status.

 

This is why I suggested what I suggested.

[tjkintz]

Everyones needs are obviously different but in the vast majority of situations all I care about is if something is off or not off and the transitions between those two states. Therefore I just want the simplest programmatic test for this situation. The best I could come up with is testing status. If the status changed to Off then it had to previously be some level of On. If the status changed to Not Off then it has been turned on to some level or has been changed to some new level of On.  

 

oberck makes a good point re: restarting the timer but that only works if the user truly taps the up paddle. People in my household tend to hold things instead of tapping so that necessitates testing for all the "up" possibilities of Control. I agree that if the status is already On then simply tapping on again would not trigger the program if testing status.

 

I had to think a bit about larryllix's suggestion and I am still confused. The second clause of the And test seems redundant and doesn't accomplish anything. If it has been switched on then implicitly it has not been switch off so the and condition is always true. If it was an Or test then it would indicate a button push resulting in some state of On. But that could have been a push (not tap) of either side of the paddle. A Not of an Or test would be logically equivalent to a test for control Off.  Is there a typo? If the user was like my family members then a push of the down paddle could easily have resulted in something other than Off, even though they might have wanted an Off. 

 

I have agonized about the best and simplest way of programming  for what I need and still haven't come up with something that doesn't have some possibility of failure.

[oberkc]

 

I had to think a bit about larryllix's suggestion and I am still confused. The second clause of the And test seems redundant and doesn't accomplish anything. If it has been switched on then implicitly it has not been switch off so the and condition is always true. If it was an Or test then it would indicate a button push resulting in some state of On. But that could have been a push (not tap) of either side of the paddle. A Not of an Or test would be logically equivalent to a test for control Off.  Is there a typo? If the user was like my family members then a push of the down paddle could easily have resulted in something other than Off, even though they might have wanted an Off. 

 .

The purpose of the second clause is to watch for an OFF command and, when encountered, run the ELSE path (thus halting the program).

[larryllix]

Everyones needs are obviously different but in the vast majority of situations all I care about is if something is off or not off and the transitions between those two states. Therefore I just want the simplest programmatic test for this situation. The best I could come up with is testing status. If the status changed to Off then it had to previously be some level of On. If the status changed to Not Off then it has been turned on to some level or has been changed to some new level of On.  

 

oberck makes a good point re: restarting the timer but that only works if the user truly taps the up paddle. People in my household tend to hold things instead of tapping so that necessitates testing for all the "up" possibilities of Control. I agree that if the status is already On then simply tapping on again would not trigger the program if testing status.

 

I had to think a bit about larryllix's suggestion and I am still confused. The second clause of the And test seems redundant and doesn't accomplish anything. If it has been switched on then implicitly it has not been switch off so the and condition is always true. If it was an Or test then it would indicate a button push resulting in some state of On. But that could have been a push (not tap) of either side of the paddle. A Not of an Or test would be logically equivalent to a test for control Off.  Is there a typo? If the user was like my family members then a push of the down paddle could easily have resulted in something other than Off, even though they might have wanted an Off. 

 

I have agonized about the best and simplest way of programming  for what I need and still haven't come up with something that doesn't have some possibility of failure.

No typo. This take a while to digest with the usual boolean algebra people but...

• If
• ....control SwitchLinc is switched 'On' <-------runs Then if the paddle is tapped on the top
• and
• ....control SwitchLinc is NOT switch 'Off'  <----runs Else if the paddle is tapped on the bottom
•  

This was the point of my post. In a Switchlinc you are dealing with three different devices.

• The  pushbutton under the top of the paddle sends Control / switched 'On'
• the  pushbutton under the bottom of the paddle, sends Control / Switched 'Off'
• and the status of the dimmer electronics sends Status if changed

ISY programing has provided a separate code to sense and trigger on each one.

 

All three devices send status changes, and all three devices cause ISY programs to trigger. It depends what you want to detect.

 

 

What does that mean to you?

If you use 'status' and somebody turns the dimmer off from anywhere, the program will stop immediately and run 'Else'

If you use Control / Switched 'On' there is no 'Off' because that PB cannot send an Off so Else can never be triggered to run. Only the paddle top can send an 'On' again.

[tjkintz]

I am definitely a boolean algebra person. Having had a career writing software I have found programming ISY to be maddening at times. 

 

I now see the point of the second clause. With the code snippet not explicitly showing an Else clause I forgot all about it. However my head is still exploding as I think through this.

 

First, what is a "PB"?

 

It seems your If clause is true only for a tap on the top of the paddle and that may be all you care about. But that seems to ignore other ways of getting to On such as Fast On or Brightening to 100%, let alone On at less than 100%. It also only catches Off via a bottom paddle tap and ignores all the other ways of getting to Off such as Fast Off and dimming to Off. Like I said before, my users tend to fat finger, instead of tapping even though they think they are just tapping. I know I could write code to explicitly test for all states and presses and respond accordingly but that is a lot of code to repeat in a lot of programs. Oh, for a subroutine! Heck, I would even take a macro! Is there an easier solution that I am missing?

[oberkc]

No, I dont think you are missing anything. It just depends on what you are trying to accomplish and what is important to you. I think you have already mastered the hard part just by the recognition that you need contemplate all the scenerios. Of course, it is also important to understand what triggers an evaluation, along with the pure boolean logic of the condition.

 

If you want to capture the most scenerios, I suppose you could include them all:

 

If

(

Status is not off

Or

Control is on

)

And

Control is not off

Then...

Else....

[larryllix]

I am definitely a boolean algebra person. Having had a career writing software I have found programming ISY to be maddening at times. 

 

I now see the point of the second clause. With the code snippet not explicitly showing an Else clause I forgot all about it. However my head is still exploding as I think through this.

 

First, what is a "PB"?

 

It seems your If clause is true only for a tap on the top of the paddle and that may be all you care about. But that seems to ignore other ways of getting to On such as Fast On or Brightening to 100%, let alone On at less than 100%. It also only catches Off via a bottom paddle tap and ignores all the other ways of getting to Off such as Fast Off and dimming to Off. Like I said before, my users tend to fat finger, instead of tapping even though they think they are just tapping. I know I could write code to explicitly test for all states and presses and respond accordingly but that is a lot of code to repeat in a lot of programs. Oh, for a subroutine! Heck, I would even take a macro! Is there an easier solution that I am missing?

LOL! You'll fit in just fine here then!

 

OK. To make things more complicated on these Switchlincs you can Or a bunch of triggers together.

The SwitchLinc paddles can sense double tap, long tap, short tap.

 

• If
• ...Control switchlinc is switched 'On'
• OR
• ...Control switchlinc is switched 'Fast On'
• OR
• ...Control switchlinc is switched 'Brighten'  <----this may not be the right syntax. I can never keep the ramping straight in my head and seldom use it.'
•  
• Then
• .... somebody fingered the button up with some type of press.

 

Yes...as Switchlinc has 7 different output signals! I have one that controls about 18 lights in 25 different scenes and colours of lighting.

 

 

PB        Sorry.... electronic shorthand for 'pushbutton' switch.

 

 

Also please note oberkc's line above.

 

• status is Not off.. This is to handle anything from 1% to 100% ... as simple On won't do it.

[tjkintz]

All, thanks for all the input. In the wee hours of a typical insomniac night I was reaching the same conclusions about combining status and control tests to catch all the possibilities. I now need to revisit a bunch of programs to see if I want to change anything. Given the way Admin Console works, it seems impossible to copy and paste a bunch of lines from one program to the next. Is there a way to do this?

[larryllix]

All, thanks for all the input. In the wee hours of a typical insomniac night I was reaching the same conclusions about combining status and control tests to catch all the possibilities. I now need to revisit a bunch of programs to see if I want to change anything. Given the way Admin Console works, it seems impossible to copy and paste a bunch of lines from one program to the next. Is there a way to do this?

Not easily but.... click on a line you want to copy in the source program.

Then select the construct menu in the destination program. The parameters typically will fill in the same.

 

Rinse and repeat.

[tjkintz]

One more question, do you know if the firmware signals on a paddle/button press or release? I ask because if it signals on a press, and the user is holding the key to dim or brighten, then there is a potential race condition if I am trying to determine if the status is on or off. Control would signal the press but the final status would be undetermined at that instant.An accurate status would not be known until the release.

[larryllix]

One more question, do you know if the firmware signals on a paddle/button press or release? I ask because if it signals on a press, and the user is holding the key to dim or brighten, then there is a potential race condition if I am trying to determine if the status is on or off. Control would signal the press but the final status would be undetermined at that instant.An accurate status would not be known until the release.

Just by logic I think you are correct. The style of push can only be determined once the release is done.

 

The violation of that thinking may be the long press (dimming) but somebody would have to do some test programs in ISY to determine that.

I know only one signal is ever sent AFAICT because my main Gathering room switchlinc would trigger many programs at the same time. I run a dozen programs off one switchLinc.

[apostolakisl]

You can also do this.

 

If

control switched on

or

status is not off

 

Then

do your timer thing

Else

do something else

 

With this, you can reset your timer by tapping the on paddle regardless of "how on" the switch currently is (80%, 100%, 36% etc etc).  The 'status is not off' will capture all changes to the condition of the light and trigger true aside from it being turned completely off (which will tigger the else).  The control switched on will only ever evaluate to true and will only have any affect on this program with a single "on" click of the paddle.

 

Also, keep in mind that 'status' programs trigger no matter how the light changed status, 'control' programs only trigger upon physical pressing of the switch. 

[tjkintz]

I did some testing to see if there were timing issues. The results were surprising and I don't understand them. Explanations would be appreciated. 

 

The situation is:

- There is a set of garage closets radiating off a common area that I refer to as a foyer. Each closet has a dimmer, as does the foyer.

- There is a follower program for the closets which turns on the foyer dimmer if any closet is on.

- The following is a program to turn off all the closet lights if the foyer is turned off, or goes to Off through dimming or Fast Off.

 

Garage Closets Off 

 

If

        Control 'Garage / Closets / Foyer' is not switched Off

     Or Status  'Garage / Closets / Foyer' is not Off

 

Then

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

 

Else

        Set Scene 'Garage / Garage Closets' Off

 

Test case:

I turned on the foyer light and turned on a closet light.

If I tap the foyer light off, it turns off the closet light

If I hold the foyer down paddle until it hits Off, the closet light does not turn off even after releasing the paddle.

Logically, at some point while I am holding down the lower paddle, the status hits 0 but the program doesn't detect that.

 

Now for the weird part. If I change the If condition to be an And instead of an Or, the program works and the light turns off once I release the paddle after dimming to 0. I tried reversing the order of testing control and status but it did not change the behavior in either case.

 

Like I said earlier, programming ISY can be maddening at times.

[oberkc]

Let's think this through aloud....

 

The first condition will trigger only upon receipt of an OFF command from the paddle.  It will not trigger if the status of the device is changed by program or scene response.  When so triggered, it will evaluate false.  All other times, it will be true.

 

The second condition will trigger upon any change in status, however achieved (locally or indirectly).  Once triggered, I expect to evaluate true, except when the foyer light is off.

 

When you manually dim down the switch to zero, the switch probably DOES go to zero, but you did not receive an OFF command from the switch.  At that point, therefore, the first condition is TRUE, the second condition is false.  By Boolean logic, the condition, therefore, is true (at least one condition is true).

 

When changing OR to AND, both conditions are not true, therefore, the condition as a whole is FALSE.  This sounds consistent with your experience.  

 

Sounds like it is working as designed.  My perception is that there may be some confusion regarding triggers and when a CONTROL...NOT OFF evaluates false.

[MWareman]

Why not trigger on ‘status is off’ and put the scene command into the ‘Then’?

 

My head is hurting working the logic and timing otherwise. It’s unlikely that control will be triggering still as the ISY receives the updated status. I think it’s best to separate the two clauses.

[oberkc]

 It’s unlikely that control will be triggering still as the ISY receives the updated status. I think it’s best to separate the two clauses.

 

I think you nailed it here.  The control condition always evaluates as TRUE, except when manually toggled off.  Since it was not manually toggled off, it is TRUE.  TRUE or FALSE = TRUE.  Runs THEN clause.

[MWareman]

When you manually dim down the switch to zero, the switch probably DOES go to zero, but you did not receive an OFF command from the switch. At that point, therefore, the first condition is TRUE, the second condition is false. By Boolean logic, the condition, therefore, is true (at least one condition is true).

I have to disagree. Dimming will never trigger a ‘control on’ or ‘control off’ event.

 

Ergo, dimming to zero should cause the status to trigger (and evaluate false) but the first clause will not trigger - but will be evaluated when the status triggers. It will evaluate false.

 

So, both the first and second condition is false at the triggering event.

 

I would think that should run ‘Else’...

[oberkc]

I have to disagree. Dimming will never trigger a ‘control on’ or ‘control off’ event.

 

Ergo, dimming to zero should cause the status to trigger (and evaluate false) but the first clause will not trigger - but will be evaluated when the status triggers. It will evaluate false.

 

So, both the first and second condition is false at the triggering event.

 

I would think that should run ‘Else’...

 

We agree that the first clause will not trigger.  My understanding of the first clause (and all such "not off") conditions is that when it DOES trigger, it will evaluate FALSE.  At all other times, it will evaluate TRUE.  Since it did not trigger during the dimming experiment, it would be TRUE.  

 

A simple program such as:

 

if control device is not switched off

then

...

else

...

 

Will never evaluate true (unless externally triggerrd).

[MWareman]

I think it is triggering, but evaluating true and running then....

 

‘Control’ is the trigger.

 

‘Not Off’ means any one of On, dim, brighten, fast on or fast off. Since dim is one of those, it may be true at the moment the status comes in as ‘not off’.

 

Therefore, ‘Then’ will run instead of ‘Else’ - as is being seen.

 

Split the program in two...