Jump to content

Programs acting differently and inconsistency


simplextech

Recommended Posts

Riddle me this.....

The below program works and honors the time designation of From/To with the EXCEPTION of oc.Garage.Ext.Door-Opened.  I can open any of the other two doors and the lights do NOT come on.  This is the intention.  However if I open the Garage Ext door the lights come on?

Garage.Lights-On - [ID 000A][Parent 0001]

If
        'CL Bedroom / oc.CL-Bedroom.Int.Door-Opened' is switched On
     Or 'Garage / oc.Garage.Ext.Door-Opened' is switched On
     Or 'Laundry Room / oc.Laundry.Door-Opened-Opened' is switched On
    And (
             From    Sunset  -  1 hour 
             To      Sunrise (next day)
        )
 
Then
        Set 'Garage / sc.Garage.Lights' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Now this one:

This one is similar with the difference of two doors.  The garage exterior door is in this list as well.  This program completely ignores the From/To time designation and turns on.

Deck.Lights-On - [ID 0002][Parent 0001]

If
        'Living Room / oc.LVR.Door-Opened-Opened' is switched On
     Or 'Dining Room / oc.Dining-Room.Door-Opened' is switched On
     Or 'Garage / oc.Garage.Ext.Door-Opened' is switched On
    And (
             From    Sunset  -  1 hour 
             To      Sunrise (next day)
        )
 
Then
        Set 'Deck / sc.Deck.Lights' On
 
Else
   - No Actions - (To add one, press 'Action')
 

Questions:

  • Why is the time designation ignored in the first program for the Garage Ext Door?
  • Why is the second program completely ignoring the time designation?
  • Am I not understanding the time rules with ISY?
Link to comment

The ifs are kind of a stack.. first condition checked first, then second,...  In this case, I would start with the time conditions at the top of both programs so the programs do nothing at all most of the day because the programs will stop thinking once they validate time. I follow that method.

There's a number of ISY-isms that you'll need to learn and adapt to the way it works.  It will be more productive to focus on what it is, then trying to find out all of the things its not

Paul

Link to comment
8 minutes ago, paulbates said:

The ifs are kind of a stack.. first condition checked first, then second,...  In this case, I would start with the time conditions at the top of both programs so the programs do nothing at all most of the day because the programs will stop thinking once they validate time. I follow that method.

There's a number of ISY-isms that you'll need to learn and adapt to the way it works.  It will be more productive to focus on what it is, then trying to find out all of the things its not

Paul

I agree there are the 'isms to learn.  But why do the same program act differently?

BTW I did and normally do start with the time restrictions as the first item and it was not working as expected so I thought maybe change the trigger order... but none the less why do two programs of the basic same structure behave differently?

Link to comment
1 hour ago, simplextech said:

I agree there are the 'isms to learn.  But why do the same program act differently?

BTW I did and normally do start with the time restrictions as the first item and it was not working as expected so I thought maybe change the trigger order... but none the less why do two programs of the basic same structure behave differently?

I've seen the same behavior on 5.0.14 myself. I've figured out ways to program around it but I haven't figured out the why either

Link to comment

For what it is worth, I expect both programs to honor the time condition ONLY in conjunction with the last OR condition.  The first two conditions should without any time constraint.  If either of the first two conditions are true, in either of the two programs, your program will run the THEN clause.  If you find yours doing anything different than this, I would be extremely surprised.  This is standard Boolean logic.

Parentheses around the cluster of OR conditions is the solution.

Link to comment
32 minutes ago, oberkc said:

For what it is worth, I expect both programs to honor the time condition ONLY in conjunction with the last OR condition.  The first two conditions should without any time constraint.  If either of the first two conditions are true, in either of the two programs, your program will run the THEN clause.  If you find yours doing anything different than this, I would be extremely surprised.  This is standard Boolean logic.

Parentheses around the cluster of OR conditions is the solution.

That's a great point, I totally missed that. Its working as designed without the first three lines being encapuslated in an "and"

Link to comment
34 minutes ago, oberkc said:

For what it is worth, I expect both programs to honor the time condition ONLY in conjunction with the last OR condition.  The first two conditions should without any time constraint.  If either of the first two conditions are true, in either of the two programs, your program will run the THEN clause.  If you find yours doing anything different than this, I would be extremely surprised.  This is standard Boolean logic.

Parentheses around the cluster of OR conditions is the solution.

The two programs that were posted acted very differently.  I did modify them to have the time restriction as the very first item and then put the multiple OR statements inside an AND block and so far both are behaving correctly. The 'ism's...

Link to comment

Its hard to diagnose / fix something that everyone agrees is broken... what difference does it make why a broken program isn't consistent? Try putting parenthesis around the first 3 if rows as oberkc recommended for both programs and test again

 

Link to comment
10 minutes ago, simplextech said:

The two programs that were posted acted very differently.  I did modify them to have the time restriction as the very first item and then put the multiple OR statements inside an AND block and so far both are behaving correctly. The 'ism's...

Glad the parens worked.  The behavior you originally described is still disturbing.

Link to comment
7 minutes ago, palayman said:

Glad the parens worked.  The behavior you originally described is still disturbing.

I agree that it is weird.  Some of this is my learning curve with the ISY and unique properties but some of it is boggling that it works for one program but not an almost identical one.  The only solid thing I could say could be the problem was the structure/order without the parens for the AND with the group of OR statements and that was causing it to register true on a single door within the logic flow.  This is probably what it was and is one of those 'ism's of the hard coded nature of the language used in the programs.  I'm going to start a new thread to discuss "Time" that's a favorite and fun one that I see asked for every system and is a common HS thread :)

 

Link to comment
7 minutes ago, simplextech said:

This is probably what it was and is one of those 'ism's

Shouldn't be an "ism".  Should have behaved as oberkc described in detail.  Order of operations should have "AND" take precedence over "OR" without exception.

Link to comment
14 minutes ago, palayman said:

Shouldn't be an "ism".  Should have behaved as oberkc described in detail.  Order of operations should have "AND" take precedence over "OR" without exception.

Yep, you and oberkc were right, its not an ism

Link to comment

Thank you all. And, that's correct, there are two things at play here:

1. Order of precedence (And before Or just like * and /  is before + and -)
2. Short circuit which increases evaluation performance: if you have a condition with And, and based on 1, if the And is false, then the rest is NOT even evaluated

With kind regards,
Michel

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...