how come this program runs?

[johnnyt]

I don't quite get the "control not switched off" logic when I use it as part of multiple conditions. I assumed (wished) it would trump everything but it doesn't.

 

Here's a program that I don't want to run true if I switch the garage light off but it runs true anyway. Both "program" variables are True when this happens, so the program certainly does what it's supposed to when I don't touch the garage light, which is to turn the garage light on when it's night time and the outside garage door opens (is open).

 

If

Status 'Main Floor / Garage Light' is not On

And Control 'Main Floor / Garage Light' is not switched Off

And Control 'Main Floor / Garage Light' is not switched Fast Off

And Program 'Nightime Flag' is True

And Program 'Garage Door Outside Open Flag' is True

 

Then

Set 'Main Floor / Garage Light' On

 

Else

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

 

 

 

To do what I want in other scenarios I've found myself having to write several programs with the one for the "control not switched off" disabling the one that runs the command then have another program run later to re-enable it. The problem with that has been all the fiddling needed to cover all the conditions needed for re-enabling the program.

 

Am assuming there's a clean one-program way to do this and that seeing it will provide me insight into the way things are evaluated when there's a "control is not switched off".

 

Any advice would be appreciated.

[oberkc]

Here's a program that I don't want to run true if I switch the garage light off but it runs true anyway.

 

In other words, you want the program to evaluate as false ("don't want to run true") if you switch the garage light off?

 

Status 'Main Floor / Garage Light' is not On 

 

This particular condition will be TRUE if you switch the garage light off. (This is not a dimmer, is it? Only two conditions: on and off?) This sounds to me exaclty the opposite of what you want. If you want a condition that will be false when you switch the garage light off, try:

 

Status 'Main Floor / Garage Light' is not off

 

To do what I want

Am assuming there's a clean one-program way to do this

 

I apologize, but besides "I don't want to run true if I switch the garage light off , I don't see where you describe what it is that you want your program to do.

[apostolakisl]

What firmware are you running? 3.1.16 fixed some issues with the combo of status/control combos on the same switch that could have easily caused your probs.

[bmercier]

It's not a good idea to combine status and control conditions in the same program.

 

I have played with this a lot, just to find out that control and status generates 2 different events if they relate to the same device.

 

