add an else if

[flemingmike]

i would like it if you could have it so programs could be

 

if

 

then

 

elseif

 

then

 

else

[apostolakisl]

You do this by using two programs and deactivating the second program

  
IF
    - some condition
Then
   - do something
Else
   - Run program 2 if clause

Program 2 (set to disabled)

If
  - some condition
Then
  - do something
Else
  - do something else

[flemingmike]

Thats what i have done. I just find i have 3 or more programs to do one task. Was just a thought.

[apostolakisl]

Then you put the programs into a folder and pretend the folder is one program.

 

When you have a

 

if

then

else if

then

else

 

you actually have two programs nested. The only advantage would be that they are both on the screen at the same time. And then you might say why not a second "else if" in the second else and so on and so on. That would get to be a big mess for the programming console.

[flemingmike]

ok, i could do that. if you ever did put in an elseif, you could just have a button that says insert elseif. then you could have unlimited elseif's.

[bigdog]

I think that adding an ELSE IF construct would be an excellent enhancement. CASE selection has traditionally been a standard method of evaluating conditions in procedural programming languages, and ELSE IF is just another way of doing CASE selection.

 

There are some very good uses for this. For example, I have ordered some Flora irrigation controllers that I am going to install this weekend. My current irrigation controllers start their cycles about 8pm. I have over an acre of landscaped grounds, with about half on drip and the other half on conventional sprinklers or rain birds. I live in the foothills of Santa Barbara, CA. We are in an area prone to "Santa Ana" or "sundowner" hot dry winds after sunset. These winds can sometimes reach 50+ mph. This does not bother the drip systems, but the sprinklers and rain birds are simply wasting water if the wind is much over 10 mph. I also have a Davis weather station and the ISY Weatherbug module. It would be really cool to be able to check the wind speed before firing a sprinkler zone. I know that I can already do this, but ELSE IF capability would allow much more control. For example, normal windy conditions are different than Santa Ana wind conditions. If it is just windy, I might not fire the sprinklers, but if there are hot dry winds, it dries out the soil almost immediately and I could either cancel the cycle, or increase the run time for a particular zone. This would all be possible with multiple programs of course, but being able to test multiple conditions and define the behavior of each in a single program would be immensely easier and much easier to debug.

 

Even if the users needs were not quite this complex, having the ability to use multiple ELSE IF constructs would still be helpful. I have been thinking about how to create programs to detect whether or not we're home when it gets dark and have different scenes applied. Having the ability test multiple conditions in a single program would make this much easier.

 

For example:

 

If lamp1 is ON, and Lamp2 is ON then //We're definitely home

run scene2

else if Lamp1 is OFF and Lamp2 is OFF and Lamp3 is OFF then //We're definitely not home

run scene3

else if Lamp1 is OFF and Lamp2 is OFF and Lamp3 is ON then //We're probably working in the garage

run scene4

else

run scene1 //We're probably home somewhere - run a default scene

 

1 or more lamps might simply be ones we would normally turn on manually when we were home and not necessarily part of any scene. I would be able to check the status of certain devices and run a different scene(s) depending on a variety of possible status conditions. Having the ability to do this from one program would be the icing on the cake for me.

 

There is a difference between Home Automation and Intelligent Home Automation. IMHO, this capability would elevate the ISY to a truly Intelligent Home Automation device. On the plus side for the ISY developers, think of all the support issues that this would solve!

 

-Brian

[apostolakisl]

I think that adding an ELSE IF construct would be an excellent enhancement. CASE selection has traditionally been a standard method of evaluating conditions in procedural programming languages, and ELSE IF is just another way of doing CASE selection.

 

There are some very good uses for this. For example, I have ordered some Flora irrigation controllers that I am going to install this weekend. My current irrigation controllers start their cycles about 8pm. I have over an acre of landscaped grounds, with about half on drip and the other half on conventional sprinklers or rain birds. I live in the foothills of Santa Barbara, CA. We are in an area prone to "Santa Ana" or "sundowner" hot dry winds after sunset. These winds can sometimes reach 50+ mph. This does not bother the drip systems, but the sprinklers and rain birds are simply wasting water if the wind is much over 10 mph. I also have a Davis weather station and the ISY Weatherbug module. It would be really cool to be able to check the wind speed before firing a sprinkler zone. I know that I can already do this, but ELSE IF capability would allow much more control. For example, normal windy conditions are different than Santa Ana wind conditions. If it is just windy, I might not fire the sprinklers, but if there are hot dry winds, it dries out the soil almost immediately and I could either cancel the cycle, or increase the run time for a particular zone. This would all be possible with multiple programs of course, but being able to test multiple conditions and define the behavior of each in a single program would be immensely easier and much easier to debug.

 

