Program not setting Int variable after Wait (Eisy)

[AllDigital]

I've got a simple program that sends me a text when one of my motion detectors fires a zWave relay switch. The motion detector could fire ten times in a minute, so I set up an int variable to provide ten minute "anti-bounce" logic. The If statement fires correctly and I get my notification, but the variable never gets reset to zero.

On my old 994i I had a similar anti-bounce, but I just used an and condition to test if the program status was "true". While in the wait 10 minutes loop it stayed true and then went false. 

On my Eisy I am having a lot of strange anomalies with my programs. I've tried deleting them, creating new variables, or doing crazy work arounds like firing off another program.

Is there anything wrong with the approach I'm using in the logic below? Is there a better way to script a 10 minute anti-bounce on a notification? Any idea why the variable doesn't get set back to 0?

Thanks,

Mike

using firmware 5.5.4 

[jwagner010]

As I understand it when it hits the wait the if is reassessed at which point the program is false and doesn’t run your last command line after the wait.  It’s one thing to keep in mind with adding wait statements they trigger reevaluation of the if statement.  
 

the way around it is divide into two programs. After the notification have a command that runs the then statement of the second program that just has the wait 10 and set to zero command in the program. 

Edited January 28, 2023 by jwagner010

[AllDigital]

Oh, yikes!  That is good to know. I am not aware of any programming language that would re-evaluate the conditional once it dropped into the action, unless it was being treated like a while(X) instead of an if.

I'll need to play with some small programs to see what works best for an anti-bounce timer.

Thanks for the quick response @jwagner010

 

[vbPhil]

The way I handle this is with 2 programs. The trigger program fires the 2nd action program. The action program immediately disables the trigger program. When the action program finishes all the actions, it enables the trigger program. Been running for years on a 994i and now on Polisy. Variations exists for damping and false trigger scenarios but that’s the basic. Beware of wait statements!

[oskrypuch]

That is a nasty one, I was not aware of it. But, I tend to two-step situations like this in any case -- good thing!

* Orest

[AllDigital]

Yeah, this is really inconsistent behavior. I have a bunch of other programs that I've been running for 5+ years that use wait statements with Insteon motion sensors. I just double-checked the logic and in those programs and the if statement is not getting re-evaluated during the wait (see program below). Those motion sensors act similar in that they go on, but then quickly go off. Those programs turn on lights, wait ten minutes, then turn off lights. During the "wait 10 min" the if conditional is going negative because the motion sensor went off, but the lights always go off in ten minutes. Very reliable. Go figure...

I just did some more testing and I found the easiest solution is to use a int variable in the conditional, but move the wait statement and the variable reset to a then statement in a second program (with an empty if conditional). The trigger program fires the Then statement in the wait program. I like your approach @vbphil of disabling the trigger program, but I'd be concerned if the power went out and the trigger program stayed disabled. Either way, it does seem like a hack to have to use two programs. I will be very wary of wait statements going forward.

 

 

[GJ Software Products]

I had the same issue.  Had program in my 994i that worked for years but as soon as I went to the eisy anything following the wait in the then would not run if the evaluation of the if went false during the wait.  I did like spoken about above, I'm now using two programs.  Yes, I too have never seen a language that re-evaluates the if once it's dropped into the then or else unless you're using a looping function like a do while...

[brians]

The programs are event driven and non-reentrant. There can be no multiple instances of same program. I wouldn't really call them full programs or compare them to a programming language really.

Every time the program is executed, for whatever reason, it halts the current running instance no matter what state it is, or what it is doing, and re-runs again - re-evaluates the if and executes either then or else again.

In this case, because the motion sensor is being triggered often before the 10 minute wait, it keeps re-running, and because the variable has been set to 0 within the program, the And statement makes the result False, therefore the program will ALWAYS run whatever is in the then section (in this case nothing). Not sure why it ran on the ISY before but it does not seem correct in how programs are supposed to be run so maybe was a bug.

