Control 'is not' question

[bsobel]

I had a program that triggered on a keypad button being turned on. That button activated a bunch of items that are turned off for power/security reasons when I am not at the guest house. Recently I had a friend visit and realized his attempt to turn the button 'on' was read a 'bright' (guess he held the button too long). So I change my logic from 'if control KEYPAD.E is ON' to 'if control KEYPAD.E is not off'

 

I thought this would trigger on any physical interaction with the button other than off. But instead I found the program began running in a tight loop. The behavior seemed like the 'control is not' was acting like a 'status is not'. Can anyone else confirm if this is the correct behavior?

 

Thanks,

Bill

[LeeG]

If Control triggers the Program only on the specific command defined in the If. The

 

If Control 'xxxx' is not switched Off

 

triggers the Program when an Off command is received. Because of the "not" the If is False and drives the Else clause.

 

Add the Bright command with an additional If statement Or’ed with the If Control …. On

 

If
       Control 'ICON Dimmer 1' is switched On
   And Control 'ICON Dimmer 1' is not switched Off

Then
       Set 'ICON Relay 1' On

Else
       Set 'ICON Relay 1' Off

[bsobel]

Lee that behavior first off makes no sense and second off is clearly not what I am seeing. The then clause of my if was being invoked in a tight loop...

[TJF1960]

Hello bsobel,

Can you paste your program.

[LeeG]

Okay. Suggest posting the Program with the type of button activity that result in the loop.

[LeeG]

Try this example

 

If
       Control 'ICON Dimmer 1' is not switched Off

Then
       Set 'ICON Relay 1' On

Else
       Set 'ICON Relay 1' Off

 

Press the device On paddle/button, the Programs | Summary will show the Last Run Time does not change. With If Control the command received has to match the command specified in the If for the Program to be triggered. Now press the device Off paddle/button. The Last Run Time will be updated and the Status will be False indicating the Else clause ran.

[bsobel]

Sorry guys, was in Israel and India. Back home. I'll dig out the code when I'm next at that house and post it.

 

That said, LeeG with the example you posted I'm hardpressed to see how you don't consider the behavior a bug. The If should evaluate a condition to true. You may have documented how it's currently working, but I have a strong suspicion that is not what was intended as the flow doesn't make sense in context of the overall programming language. The correct behavior is to trigger the then clause on any control event which is not the type specified. I seem to seeing an additional bug that the statement evaluates as a status vs a control in some cases...

[apostolakisl]

If Control triggers the Program only on the specific command defined in the If. The

 

If Control 'xxxx' is not switched Off

 

triggers the Program when an Off command is received. Because of the "not" the If is False and drives the Else clause.

 

Add the Bright command with an additional If statement Or’ed with the If Control …. On

 

If
       Control 'ICON Dimmer 1' is switched On
   And Control 'ICON Dimmer 1' is not switched Off

Then
       Set 'ICON Relay 1' On

Else
       Set 'ICON Relay 1' Off

 

Lee's above program will run true when you click "on" on the icon dimmer, and false when you click the "off" side of the dimmer. It can not create a loop.

 

The design of this program has 2 triggers (clicking "on" or clicking "off" on the referenced dimmer). No other action will cause the program to run (natively).

 

"On" click triggers the first line. . . it is true. The second line also evaluate as true because indeed clicking on "is not" clicking off.

"Off" click triggers the second line. .. it is false. The first line is also false because indeed clicking "off" is not "is" clicking on.

 

A note: Using the terminology "clicking" instead of "control" might help you. It really drives home the point that you have to actually push the switch and make it "click". No other action besides actually pushing (clicking) the switch triggers a "control" condition.

[bsobel]

Here is the actual program:

 

 

If

Control 'Living Room Keypad E' is switched On

Or Control 'Living Room Keypad E' is switched Fast On

Or Control 'Living Room Keypad E' is switched Bright

Or Control 'Living Room Keypad E' is switched Dim

Or Control 'Breakfast Entry Right.E' is switched On

Or Control 'Breakfast Entry Right.E' is switched Fast On

Or Control 'Breakfast Entry Right.E' is switched Bright

Or Control 'Breakfast Entry Right.E' is switched Dim

Or (

$Owner_At_Home > 0

And From 6:00:00PM

To 6:00:00AM (next day)

And (

Control 'Guest Room Motion-Sensor' is switched On

Or Control 'Master Closet Motion-Sensor' is switched On

Or Control 'Master Main Lights' is switched On

Or Control 'Guest Room Main Lights' is switched On

Or Control 'Kitchen Keypad.1' is switched On

Or Control 'TV Room Sconces' is switched On

)

)

 

Then

$Owner_At_Home += $Default_Occupancy_Time_In_Hours

 

Else

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

 

 

If I change:

 

Control 'Living Room Keypad E' is switched On

Or Control 'Living Room Keypad E' is switched Fast On

Or Control 'Living Room Keypad E' is switched Bright

Or Control 'Living Room Keypad E' is switched Dim

Or Control 'Breakfast Entry Right.E' is switched On

Or Control 'Breakfast Entry Right.E' is switched Fast On

Or Control 'Breakfast Entry Right.E' is switched Bright

Or Control 'Breakfast Entry Right.E' is switched Dim

 

to

 

Control 'Living Room Keypad E' is NOT switched Off

Or Control 'Breakfast Entry Right.E' is NOT switched Off

 

The 'then' clause runs in a very tight loop. No user is 'clicking' (I fully understand control versus status btw) the switches for this tight loop to occur. It is if the evaluation is occurring as a status evaluation. My gut still says this is a bug. I know the system pretty well (I think) and am not seeing why that change would evaluate to a true everytime. I realize that $Owner_At_home is a state variable so when it gets added to the evaluation occurs again. But the evaluation should be false on the second run (since there is no active control events at the time).

