how programs are processed (Pt 2)

[aweber1nj]

I have a question about when the time-based constructs are executed. Please assume these to be simple programs with ONLY these time-constructs in the IF-Statement...

 

I guess the IF (specific time) is pretty self-explanatory. All good.

 

But when you say FROM - TO. Are we actually writing shorthand for:

@ From-Time, run "THEN"

@ To-Time, run "ELSE"

???

 

It's not entirely intuitive to someone who develops software (or possibly many others reading it). I think it's a powerful shorthand, but it's not intuitive to look at and understand/learn.

 

When is the "Else" run if you just use a "IF Time Is" ? I assume you are not running the THEN one second of the day, and continually running the ELSE every other second of the day (which is what the statement literally says).

 

Thanks,

AJ

[LeeG]

Things in the ISY are event driven.

 

At the From time the Then clause is invoked.

 

At the To time the Else clause is invoked.

 

A Program that has a single specific time, only the Then clause is invoked at the specific Time

[oberkc]

But when you say FROM - TO. Are we actually writing shorthand for:

@ From-Time, run "THEN"

@ To-Time, run "ELSE"

 

Yes.

 

When is the "Else" run if you just use a "IF Time Is" ?

Under this condition (still assuming the simple case that this is the only program condition) the else path is not run.

[aweber1nj]

Ok, then it's never really an "else". (I still have not thoroughly investigated other conditions, but I think it still applies)

 

It's more a Start-Condition, statements-to-execute, Exit-Condition, exit-statements. If you omit an exit condition, you will never run any exit statements.

[LeeG]

Keep in mind the answers applied to the questions asked. Change the question a little and the answer changes. For example .....

 

If
       Control 'KPL Floor Dimmer 6 / KPL Floor Dimmer 6 - B' is switched On
   And Time is  2:38:00PM

Then
       Send X10 'D1/All Lights Off (1)'

Else
       Send X10 'D1/Off (11)'

 

will execute the Else clause.

[aweber1nj]

When?

 

Technically if you read that statement, if that device is OFF: for every second it is NOT 2:38:00PM, the ELSE statement is TRUE.

 

So is the ISY going to send OFF to X10 device D1 86,399 times per day (and at one second, one time per day it will send D1 All Lights Off)?

 

I highly doubt that it is, but my point is when you read the If-Then-Else explicitly, that's what you would read. (But that depends on whether the language short-circuits the ANDs and ORs, in which case you have to be careful what order you put these statements in too.)

[apostolakisl]

If

Time is x

 

This program will only self trigger at that time and be true (run then). It will never run the else clause on its own. If anything else causes it to trigger, it will only run the else clause since you could never have an external trigger happen exactly at time x. This program will also always be "true" when left to itself. Again, if some other program triggered it, then it would be false. But there really is no reason to ever do that so it would almost certainly have a blank Else clause.

 

If Time is x

And some other condition

 

You can "and" a single time clause to other clauses, in this case the time trigger would likely be the important trigger and the "anded" items would be secondary conditions that you might want to also be true at that time in order to execute. If the "anded" items trigger, then it will run false because the time would not be true at that instant. It is very unlikely that you would ever use the "else" clause in a program like this.

 

If

time is from x to y

 

This has 3 useful functions. First, it triggers a then at the from time, and an else at the to time. It also will be true between the times, so another program can reference it. You would pretty much always have a "then" and "else" clause for this program. Leaving the "else" blank would more or less make it the same as "if time is x". The exception would be if another program calls it.

 

If

time is from x to y

and other condition

 

You can have other conditions "anded" to it and still get either a true or false response. This program will often have both "then" and "else" conditions, but not necessarily. You may just want "then" clause conditions to execute at time x and between times x and y whenever the other condition is also true. But you may just want nothing to happen outside of that window.

[aweber1nj]

OK, my point is that an If-Then-Else branching construct is, IMHO, not the clearest way to allow a user to design a "program", since as you say, the If statement actually causes execution paths to occur differently depending upon the actual condition-types -- not just the pure logic of the expression.

 

