Embedded IF-Then-Else in Programs

[j.rieff]

Yes - yet another question during the installation process. 

 

Now, I am looking at building programs for the devices and I have encountered a situation where I need to use an embedded If-Then-Else

 

For example:

 

If <condition 1> and <condition 2>

 

Then <perform action 1>

 

Else

   If <condition 2>

   Then <perform action 2>

    Else <perform action 3>

 

Not quite sure how to program then 2nd If statement as part of the 1st Else statement. 

 

Thanks in advance.

 

 

[MWareman]

Yes - yet another question during the installation process.

 

Now, I am looking at building programs for the devices and I have encountered a situation where I need to use an embedded If-Then-Else

 

For example:

 

If <condition 1> and <condition 2>

 

Then <perform action 1>

 

Else

If <condition 2>

Then <perform action 2>

Else <perform action 3>

 

Not quite sure how to program then 2nd If statement as part of the 1st Else statement.

 

Thanks in advance.

You must split to two programs. Have the first program call the second programs 'If'.

 

I'm concerned though that your thinking about programming in the traditional 'flow' sense. ISY is event driven. Sometimes we need to think differently.

 

Edited: typo

[apostolakisl]

MWareman meant to say "event driven" not "even driven".  A typo that would be challenging to figure out.  Basically it means you have to think in sense of triggers.  In the below example at least one of the 2 conditions must be a triggering item and the programs would only run when the trigger event happens.  Either that or the programs below would need to be externally triggered (ie a 3rd program that says "run if" of these programs as part of its then/else clauses.  For example, if a condition where the "status" of a switch, the trigger would be a change in the status of the light.  If the condition were a "control" of a switch, it would require that someone physically acted upon the switch (pushed it in some way).

 

 

As mentioned, 2 programs

 

 

If

condition 1

and

condition 2

 

Then

do x

 

Else

blank

 

If 

not condition 1

and

condition 2

 

Then

y

 

Else 

blank

[andyf0]

 If the condition were a "control" of a switch, it would require that someone physically acted upon the switch (pushed it in some way).

Again, I have to remind folks that "control" of a switch only works with Insteon switches. You must use "status" of a switch if the switch is a Z-Wave device. There is no method in Z-Wave to determine if the switch was physically pressed or controlled by some other source.

[larryllix]

Again, I have to remind folks that "control" of a switch only works with Insteon switches. You must use "status" of a switch if the switch is a Z-Wave device. There is no method in Z-Wave to determine if the switch was physically pressed or controlled by some other source.

Another reason not to go to the "dark side" and stay with Insteon, real HA

[KeviNH]

I agree -- it does take effort to think about coding in an event driven environment compared to traditional programming flow. I've worked with other systems and intepreters which are also event-driven, and while that helps, I still sometimes have to stop and rethink my approach when implementing something complex with ISY994.

 

You must split to two programs. Have the first program call the second programs 'If'.

I'm concerned though that your thinking about programming in the traditional 'flow' sense. ISY is even driven. Sometimes we need to think differently.

On a related note, if the second program should never run on it's own, but only when "Run IF ..." is called from another program, you can disable the second program.
 
A program that is not enabled only runs when called explicitly (e.g. from a program or via REST), never is automatically run by the ISY, see http://forum.universal-devices.com/topic/14904-disabled-program-run-if-by-another-program-does-not-revaulate-if-conditions-change-while-it-is-in-running-then-state/ for more.

[j.rieff]

Thanks everyone. All the comments make a lot of sense. I will need to rewiring a few brain cells. 

[PhanTomiZ]

Again, I have to remind folks that "control" of a switch only works with Insteon switches. You must use "status" of a switch if the switch is a Z-Wave device. There is no method in Z-Wave to determine if the switch was physically pressed or controlled by some other source.

 

These are not switches, but the only Z-Wave device I currently have that responds to "Control" is my Kwikset 910 Deadbolt Locks (Lock, Unlock, Jammed,Tamper and Battery).  Battery has Battery Low, Critically Low and Too Low To Operate.  For me, with 4 On/Off cycles per day, when it's Critically Low, they will last about 1 month. My other Z-Wave devices are switches and they do not work with Control as you stated.

 

PhanTomiZ

[MWareman]

Again, I have to remind folks that "control" of a switch only works with Insteon switches. You must use "status" of a switch if the switch is a Z-Wave device. There is no method in Z-Wave to determine if the switch was physically pressed or controlled by some other source.

Not true with the Homeseer zwave switches. 'Control' works just fine with these on 5.0.8.