check for event, wait, check again and send sms if still on

[thomas]

Hello. Fairly new to ISY programming. I got the basics down and have done a lot of other types of programming so opening to learning some advanced ISY.

 

Here is what I am trying to do. When an Insteon I/O link sensor is activated (changed from Off to On) I want to wait 10 minutes and check that sensor again. If it is still on I want to send an sms notification.

 

I have the SMS part down but can't really figure out the "wait" part. From what I read if you wait it rechecks the conditions...and I feel like I would be in an infinite loop.

 

Do I need a program variable or something to "persist state" across condition checks or something?

 

Any suggestions?

 

Thanks!

[oberkc]

Try something like (syntax not exact):

 

If
Status of IOLinc is on
Then
Wait 10 minutes
Send sms notification
Else

[arw01]

Now won't that program retrigger if the IO linc changes states again.

 

So if you split that program into one that calls the second program with no if, but only a then, you can get the first program to call the second program, wait 10 minutes and then send the sms. You probably need a query in there to check after the 10 minute timer?

 

Or are you thinking that if the status didn't change and cause the re-evaluation, then obviously it is still on and go ahead and send the sms..

 

So many choices with the ISY.

[thomas]

Seems too easy but it worked! The way I interpreted the wiki pages was that it would re-evaluate the condition and then re-execute the "then" clause. But it seems it just re-evaluates the condition and picks up at the statement after the wait.

 

Perfect. Thanks!

[LeeG]

thomas, arw01

 

When in a Wait or Repeat statement any change to the Status conditions the If is checking causes the Program to be triggered again from the beginning. The only change in Status in this case would be going from On to Off. The ‘If Status On’ would be False which drives the Else clause.

[apostolakisl]

Seems too easy but it worked! The way I interpreted the wiki pages was that it would re-evaluate the condition and then re-execute the "then" clause. But it seems it just re-evaluates the condition and picks up at the statement after the wait.

 

Perfect. Thanks!

 

That program doesn't do exactly what you asked, but it might be what you meant.

 

"(changed from Off to On) I want to wait 10 minutes and check that sensor again. If it is still on I want to send an sms notification." Taken literally, this could mean you want it to ignore any off/on cycles that happen during those 10 minutes. This won't be the case.

 

That program will only send you an SMS if the i/o linc were continuously on for 10 minutes.

[thomas]

Seems too easy but it worked! The way I interpreted the wiki pages was that it would re-evaluate the condition and then re-execute the "then" clause. But it seems it just re-evaluates the condition and picks up at the statement after the wait.

 

Perfect. Thanks!

 

That program doesn't do exactly what you asked, but it might be what you meant.

 

"(changed from Off to On) I want to wait 10 minutes and check that sensor again. If it is still on I want to send an sms notification." Taken literally, this could mean you want it to ignore any off/on cycles that happen during those 10 minutes. This won't be the case.

 

That program will only send you an SMS if the i/o linc were continuously on for 10 minutes.

 

 

Ah yes. I understand what you are saying and, unknowingly, the program above is what I wanted. I only care if it is on for 10 minutes continuously. The exact program I have is below.

 

The intent is to send me an email/sms if the time is between 7:30am and 3:00am next day AND my irrigation pump has been on for 10 minutes continuously.

 

If

From 7:30:00AM

To 3:00:00AM (next day)

And Status 'Irrigation Pump Sensor' is On

And Status 'Irrigation Pump Sensor' is not Off

Then

Wait 10 minutes

Send Notification to 'Cell Phone' content 'Irrigation Pump Power'

Else

-No Actions

 

So the next question is...what happens if the pump turned on at 7:25AM? The program would not be invoked until 7:30AM and, assuming the pump is still on at 7:40AM I would get an SMS at 7:40AM? Or did I "miss" the On event for the pump I was outside my time window?

 

Appreciate the help!

[LeeG]

"So the next question is...what happens if the pump turned on at 7:25AM? The program would not be invoked until 7:30AM and, assuming the pump is still on at 7:40AM I would get an SMS at 7:40AM? Or did I "miss" the On event for the pump I was outside my time window?"

 

The Notification message will be sent at 7:40AM assuming the pump sensor is still On. The From time, 7:30 AM, triggers the Program. The If will be True assuming the sensor Status is On. The Sensor turning On also triggered the Program but since the 7:25 AM time is outside the From/To time window the If is False which drives the Else clause.

 

Note the two Sensor Status checks are redundant. Likely the Sensor is either On or Off which makes the not Off Status check unnecessary.

[thomas]

"So the next question is...what happens if the pump turned on at 7:25AM? The program would not be invoked until 7:30AM and, assuming the pump is still on at 7:40AM I would get an SMS at 7:40AM? Or did I "miss" the On event for the pump I was outside my time window?"

 

The Notification message will be sent at 7:40AM assuming the pump sensor is still On. The From time, 7:30 AM, triggers the Program. The If will be True assuming the sensor Status is On. The Sensor turning On also triggered the Program but since the 7:25 AM time is outside the From/To time window the If is False which drives the Else clause.

 

Note the two Sensor Status checks are redundant. Likely the Sensor is either On or Off which makes the not Off Status check unnecessary.

 

Perfect. That is what I was hoping for. In many of the examples I have seen the If statements included the "On" and "not Off" status. So I adopted that logic as well. Good to know it doesn't matter and I can just check for "On". Thanks LeeG!

[apostolakisl]

Including the "not off" statement is to drive the "else" clause. If you don't have an else clause, it serves no purpose.

 

For example:

 

If

x is switched on

Then

do a

Else

do b

 

This program will never run an else clause. the only trigger is it turning on.

 

If

x is swithched on

and

x is not switched off

Then

do a

Else

do b

 

Now switching "off" the device is also a trigger. So, switching "on" runs the "true" and switching "off" runs the "else".

 

 

Pretty much any time you use "not" anything, you are using it to drive an else clause.

[LeeG]

thomas

 

The 'not Off' is used with 'If Control' which is looking at commands flowing from a device. When using 'If Control', a Program is triggered ONLY on the specific commands being tested for. Without the 'not' the Else clause would not be executed (as apostolakisl said) because the If would always evaluate to True.

 

If is also used with ‘If Status’ when checking a Dimmer which can have many Dim values between Off and On (which is 100% On). A single “If Status ‘xxxx’ is not Off†would be True if the Dimmer is anything but Off (5% On, 50% On, 100% On, all result in a True If evaluation with not Off).

 

The examples you are referencing look like

 

If

Control ‘xxxx’ is switched On

Or Control ‘xxxx’ is not switched Off

Then

…….

Else

……

 

If Control triggers ONLY when the specific command is received. When an On command is received the Then clause executes. When an Off command is received the Else clause executes because of the ‘not’.

[apostolakisl]

As Lee mentioned, those programs I wrote above are using "control". I really should copy real programs to keep things technically correct. They demonstrate the only time you use that combo of "is on, and is not off". This is because "control" programs only trigger when you do the exact thing listed (like push the "on" button of the actual device for a program stating "control is switched on"). Dimming or pushing off will be ignored by the program. That is why you need the "control is not switched off" line, to trigger the program when "off" is pushed.

 

"Status is not" is often times used to encompass all of the states of a device being on. Since "status is on" means 100% on, and you might want to include all amounts of on from 1 to 100%, then you say "status is not off" to include all of those. In these programs

 

status is not off

and status is on

 

are both saying the same thing for a device that is either on or off. For a device that could be in between, then the "status is not off" line becomes irrelevant since the program will behave exactly the same without it. It will be true when something is on 100% and false at any other time. It will trigger the same as well (with any change in state).