Why does a program just stop in the middle of executing? Sometimes?

[lpollis]

I have the following program:

 

Irrigation Schedule 10 Min Copy - [iD 0031][Parent 000A]

If
        Module 'Climate' Temperature > 40 °F
    And (
             Status  'KpIrr H Enable Schedule' is 100%
         And Status  'KpIrr D IrrigationTime 10 Min' is 100%
         And (
                  On Mon, Thu
                  Time is  6:00:00AM
               Or On Mon, Thu
                  Time is  6:00:00PM
             )
        )
     Or (
             Control 'KpIrr G Follow Schedule' is switched On
         And Status  'KpIrr D IrrigationTime 10 Min' is 100%
        )
Then
        Run Program 'Notify Start 10 Min Cycle' (Then Path)
        Set Scene 'Irrigation Schedule Follow' On
        Set Scene 'Irrigation Zone 1 Indicator' On
        Set 'EZRain 1 - Drip Zone' On
        Run Program 'Notify 10 Min Drip' (Then Path)
        Wait  10 minutes
        Set 'EZRain 1 - Drip Zone' Off                                          <--- Did not execute and program did not complete. Why?
        Set Scene 'Irrigation Zone 1 Indicator' Off
        Set Scene 'Irrigation Zone 2 Indicator' On
        Run Program 'Notify 10 Min Side Yard' (Then Path)
        Set 'EZRain 2 - Side Yard' On
        Wait  10 minutes
        Set 'EZRain 2 - Side Yard' Off
        Set Scene 'Irrigation Zone 2 Indicator' Off
        Set Scene 'Irrigation Zone 3 Indicator' On
        Run Program 'Notify 10 Min Patio' (Then Path)
        Set 'EZRain 3 - Back Patio' On
        Wait  10 minutes
        Set 'EZRain 3 - Back Patio' Off
        Set Scene 'Irrigation Zone 3 Indicator' Off
        Set Scene 'Irrigation Schedule Follow' Off
        Run Program 'Notify Cycle Complete' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')

 
This program (and others like it; some much simpler) just seems to stop in the "Wait" statement. Sometimes. Other programs without a timer work as expected. Any insight would be appreciated. And just to be clear, the program can stop during any of the "Wait" statements. It is totally unpredictable.

 

Lp

Edited September 7, 2015 by lpollis

[LeeG]

The Wait (and Repeat) statement can be interrupted by any condition change that can trigger the Program.

 

There are two Programs as well as two Scenes executed before the Wait.  If any of them affect what the If is checking will terminate Wait.  Also a change in Climate temperature will terminate the Wait.  

[MWareman]

To further LeeG's statement. One condition is the Temperature >40. Let's say the program triggers one day and the temp is 46. We get to the wait and start waiting. 4 mins later,z the temp updates to 47. This will terminate the wait and cause the If to reevaluate. At this point, the time won't match and 'Else' will be executed instead, doing nothing.

[LeeG]

The last two statements in If are Ored with Climate temperature check so there is a path for True that is not Time based.

[MWareman]

Your program will only execute if the time is 6 am or 6 pm. When the time changes your then statement, which is in a wait state, is no longer true.

 

Break the program into two programs and put the data in your "then" statement into the 2nd program. The second program will run until completed once called regardless of the state of your IF statement in the 1st program.

I don't think time change causes reevaluation of the program. Otherwise many of mine wouldn't work!

[lpollis]

So this should work:

Irrigation Schedule 10 Min - [iD 0031][Parent 000A]

If
.

.

.

         And (
                  On Mon, Thu
                  From     6:00:00AM
                  To       7:00:00AM (same day)
               Or On Mon, Thu
                  From     6:00:00PM
                  To       7:00:00PM (same day)
             )
        )

.

.

.

Since it is unlikely that the temp will not fall below 40 this time of year.

True?

Lp

[lpollis]

No. In this program I have 3 10 minute 'waits', one for each irrigation zone.

[MWareman]

but do you have a long wait in your program?.

I have some, but I've never really dug into this. There are only some triggering conditions that will interrupt a 'wait' or 'repeat'. Not all of them will. I believe time is one of the triggering events that will not interrupt a wait or repeat.

[Techman]

I have some, but I've never really dug into this. There are only some triggering conditions that will interrupt a 'wait' or 'repeat'. Not all of them will. I believe time is one of the triggering events that will not interrupt a wait or repeat.

But if the "IF" statement is no longer true, i.e. a condition in the statement changes, then the program gets reevaluated,

[MWareman]

But if the "IF" statement is no longer true, i.e. a condition in the statement changes, then the program gets reevaluated,

Only if the specific event type is one of the several that will actually interrupt the 'wait' or 'repeat'. If not, the program continues atomically. Only those events that are allowed to interrupt the 'wait' will cause the reevaluation, and restart the 'then' or 'else' as the evaluation dictates.

[Techman]

Only if the specific event type is one of the several that will actually interrupt the 'wait' or 'repeat'. If not, the program continues atomically. Only those events that are allowed to interrupt the 'wait' will cause the reevaluation, and restart the 'then' or 'else' as the evaluation dictates.

 

You're correct. I always thought any change in the "IF" statement would restart the program.

[lpollis]

Are these documented anywhere?

"specific event type is one of the several that will actually interrupt the 'wait' or 'repeat'"

Edited September 7, 2015 by lpollis

[LeeG]

Any event which will trigger an Idle Program will terminate a Wait or Repeat and cause If clause to evaluate. 

