When do programs run and in what order?

[shadowb]

When does ISY run the programs?  e.g., 

 

1) when it detects any event, Insteon or X10, from any device?

 

2) when it detects only events in its own link tables? 

 

3) other ... 

 

Is there any order in which the programs are run? 

 

I did a Google on these topics and didn't find anything useful.  Are the inner-workings of ISY described somewhere?  

 

Thanks,

Richard

 

[stusviews]

The program runs as soon as the conditions are true and stops when it's done or the conditions become false, whichever occurs first.

[LeeG]

X10 addresses are not in the link table.

 

A Program is triggered whenever a Condition the Program checks occurs.  (and triggers a Program.   If integer variable does not trigger a Program) 

 

Some trigger examples (not all inclusive)

 

A change of Status

A command defined in "If Control" is received

Change in State Variable

An X10 address receives checked command

ELK State change

 

Once a Program is triggered the If clause is evaluated for True or False.   When the If is True the Then clause executes.  When the If is false the Else clause executes.

 

The order in which Programs run is controlled by ISY

[shadowb]

I suspected my question wasn't very clear ... I understand how ISY executes programs ... I'm interested in the mechanism that ISY uses internally to monitor/detect events and then the order that it invokes triggered programs.  

 

For example, I assume the ISY is monitoring the powerline and RF inputs watching for valid Insteon and X10 events (X10 included since an X10 event can be in the IF clause even if not in the Link Table).  When it detects an event it must process the "programs" in some order to decide which IF clauses and ELSE clauses to trigger.  Is that order predictable and/or user controllable in any way?  I could try doing some tests but coincidences could lead to an incorrect conclusion.  

 

The fact that IF/ELSE clauses can be AND'ed raises a crucial timing question.  If an IF clause specifies two AND'ed Control events what is the required time relationship between the two events that results in them both being TRUE at the "same time".  I can see how AND'ing a Status works because Status is persistent but Control events are transitory. 

 

When I was using Houselinc I discovered lots of undocumented nuances in its behavior.  I'm just trying to understand the nuances of ISY so I can use it most effectively and avoid dead-ends.  

 

Thanks for your patience,

Richard 

[LeeG]

In the following Program the If is NEVER True.

 

If

        Control 'KPL Test2 - C' is switched On

    And Control 'KPL Test2 - D' is switched On

 

Then

        Send X10 'A1/On (3)'

 

Else

        Send X10 'A1/Off (11)'

 

As far as how the ISY internally selects Programs to evaluate If clause will have to come from UDI. 

[larryllix]

I don't think UDI has ever disclosed the algorithm for running programs and that also keeps the process open for changes  if another algorithm is developed to make it more efficient or any other reason.

 

Users cannot depend on programs operating in any particular order.  If we did, and UDI changes the technique, the order of execution might change and  critical timing would not work. I believe this has happened with v5, as it seems they have changed the internal engine workings and sped it up, too.

 

Dealing with a previous realtime event based system I discovered it's inner workings. I questioned Michel about the event trigger evaluation list/table  but he denied it's existence, so the engine may be really busy evaluating every trigger possibility, every chance it gets.

 

Yeah I would like to understand this also.

[stusviews]

Do you have a particular situation where order matters?

[shadowb]

I do not have an order dependent situation yet but have read about some folks who are having problems with compound IF clauses.  I wanted to try to understand any order/timing dependent issues before I went much further with programming.  

 

As a long-time programmer (various assembler, Pascal, BASIC and object-oriented languages including Java) who has written device control programs I prefer to understand the algorithms if at all possible, rather than having to figure them out via trial and error.  

 

For now I'll just try to keep it simple.  I may try to do some experiments and if I find anything interesting I'll report it here.  

 

I very much appreciate an active forum like this ... learning from others really helps speed things along. 

 

Richard

[stusviews]

Compound statements include one or more AND or OR conditions. Do you mean nested IF statements?

[larryllix]

Well welcome!

 

Diggers welcome!

[Techman]

I do not have an order dependent situation yet but have read about some folks who are having problems with compound IF clauses.  I wanted to try to understand any order/timing dependent issues before I went much further with programming.  

 

As a long-time programmer (various assembler, Pascal, BASIC and object-oriented languages including Java) who has written device control programs I prefer to understand the algorithms if at all possible, rather than having to figure them out via trial and error.  

 

For now I'll just try to keep it simple.  I may try to do some experiments and if I find anything interesting I'll report it here.  

 

I very much appreciate an active forum like this ... learning from others really helps speed things along. 

 

Richard

 

Is this what you're looking for?

ISY Program execution order.pdf

[shadowb]

stusviews, yes I meant compound with AND's and/or Or's.  For example, I can write a compound IF with two AND'ed clauses.  If the clauses are AND's it's important that the events in both clauses be "True" for the entire evaluation of the IF statement.  In a true event-oriented system an Event occurs at a point in time, and then it's gone.  A Status is persistent.  ISY seems to mix the two with Control and Status options in the IF.  I suspect that the Control "events" are actually persistent at least for the duration of the evaluation of the IF, so in a sense it's a "status" that the Control "event" has happened.  

 

So what's confusing is an IF with two AND'ed Control settings.  One would think that Control's are events (e.g., a button pressed and released).  But since events are transitory how can it ever be True that "Button A pressed and released" is true at the exact same moment that "Button B pressed and released" is also true.  The ISY engine timings have to somehow detect that two transitory events are in fact related - but how long should it wait after Button A to see if Button B is going to be pressed also to make this compound IF statement evaluate to True?  

 