You first get an event for the control, the if is evaluated and the program runs accordingly. Then, the status change, cancels the program and retriggers the evaluation. The status is always the second event (no matter if it's a on, Fast on, etc), and the controls always evaluate to false, because the event is the status change.

 

Perhaps this behavior has changed in recent firmwares, as apostolakisl suggest, but this was like that not so long ago.

 

So for my own needs, I wanted to have different behavior for a Fast On, and a "normal" On (no matter how it was turned on). So I used a program triggered on a Fast On that sets a variable. Then, from a status change I can also check the variable, so I know it comes from the Fast On, or not.

 

Benoit.

[bmercier]

Hi Johnny,

 

I woulld also add that it's better to avoid disabling/enabling programs within programs, especially if they are to run frequently. Each time, this writes to the nvram in the ISY. It would be better to catch it with variables, as this stays in memory, and does not write to nvram (unless you also change the init value).

 

Benoit.

[apostolakisl]

It's not a good idea to combine status and control conditions in the same program.

 

I have played with this a lot, just to find out that control and status generates 2 different events if they relate to the same device.

 

You first get an event for the control, the if is evaluated and the program runs accordingly. Then, the status change, cancels the program and retriggers the evaluation. The status is always the second event (no matter if it's a on, Fast on, etc), and the controls always evaluate to false, because the event is the status change.

 

Perhaps this behavior has changed in recent firmwares, as apostolakisl suggest, but this was like that not so long ago.

 

So for my own needs, I wanted to have different behavior for a Fast On, and a "normal" On (no matter how it was turned on). So I used a program triggered on a Fast On that sets a variable. Then, from a status change I can also check the variable, so I know it comes from the Fast On, or not.

 

Benoit.

 

This isn't really true. ISY does know how to properly execute programs where control and status refrencing the same switch co-exist. However, there were quite a number of firmware versions that status/control didn't behave properly. This was a result of homes where the communication was one step below perfect. The problem was that if the switch didn't get an ack from the plm, it resent the message causing a faulty running of the program when the PLM thought someone pushed the button again. See this for a more detailed description. viewtopic.php?f=27&t=7622

 

For example, I have lots of programs like this:

If
       Status  'Alexis Room / Alexis Bath-Cans L' is Off
   And Control 'Alexis Room / Alexis Bath-Cans L' is switched Off

Then
       Set 'Alexis Room / Alexis Bath-Cans L' 25%

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

 

They have all been running perfectly since firmware 3.1.16. Starting in either the last 2. versions or first 3. version these programs started misbehaving. They would turn the light on to 25% virtually every time you turned the light off.

[johnnyt]

Thanks for the replies.

 

A couple of clarifications:

 

1. am running firmware 3.1.17

 

2. I want this program (and others just like this one) to automatically turn a light on if it's off (garage light in this case) when something is true (in this case when either of my two outside garage doors are open at night) except if I manually turn the light off (Off or Fast Off).

 

Benoit, you bring up a great separate conversation I'd like to have about saving (or not) to nvram. Have read a couple of posts now about avoiding that where one can and I'd like to hear more about that because I do a lot of writing to nvram and have recently encountered speed problems that were (in part) do to the SD card after only a little over one year of use. I'll start a new thread at some point for that, unless someone knows of one (I haven't done any searching for that yet.)

[oberkc]

I want this program (and others just like this one) to automatically turn a light on if it's off (garage light in this case) when something is true (in this case when either of my two outside garage doors are open at night) except if I manually turn the light off (Off or Fast Off).

 

This is not a trivial set of criteria. So the plain-english condition would be something like:

 

if

either of my two garage doors are opened

and garage light is off

and garage light was not turned off manually

then

turn the garage light off

 

I cannot help but suspect I am misunderstanding something.

[johnnyt]

The then above should read "turn garage light on"

 

The "2 garage doors open" is really just a check of a program variable "false=open"

 

 

Sent from my iPod touch using Tapatalk

[johnnyt]

Oops. I meant "true=open"

 

 

Sent from my iPod touch using Tapatalk

[oberkc]

The then above should read "turn garage light on"

 

I stand corrected. Brain dead.

 

So you have a variable to indicate one, or both, doors are opened. That should work. You may need to create a second variable (I will call it IGarageLight) to track how your garage lights are last turned off and create a program to track. The logic would be something like:

 

if
(
control garage light is set off
or control garage light is set fast off
)  
and status garage light is not on
then
Set IGarageLight = 1 <<< indicating light was last turned off manually
else
set IGarageLight = 0 <<< indicating light is either on or turned off other than manually

 

Your main program would then look something like:

 

if
Status Program = "true" <<<IGarageLight = 0 <<< not last turned off manually
then
Set garage light on

 

This is all theoretical an untested, but I hope it gives you enough ideas to move forward.

[johnnyt]

Setting a variable does seem like a cleaner/better idea than disabling the program and re-enabling it later but I end up in the same boat as before. I still need to reset the variable to 0 at an appropriate time later, with "appropriate" being several conditions, including time period, status change like nighttime variable change and "switched on or switched fast on", perhaps others. Since it isn't clear to me anymore if/when I can include "control" and "status" in the same program, this will just add one more program.

 

Does the order of the execution matter with conditions, i.e. does it make a difference if I put "control" conditions first or last?

 

Could this be because my insteon network is less than ideal but not bad enough that things aren't visibly not working for me so I don't realize it?

[apostolakisl]

I have a situation that I control as follows. It is essentially identical to yours, however I also have a included a shut off timer. The timer can be interupted by pushing the "on" paddle (or off paddle), this is what the "if" clause is for in program 3 and why I put the timer in the "else" clause. . so it could be interupted.

 

If
       Elk Zone 'Gar Overhead Lou' is Violated
    Or Elk Zone 'Gar Overhead Ell' is Violated

Then
       Run Program 'Garage Lights 2' (If)

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





****GARAGE LIGHTS 2***** **THIS IS DISABLED***
If
       Status  'Garage / Garage-Floures L' is not On
   And Program 'Dark Outside' is True

Then
       Run Program 'Garage Lights 3' (Else Path)

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





*****GARAGE LIGHTS 3*****
If
       Control 'Garage / Garage-Floures L' is switched On
    Or Control 'Garage / Garage-Floures L' is not switched On

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

Else
       Set 'Garage / Garage-Floures L' On
       Wait  10 minutes 
       Set 'Garage / Garage-Floures L' 250 (Beep Duration)
       Wait  30 seconds
       Set 'Garage / Garage-Floures L' Off

 

Program 1 and 2 are separated because I didn't want the light to turn on if the door was open and then it became dark outside. I wanted the only trigger for this program to be the opening of the garage door.

[oberkc]

Does the order of the execution matter with conditions, i.e. does it make a difference if I put "control" conditions first or last?

 

I don't believe so, just as long as you pay attention to the priority between "and" and "or", putting parentheses in the appropriate places.

 

with "appropriate" being several conditions, including time period, status change like nighttime variable change and "switched on or switched fast on", perhaps others

 

Yup. You have some interesting conditions.

 

Since it isn't clear to me anymore if/when I can include "control" and "status" in the same program

 

I do, without observed problems. Apparently, my experience is different than bmercier, however.

 

Could this be because my insteon network is less than ideal but not bad enough that things aren't visibly not working for me so I don't realize it?

 

Possibly, but the use of scene tests, event viewers, and program status can often help figure things out. It is not always easy and sometimes frustrating.

 

It sounds as if you have a lot more requirements in you head than I have attempted to address in the suggested programs. I apologize, but I also continue to be unclear about what your progam is, or is not, doing that is should not, or should, do to be able to offer more concrete suggestions.

[apostolakisl]

I believe the reason your original program doesn't work is as follows.

 

ISY evaluates everything in an if clause simultaneously. When the program triggers it looks at all the conditions at that moment as a single block.

 

So, lets say it is night, the light is on, and you switch it off.

 

If

Status 'Main Floor / Garage Light' is not On <<<< this is false,

And Control 'Main Floor / Garage Light' is not switched Off <<<<

And Control 'Main Floor / Garage Light' is not switched Fast Off <<<

And Program 'Nightime Flag' is True <<<<

And Program 'Garage Door Outside Open Flag' is True <<<<

 

Probram evaluates false, else clause is empty, so program does nothing, however light turns off because you pushed "off" at the switch

 

However, ISY then receives a status change from the light to "off"

If

Status 'Main Floor / Garage Light' is not On <<

And Control 'Main Floor / Garage Light' is not switched Off <<<<<

And Control 'Main Floor / Garage Light' is not switched Fast Off <<<<

And Program 'Nightime Flag' is True <<<<

And Program 'Garage Door Outside Open Flag' is True <<<<

 

All conditions are TRUE and the program triggered. The light is thus set to "on"

 

 

Take this program

If
       Status  'Alexis Room / Alexis BR-Overhead L' is Off
   And Control 'Alexis Room / Alexis BR-Overhead L' is switched Off

Then
       Set 'Alexis Room / Alexis BR-Overhead L' 25%

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

 

It runs true when the light is off and you switch it off. But, a split second later it changes to false. The Else clause is empty, so it doesn't matter. But it switched to false because the light status changed to "25%" when it executed its own then clause. The initial act of turning the light "off" when "off" and then the light status comming on to 25% are two different events and thus the program runs twice. In this case, it simply doesnt matter that it ran the second time. In your case, it does.

[bmercier]

This isn't really true. ISY does know how to properly execute programs where control and status refrencing the same switch co-exist. However, there were quite a number of firmware versions that status/control didn't behave properly. This was a result of homes where the communication was one step below perfect. The problem was that if the switch didn't get an ack from the plm, it resent the message causing a faulty running of the program when the PLM thought someone pushed the button again. See this for a more detailed description. viewtopic.php?f=27&t=7622

 

That makes sense. I was running below 3.1.16 when I tested that. So maybe it works better now.

 

I wanted to test it again at 3.1.16 last night, but my ISY is not working well at the moment

See my previous post on my issue: viewtopic.php?f=27&t=7928

 

Thanks for correcting me.

 

Benoit.

[bmercier]

This isn't really true. ISY does know how to properly execute programs where control and status refrencing the same switch co-exist. However, there were quite a number of firmware versions that status/control didn't behave properly. This was a result of homes where the communication was one step below perfect. The problem was that if the switch didn't get an ack from the plm, it resent the message causing a faulty running of the program when the PLM thought someone pushed the button again. See this for a more detailed description. viewtopic.php?f=27&t=7622

 

Now that my ISY is back to work, I just upgraded the firmware to 3.1.17 and was anxious to test this.

 

My conclusion is that it still generates two events. In the following program, the counter is increased by 2 each time the light is turned on:

 

If
       Status  'Etage / Salle de bain' is On
    Or Control 'Etage / Salle de bain' is switched On

Then
       $TestCounter += 1

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

 

And the control is always the first event.

 

Sometimes, it may be desirable to combine control and status of the same device, if you AND a control and status from the same device, the program will run only once, and this will be during the control. When the status event occurs, it will run the else, because the control will always be false on that event.

 

Also, during the control event, the evaluation occurs with the status PRIOR to the switch being pressed, not the new status (if that happens to actually change the status).

 

Benoit.

[apostolakisl]

This isn't really true. ISY does know how to properly execute programs where control and status refrencing the same switch co-exist. However, there were quite a number of firmware versions that status/control didn't behave properly. This was a result of homes where the communication was one step below perfect. The problem was that if the switch didn't get an ack from the plm, it resent the message causing a faulty running of the program when the PLM thought someone pushed the button again. See this for a more detailed description. viewtopic.php?f=27&t=7622

 

Now that my ISY is back to work, I just upgraded the firmware to 3.1.17 and was anxious to test this.

 

My conclusion is that it still generates two events. In the following program, the counter is increased by 2 each time the light is turned on:

 

If
       Status  'Etage / Salle de bain' is On
    Or Control 'Etage / Salle de bain' is switched On

Then
       $TestCounter += 1

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

 

And the control is always the first event.

 

Sometimes, it may be desirable to combine control and status of the same device, if you AND a control and status from the same device, the program will run only once, and this will be during the control. When the status event occurs, it will run the else, because the control will always be false on that event.

 

Also, during the control event, the evaluation occurs with the status PRIOR to the switch being pressed, not the new status (if that happens to actually change the status).

 

Benoit.

 

 

Yes, it is supposed to run twice, depending on the situation and how you wrote it, it will run the "then" twice, the "else" twice, or one of each, or it could run just once. Remember, "status" is a trigger when the status changes. If the program runs and that causes the status to change, the program will run a second time. Programs do not ignore the consequences of their own action (or the conseqeunces of actually hitting the on/off switch). When a program triggers, the entire "if" clause is evaluated at that instant in time, then, it is open to be evaluated again. It does not ignore the consequences of it's own "then" and "else" clauses or the consequences of pushing the switch paddle.

 

This isn't a malfunction or bad logic. It is the correct logic. You just have to understand it so you can use it to your benefit.

[johnnyt]

Thanks for the great insights.

 

 

Sent from my iPod touch using Tapatalk

[bmercier]

Yes, it is supposed to run twice, depending on the situation and how you wrote it, it will run the "then" twice, the "else" twice, or one of each, or it could run just once. Remember, "status" is a trigger when the status changes. If the program runs and that causes the status to change, the program will run a second time. Programs do not ignore the consequences of their own action. When a program triggers, the entire "if" clause is evaluated at that instant in time, then, it is open to be evaluated again. It does not ignore the consequences of it's own "then" and "else" clauses.

 

This isn't a malfunction or bad logic. It is the correct logic. You just have to understand it so you can use it to your benefit.

 

Ok, so we are saying the same thing then. I though you meant it ran only once.

 

Thanks,

 

Benoit.