Programming Gotcha's

[rleidy]

Having just purchased an ISY earlier this year, I am still a newbie at ISY programming.  I've found that regardless of one's programming experience with more transitional languages, the ISY environment and programming can sometimes throw you for a loop.    Yesterday, I ran into an issue that took some head-scratching to figure out what was going on.  But, once I recognized the cause, it was an "Oh. duh." moment.  I share that issue below, and hope that other more experienced ISY programmers will jump in and share their own bite-sized tidbits of wisdom on ISY programming problems/solutions/workarounds/etc.

 

Here's my Gotcha:

 

I have a program to turn on some outside lights when there's motion within a range of hours when it's dark.   After 10 minutes, it turns them off.  It seemed simple enough, but yesterday I discovered that all of the lights were sill on in the middle of the day.  I'm sure the experts will spot the problem immediately.  It took me a little longer.

 Driveway Motion - [ID 000F][Parent 0010]

If
        From    Sunset 
        To      Sunrise + 30 minutes (next day)
    And Control 'Outside / Front Door Motion Sensor-Sens' is switched On
 
Then
        Run Program 'Christmas Lights' (Then Path)
        Wait  2 seconds
        Set 'Entryway KPL.1' On
        Wait  2 seconds
        Set 'Outside / Lightpost' On
        Wait  10 minutes 
        Set 'Outside / Lightpost' Off
        Wait  1 minute 
        Set 'Entryway KPL.1' Off
        Wait  1 minute 
        Run Program 'Christmas Lights' (If)
 
Else
   - No Actions - (To add one, press 'Action')

The thing that bit me was that I didn't account for all reentrancy paths.  In my case, I left for work that day less than 10 minutes prior to 'Sunrise + 30 minutes', triggering the program by my motion, and all the lights came on. While the program was in the 'Wait 10 minutes', the time went past 'Sunrise + 30 minutes' causing the program to run again, aborting the running program, and the program took the Else path, leaving all the lights ON.

 

My takeaway was that I need to consider all reentrancy paths in programs that can be interrupted (due to Wait, Repeat..)

 

To fix this, I believe all I need to do is place the contents of the Then block into a separate program (disabled) and simply call its 'Then' path from this program.  The separate program will only be reentered with continued motion that resets the 10 minutes ON timer, which is what I want. 

 

Regarding the separate 'Christmas Lights' program:  The Christmas lights are ON for a wider time range, so that's in a separate program.  Calling the 'then' path forces them ON.  Later, calling the 'If' allows them to stay On or go OFF according to that program's time range. 

 

Anyone else have some programming gotcha's to share?  

[stusviews]

There are no conditions that initiate Else. That's because the condition indicates what to occur only when the MS sends an On. To trigger the else, you'll need a statement like, "And Control 'Outside / Front Door Motion Sensor-Sens' is not  switched Off." As it stands now, Else never runs.

 

Back to the program, it should have run correctly. But, if you have a different program that controls some or all of those lights, then that may be the culprit. Post that program.

[LeeG]

Stu

 

The Else does execute as the OP indicates.  The Program is Triggered at Sunrise + 30.minutes.  Once Triggered the Program must execute either the Then or Else.  Since the If evaluation is False the Then execution is canceled because of the Waits and the Else executes.  This leaves unexecuted statements in Then.

 

 

If
From Sunset
To Sunrise + 30 minutes (next day)
And Control 'Outside / Front Door Motion Sensor-Sens' is switched On

[oberkc]

Technically, the ELSE will run twice every day...once at sunset, and the second as sunrise+30.  In addition the ELSE will run any time the motion sensor is switched ON but not between the specified times.

[Amigo]

why would the ELSE not run continuously any time that is not between the specified times?

[oberkc]

Because programs execute only when triggered. And, the conditions, themselves, are the triggers.

 

In this case there are two conditions (to..from, and control...switched on). The first condition WILL trigger only twice daily: at sunset and sunrise+30. The second condition will trigger only upon receipt of an ON command (not triggered by OFF, DIM, BRIGHT, etc). Once triggered, the entire condition WILL be evaluated.

 

Besides, there is nothing in the ELSE to run at all, let alone run continuously.

[MikeD]

Hi Amigo,

 

If

From Sunset

To Sunrise + 30 minutes (next day)

And Control 'Outside / Front Door Motion Sensor-Sens' is switched On

 

The trigger for TIME conditions are only evaluated for those two specific moments in time and not for the whole time period in between. Therefore would evaluate FALSE unless a 'Control On' is sent from the Motion Sensor at those two moments in time. -- Which would be highly unlikely to occur.

 

The trigger for the CONTROL condition is valid during the whole TIME period. A 'Control On' sent from the Motion Sensor evaluates TRUE during this period and FALSE outside this period.

 

