Events versus Procedures

[Algorithm]

The current ISY paradigm is completely event driven, which is excellent in many ways--from a hardware perspective, interrupt driven; from a device perspective, event driven; from a time perspective, also event driven; etc. For example, every ISY 'program' is really an event:

 

IF condition

THEN some actions

ELSE other actions

 

really means:

 

WHEN this condition

BECOMES TRUE take some actions

AND THEN BECOMES FALSE take other actions

 

The 'conditions' are continuously evaluated, and 'actions' are triggered when a 'condition' changes (an 'event').

 

But an 'event' is the only current method of logical testing. No allowance is made for a procedural paradigm in the logic, and this greatly limits what can be done in terms of complex logic, including nested conditions, mutually exclusive conditions, and so forth. My current Ocelot program is in excess of 2,100 lines of ladder logic, and it is proving extremely difficult if not impossible, to convert that logic to ISY. Not due to any shortcoming in the hardware, but due to the missing logical tests.

 

Under no circumstances am I suggesting that the event driven paradigm should be replaced with a procedural one, but rather augmented by it, thus giving us the outstanding benefits of both.

 

It would be invaluable for me (and for other users either now, or as each expands and multiplies the complexity of his installation) if procedural logic could be used within event driven programs. The terms IF, THEN, ELSE and others could resume their traditional meanings inside of a program, while the program wrapper would remain an event, with just a slight modification of the keywords used. [And there are certainly very many possibilities for keywords.] So it may look something like this:

 

WHEN condition

IS TRUE

....actions

....IF condition

....THEN

........actions

....ELSE

........actions

....ENDIF

....actions

IS FALSE

....actions

....IF condition

....THEN

........actions

....ELSE

........actions

....ENDIF

....actions

 

where an event based on a continuously evaluated condition wraps and entire program which may consist of multiple logical tests of conditions which are evaluated only as required.

 

This would easily allow complex tests and conditions which are presently extremely difficult, if possible at all. Especially when combined with variables in an upcoming version.

[Chris Jahn]

Very nice writeup, this does look promising. One of the things I like about it is the casual user can still write simple programs, but the power user could write very complex ones.

[IndyMike]

Joe,

 

Great Idea and yet another beautiful write up. This would, at a minimum, allow the condensation of many loosely linked programs into a single state driven program.

 

 

Chris,

 

Expanding a bit on the idea of "states", would it be possible to implement a "case" structure with multiple "states". Same basic structure as what Joe has proposed, but with multiple state qualifiers. This could really reduce the number of of the "time" based programs that I currently have running.

 

 

EX: Time Based

 

Case Time of

 

8:00 AM : Action

 

8:15 AM : If Condition

...............Then Action

...............Else Action

...............Endif

 

End Case

 

Ex: Insteon Condition

 

Case Insteon Condition of

 

On : Action

 

Off : If Condition

...............Then Action

...............Else Action

...............Endif

 

Level 40% to 60% : Action

 

End Case

[Algorithm]

Chris and Indy, thanks so much!

 

Yes, this would nicely allow the use of complex logic when needed, while still allowing the same, current easy-to-understand programs where advanced logic is not needed.

 

My (unexpressed) idea was that the procedural paradigm used within any program wrapper (event based or otherwise) could eventually expand past just the IF, THEN, ELSE keywords to encompass many more of the common program structures typically found within procedural languages. But I didn't want to ask for too much at one time !

 

Should this request be implemented, I would think that an ELSEIF could be included along with the others in the first release. I was also strongly hoping for a CASE structure to be implemented very shortly after, if not with the original release. [i hinted at that structure by referring to mutually exclusive conditions .]

 

So I definitely agree with you, Indy, about the usefulness of that structure. But in reading your post, it occurs to me that perhaps you are proposing that structure be used in place of WHEN as an event/wrapper structure? So the idea of additional event/wrapper structures is an interesting one as well. [There is, of course, no reason a particular structure could not be used both ways. One might in that case choose differing keywords in order to avoid confusion.]

 

