lpollis Posted September 7, 2015 Posted September 7, 2015 (edited) 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Author Posted September 7, 2015 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 Posted September 7, 2015 Author Posted September 7, 2015 No. In this program I have 3 10 minute 'waits', one for each irrigation zone.
MWareman Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Author Posted September 7, 2015 (edited) 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 Posted September 7, 2015 Posted September 7, 2015 Any event which will trigger an Idle Program will terminate a Wait or Repeat and cause If clause to evaluate.
MWareman Posted September 7, 2015 Posted September 7, 2015 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 Posted September 7, 2015 Posted September 7, 2015 (edited) 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 Posted September 8, 2015 Posted September 8, 2015 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 Posted September 8, 2015 Posted September 8, 2015 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 Posted September 8, 2015 Posted September 8, 2015 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 Posted September 8, 2015 Posted September 8, 2015 (edited) 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 Posted September 8, 2015 Posted September 8, 2015 (edited) 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 Posted September 8, 2015 Posted September 8, 2015 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 Posted September 8, 2015 Posted September 8, 2015 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).
Recommended Posts