I did not fully consider the "programs calling programs" in the "from x to y" you gave for example. It is a good idea.

 

And I think the power of many of these is good, my issue is with the terminology it's presented with for programming. I was just offering my $0.02 on the convention. I'm in no way trying to flame or bash the ISY or the software inside it.

 

And I do find the discussion that has resulted valuable.

[oberkc]

OK, my point is that an If-Then-Else branching construct is, IMHO, not the clearest way to allow a user to design a "program", since as you say, the If statement actually causes execution paths to occur differently depending upon the actual condition-types -- not just the pure logic of the expression.

 

You are not the first to express the opinion that there is something not quite right. However, I have always found that it works completely predictably once you understand it: that is, what triggers a program to be evaluated. Once evaluated, the "pure logic of the expression" does, indeed, govern the execution.

 

Understand program "triggers", and I think you will find the ISY to be quite logical.

[apostolakisl]

As oberkc mentions, it does work and it follows its logic. But it is a different language. Don't try to just apply the usual stuff.

 

Programs calling programs or programs checking the true/false nature of a program is very common with people who take the programming past the total beginner level.

 

Understand triggers and you will get most of it. Important concepts.

 

1) "control" statements are triggers on ISY receiving that command. ie "control switched on" means someone must push the on paddle. Otherwise it is false. It will always be false if something else triggers.

2) "status" statements trigger on every change of the status no matter what it might be. It could be true or false if it is its own trigger or if something else triggers.

3) All of the conditions are equal as far as potential to be triggers. The first or the last statement makes no difference, a trigger causes the entire program to stop (if it is already running) and evaluate the entire "if" clause.

4) Conditions will be triggers whether you want them to be or not. In other words, you can't shut off a condition as far as being a trigger. This is when you use multiple programs where one calls another. It is a bit of a workaround. The program that you want to disable the trigger clause is set as "disabled" so it never self-triggers. Disabled does not stop a program from running, only self triggering.

5) Time commands are triggers as noted earlier.

 

ISY is very powerful. But it is definitely different.

[aweber1nj]

Programs calling programs or programs checking the true/false nature of a program is very common with people who take the programming past the total beginner level.

I don't know where you got that information. Maybe there's a study somewhere, but I will take the other side of that statement: Programs calling programs is relatively rare because the programmer loses some (or a lot of) control of the execution, especially where daisy-chained programs can be stopped/killed (easy to do on any semi-interactive OS). Programs checking the result of those daisy-chained programs is also usually a "last resort." It is, actually, either a workaround or the result of a "beginner level" programmer. We could discuss the concept of shared-libraries and similar reusable components, but programs-calling-programs is definitely more junior level stuff.

 

I very much appreciate the concepts you documented, but you (and others) keep returning to my very point...

1) "control" statements are triggers on ISY receiving that command. ie "control switched on" means someone must push the on paddle. Otherwise it is false.

"Otherwise it is false". Then why aren't the FALSE statements being executed at all of those times????

 

If a program's IF-Statement is only evaluated upon certain events, then we need information about WHEN programs are attempted or executed. If the IF-Statement is specifically WHEN a program is being executed, then it should be the trigger-event, not an IF-Statement (because there is an ELSE-Statement that should be executed when the IF-Statement is _not_ true).

 

-AJ

[apostolakisl]

Please read what I wrote again. You are being oddly judgmental for someone who is asking for help as a beginner.

 

The fact is, ISY is event driven. Programs calling programs is a fundamental part of how ISY works in more complex situations. If you don't like it, tough luck. Don't use ISY.

 

And, to your second question. ISY does not always run false because like I said, it is event driven. The only trigger for a "control swithed on" is receiving a "switched on" signal from the switch. How would it ever be false? It either receives that signal and the "event" triggers the program, and it is true, or no trigger ever occurs and the program simply doesn't run. The else clause has lots of value, but not in a single line "control switched" program.

[aweber1nj]