I dearly hope that some of this will make it into the next release; I am working so hard at migrating all of the logic from Ocelot to ISY!

[IndyMike]

Joe,

 

Make no mistake, I understood exactly where you were headed with your post. I've been looking for this type of functionality (in a stand alone device) for years. After your detailed request, and the encouraging response from Chris, I was overcome by anticipation and simply couldn't resist taking the next jump.

 

I understand that this would be quite a leap, and that things would likely need to progress in logical steps (as you have outlined). Nonetheless, I see a glimmer of some very "next level" capabilities here and am looking for confirmation that this might just be possible somewhere down the road.

[blartyo]

This is such a helpful, concise way of explaining the current program structure. As a new user, I really struggled with the If...Then terms because they are so different than how I think of If...Then.

 

I think it would be helpful to new users (and even some older ones!) if the syntax were changed to what J.A.J describes:

 

 

 

IF condition

THEN some actions

ELSE other actions

 

really means:

 

WHEN this condition

BECOMES TRUE take some actions

AND THEN BECOMES FALSE take other actions

 

The 'conditions' are continuously evaluated, and 'actions' are triggered when a 'condition' changes (an 'event').

[Mark Sanctuary]

So how deap are you thinking? Just one level or can it go several levels?

 

when condition

....if condition

....then

........if condition

........then

............if condition

............then

................if condition

................then

....................if condition

....................then

 

also I vote for the case structure.

[Algorithm]

So how deap are you thinking? Just one level or can it go several levels?

 

Definitely it should be able to nest many levels, not just one.

 

also I vote for the case structure.

 

Me too!

[yardman 49]

Hello IndyMike:

 

I really know almost nothing about programming, but I was wondering if your "case" concept applies to things like the following:

 

I want lights to turn on at sunset (which varies of course), but also I want them to change states at fixed times (2am, or whatever). Right now this would have to be two programs to work correctly.

 

Would the case approach allow this to be rolled into one program?

 

Thanks! This thread is really starting to get my old brain cells working!

[Algorithm]

This is such a helpful, concise way of explaining the current program structure.

 

Aw shucks... yer jes' sayin' that 'cause it's true!

 

Thanks for saying so, blartyo. I'm glad the explanation was of help, but I can't take credit for it--Chris has explained it in at least one thread. Then again, Chris and the guys are also responsible for the way the terms operate.

 

As a new user, I really struggled with the If...Then terms because they are so different than how I think of If...Then.

 

I think it would be helpful to new users (and even some older ones!) if the syntax were changed to what J.A.J describes:

 

 

 

IF condition

THEN some actions

ELSE other actions

 

really means:

 

WHEN this condition

BECOMES TRUE take some actions

AND THEN BECOMES FALSE take other actions

 

The 'conditions' are continuously evaluated, and 'actions' are triggered when a 'condition' changes (an 'event').

[Algorithm]

After... the encouraging response from Chris, I... am looking for confirmation that this might just be possible.

 

Oh yes, please!

[Chris Jahn]

As you can see, this would be a fairly large change both to the user interface and to logic on the ISY that runs the programs. This is not something that will be in the next release, but is something we want to consider for our next major Program related release (for some reason we are calling it 'Triggers 2.0')

[IndyMike]

Frank,

 

That's exactly what I was hoping for. I currently have roughly 25 (and growing) separate time based programs. These are evaluated depending of the time of day (obvious), day of week, Vacation/home mode, and house open/secure mode. I have notes on all of these but my old brain cells make mistakes. I've broken my system many times because things are simply too spread out.

 

I'm trying not to put too many words in the ISY guy's mouth(s). Implementing a case structure would not be a small task. I do believe that the basics of the structure already exist in the ISY.

 

General rules for a case statement are -

• 1) A case statement evaluates each state (condition) in order.
  2)When a state is evaluated as true, the corresponding code is executed.
  3)After execution of the "state" code, the case statement is exited (remaining states are not evaluated).
  

 

In the case of the ISY, the Case statement would be evaluated at a predetermined iteration rate (lets say once a minute). The problem here is that Sunrise and Sunset drift around with the calender (and with DST). This can lead to complications. Here's an example:

 