~Mike

[oberkc]

MikeD, I would describe it a little differently. Triggers have no logical condition and triggers are not evaluated. Instead, I believe it more accurate to state that once an IF statement is triggered by one or more of the individual conditions contained therein, the ENTIRE logical condition is evaluated based on the logical state of each condition at that moment in time.

[MikeD]

Hi obertec,

 

I guess it is just how you look at it. True that as you stated 'triggers' themselves have no logical condition. I mentioned the 'trigger' as an evaluation for the TIME and CONTROL condition. Thus running the THEN or ELSE clause as appropriate.

 

I was just trying to say the same thing as you did a different way. Hope that makes sense!

 

~Mike

[larryllix]

Hi Amigo,

 

If

From Sunset

To Sunrise + 30 minutes (next day)

And Control 'Outside / Front Door Motion Sensor-Sens' is switched On

 

The trigger for TIME conditions are only evaluated for those two specific moments in time and not for the whole time period in between. Therefore would evaluate FALSE unless a 'Control On' is sent from the Motion Sensor at those two moments in time. -- Which would be highly unlikely to occur.

 

The trigger for the CONTROL condition is valid during the whole TIME period. A 'Control On' sent from the Motion Sensor evaluates TRUE during this period and FALSE outside this period.

 

~Mike

The time period causes triggers at sunset and sunrise+30 minutes because evaluation is triggered by the time condition nodes.

 

However, the time conditions are also evaluated any time of the day when the logic is triggered by the MS sending an On signal. This is when the time nodes act as a conditions. Between the times the logic evaluates as true and runs Then.

 

The MS Switched Off is not a trigger in this logic because it is a different signal and unrelated.

 

Most If lines act as evaluation triggers and, as well,  act as condition filters.

Edited December 18, 2015 by larryllix

[oberkc]

MikeD, makes sense, yes.

 

Was simply responding to a couple of your statements such as

 

"The trigger for TIME condition are only evaluated..." (Triggers are not evaluated, in my mind).

 

"The trigger for the CONTROL condition is valid during the whole time period" (triggers are moments in time, not over whole time periods.)

 

I could not reconcile statements such as those with my own understanding of how things work.

 

While I am confident that you and I understand things equally well, I believe that triggers is a fundamental concept of the ISY and it is important to be precise. Otherwise, results will be unpredictable.

 

Perhaps that is the "gotcha" from all this?

[MikeD]

Hi oberkc,

 

I misspelled your username in my first response.  My apologies!

You and many other forum members endeavor to be very precise in explaining the logic of ISY programming and it is very much appreciated. I know it can be frustrating to someone new.

 

~Mike

[Amigo]

Thank you all.

Yes, I understand the triggers, but how the MS trigger can also force the past triggers (time triggers) to be re-evaluated, that part will need some getting used to for me.

 

cheers. 

[oberkc]

I am glad you understand triggers.

 

I view triggers separately from conditions, though both are based upon the same individual statements. Think of the condition (if statement) as a single entity, made up of multiple statements, OR, AND, and parentheses. Regardless of which statement triggers a program, the ENTIRE IF condition is evaluated, always.

[Amigo]

Thank you.

Yes, the light bulb moment for me was that every and each trigger forces the entire IF statement to be evaluated/re-evaluated.

And if I understand it correctly, if you have a "Wait" in the body of path, then it also forces the IF statement to be evaluated (continuously?) while in the wait state. If this is true, how often is the IF statement evaluated while in wait state? Is it as often as possible by ISY processor tasks? 

cheers.

[LeeG]

Amigo

 

"if you have a "Wait" in the body of path, then it also forces the IF statement to be evaluated (continuously?)"

 

That is not accurate.  A Wait allows the If to evaluate, it does not cause a reevaluation.

 

Program If processing is event driven.   The Program can be in a Wait and the If clause not run.  Something in the If conditions must want to trigger the Program and be in a Wait.  

 

The 'state var 1' changing to 4 triggers Program and executes the Then clause with the Wait.  While in the Wait the If does not execute again because 'state var 1' has not changed.

 

While in the Wait should 'state var 1' value change the If is evaluated once.

 

 

If 'state var 1' is 4

Then

   do something

   Wait 5 minutes

   do something

Else

[Amigo]

Ok, I think I got it. Thank you.

 

another question:

what is the difference between a state variable and integer variable, by that I mean are the following the same triggers:

 

 

If 'state var 1' is 4

Then

   do something

   Wait 5 minutes

   do something

Else

 

If 'integer var 1' is 4

Then

   do something

   Wait 5 minutes

   do something

Else

Edited December 18, 2015 by Amigo

[oberkc]