No, if you read my previous posts, you'd note that I specifically said I wasn't trying to bash the ISY and am trying to understand how the programs logic is put together. It isn't apparent as first glance because it seems the constructs aren't entirely what they seem. So I ask for information in a Q&A forum.

 

So you are absolutely right; I don't know how the ISY works, and that's why I'm posting my question here.

 

So far, I love this device, but to get the most power out of it, I strive to understand it better. The programming constructs are tripping me up.

 

I always value responses, because they're from people taking the time to help others.

 

I think it's the labels here. And I'm sorry if I offended you.

 

The simple example of a "switched on" event you mention I totally agree with and understand. There should be no Else allowed in that program.

 

I'm just saying back to you (in trying to understand it) that what we're saying is it's a trigger event, not really an if-statement per se. Otherwise we'd need definition as to when the if is evaluated, and if it's more frequently than when the event occurs, and you throw time specs in with and logic, then else statements would be run a lot.

[Michel Kohanim]

Hello apostolakisl, thanks so very much!

 

Hello aweber1nj, I know this subject is a little confusing so let me see if I can explain it.

 

Status events are generated based on change of state. Control events are generated when a person physically turns something on/off. As such, if you turn a device physically on 10 times, the status is only changed once and programs that depend on status will NOT be evaluated because the status never changed. Control events, on the other hand, cause programs that depend on them to be re-evaluated.

 

As far as programs calling programs, it's really up to you whether or not you like using them. From an atomic operation perspective, you can consider programs without conditions as tasks/threads the execution of which does not depend on the events received and/or evaluated.

 

With kind regards,

Michel

[apostolakisl]

The simple example of a "switched on" event you mention I totally agree with and understand. There should be no Else allowed in that program.

 

 

If you were to add more conditions or if you were to call the program from another program, then the else could run. It is not ruled out as a possibility. Furthermore, it is just a "form" of sorts. You don't always need all the blanks on a form, and you don't necessarily need all the options in an ISY program.

 

And if you want to substitute other terminology for the word "if" in your own mind, then fine. Like "in the event that"

 

Elk, which uses similar event driven programs using the term "whenever" instead of "if"

[oberkc]

"Otherwise it is false".

 

In my mind, a simple program such as:

 

if

control 'switch-A' is on <<

then

do something

else

nothing

 

will NEVER be false, unless triggered externally, such as being called from another program, or if triggered by additional conditions within the program, such as:

 

if control 'switch-A" is on <<

and time is between 0700 - 1000 <<

Then...

Else...

 

Such a program will trigger itself at 0700 and at 1000, and upon receipt of an ON command from switch A. Such a program will be TRUE only if receipt of an ON command occurs between 0700 and 1000. It will stay true until 1000, at which point this program will turn false and stay false until receipt of another ON command between 0700 and 1000.

 

 

aweber1nj, it seems to me from your posts that you are understanding it just fine. Just to be sure, I offer the following examples:

 

if control switch-A is turned on <<<

if control switch-A is turned off <<<

if status switch-A is ON <<<

if status switch-A is OFF <<

if status switch-A is NOT switched OFF <<

 

The other thing about the ISY that seems to trip folks up who have experience with other programming languages are WAITs and REPEATs. If a program is triggered while in a waiting period, the execution will halt and start executing a new path, based on results of the evaluation. For example:

 

If

control switch A is turned on

and control switch A is NOT turned off

then

wait a few minutes

do something

else

do something else

 

In the program above, if switch A is turned ON, it triggers an evaluation and the evaluation for the entire condition is TRUE. Then path will run. If, in less than a few minutes, the switch is again turned ON, the program will halt the existing wait period and start a new wait period. If, in less than a few minutes, the switch is turned OFF, it will halt the existing wait period and execute the ELSE path.

 

Beyond triggers and wait/repeat, I think you will find the programming quite intuitive and consistent with your experience.

 

Hopefully, this helps.

[aweber1nj]

Great info on the "Waits" and "Repeats", thank you!

 

-AJ