Even if the users needs were not quite this complex, having the ability to use multiple ELSE IF constructs would still be helpful. I have been thinking about how to create programs to detect whether or not we're home when it gets dark and have different scenes applied. Having the ability test multiple conditions in a single program would make this much easier.

 

For example:

 

If lamp1 is ON, and Lamp2 is ON then //We're definitely home

run scene2

else if Lamp1 is OFF and Lamp2 is OFF and Lamp3 is OFF then //We're definitely not home

run scene3

else if Lamp1 is OFF and Lamp2 is OFF and Lamp3 is ON then //We're probably working in the garage

run scene4

else

run scene1 //We're probably home somewhere - run a default scene

 

1 or more lamps might simply be ones we would normally turn on manually when we were home and not necessarily part of any scene. I would be able to check the status of certain devices and run a different scene(s) depending on a variety of possible status conditions. Having the ability to do this from one program would be the icing on the cake for me.

 

There is a difference between Home Automation and Intelligent Home Automation. IMHO, this capability would elevate the ISY to a truly Intelligent Home Automation device. On the plus side for the ISY developers, think of all the support issues that this would solve!

 

-Brian

 

"Else if" is useful, but as I mentioned earlier, it already exists. "Else if" would be a nested program inside of a program. In ISY, you nest a program by having the else clause call a second program which itself is set to "disabled". In this fashion, the second program only has its "if" clause evaluated when called and is therefore nested into the program(s) that call it.

[bigdog]

I understand that this can be done. However, having an else if would sure make programs a lot more readable and maintainable.

[ndfan77]

"Else if" is useful, but as I mentioned earlier, it already exists. "Else if" would be a nested program inside of a program. In ISY, you nest a program by having the else clause call a second program which itself is set to "disabled". In this fashion, the second program only has its "if" clause evaluated when called and is therefore nested into the program(s) that call it.

I know I'm a year and a half late to this conversation (but I'm just getting started with my ISY994i).

 

To be completely candid, I'm rather surprised "Else If" functionality is not supported. Running a second program in the Else portion of the first program IS SIMPLY ARCANE! I know you can do better!

[apostolakisl]

"Else if" is useful, but as I mentioned earlier, it already exists. "Else if" would be a nested program inside of a program. In ISY, you nest a program by having the else clause call a second program which itself is set to "disabled". In this fashion, the second program only has its "if" clause evaluated when called and is therefore nested into the program(s) that call it.

I know I'm a year and a half late to this conversation (but I'm just getting started with my ISY994i).

 

To be completely candid, I'm rather surprised "Else If" functionality is not supported. Running a second program in the Else portion of the first program IS SIMPLY ARCANE! I know you can do better!

 

I am still going to point that an "elseif" itself is a nested program. The difference between "elseif" and "else run if of program 2" is strictly in how it is presented to the user in the GUI. The code logic is going to be identical.

 

I say leave it alone, there is no advantage in functionality. I would rather see ISY coders work on stuff that puts new functionality into the product, like expanded use of variables and improving the network module. Or add a checkbox next to each line of code that lets you disable it as a trigger . . . that would really make a big difference when it comes to programs calling programs.

[G W]

And it does not already exist. In an IF ELSE structure, it flows from top down and stops at the first true condition. This allows for several conditions to actually be true, with only the first true if being executed.

 

CASE will evaluate and execute for each case that evaluates true.

[apostolakisl]

And it does not already exist. In an IF ELSE structure, it flows from top down and stops at the first true condition. This allows for several conditions to actually be true, with only the first true if being executed.

 

CASE will evaluate and execute for each case that evaluates true.

 

I'm confused. Are you saying to have

 

If

whatever

Then

whatever

Elseif

conditions/then/else

Elseif

conditions/then/else

Elseif

conditions/then/else

 

?

 

 

If so, this does exist

 

If

Whatever

Then

Whatever

Else

run if of program 2

run if of program 3

run if of program 4

etc.

 

All 3 (or more) of the other 3 programs will have their conditions evaluated and executed.

 

Or, if instead you want the next condition to be evaluated in the event that the predecessor was false then

 

If

Whatever

Then