State and integer variables, I believe, are identical in function when viewed as part of the logical condition. Integer variables differ from state variables only in that integer variable do not act as program triggers.

[LeeG]

Amigo

 

The second example never Triggers.  That is the difference between Integer and State variables.  Integer variables cannot Trigger a Program.

 

If 'integer var 1' is 4

Then

   do something

   Wait 5 minutes

   do something

Else

 

In the next example once the State variable Triggers the Program the value of the Integer variable affects the ultimate If condition True/False evaluation but the Integer variable can never cause the Program to Trigger.

 

If 'state var 1' is 4

And 'integer var 1' is 2

Then

   do something

   Wait 5 minutes

   do something

Else

[Amigo]

Ok, I fully understand. Thank you all.

I really had a hard time wrapping my head around the difference, but it is clear now.

cheers.

[kohai]

The info and examples in this thread should be put up on the wiki.  I'm still trying to wrap my brain around it (it is not like a normal programming language).  This is a very common topic on the forums and more how-to info somewhere would be helpful.  (At least I didn't see anything on the wiki or in the user guide at this level of detail.)

 

BTW, I think there should be a 'sleep' command that does not cause a re-evaluation of the IF.

Edited January 5, 2016 by kohai

[larryllix]

The info and examples in this thread should be put up on the wiki.  I'm still trying to wrap my brain around it (it is not like a normal programming language).  This is a very common topic on the forums and more how-to info somewhere would be helpful.  (At least I didn't see anything on the wiki or in the user guide at this level of detail.)

 

BTW, I think there should be a 'sleep' command that does not cause a re-evaluation of the IF.

Wait does not cause re-evaluation of the If logic.

 

Wait allows the ISY PLC processing to run other tasks (gives up it's time slice control for the Wait time) which may include evaluating the If in the same program if a trigger element changes. It may only be ISY sending out an Insteon command.

[jerlands]

 

BTW, I think there should be a 'sleep' command that does not cause a re-evaluation of the IF.

 

Anytime the programs conditions are re-evaluated, wait and/or repeat are halted and the program either re-executes then or runs else.

 

 

Jon...

Edited January 6, 2016 by jerlands

[kohai]

Anytime the programs conditions are re-evaluated, wait and/or repeat are halted and the program either re-executes then or runs else.

 

 

Jon...

 

Right.  In a normal if/then/else world, that isn't expected but I do see the need in the case of an ISY (e.g. motion sensor).  It seems to me though, there could be a need for the ability to 'sleep' without being surprised and having the execution jump from the THEN to the ELSE.  Maybe it is a simple counter that is in the IF that gets incremented in the THEN.

 

Anyway, that wasn't the main point of my post.  My point was that the IF/THEN/ELSE in the ISY world is substantially different than normal programming logic and documenting the details of it on a wiki or in the user guide (or preferably both) would be helpful to newbies like me.   I found this thread by trying to understand the process.  There's been some discussion on the forums the past couple days about how to make it easier for people to start using the ISY and I think IF statements are one of those areas that people stumble.

[larryllix]

Right.  In a normal if/then/else world, that isn't expected but I do see the need in the case of an ISY (e.g. motion sensor).  It seems to me though, there could be a need for the ability to 'sleep' without being surprised and having the execution jump from the THEN to the ELSE.  Maybe it is a simple counter that is in the IF that gets incremented in the THEN.

 

Anyway, that wasn't the main point of my post.  My point was that the IF/THEN/ELSE in the ISY world is substantially different than normal programming logic and documenting the details of it on a wiki or in the user guide (or preferably both) would be helpful to newbies like me.   I found this thread by trying to understand the process.  There's been some discussion on the forums the past couple days about how to make it easier for people to start using the ISY and I think IF statements are one of those areas that people stumble.

It definitely isn't the usual top down inline program execution code.

 

I think what you are saying is a training document for newbie users with step by step, do this, do that examples.

 

This type of document could be used for sales promotion materials also.

 

One of the problems is demonstration of execution. Every new user has a few different Insteon devices. If I told you to define a variable and write a short program example that is triggered when the variable is changed, would you be confused when you susbstitute a motion sensor or a hidden door sender?

 

It could be done with a few different angles and probably should be done.

 

Perhaps UDI could provide a user space in Wikipedia for users to write and polish such a thing before launch. I wrote for Wikipedia, for a few years, and suspect the same executive system  is in use for UDI's wiki.

 

 

EDIT: I have a copy of an "ISY User Guide v4.2.8.pdf" somebody directed me to  bout a month ago. It does provide some basic programming examples that may be just what we are talking about.

 

Perhaps somebody could provide a link to it as I have the doc and lost any link to where I got it from.

Edited January 6, 2016 by larryllix