Here are two programs that should do what you want but will only reset if there is no more motion for 10 minutes... if someone or something is continuously setting off the motion sensor you will not get another notification until 10 minutes after they are finished.

 

-----------------------------------------------------------------------------------
Motion Notify - [ID 00CF][Parent 00D5]

If
        'Garage / Garage Motion-Sensor' is switched On
 
Then
        Send Notification to 'Brian Telus' content 'Test'
        Disable Program 'Motion Notify'
 
Else
   - No Actions - (To add one, press 'Action')
 



-----------------------------------------------------------------------------------
Motion Wait - [ID 00D6][Parent 00D5]

If
        'Garage / Garage Motion-Sensor' is switched On
 
Then
        Wait  10 minutes
        Enable Program 'Motion Notify'
 
Else
   - No Actions - (To add one, press 'Action')
 

To solve issue if power outage, make a program that runs at startup, which enables Motion Wait program above.

Edited January 28, 2023 by brians

[MrBill]

18 hours ago, AllDigital said:

but I'd be concerned if the power went out and the trigger program stayed disabled. Either way, it does seem like a hack to have to use two programs. I will be very wary of wait statements going forward.

The thing to understand the event driven IF statements of an ISY.  Anytime the status of the IF statement changes it will be reevaluate.  If the program is "waiting" there is a chance to interrupt, therefore the program won't complete and at the very minimum the wait will be restarted.  On the other hand, the example in your first post when re-evaluated during the wait will always re-evaluate as false which will end the wait immediately and run ELSE (which is empty).

To prevent the trigger program from being disabled then loosing power, there are two options.  the second program might be enabled for Run At Startup. so that it would restart and finish.  If that's not appropriate after a restart, or might create a new issue, then a third program would be needed... no IF, then being reset the variable and enable the program, with the Run at startup attribute set.   In the case of your program in Example 1 you would likely want to use the second option, to make certain the program is enabled, the variable should reset on its own if it has an init value of 0.  (there's no problem with the run at startup program enabling a program that's already enabled, but having it ensures the if the program is disabled it will be re-enabled during startup.

[kclenden]

10 hours ago, MrBill said:

Anytime the status of the IF statement changes it will be reevaluate.

I know you know this, but just for clarity, that should read more like "Anytime the status of a trigger in the IF statement changes, the IF will be reevaluated."  In the OP's first post, the program has a trigger (the status of the switch) and a filter ($Int_MotionGolf - if it's actually created as an INTEGER variable and not a STATE variable).

[MrBill]

8 hours ago, kclenden said:

I know you know this, but just for clarity, that should read more like "Anytime the status of a trigger in the IF statement changes, the IF will be reevaluated."  In the OP's first post, the program has a trigger (the status of the switch) and a filter ($Int_MotionGolf - if it's actually created as an INTEGER variable and not a STATE variable).

You're correct, i wasn't very clear there, and I also didn't throw in the comparison to int vs state.  I really replied to supply the second paragraph but felt it needed into rather than just diving in.

[AllDigital]

Thanks guys. These clarifications help a lot and I believe I have an understanding of the logic flow and I can code/configure around the behavior. 

It will force me to rethink some of my programs where the trigger could bounce a lot and/or where the trigger only lasts a few milliseconds. In the later case, it would be a risk to put a lot of actions into a then statement or actions that took longer to execute than the trigger condition takes to reset.

It still seems to me that from an IoX design perspective the THEN logic should execute 100% once the IF conditions are met. If the triggers are reset and met again and again and again in succession then the whole of the THEN actions should fully execute over and over. 

I could see some rationale for stopping the THEN statement, like if I turned on a switch that then commanded ten lights to turn on -- if it was halfway turning on the lights and I turned the switch off the code would be justified to run the ELSE and command ten lights off.

Is there any other design rationale I am missing that justifies stopping the THEN actions midway? 

[vbPhil]

6 minutes ago, AllDigital said:

In the later case, it would be a risk to put a lot of actions into a then statement or actions that took longer to execute than the trigger condition takes to reset.

So, I believe it’s only when you have a Wait statement in the Then that the If can be reevaluated. Without a Wait the entire Then is executed regardless what is happening in the IF. 

[AllDigital]

6 hours ago, vbphil said:

So, I believe it’s only when you have a Wait statement in the Then that the If can be reevaluated. Without a Wait the entire Then is executed regardless what is happening in the IF. 

I believe that @MrBill is correct and that the THEN stops executing if the IF triggers change regardless of a wait statement. I have a program that does a lot of actions when motion fires and in extensive testing I notice that it doesn't always finish all of the actions. In my case it is sending notifications, executing other programs, and setting variables. Sometimes it will stop after sending me notifications, but before launching the other programs -- without any wait calls in the logic path. 

I tried to create a test program to capture the behavior with about ten lights and setting a state variable, but I am not fast enough on the state variable change to catch it. With more time this should be straight forward to test.

[MrBill]

If the state variable is included in the same program’s IF statement then changing it should be the last step of the THEN or ELSE body.

the method to protect waits is to use two programs.  The first program runs the then body of a second program, the second program disables the first program, does other things, then as it’s last statement re-enables program 1.  A third program (disabled/blank IF) would be used with the ‘run at startup’ flag set to establish the second program is enabled.

the ”phenomenon” that you’re observing is in fact expected behavior.

[AllDigital]