Whatever

Else

Run if of program 2

 

Program2

If

Whatever

Then

Whatever

Else

Run if of program 3

 

Program 3

If

Whatever

Then

Whatever

Else

Run if of program 4

 

etc.

[G W]

Interesting. The last bit of code should do exactly that. It's a bad practice but I can see where it will work.

 

Sent from my SPH-L720 using Tapatalk

[PurdueGuy]

I guess I am in the minority here. Having an "else if" doesn't really make sense to me.

The triggers would get much more complex. How would you trigger it?

 

Given a program such as:

If A = 1 then

else if B=2 then

else

end

 

When do you trigger? When A changes only? When B changes only? When either A or B changes?

Not having nested programs makes it obvious when they trigger.

[apostolakisl]

I guess I am in the minority here. Having an "else if" doesn't really make sense to me.

The triggers would get much more complex. How would you trigger it?

 

Given a program such as:

If A = 1 then

else if B=2 then

else

end

 

When do you trigger? When A changes only? When B changes only? When either A or B changes?

Not having nested programs makes it obvious when they trigger.

 

Interesting thought. And this sort of comes back to the other point I had made. Having a checkbox next to each condition in an "if" that lets you disable it as a trigger. Nested if's are easy for me to keep straight in my head, especially if you export the programs and view them on a single screen. But doing "run if", "run then", "run else" in an attempt to get rid of conditions that you wanted tested but only on other triggers is easier to get jumbled. Just going by the questions people post here on having programs not do what they expect, this issue is far more prevalent.

[G W]

And that is what causes confusion; what triggers what?

 

I see a need to trigger on one condition, yet check another condition to decide what to do.

 

Sent from my GT-P5210 using Tapatalk 4

[apostolakisl]

And that is what causes confusion; what triggers what?

 

I see a need to trigger on one condition, yet check another condition to decide what to do.

 

Sent from my GT-P5210 using Tapatalk 4

 

Well of course the solution to that is the trigger condition goes in program 1, and the non-trigger condition goes in a disabled program 2 along with all of the then/else statements. This really is turning 1 program into 2 programs. Nested "elseif" is just putting 2 inter-related programs on the screen at the same time.

[G W]

I agree. And that is the way one needs to think when writing code for the ISY.

 

I'm going to separate everything I've written into triggers and run code and see if that improves the logic.

 

Sent from my GT-P5210 using Tapatalk 4

[ndfan77]

I am still going to point that an "elseif" itself is a nested program. The difference between "elseif" and "else run if of program 2" is strictly in how it is presented to the user in the GUI. The code logic is going to be identical.

 

I say leave it alone, there is no advantage in functionality. I would rather see ISY coders work on stuff that puts new functionality into the product, like expanded use of variables and improving the network module. Or add a checkbox next to each line of code that lets you disable it as a trigger . . . that would really make a big difference when it comes to programs calling programs.

I don't think it actually does exist technically. As I think you've subsequently mentioned, the trigger for the first program doesn't account for the triggers needed for the 2nd or 3rd programs that are called to perform the "else if" logic.

 

Last night I tried to setup a program that run my front porch lights at full brightness from sunset to 10 PM, then 40% from 10 Pm to 1:00 AM, and then 15% from 1:00 AM to sunrise. Unless I'm missing something this effectively needs three programs:

 

   Program 1:
      If From Sunset to 10PM Then
         Set lights to 100%
      Else
         Run Program 2
      End If

  Program 2 (disabled):
      If From 10PM to 1AM Then
         Set lights to 40%
      Else
         Run Program 3
      End If

  Program 3 (disabled):
      If From 1AM to Sunrise Then
         Set lights to 15%
      Else
         Set lights Off
      End If

This morning the porch lights were still on.

 

I don't believe the isy994i knows that Program 1 needs to be called at 10Pm and 1AM in addition to Sunset, because Program 1 calls Program 2, and Program 2 has a different time test, and/or that Program 2 calls Program 3, which has yet another time test for 1AM?

 

The other point I'd like to make is that "Else If" functionality can reduce the number of programs needed by 50%, 60%, or 75%. Why would that not be a worthy use of development resources? If I had ten scenes that needed this type of logic, why in the world would we think that having 30 programs to support that would be perfectly acceptable -- instead of just 10 programs (assuming it even worked with 30)!

 

