A BIG feature request - "trigger on" command

[oskrypuch]

In line with such considerations, it would be useful to establish a second "wait" command, one that would NOT allow a re-evaluation of the IF clause, during the wait. It is useful to be able to do both, but sometimes you really want the other, and prefer not having to branch out to another separate program macro.

 

So something like this:

WAIT (the current wait command)

HOLD_and_WAIT (this will wait, but will NOT allow reevaluation of the IF)

 

* Orest

[tpolito]

I have been following this thread (and other similar ones), and I guess I only half-way understand what the issue is. In terms of a program that I am currently using:

 

If

Control 'Kid's Bathroom Light' is switched Off

And Status 'Kid's Bathroom Vent' is On

 

Then

Wait 10 minutes

Set 'Kid's Bathroom Vent' Off

 

Else

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

 

 

I assume what currently happens is when I turn off the kid's bathroom light, the program evaluates whether or not the vent is on. If it is, then in 10 minutes it will be turned off. What I am not sure of is what happens if I go back into the bathroom and turn on the light again, and then turn it off within the original 10 minute "wait". Will a new 10 minute period start, or will the light turn off after the original 10 minutes?

 

Is this along the same lines y'all are discussing, or am I way off?

[Goose66]

Is this along the same lines y'all are discussing, or am I way off?

I think your question revolves around the fact that while WAITing, if the program is triggered again, the WAIT is cancelled and any following actions are not taken, in favor of the entire program running again with a reevaluation of the IF statement.

 

What this thread is about is what will actually cause the program to run (or run again). So for instance, in your example, if the light is turned Off and the fan is running, the program will wait 10 minutes and turn the fan off. However, if someone manually turns the fan off, i.e. the Status of 'Kid's Bathroom Vent' changes, the program will run again, cancelling the pending WAIT and the subsequent Off command. This time, the program's IF condition will evaluate to FALSE, because the Off for the 'Kid's Bathroom Light' was not received, and the ELSE branch will be executed.

 

In your example, this is not a bad thing, since the fan was turned OFF, cancelling the WAIT and subsequent OFF command doesn't affect anything. However, I am sure you can imagine examples where having the program execute when the Status of a device changes would be a bad thing. That is what we are talking about. We want to be able to tell the ISY to run the program when the OFF for the 'Kid's Bathroom Light' is received, and then check the status of the 'Kid's Bathroom Vent' in order to decide whether to run the THEN or ELSE branch, but NOT run the program when the status of the 'Kid's Bathroom Vent' changes.

 

In other words:

 

When 
       Control 'Kid's Bathroom Light' is switched Off 
If
       Status 'Kid's Bathroom Vent' is On 
Then 
       Wait 10 minutes 
       Set 'Kid's Bathroom Vent' Off 
Else 
       - No Actions - (To add one, press 'Action') 

[oberkc]

What I am not sure of is what happens if I go back into the bathroom and turn on the light again

Besides the light going on, nothing. There is no condition in your program which would be triggered by turning your light on.

 

However, if you turn it on again , then turn it off again (all during the ten minute wait), the program will trigger an evaluation (one of your conditions is control...off). This will halt further execution of your program and start another "then" or "else" path, depending on the results of your evaluation.

[Chris Jahn]

... almost ANY change that provides concurrent conditionals and event triggers of equal stature in the ISY programming would be most welcome ...

 

I need to emphasize to anyone following this thread that the you do have this today, it just requires 2 programs.

 

The issue being addressed in this thread is not functionality, but user interface, in that requiring multiple programs seems cumbersome to many.

[apostolakisl]

... almost ANY change that provides concurrent conditionals and event triggers of equal stature in the ISY programming would be most welcome ...

 

I need to emphasize to anyone following this thread that the you do have this today, it just requires 2 programs.

 

The issue being addressed in this thread is not functionality, but user interface, in that requiring multiple programs seems cumbersome to many.

 

This is exactly the point I was trying to make with my early post with the big giant photoshoped screenshot that is making this thread so hard to read! (sorry).

 

ISY is 100% capable of having non-trigger conditions and trigger conditions right now exactly as is, it just need two programs.

 

A relatively simple solution to this (I think), is for the guys at UD to manipulate the user interface such that two programs are merged into what appears to the user as one program, hiding the non-needed items. Since the ISY language would not be changed, there is no risk of introducing bugs where there were none.

 

 

Edit. .. woooohoooo, pushed it to a new page so the super wide screen is gone.