In my scenario, I had (no longer, so can't post it) a program X that was triggered by a momentary motion sensor. It had 4-5 lines of actions (no waits) then it was calling another program Y that would disable program X, wait ten minutes, then enable program X. 

The issue is that sometimes the program wouldn't get to the end of the THEN statement to fire off Program Y. I suspect it is because the motion went off before the THEN actions could finish and the program stopped. I've since moved 100% of the actions, along with the wait, into Program Y and all is good. 

[vbPhil]

We can beat a dead horse, but I found another example to bear in mind. You're all familiar with the "The ISY-994i Home Automation Cookbook", link is below. They have an example on Stopping a Program with a Wait statement. Page 159. It goes like this: (I substituted a device instead of using a scene.)

Quote

Debug - [ID 0005][Parent 0001]

If
        'Keypanels / Great Room / GR KPL #2- H' is switched On
 
Then
        Set 'Great Room / DN SwagLamp' On
        Wait  1 minute 
        Set 'Great Room / DN SwagLamp' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

The way they explain it,

Quote

9.3.4 Stop a Program
• When a Program is Waiting or Repeating it can be stopped. Here is an example that 
will cancel the above program.
• The 'DN SwagLamp' On' will remain on if the keypad button is turned off before the end of the 1 minute wait.
• Press the button On again to begin the 1 minute countdown again

This is not the behavior I see with IoX on Polisy. Even though I turn the keypanel to off the during the Wait the program still runs and the light shuts off. 

However if you change the if to :

Quote

If
        'Keypanels / Great Room / GR KPL #2- H' Status is On
 .........
 

Then it works as explained and the light never shuts off. So, there is a difference between a device being "switched" and its "status". Something that either changed or the Cookbook is in error as they used the "switched" condition and not the "status".

https://www.universal-devices.com/docs/production/The+ISY994+Home+Automation+Cookbook.pdf

 

[J-F]

30 minutes ago, vbphil said:

We can beat a dead horse, but I found another example to bear in mind. You're all familiar with the "The ISY-994i Home Automation Cookbook", link is below. They have an example on Stopping a Program with a Wait statement. Page 159. It goes like this: (I substituted a device instead of using a scene.)

The way they explain it,

This is not the behavior I see with IoX on Polisy. Even though I turn the keypanel to off the during the Wait the program still runs and the light shuts off. 

However if you change the if to :

Then it works as explained and the light never shuts off. So, there is a difference between a device being "switched" and its "status". Something that either changed or the Cookbook is in error as they used the "switched" condition and not the "status".

https://www.universal-devices.com/docs/production/The+ISY994+Home+Automation+Cookbook.pdf

 

This is exactly how the program should behave. Control is an event (it either happens or it doesn't), status is a state with two values and a value change triggers evaluation of a program condition. No mystery there.

[Javi]

Hi @vbphil

9.3.4 has 2 conditional arguments which allow the program to be stopped (is switched on and is not switched off).  For control conditions the program is only triggered if the control is in the condition.  So, in 9.3.4 the controls are both on and off.

[Geddy]

5 hours ago, vbphil said:

We can beat a dead horse

I feel for that horse! 

As @Javi points out you need that 2nd condition in your "IF" to make the program false. I ran a test and you have to have the second condition if you're using switched. As in the reference (pg 160) of the cookbook. In my program I have the office being manually turned on causing a lamp to come on. If I manually turn the office off the light stays on because it was true. During the wait the program became false and stopped the "THEN". Because there is nothing in the else the lamp will stay on until I turn it off. 

test1 - 

If
        'Office' is switched On
    And 'Office' is not switched Off
 
Then
        Set 'Desk Lamp' On
        Wait  2 minutes 
        Set 'Desk Lamp' Off
 
Else
   - No Actions - (To add one, press 'Action')

 

Status works for your situation because you only have the one condition being checked. Once the "STATUS" is true then the program runs THEN. If you then change the status to be off it turns your program FALSE and thus ends the "THEN" so anything that turned on would remain on. 

Since there's nothing in the ELSE there's nothing happening when the program goes FALSE. 

If you have Admin Console open while testing you should see the program turn green when true and running then. If you turn it off while running THEN it would put the red along the side of the program indicating that it's FALSE and no longer running THEN.

 

I think it's an unfortunate page break in the cookbook that Figure 153 applies to 9.3.4, but it does reference "above program". Figure 152 goes to the prior section of simple conditional programming. 

 

[vbPhil]

@Geddy All true. You can't un-switch something once it switched, but you can change status true to false.

[Geddy]

12 minutes ago, vbphil said:

You can't un-switch something once it switched, but you can change status true to false.

Correct, but your statement was that as you wrote the program the light still turned off after the wait if you turned the switch off. You made it sound as though you want it to stay on (which when you changed to status did leave it on). To do that you'd have to add the 2nd part of the "IF" for "not switched off". 

In my program when I turned the office on my lamp came on. If I turned the office off during the wait the lamp remained on. Because I had manually controlled the switch off. 

You would need to add:

And 'Keypanels / Great Room / GR KPL #2- H' is not switched Off

Put that in your IF of the original as you have it above and the lamp should stay on if you turn off the switch (manually) during the wait period. 

Sorry...really beating that horse now. Just goes to prove sometimes there is more than one way to achieve desired result. But think we've hijacked original post too much. My closing remark is that I'm on eisy IoX 5.3.3 and works as expected.

OP (@AllDigital was having issue with the wait because variable was changing before the wait and thus causing the IF to become FALSE and stopping the running of the THEN during the wait so the resetting of the variable never occurred. The reason their other programs ran with waits in them was probably because the if remained TRUE and allowed the whole THEN to complete. Once the IF becomes FALSE the THEN stops and runs ELSE.  So maybe put the wait in the ELSE then set the variable after the time. Or, as @vbphil and @MrBill mentioned using 2 programs.)

 

 

[brians]

Here is something relevant to this... programs which control my bathroom light/fan.

In particular look at my bathroom fan off else which sets the parameter because in the then when I turn off the fan, it re-triggers itself and would never execute anything after it. The reason I do this is because the junk Jasco GE motion sensors seem to be over-sensitive and turn on the light if I turn on the fan which is in same 2-gang box. I have tested this by turning off the motion using parameter and flick fan on/off and light never comes one, but as soon as I enable the motion sensor, the light comes on about 25% of the time when I turn fan on remotely via program or manually.

-----------------------------------------------------------------------------------
Bathroom Fan Off - [ID 007F][Parent 0084]

If
        'Main Bathroom / Main Bathroom Light' Status is Off
    And 'Main Bathroom / Main Bathroom Fan' Status is On
 
Then
        
        // Wait 5 minutes before turning Bathroom Fan Off.
        // If light turns back on then program halts/re-triggers and will be false.
 
        Wait  5 minutes 
        
        // Turn off motion sensor and wait 3 seconds before turning fan off. Found the relay sometimes sets off motion sensor, turning light back on.
 
        Set 'Z-Wave extra nodes / Main Bathroom / ZY 006 On-Off Power Switch' Set Configuration Parameter 6 = 0
        Wait  3 seconds
        Set 'Main Bathroom / Main Bathroom Fan' Off
 
Else
        
        // Turn on motion sensor because program will re-trigger after Main Bathroom Fan is turned off so cannot place this
        // after that command in Then because never runs. The result will be False so will re-enable motion here.
 
        Set 'Z-Wave extra nodes / Main Bathroom / ZY 006 On-Off Power Switch' Set Configuration Parameter 6 = 1
 
Main Bathroom light turns off automatically after 5 mins of last motion detected.
This program will make Fan shut off after 5 minutes of light turning off... 
eg. around 10 min if person leaves and lets the light time out. Want the fan to run a bit longer than the light.

Turns off motion sensor via parameter during the fan Off because the close proximity in same gang box tends to trigger the motion sensor
when the Fan is turned on/off.

This program will automatically turn it off if fan is turned on by any other means eg. fan turn on throughout day on schedule.
No other handling required in those programs.
If someone happens to be in the bathroom with light on then because the fan is already running user would not notice... and this program would not run to shut it off.




-----------------------------------------------------------------------------------
Bathroom Fan On - [ID 0069][Parent 0084]

If
        'Main Bathroom / Main Bathroom Light' Status is On
 
Then
        Wait  15 seconds
        Set 'Main Bathroom / Main Bathroom Fan' On
 
Else
   - No Actions - (To add one, press 'Action')
 
Uses Jasco Bathroom Light Motion Sensor to determine occupancy.
The motion sensor is set to turn on via motion, and off after default 5 minutes of no detected motion.
Note that re-triggering motion will reset the 5 minutes internally in the Jasco switch.
Therefore light should shut off 5 min after leaving room.
Use light On to determine when motion is triggered instead of looking at motion sensor directly.
Turns fan on 15 seconds after entering/triggering motion or light is turned on another method.

Another program handles the Fan shut off after 5 minutes of light turning off...
Therefore Fanshould stay on minimum 10 min: 5 minutes of light on and 5 min fan.






-----------------------------------------------------------------------------------
Bathroom Fan On Schedule - [ID 0085][Parent 0084]

If
        Time is 12:00:00AM
     Or Time is  4:00:00AM
     Or Time is  8:00:00AM
     Or Time is 12:00:00PM
     Or Time is  4:00:00PM
     Or Time is  8:00:00PM
     Or Time is Last Run Time for 'Bathroom Fan On Schedule' +  1 hour 
 
Then
        Set 'Z-Wave extra nodes / Main Bathroom / ZY 006 On-Off Power Switch' Set Configuration Parameter 6 = 0
        Wait  3 seconds
        
        // Turn off motion sensor before turning fan on. Found the relay sometimes sets off motion sensor, turning light on.
 
        Set 'Main Bathroom / Main Bathroom Fan' On
        Wait  3 seconds
        Set 'Z-Wave extra nodes / Main Bathroom / ZY 006 On-Off Power Switch' Set Configuration Parameter 6 = 1
 
Else
   - No Actions - (To add one, press 'Action')
 
Resets to time every 4 hours.
Runs fan every hour.
Other program will shut it off.

 

Edited February 1, 2023 by brians