Update: To get this logic to work right the program(s) needed to be changed as follows:

 

   Program 1:
      If    From Sunset to 10PM
         Or From 10PM to 11:59PM
         Or From 11:59PM to Sunrise (Next Day)
      Then
         Run Program 2
      Else
         Set Lights Off
      End If

  Program 2 (disabled):
      If From Sunset to 10PM Then
         Set lights to 100%
      Else
         Run Program 3
      End If

  Program 3 (disabled):
      If From 10PM to 11:59PM Then
         Set lights to 40%
      Else
         Set lights to 15%
      End If

I believe this works because Program 1 now has all the pertinent times in it's IF statement, so the isy994i knows it needs to be scheduled again at 10PM after it runs at sunset, and scheduled again at 11:59PM after it runs at 10PM.

 

But I can't help but feel that this is way to cumbersome. It would be one thing if this was Freeware or Open Source, but it isn't -- I paid a pretty decent sum of money for the isy994i and the Insteon hardware. The isy994i fundamentally seems like a pretty classy act -- but the lack of Else If (or CASE) functionality seems like a sizable deficiency and turns what should be a rather simple program into a hard to maintain, unreadable kludge.

[apostolakisl]

I am still going to point that an "elseif" itself is a nested program. The difference between "elseif" and "else run if of program 2" is strictly in how it is presented to the user in the GUI. The code logic is going to be identical.

 

I say leave it alone, there is no advantage in functionality. I would rather see ISY coders work on stuff that puts new functionality into the product, like expanded use of variables and improving the network module. Or add a checkbox next to each line of code that lets you disable it as a trigger . . . that would really make a big difference when it comes to programs calling programs.

I don't think it actually does exist technically. As I think you've subsequently mentioned, the trigger for the first program doesn't account for the triggers needed for the 2nd or 3rd programs that are called to perform the "else if" logic.

 

Last night I tried to setup a program that run my front porch lights at full brightness from sunset to 10 PM, then 40% from 10 Pm to 1:00 AM, and then 15% from 1:00 AM to sunrise. Unless I'm missing something this effectively needs three programs:

 

   Program 1:
      If From Sunset to 10PM Then
         Set lights to 100%
      Else
         Run Program 2
      End If

  Program 2 (disabled):
      If From 10PM to 1AM Then
         Set lights to 40%
      Else
         Run Program 3
      End If

  Program 3 (disabled):
      If From 1AM to Sunrise Then
         Set lights to 15%
      Else
         Set lights Off
      End If

This morning the porch lights were still on.

 

I don't believe the isy994i knows that Program 1 needs to be called at 10Pm and 1AM in addition to Sunset, because Program 1 calls Program 2, and Program 2 has a different time test, and/or that Program 2 calls Program 3, which has yet another time test for 1AM?

 

The other point I'd like to make is that "Else If" functionality can reduce the number of programs needed by 50%, 60%, or 75%. Why would that not be a worthy use of development resources? If I had ten scenes that needed this type of logic, why in the world would we think that having 30 programs to support that would be perfectly acceptable -- instead of just 10 programs (assuming it even worked with 30)!

 

 

An elseif wouldn't fix your problem. The problem is that the primary program is only triggering twice. At Sunset (true) and 10pm (false). So an "elseif" would only get a chance to run at 10pm, just like your "else run program 2" is only running at 10pm. Either way, it won't work. Your issue is with the event driven logic of ISY, not the existence (or lack thereof) of elseif.

[kck]

One thing to be careful about that I see in a lot of this discussion is treating "programs" as though they were "subroutines" which so far as I can tell they are not. "Calling" a program from what I can tell simply posts it for execution but does not guarantee it will execute *now* sequential to the code before and after the call. That is

 

I = 1

Run prog

I = 2

 

does not guarantee that I equals 1 when prog executes.

 

If there are no sequential semantics in play (i.e., only the program invocation is in the flow) this doesn't make a difference. But if the call is part of a sequence of operations then you need to be very careful.

 

This is one reason I think some of the ISY "work-arounds" for what I think of as "missing" programming constructs are actually a bit dangerous in that they use ISY constructs with rather different semantics to "fake" something else - and you get away with it often but not always. The semantics of "program" as state triggered execution fragment (even if the trigger is an explicit call) is fine but don't think it is something else.

[apostolakisl]

One thing to be careful about that I see in a lot of this discussion is treating "programs" as though they were "subroutines" which so far as I can tell they are not. "Calling" a program from what I can tell simply posts it for execution but does not guarantee it will execute *now* sequential to the code before and after the call. That is

 

