IR Press running both then and else???

[wpmjones]

Hey all -

 

I'm just going to post my program and the log. Weirdest thing, but best I can tell, it's running the THEN statement and then the ELSE statement. The light starts to fade on, then instantly shuts off. (Light only reaches about 4-5%)

 

Any thoughts?

 

If
IR 'IR_001' is Pressed
  AND	Status 'Portrait Light' is Off

Then
Set 'Portrait Light' On

Else
Set 'Portrait Light' Off

 

 

 

Sat 09/11/2010 06:36:56 PM : [ IR] 0001 Press

 

 

Sat 09/11/2010 06:36:56 PM : [iNST-ACK ] 02 62 15.2B.DB 0F 11 FF 06 LTONRR (FF)

 

 

Sat 09/11/2010 06:36:56 PM : [iNST-SRX ] 02 50 15.2B.DB 13.27.18 2B 11 FF LTONRR (FF)

 

 

Sat 09/11/2010 06:36:56 PM : [standard-Direct Ack][15.2B.DB-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

 

Sat 09/11/2010 06:36:56 PM : [ 15 2B DB 1] ST 255

 

 

Sat 09/11/2010 06:36:57 PM : [iNST-ACK ] 02 62 15.2B.DB 0F 13 00 06 LTOFFRR(00)

 

 

Sat 09/11/2010 06:36:57 PM : [iNST-SRX ] 02 50 15.2B.DB 13.27.18 2B 13 00 LTOFFRR(00)

 

 

Sat 09/11/2010 06:36:57 PM : [standard-Direct Ack][15.2B.DB-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

 

Sat 09/11/2010 06:36:57 PM : [ 15 2B DB 1] ST 0

 

 

Sat 09/11/2010 06:36:57 PM : [iNST-ACK ] 02 62 15.2B.DB 0F 13 00 06 LTOFFRR(00)

 

 

Sat 09/11/2010 06:36:57 PM : [iNST-ACK ] 02 62 15.2B.DB 0F 13 00 06 LTOFFRR(00): Process ACK: duplicate ignored

 

 

Sat 09/11/2010 06:36:58 PM : [iNST-SRX ] 02 50 15.2B.DB 13.27.18 2B 13 00 LTOFFRR(00)

 

 

Sat 09/11/2010 06:36:58 PM : [standard-Direct Ack][15.2B.DB-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

 

Sat 09/11/2010 06:36:58 PM : Duplicate: ignored

Sat 09/11/2010 06:36:58 PM : [iNST-SRX ] 02 50 15.2B.DB 13.27.18 2B 13 00 LTOFFRR(00): Process Message: failed

 

 

Sat 09/11/2010 06:36:58 PM : [standard-Direct Ack][15.2B.DB-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

[Sub-Routine]

Hi wpmjones,

 

Just separate that into two programs with nothing in the Else actions.

 

What's happening is that as soon as the light starts to turn On the Condition turns False and the Else action is executed.

 

Rand

[wpmjones]

I can do that, but it seems a little counter-intuitive. In my understanding...

 

IF button pressed and light off

THEN light turns on

Done, over, no further action or evaluation should be done.

 

How come it re-evaluates after performing the THEN statement?

[Sub-Routine]

How come it re-evaluates after performing the THEN statement?

 

Depending on the Press Delay the ISY probably still thinks the button is pressed.

 

Rand

[wpmjones]

I guess maybe I'm not getting it then. I'm using a Logitech Harmony Remote. I've set it to the lowest possible setting on repeat commands so that it doesn't appear as a double press or an actual second press.

 

The log only shows one press. I would think if the ISY still thought the button was pressed, it would either evaluate as a hold, or at worst, a double press. But since there is neither of those nor a second entry for a press, I'm at a loss as to why it would re-evaluate after performing the THEN statement.

 

I'm just a rookie with ISY, but I have done some limited program in other languages and in all of them, if the IF statement evaluates as true, the THEN statement runs and that's it. No re-evaluation. If ISY doesn't work this way, I can accept that, I just don't understand why it's different.

 

I'm not trying to be rude or snooty. I'm just trying to understand.

[oberkc]

I don't believe this to be a problem with double-presses or fast-on or anything like that. This appears to me to be the oft-discussed issue when one's program "then" or "else" responses change one or more of the "if" conditions. I am actually a little surprised that this does not result in something like an infinite do loop.

 

I think the missing piece is a full understanding of when it is that a program evaluates the "if" condition. My understanding is that an if condition is evaluated at any change of state, or at reciept of included control input.

 

In your case, for example, your "portrait lights" are off. You press your harmony button, which sends the "IR_001" signal to the ISY. This receipt of the IR_001 signal forces an evaluation of your conditions, which is, at this point, true. As a result, your "then" statement executes.

 

Your then statement results in your "Portrait Light" turning on. Unfornately, this is one of the events which forces an evaluation of your program conditions. Now that the light is on (and the fact that there was no IR_001 signal recieved) the condition reports as false, and the "else" statement executes.

 

I suspect the better way to solve your problem is to break this into two programs.

 

If 
  IR 'IR_001' is Pressed 
  AND   Status 'Portrait Light' is Off 

Then 
  Set 'Portrait Light' On 

Else

 

If 
  IR 'IR_001' is Pressed 
  AND   Status 'Portrait Light' is On 

Then 
  Set 'Portrait Light' Off

Else

[Sub-Routine]

Here is an example when using the Else procedure works well.

 

If
       IR 'Button +' is Held
   And IR 'Button +' is not Released

Then
       Set Scene '~Family Room To Fade' Fade Up

Else
       Set Scene '~Family Room To Fade' Fade Stop

 

Rand

[wpmjones]

Yeah oberkc, that is what I did - just made two programs. I still don't understand why the IF statement is re-evaluated, but at least, now that I know, I can work around it. Just makes for a lot of programs!

 

Thank you both for your help. I have it working the way I want it to now.

[oberkc]

I still don't understand why the IF statement is re-evaluated, but at least, now that I know, I can work around it. Just makes for a lot of programs!

 

Yes, it does make for a few extra programs. It is, I believe, important to understand what happens, however, in order to become proficient on this thing. You may want to do a forum and wiki search on "status".

 

The big thing that I want to point out is in regards to your code:

 

AND   Status 'Portrait Light' is On

 

If this is one of your program conditions, your program condition will get evaluated EVERY TIME there is a change in status of "portrait light". If status changes from on to off, then this WILL get evaluated. Changing from off to on will force an evaluation. Changing from on to off (as a result of your "then" condition) is what forced the evaluation of your program conditions.

[wpmjones]

Thanks for the explanation! If I understand you correctly, then the idea is that any time the status of a device changes, ALL programs that evaluate that device's status run the IF statement. Is that correct?

 

If so, then I can understand the logic, as it would be important for those programs to kick off once the ISY knows there is a status change. It just takes a little getting used to the differences from other things I've worked with. I'll take a look at the status info on the site and see what else I can learn.

 

Thanks again!

[oberkc]

If I understand you correctly, then the idea is that any time the status of a device changes, ALL programs that evaluate that device's status run the IF statement. Is that correct?

 

I believe your statement is accurate, but let me put it another way to see that you agree we are saying the same thing:

 

All programs who's "if" condition is based on a given device will be evaluated any time the status of that device changes.

 

Understand another thing...I am an engineer. This means that I am relatively good at math. I am not good with languages, including english.

[wpmjones]

LOL - I'm a helpdesk technician turned preacher. I don't know what that says about me!!

 

But we do agree. What you said, jives with my understanding. One of the reasons that I like playing with my little ISY is because every time I figure one thing out, I have something else I want to try and make it do. I think now, it's time to revisit an old problem and see if I can figure it out.

 

Thanks again!

[Sub-Routine]

Also note that On is 100% so if you use dimmers youmay want to use Not Off in place of Is On.

[ergodic]

Note there is a straightforward to do this sort of 'toggle'-type of thing just using two simple programs:

 

The first program waits for the keypress event and calls the second program. The second program tests the state of the device and runs the Then or Else part accordingly.

 

The 'trick' is that the second program is always disabled, so the only time it gets evaluated is when the first program explicitly calls it.

 

For example:

 

Program P1:

If Button is Pressed

Then Run Program P2 (If Part)

 

Program P2: (leave permanently disabled)

If Status Device is On

Then Set Device Off

Else Set Device On

 

IOW, separate the event you are waiting for from the status you are testing into two programs. The testing program is always disabled so the ISY doesn't poke around in it whenever the status changes.

 

In this type of construction of a disabled program the "If" actually becomes more of a conventional programming-type "If", and so the Else clause can be quite useful here.

[wpmjones]

Nice solution ergodic! Thanks!