One possible answer is it will never be true.  There are programming languages in which the evaluation of a compound IF statement will not include one of the operands due to the order of evaluation.  Languages have rules for order of evaluation and I'm just trying to discover what the rules are for ISY.  

 

Am I making sense here?  

[shadowb]

Techman, just saw your post.  Thanks!  Will carefully read that article tomorrow.  

[larryllix]

stusviews, yes I meant compound with AND's and/or Or's.  For example, I can write a compound IF with two AND'ed clauses.  If the clauses are AND's it's important that the events in both clauses be "True" for the entire evaluation of the IF statement.  In a true event-oriented system an Event occurs at a point in time, and then it's gone.  A Status is persistent.  ISY seems to mix the two with Control and Status options in the IF.  I suspect that the Control "events" are actually persistent at least for the duration of the evaluation of the IF, so in a sense it's a "status" that the Control "event" has happened.  

 

So what's confusing is an IF with two AND'ed Control settings.  One would think that Control's are events (e.g., a button pressed and released).  But since events are transitory how can it ever be True that "Button A pressed and released" is true at the exact same moment that "Button B pressed and released" is also true.  The ISY engine timings have to somehow detect that two transitory events are in fact related - but how long should it wait after Button A to see if Button B is going to be pressed also to make this compound IF statement evaluate to True?  

 

One possible answer is it will never be true.  There are programming languages in which the evaluation of a compound IF statement will not include one of the operands due to the order of evaluation.  Languages have rules for order of evaluation and I'm just trying to discover what the rules are for ISY.  

 

Am I making sense here?  

Here is an If with two ANDed controls that works.

Just to confuse you but you seem to have  good handle on real time event/triggers and statuses already.

 

If

      control of wallswitch is switched On

  AND

    control of wallswitch is NOT switched Off

 

Then

     switched On code

 

Else

   NOT switched Off code

[stusviews]

shadowb,

 

The ISY has a different construct for the situation you proposed, that is A is turned On and then B is turned On. Because each press occurs in an instant, two different button presses occurring simultaneously is virtually not possible. Also, the ISY does not have nested IFs, for example, IF A is turned On, then IF B is turned On doesn't exist because THEN cannot contain a condition.

 

Using "Status" is one approach.

 

If

        Status A is ON

  And Status B is ON

 

depends on both A and B being on concurrently. The order in which the devices are turned on doesn't matter, only that both devices are on AND at least one device changed from OFF to ON.

 

 

Another, more complex method requires multiple programs:

 

Prog1

If

        Control A is switched ON

   Or  Control B is switched ON

 

Then

        Run 'Prog2'

 

Prog2 B (disabled, only running Prog1 will cause this program to run)

If

        Control A is switched ON

   Or  Control B is switched ON

 And (Status A is ON

         Or Status b is ON

         )

 

 

Then

        ....

 

There are bunches of more complex methods including using variables that analyze the state of each device, perform multiple tests, etc.

[shadowb]

larryllix and stusviews - yep, you are both in tune with the issues, glad to know I'm talking with the right guys.  I had not yet explored the nested IF's ... I had assumed they were possible.  Thanks for the tip-off.  

 

I'm sure that once I've got everything running and don't visit ISY for 6 months I'll have to reread these posts!  : )  

 

I have also started writing my own "user's guide" as a refresher.  

 

Thanks again,

Richard

[shadowb]

Techman, thanks for that article - it does address several of the key issues with IF/Then/Else evaluation - such as precedence.  That was often an issue I ran into going from one programming language to another.  Left-to-right and explicit use of parentheses seems to be most common.  I have saved the article in my folder of cheat sheets.  

[oberkc]

While a single condition cannot include nested IFs, one can create an equivalent condition using multiple programs.

 

For example:

 

If A is tuned on

Then run next program

 

Next program:

 

If sky is blue

Then do something

 

Obviously, these are conceptual examples with inexact syntax. Also, as the others suggests, use of parentheses and exploitation of the various statements at or disposal will allow darn-near any logical construct.

 

Like others suggest also, two programs that would be triggered by a given event would be run essentially simultaneously. If program order becomes important, one could control this by a series of prograns, with each subsequent program being called by the previous....

 

If some condition exists

Then do something, then call next program

 

Next program...

 

And next, and next..

[Michel Kohanim]

Hello everyone, thanks so very much for your invaluable input.

 

Hi Richard,

 

At a very simplistic level, all events in ISY go through a queue (FIFO) and the program task reads from the queue. So, there will never be a situation when two events are processed at the same time by ISY. Operator precedence is exactly like the corresponding programming languages that you are familiar with including () and short circuit for & and | .

 

With kind regards,

Michel

[shadowb]

I second Michel's "Thanks"!  

 

It's great to know there is a forum with good activity and a lot of experience and understanding.  

 

Humorous aside ... during further exploring today I encountered "Flex Alert" ... Wow!  I wondered how ISY knew I have a Flex Radio 6300 SDR (software defined radio).  (tongue in cheek) ... a Google led me to California's energy alert "Flex Alert" ... and of course when I Google anything "Flex" I get lots of results from Ford.  

[Michel Kohanim]

Hi Richard,

 

Yes, Flex Alert is an energy conservation paradigm for CA utilities. Sorry.

 

With kind regards,

Michel