I = 1

Run prog

I = 2

 

does not guarantee that I equals 1 when prog executes.

 

If there are no sequential semantics in play (i.e., only the program invocation is in the flow) this doesn't make a difference. But if the call is part of a sequence of operations then you need to be very careful.

 

This is one reason I think some of the ISY "work-arounds" for what I think of as "missing" programming constructs are actually a bit dangerous in that they use ISY constructs with rather different semantics to "fake" something else - and you get away with it often but not always. The semantics of "program" as state triggered execution fragment (even if the trigger is an explicit call) is fine but don't think it is something else.

 

Yes, you are correct. The only way to know that 2 things will happen in a certain order is to put them in order in the same program. You can not call another program and expect that program to finish and then return to the first program.

 

As I was saying before, ISY is event driven logic, not thread logic. Event driven logic works very well for home automation and avoids a lot of work arounds for the most commonly used HA stuff. But it is sort of a damned if you do, damned if you don't since then you present yourself with the need for other work arounds. But most people never need these work arounds since most HA objectives work in the event driven construct.

[apostolakisl]

   Program 1:
      If    From Sunset to 10PM
         Or From 10PM to 11:59PM
         Or From 11:59PM to Sunrise (Next Day)
      Then
         Run Program 2
      Else
         Set Lights Off
      End If

  Program 2 (disabled):
      If From Sunset to 10PM Then
         Set lights to 100%
      Else
         Run Program 3
      End If

  Program 3 (disabled):
      If From 10PM to 11:59PM Then
         Set lights to 40%
      Else
         Set lights to 15%
      End If

I believe this works because Program 1 now has all the pertinent times in it's IF statement, so the isy994i knows it needs to be scheduled again at 10PM after it runs at sunset, and scheduled again at 11:59PM after it runs at 10PM.

 

But I can't help but feel that this is way to cumbersome. It would be one thing if this was Freeware or Open Source, but it isn't -- I paid a pretty decent sum of money for the isy994i and the Insteon hardware. The isy994i fundamentally seems like a pretty classy act -- but the lack of Else If (or CASE) functionality seems like a sizable deficiency and turns what should be a rather simple program into a hard to maintain, unreadable kludge.

 

 

Here is I think a simpler way to do what you want.

"Lights on At Sunset to Sunrise Program"

If 
time is from sunset to sunrise next day
Then
Set light to 100 percent
Else
Set light off

"Light Brightness Step Down Program"

If
Time is 10pm 
Then
set light to 40 percent
wait 3 hours
set light to 15 percent
Else
---

 

This would be thinking more as an event driven logic rather trying to force logic that works better in other environments.

[ndfan77]

An elseif wouldn't fix your problem. The problem is that the primary program is only triggering twice. At Sunset (true) and 10pm (false). So an "elseif" would only get a chance to run at 10pm, just like your "else run program 2" is only running at 10pm. Either way, it won't work. Your issue is with the event driven logic of ISY, not the existence (or lack thereof) of elseif.

An implementation of ElseIf should look something like this (logically):

If From Sunset to 10PM Then

    Set lights to 100%

ElseIf From 10PM to 1AM (Next Day) Then

    Set lights to 40%

ElseIf From 1AM to Sunrise Then

    Set lights to 15%

Else

    Set lights Off

End If

An Implementation of ElseIf would also (naturally) require the isy994i to analyze each ElseIf statement for additional triggers.

 

I fail to see why this wouldn't be a much more appealing arrangement than having two, three, four, or five, separate programs cobbled together.

[ndfan77]

Here is I think a simpler way to do what you want.

"Lights on At Sunset to Sunrise Program"

If 
time is from sunset to sunrise next day
Then
Set light to 100 percent
Else
Set light off

"Light Brightness Step Down Program"

If
Time is 10pm 
Then
set light to 40 percent
wait 3 hours
set light to 15 percent
Else
---

 

This would be thinking more as an event driven logic rather trying to force logic that works better in other environments.

Ahhh, seems like that could actually be simplified further into the ultimate goal of having just one program per task!

"Lights on At Sunset to Sunrise Program"

 

If

    time is from sunset to sunrise next day

Then

    Set light to 100 percent

    wait 3 hours

    set light to 40 percent

    wait 2 hours

    set light to 15 percent

Else

    Set light off

End

 

(Sorry, didn't mean to turn this into a "I can code that in 5 lines or less" competition .)