Case time of

 

Sunset: Action

6:00 PM to 7:00 PM : Action

Condition 3

Condition 4

end Case

 

Now for a set of conditions:

• 
  1) Time is 6:10 and sunset is 6:15. Sunset would be evaluated as false and the 6:00 - 7:00 PM would be evaluated as true (executed). The case statement would exit without evaluating the remaining conditions.
  2) Time is 6:15 and sunset 6:15. Sunset evaluated as true and executed. Sunset would require a "tolerance" applied based on the iteration rate and other overhead factors. I believe this tolerance already exists in the ISY. Again the remaining conditions are not evaluated.

 

Note that in the above, if you reverse the "sunset" and "6:00-7:00" statements, the "6:00-7:00" would be evaluated as true and prevent execution of the "sunset" condition.

 

Since the Case statement would be evaluated once every TBD seconds/minutes, each "true" condition would be executed at the same rate. To prevent a device from being turned on at every iteration (repeatedly turned on) a lockout would be required. I would expect that this would be the responsibility of the end user (maximum flexibility).

 

6:00-7:00: If scene familyroom is off

then turn familyroom on

 

The real problem in all of this may be the amount of time consumed in evaluating the case statement. This statement is stealing time from the "event driven" realtime execution. Multiple case statements will obviously make things worse. I'm simply not sure how much of this "overhead" the ISY can support and still be responsive to realtime Insteon events (it's real purpose in life).

 

Whichever way this goes, I am extremely satisfied with the ISY. I came from the X10 CM11a/CM15a world. I had 100's of macros that would take hours (days) to modify. I really dreaded Christmas time and the required updating of my Christmas program. After Insteon came out I began updating my X10/leviton units but waited for two years for something like the ISY controller. After finally "biting the bullet", I was able to transfer my CM15a programming to the ISY in the space of a day (Inconceivable).

 

Sorry for the verbose response, I'm still a bit pumped up about this.

IM

 

Hello IndyMike:

 

I really know almost nothing about programming, but I was wondering if your "case" concept applies to things like the following:

 

I want lights to turn on at sunset (which varies of course), but also I want them to change states at fixed times (2am, or whatever). Right now this would have to be two programs to work correctly.

 

Would the case approach allow this to be rolled into one program?

 

Thanks! This thread is really starting to get my old brain cells working!

[Algorithm]

General rules for a case statement are -

• 1) A case statement evaluates each state (condition) in order.
  2)When a state is evaluated as true, the corresponding code is executed.
  3)After execution of the "state" code, the case statement is exited (remaining states are not evaluated).
  

Depends on the language. Some (many?) continue evaluation of successive case statements unless the user specifies an exit to the structure, eg. C pseudo code:

 

switch Time_of_Day
....case Sunset
....................actions
....case 6:00 PM to 7:00 PM
....................actions
....case 7:00 PM to 9:00 PM
....................actions
....................break
....other cases
....case default
....................actions

If either of the first two cases are true, their code is executed and evaluation of other cases continues. If the third case is true, its code is executed and the switch structure is exited because of the 'break' statement.

 

EDIT: Slight correct; execution falls through into successive cases until a break statement is encountered.

 

The real problem in all of this may be the amount of time consumed in evaluating the case statement. This statement is stealing time from the "event driven" realtime execution. Multiple case statements will obviously make things worse.

 

This could be true for a event type case structure, but would not be so for a procedural case.

 

As an example, the user could determine resolution required (eg. one minute) and create a program (event) which was executed every one minute in this example. This single program could contain multiple case structures, each of which would only be evaluated on demand, i.e. once each time the program was run (in this case, once per minute) rather than being continuously evaluated as events are (I wonder how many times per second ISY evaluates events?).

 

This approach really does save an incredible amount of execution time. As a real life example, the Ocelot's timers have a resolution of one second, but the main program may loop dozens or hundreds of times per second, depending on the length of the program. Since timer resolution is one second, I group all of my timer checks and have the group evaluated only once per second, each time the clock 'ticks', rather than evaluated on every program pass. This step increased the number of program passes by an order of magnitude!

 