[bsobel]

The second line also evaluate as true because indeed clicking on "is not" clicking off.

 

That appears in complete opposite to what LeeG stated "Press the device On paddle/button, the Programs | Summary will show the Last Run Time does not change. With If Control the command received has to match the command specified in the If for the Program to be triggered."

 

I agree your reading *should* be how it works...

 

Bill

[LeeG]

Open a Ticket with UDI Tech Support. Describe how it is working, how you think it should be working. They will either fix it or characterize it as normal.

 

EDIT: the conditions that trigger a Program (cause it to Run) are separate from evaluating the True/False of the If section. An Integer variable value change never triggers a Program (never causes it to Run) but the compare of the Integer variable value always affects the True/False result.

 

Same with If Control, what triggers a Program is very different from what determines True/False.

 

Ask UDI directly. That is the only answer which will satisfy the question.

[apostolakisl]

The second line also evaluate as true because indeed clicking on "is not" clicking off.

 

That appears in complete opposite to what LeeG stated "Press the device On paddle/button, the Programs | Summary will show the Last Run Time does not change. With If Control the command received has to match the command specified in the If for the Program to be triggered." This is because Lee was referring to a different program that only contained a "switch off" command

 

I agree your reading *should* be how it works...

 

Bill

 

Just to be 100% certain I ran that program last night and it worked as expected.

 

In other words,

click "on" and the program runs true

click "off" and the program runs false

any other action on the switch does nothing (ramp up/down fast on/off etc).

 

 

 

 

edit. . . I just read your program. The loop is from the variable. You are probably using a state variable which is triggering the program. Try an integer variable

 

 

 

 

 

 

 

 

 

 

 

EDIT

[oberkc]

I have lost track of what your program is doing/not doing that you don't/want it to do, but it appears to me that LeeGs point is insightful: there does appear to be some confusion about triggers versus evaluations.

 

In case this helps:

 

Or Control 'Living Room Keypad E' is switched Fast On

 

Will act as a trigger only upon reciept of a "fast on". Will evaluate as true when triggered. Evaluates false if program evaluation is triggered by another condtion.

 

As opposed to:

 

Control 'Living Room Keypad E' is NOT switched Off

 

Will act as a trigger only upon recipet of an "off" command. Will evaluate as FALSE when triggered. Evaluates as TRUE if program evaluation is triggered by another condition.

[bsobel]

Control 'Living Room Keypad E' is NOT switched Off

Will act as a trigger only upon recipet of an "off" command. Will evaluate as FALSE when triggered. Evaluates as TRUE if program evaluation is triggered by another condition.

 

This (finally) explains the behavior but as a developer I still feel strongly this is a bug. Logical statements should not evaluate to 'FALSE' when the evaluation succeeds. That is bug #1 however if you accept that is how UDI did this (a bit backwards from about any other system I can think of) then bug #2 is that the statement evaluates as TRUE in any case when triggered by another condition (an If Control should only evaluate to TRUE if the controlled item was activated)

 

I realize both aren't bugs (one negates the existence of the other) but do you 3 really think this is 'intended' behavior?

[LeeG]

I believe it has been this way for the nearly 4 years I have been using an ISY. It may not be logical to someone with a programming background (which I have) but it serves a purpose. This will not be the only aspect of ISY programming that may look unusual but they all serve a purpose in an event driven environment.

[apostolakisl]

Control 'Living Room Keypad E' is NOT switched Off

Will act as a trigger only upon recipet of an "off" command. Will evaluate as FALSE when triggered. Evaluates as TRUE if program evaluation is triggered by another condition.

 

This (finally) explains the behavior but as a developer I still feel strongly this is a bug. Logical statements should not evaluate to 'FALSE' when the evaluation succeeds. That is bug #1 however if you accept that is how UDI did this (a bit backwards from about any other system I can think of) then bug #2 is that the statement evaluates as TRUE in any case when triggered by another condition (an If Control should only evaluate to TRUE if the controlled item was activated)

 

I realize both aren't bugs (one negates the existence of the other) but do you 3 really think this is 'intended' behavior?

 

Yes, ISY is event driven. "If" statements are affected by any event regardless of how it came to happen (that includes its own then/else clauses).

 

Your first program ran true, the variable changed, this triggered the program "if" again, this time it ran false and ended. This all happened in microseconds.

Your second program ran true, the variable changed, this triggered the program "if" again, it ran true again (because "is not" was true and included as an "or") which kept looping back.

 

If you just switch to an integer variable this won't happen since integer variables are never a program trigger. They do evaluate when something else triggers the "if" clause, but they don't cause the evaluation.

 

If you need that same variable to act as a trigger somewhere else, you can have both a state variable and integer one representing the same thing and set both at the same time, but only use the integer variable in your "if" clause of this program.

 

Note: When you name variables, include an "s" or "i" in the name for ease of differentiating. ie $sDefault_Occupancy_Time_In_Hours or $iDefault_Occupancy_Time_In_Hours

[oberkc]

but do you 3 really think this is 'intended' behavior?

 

I don't know. However, if you want something that triggers from on an "off" command AND evaluates as true when thus triggered, one can use:

 

if control .... is switched off.

 

In my mind, this is the opposite of the "if not switched off" construct, so both options are covered.

[bsobel]

I understand that I can detect a straight off case. This started as I wanted to test for all the non-off cases (bright, dim, on, fast on, etc)... In the end if control x not off is really a if not control x off for logic purposes. I still argue it's wrong (very given the rest of the programming model) but will work around it like everyone else.

 

As to variable naming, you can name them as you wish. That is a personal style choice. I disagree in this case, but understand some people prefer to decorate them as such.

 

Bill

[oberkc]

It sounds like this one is solved, then. I am glad you got it working.