Ignore False Trigger Conditions?

[ergodic]

Would it be possible to enhance an empty Else clause so that a program would simply ignore false-evaluated trigger events?

 

For instance, we're all keenly familiar with this sort of thing:

 

If ('Motion' is on) and (Status 'Light' is off)
Then Set 'Light' On; Wait 3 Minutes; Set 'Light' Off
Else (nothing)

 

The initial act of turning on the light retriggers the program, so it interrupts and goes false, never to complete what was intended. Even though there is nothing in the Else section.

 

And of course is just one example. But this one awkward feature of the (rarely useful) empty Else clause is I think where ISY programming can get troublesome.

 

What I'm suggesting is a change that would simply allow false-state triggers to be ignored in programs with empty Else sections -what one almost always wants - and so not interrupt the running program:

 

If ('Motion' is on) and (Status 'Light' is off)
Then Set 'Light' On; Wait 3 Minutes; Set 'Light' Off
Else (ignore false triggers)

 

This of course is quite easy for me to suggest as I don't know how difficult it is to implement. if the ISY evaluator now stops the program before it does the condition state evaluation, then this would be a change to that internal processing, since a program with such an Else clause couldn't be stopped until the condition value was actually determined. But it does strike me as relatively modest.

 

If it could be accomplished I think it would be a most welcome capability, and it would end a lot of the pointless need to break programs up as well as make the program logic much more intuitive.

[Michel Kohanim]

Hello ergodic,

 

Thanks so very much for your feedback.

 

Although possible but it will have quite a low priority.

 

With kind regards,

Michel

[ergodic]

Thanks for the reply.

 

My hope was that such a change would be not hard to implement. Maybe not.

 

Thinking it over, from a syntax standpoint I think it would be better to just be able to delete the Else clause entirely. Makes things clear.

 

So, if you 'Remove-Line' on the Else clause, no more spurious false-state triggers. This is really where most of the confusion comes into play for ISY programming, especially for newbies.

[ih574]

I second the request for the ability to control program execution following a change in trigger conditions. I was thinking of it a bit different though (perhaps naively). I thought an option checkbox in the "If" section could allow the user to select whether a change in the conditions would affect running code. This way, I could select whether an "If" condition change would cause running code to abort, such as in a wait statement. Like ergodic stated, this option could simplify some of my programs which I'd like to execute atomically regardless of whether the state changed after the program was triggered.

 

Tom C.

[Michel Kohanim]

Hi guys,

 

The problem is the Wait construct which is interruptible for very good reasons (restarting the counter every time you sense motion). In those cases, you might want to call another program WITHOUT any conditions and put the wait in that program which will run to finish unless told explicitly to stop.

 

With kind regards,

Michel