[MWareman]

Any event which will trigger an Idle Program will terminate a Wait or Repeat and cause If clause to evaluate. 

 

Not quite true..

New Program - [ID 0245][Parent 0244]

If
        Time is  5:30:00PM
 
Then
        Resource 'Pushover - TriggerThen1'
        Wait  4 minutes 
        Resource 'Pushover - TriggerThen2'
 
Else
        Resource 'Pushover - TriggerElse'

At 5:30PM I received the 'Then1' pushover notification.

At 5:34PM I received the 'Then2' pushover notification.

 

The 'If' was NOT reevaluated at 5:31PM, 5:32PM or 5:33PM - despite being triggered at 5:30PM. 

 

The 'Else' condition was never triggered.

 

I have not dug (experimentally) into other triggering conditions (like Elk zones, weather variables etc). I do know from memory that 'Control', 'State' and 'State Variables' all trigger evaluation AND interrupt 'wait' and 'repeat'. Other than time, I am now wondering what other triggering conditions will not break a 'wait' or 'repeat'.

 

Michael.

 

Michael.

[LeeG]

The If Time is 5:30PM triggers the Program at 5:30PM with a True If evaluation.   It does not trigger the Program at any other time.   Has nothing to do with whether there is a Wait/Repeat or not.

 

The Wait statement in the OP Program is not broken.   If the statements after the Wait do not execute the Program is being retriggered while in the Wait.

Edited September 7, 2015 by LeeG

[oberkc]

Not quite true..

 

My understanding is the same as LeeG.  Any retriggering and re-evaluation of a program will interrupt a halt or wait statement. 

 

The 'If' was NOT reevaluated at 5:31PM, 5:32PM or 5:33PM - despite being triggered at 5:30PM.

 

In different words as LeeG, this is because such a statement is only triggered once per day. This condition is not triggered at 5:31 or at 5:32, or at 5:33.  It is never triggered at any time other than 5:30.

[jerlands]

My understanding is the same as LeeG.  Any retriggering and re-evaluation of a program will interrupt a halt or wait statement. 

 

In different words as LeeG, this is because such a statement is only triggered once per day. This condition is not triggered at 5:31 or at 5:32, or at 5:33.  It is never triggered at any time other than 5:30.

 

So "Wait" causes a re-evaluation of the conditions before the wait period and not after.. this is why @ 5:34pm Else wasn't triggered?

 

Jon...

[LeeG]

The Wait statement does not cause a reevaluation, it allows a reevaluation should an event that would trigger the Program occurs while in the Wait duration.  If the event occurs after the Wait duration the Program is not retriggered by the event.

[jerlands]

The Wait statement does not cause a reevaluation, it allows a reevaluation should an event that would trigger the Program occurs while in the Wait duration.  If the event occurs after the Wait duration the Program is not retriggered by the event.

 

That seems to fly straight in the face of how Wiki defines it..

The 'Wait' command, when encountered during program execution, will cause the program's conditions to be reevaluated 
(see Statement Execution Order). 

A series of statements within a Then clause (or within an Else clause), up to the next Wait or Repeat statement, are atomic. 
In other words, all such statements are executed before the conditions of the program are retested. 
The program's conditions are reevaluated each time a Wait or Repeat statement is encountered, and at the end of each iteration of a Repeat loop. 

Probably just how I'm interpreting this

 

Jon...

Edited September 8, 2015 by jerlands

[MWareman]

I guess I've figured my own experimental results. The time based triggers are 'true' only at the specified time, and non-triggering 'False' at all other times.

 

This is different from devices 'status is off' (for example) - which will trigger 'true' when the device changes to 'off' - but will also trigger 'false' when the device changes to anything else.

 

Hence my statement of time triggers being a special case. They can never trigger false.

 

So, @LeeG is correct (as always!) in the statement made that all triggering events will interrupt a wait or repeat and force a reevaluation. Apologies for the doubt...

 

Edit: Yes. The wiki does seem to add to the confusion. The wait does not 'cause' the reevaluation. It 'allows' it to occur if any triggering status changes while the wait is waiting.

Edited September 8, 2015 by MWareman

[jerlands]

Edit: Yes. The wiki does seem to add to the confusion. The wait does not 'cause' the reevaluation. It 'allows' it to occur if any triggering status changes while the wait is waiting.

 

The Wiki needs to be dusted off   simply explained examples can save someone hours of troubleshooting..

 

Jon

[larryllix]

I think of the Wait and Repeat this way....an analogy.

 

 

Once the "Then" or "Else" program section is given the microphone it  gets to talk, exclusively, without interruption (finish it's program section) from the audience (programs).

 

A Wait or Repeat instruction is like voluntarily giving the microphone (CPU) back to the emCee (ISY) until the Wait time period is over.

 

The emcee (ISY) checks the rest of the audience (programs) to see if somebody else wants to take the microphone (other program triggers).

 

The emCee (ISY) respects the Wait time specified and attempts to give the microphone back to the original speaker (program) when the specified Wait time is over.

 

All speakers are fast talkers (code is quick) and do not run-off at the mouth, interfering with other's rights to talk (run their programs) much.

 

Speakers are picked (ISY real-time engine) in no particular order and not by age, name, or gender.

 

Sometimes speakers send the Paige (PLM) out on an errand (Insteon comms)  and other speakers (programs)  have to, not only wait their turn (time slice), but also for the Paige (PLM) to get back before they can use his service (Insteon comms).