Sorry for the verbose response, I'm still a bit pumped up about this.

IM

 

Me too!

[IndyMike]

Joe,

 

You've caught me. My programming experience is extremely... uhh... dated (70's and 80's). The specific example that I provided was for Pascal. With a bit more time I might have been able to provide an example using TI-9900 machine code (or something equally arcane).

 

Thanks for the correction. I learned something new today, that's a good thing.

 

I had used the concept of a 1 minute interval timer as well. My point with the case structure is that it could reduce the responsiveness of the ISY to realtime events. If the events are not interrupt driven, they will need to be buffered until the Case structure executes and exits. The C structure that you presented could present more of a problem with multiple "true" evaluations and an even greater overhead.

 

At this point we are really second guessing Chris and the guys. We don't know the architecture or the computational capabilities of the ISY. In addition, their code structures aren't necessarily bound by the programming rules that we are familiar with.

 

Having received a "warm fuzzy" from Chris on this subject, I'm willing to wait and expect the ISY people to implement the "correct" solution. I'm a huge fan so far.

 

IM

 

switch Time_of_Day
....case Sunset
....................actions
....case 6:00 PM to 7:00 PM
....................actions
....case 7:00 PM to 9:00 PM
....................actions
....................break
....other cases
....case default
....................actions

If either of the first two cases are true, their code is executed and evaluation of other cases continues. If the third case is true, its code is executed and the switch structure is exited because of the 'break' statement.

 

The real problem in all of this may be the amount of time consumed in evaluating the case statement. This statement is stealing time from the "event driven" realtime execution. Multiple case statements will obviously make things worse.

 

This could be true for a event type case structure, but would not be so for a procedural case.

 

As an example, the user could determine resolution required (eg. one minute) and create a program (event) which was executed every one minute in this example. This single program could contain multiple case structures, each of which would only be evaluated on demand, i.e. once each time the program was run (in this case, once per minute) rather than being continuously evaluated as events are (I wonder how many times per second ISY evaluates events?).

 

This approach really does save an incredible amount of execution time. As a real life example, the Ocelot's timers have a resolution of one second, but the main program may loop dozens or hundreds of times per second, depending on the length of the program. Since timer resolution is one second, I group all of my timer checks and have the group evaluated only once per second, each time the clock 'ticks', rather than evaluated on every program pass. This step increased the number of program passes by an order of magnitude!

[blartyo]

So can you supply some examples of what one could do with this richer programming structure?

[Algorithm]

C pseudo code:

 

switch Time_of_Day
....case Sunset
....................actions
....case 6:00 PM to 7:00 PM
....................actions
....case 7:00 PM to 9:00 PM
....................actions
....................break
....other cases
....case default
....................actions

If either of the first two cases are true, their code is executed and evaluation of other cases continues. If the third case is true, its code is executed and the switch structure is exited because of the 'break' statement.

 

Hmm... had to rethink this. It's been so long since I've done programming other than ladder logic. The above is not quite correct. If either of the first two cases is true, their code is executed. After that, execution does not evaluate the next case, rather it falls through directly into the next case (as though the case were true). Execution will continue to fall through each case in turn until a break statement is encountered. Slight difference there; my bad!

 

My point with the case structure is that it could reduce the responsiveness of the ISY to realtime events.

 

And I agree that this could happen with event case structures, but should not happen with procedure case structures (ones inside a program) because the whole program is an event, and its contents evaluated only on demand rather than continuously.

 

But I'm not trying to say that we have to choose between the two; both could be implemented.

 

At this point we are really second guessing Chris and the guys. We don't know the architecture or the computational capabilities of the ISY. In addition, their code structures aren't necessarily bound by the programming rules that we are familiar with.

 

Having received a "warm fuzzy" from Chris on this subject, I'm willing to wait and expect the ISY people to implement the "correct" solution. I'm a huge fan so far.

 

IM

 

Agreed!