Usable ELSE part

[JacquesB]

Hi,

 

Now, the programming is done only with If - Then - Else. Or Should I say only with If - Then because the Else part is almost unusable.

 

All programs are run at each and every action happening on the network. Because of that, a program with an ELSE part will always trigger an action, no matter how unrelated the event is compared to the devices describing its IF part.

 

The result is a high risk of infinite loop, unexpected cross-action, overload of useless Insteon messages on the network, races between different programs or between the Then part and the Else part of the same program, and even more.

 

A program should not be re-evaluated when a new event is detected and is unrelated to the criteria of the If.

 

A program should be evaluated only if :

1-Time changed and the program contains some scheduling parameters in its IF

2-The event detected (new status or control activation) is about a device listed in the IF

3-The program is not already running from a previous action

4-Any other idea you can think of for making the Else usable.

 

Without some kind of restriction, a program with an Else part is always True, making it "hyper-active" and causing more problems to solve than function to benefit.

 

Jacques

[MikeB]

Not sure I follow. The ELSE portion of a program is only run if something about the IF statement is explicitly not true.

 

For example:

 

If
       Control 'Bathroom1stMirror1' is switched Fast On
   And Control 'Bathroom1stMirror1' is not switched Fast Off

Then
       Set Scene 'Bathroom1stAll' On

Else
       Set Scene 'Bathroom1stAll' Off

 

This program will run the THEN statement if the switch is double-tapped ON (FAST ON) and only run the ELSE statement if the switch is double-tapped OFF (FAST OFF).

[JacquesB]

Hi,

 

In the example you gave, you are right because you only use controls as criteria. Controls are limited in time, thet exist only for a very brief moment.

 

When the IF part contains more than controls (status, scheduling, ...), they are run and re-run at every action.

 

Jacques

[JacquesB]

I'm debugging a case right now :

 

If "Status Dev1 is Off"

or "Status Dev2 is Off"

 

Then

Set Scene3 Off

 

 

With that, the scene 3 blinks when a scene that triggers both Dev1 and 2 on is activated. I have to replace the status with Controls as a fix.

 

Jacques

[MikeB]

Here is another example:

 

If
       From    Sunset  + 20 minutes
       To      10:00:00PM (same day)

Then
       Set Scene 'FrontDoor' On

Else
       Set Scene 'FrontDoor' Off

 

This program will run the THEN statement at 20 minutes after sunset, then the ELSE statement when the time range is no longer true (10:00:01pm).

 

At this time (10:24pm), the program is currently FALSE with a last run time of 10:00:01pm.

[MikeB]

I'm debugging a case right now :

 

If "Status Dev1 is Off"

or "Status Dev2 is Off"

 

Then

Set Scene3 Off

 

 

With that, the scene 3 blinks when a scene that triggers both Dev1 and 2 on is activated. I have to replace the status with Controls as a fix.

 

I don't quite follow. Can you post the exact code, and describe how Dev1, Dev2, Scene3, and the other scene are related? With the information you provided I'm not sure how turning Dev1 and Dev2 on would cause Scene3 to blink.

[JacquesB]

Hi,

 

the need for a usable ELSE is to reduce the number of program you need.

 

Here is my simple case :

2 lights are turned on by a scene, triggered by a KeypadLinc button.

I wish to turn this keypadlinc button On when both lights are turned On manually.

I also wish to turn that keypadlinc button off as soon as one of the light is off.

 

The instinctive program would be :

 

If Status Light1 is On AND Status Light2 is On

Then

Set KeypadLed On

Else

Set KeypadLed Off

 

Because of the small delay before both lights are turned On, the keypad led flashes few times.

Also, when these lights are turned on by the keypad itself, they are not both On before the ISY controller founds the time to detect at least one light off, so re-turns the keypad led to Off, causing more blinking.

 

The command would also be send and re-send over and over again every time a status change in the network, despite it is about light 4 or 6.

 

That's the kind of thing a non hyper-active Else would fixes.

 

Thanks for your reply,

 

Jacques

[MikeB]

This is what I would do in this scenario.

 

- Create a scene called, say, "Scene" that contains Light1, Light2, and Keypad1 with Keypad1 as a controller. This allows the Keypad1 button to turn on both lights.

 

- Create a scene called, say, "SceneStatus" that contains the Keypad1 button so you can control from within programs (assuming it's a secondary button).

 

- Create a program:

If
       Status  'Light1' is On
   And Status  'Light2' is On
   And Status  'Keypad1 is not On

Then
       Set 'SceneStatus' On

Else
  - No Actions - (To add one, press 'Action')

 

This will turn your Keypad1 on if both lights were turned on manually.

 

- To turn the status light off, I would do the following:

If
     (
       Status  'Light1' is not On
   Or Status  'Light2' is not On
      )
   And Status  'Keypad1 is not Off

Then
       Set 'SceneStatus' Off

Else
  - No Actions - (To add one, press 'Action')

 

This would turn your Keypad1 off if either one of the lights is manually turned off.

 

It MIGHT be necessary to add a WAIT 1 SECOND to the front of the THEN statement, but I don't believe it will be.

 

I agree that the ELSE section is not useful in this case.

[JacquesB]

Hi,

 

thanks for your suggestion. I'm doing almost what you suggest as a workaround.

 

My "Turn Off" program is true when any of the light is switched off. That may try to turn off a keypad led that could be already off. I will add the Led check as you suggest it.

 

The wait could in fact be another solution because when a program is re-run before being done, it is stopped. That would also prevent the flashing scene problem.

 

To add WAIT is a way to manage races between programs by ensuring who will win the race. Still, it would be better to not have a race at all, so to found a better way for the evaluation of an IF / ELSE program.

 

Thanks for your reply,

 

Jacques