I suppose that is what folks do, easy enough to create at least a Boolean variable, and set/reset it by running the then/else clauses.

 

When checking the status of the program (variable) in the condition group, I presume that it will act like the Insteon "status" check, vice an Insteon "control" check, IOW it would not trigger from a change in the program state but would simply allow you to branch based on its value.

 

Yes, no?

 

* Orest

My understanding is that, whether device or program, change in status will trigger an evaluation of the "if" condition and respond accordingly.

Ah, good, that makes things easier.

 

* Orest

In my opinion, that makes things a whole lot harder. I consider this a flaw in the design of the ISY program environment.

There does seem to be a small-but-vocal group out there that regularly complain of this behaviour. In my mind, it has some benefits, and some downside, depending on your purposes. Regardless, it is like any other computer programming: you have to know the language, but once you do, it is completely predictable.

It's not just a matter of understanding it, it's a matter of how limiting it is. If you could specify trigger events separately from IF conditions, it would not only be easier to understand, you could do a lot more in fewer programs. For instance, ELSE branches could become useful. As it is now, they are rarely usable.

 

This is not just my opinion, mind you. I think anyone with real programming experience would agree. I spent years programming Scara robots and telecommunication switches. In any event driven programming environment, you need to be able to specify the events which will trigger the program.