Status VS Control Triggers

[IndyMike]

I was recently burned trying to use a status trigger with a wait/repeat action. I believe that my problems were due to the fact that a "status triggered" program is re-entrant.

 

Although the following may be "common knowledge" among many of the forum members, I've never seen it stated explicitly. While I understand program re-entrance, I didn't think through the implications of using a "status" trigger with a wait or repeat loop.

 

Edit - General rules for "Status" and "Control" triggers: 4-5-08

Control Trigger

A control trigger can only be initiated at the actual Hardware device (i.e. physically turning on a Switchlinc). You can't initiate a "control" trigger using a scene, schedule, or through the on/off buttons in the ISY GUI.

Status trigger

A "status trigger" is generated by any change in the device status (ON/Off, Bright/Dim). The status trigger does respond to changes initiated by Scenes, Schedules, and the ISY GUI interface.

 

The following are examples of code that does and doesn't work.

In each of the following my "Master KPL 1st FL" is part of the '1st Floor Off' off scene. Each time the program Dims the '1st Floor Off' scene a status trigger is generated for the "Master KPL 1st FL" and the program re-enters. This can cause some interesting problems with looping, locking, and other nasty things.

If
       Status  'Master KPL 1st FL' > Off
   And Status  '1st Fl Timer Lockout ' is Off

Then
       Wait  5 seconds
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Wait  2 seconds
       Set Scene '1st Floor Off' Off

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

The above code executes ~ 10 seconds; the scene dims correctly; turns lights off correctly. Unfortunately I wanted the 2 second delay prior to the "scene off" command to be 1 minute.

 

If
       Status  'Master KPL 1st FL' > Off
   And Status  '1st Fl Timer Lockout' is Off

Then
       Wait  5 seconds
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Wait  4 seconds
       Set Scene '1st Floor Off' Off

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

Increasing the 2 second wait time to 4 seconds had dramatic effects.

This code executes for ~45 seconds; The lights wound up dimming to 0% in multiple passes. The scene off statement was never executed. I believe the 4 second wait interacted with the program re-entrance rate, resulting in a loop. I actually surprised that the program was able to "break out".

 

 

If
       Control 'Bar Lamp KPL2-Primary' is switched On
   And Status  '1st Fl Timer Lockout' is Off

Then
       Wait  5 seconds
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Wait  4 seconds
       Set Scene '1st Floor Off' Off

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

Same program using a "control" qualifier. Runs for 10 seconds; dims light properly; executes off properly. Since the "control" event is a single pass, things operate properly.

 

 

If
       Status  '1st Fl Timer Lockout' is Off
   And Status  'Master KPL 1st FL' is On

Then
       Wait  5 seconds
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Set Scene '1st Floor Off' Dim
       Wait  20 seconds
       Set Scene '1st Floor Off' Off

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

Increasing the wait time to 20 seconds reduced the execution time to ~8 seconds. The lights dimmed properly, but the off command was not executed.

 

 

If
       Status  '1st Fl Timer Lockout' is Off
   And Status  'Master KPL 1st FL' is On

Then
       Wait  5 seconds
       Repeat 11 times
          Set Scene '1st Floor Off' Dim
       Repeat 1 times
          Wait  5 seconds
          Set Scene '1st Floor Off' Off

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

Converting the individual dim actions to a repeat loop doesn't work either. The above runs for ~8 Seconds; doesn't dim; doesn't turn off light.

 

 

If
       Status  '1st Fl Timer Lockout' is Off
   And Control 'Bar Lamp KPL2-Primary' is switched On

Then
       Wait  5 seconds
       Repeat 11 times
          Set Scene '1st Floor Off' Dim
       Repeat 1 times
          Wait  5 seconds
          Set Scene '1st Floor Off' Off

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

The above shows the proper method for triggering this program. A control action is used instead of the "status" trigger. This program correctly runs for ~ 20 seconds; Proper dimming; Proper turn off;. All of the above code will run properly if triggered by a "control" action.

 

Hope this keeps others from falling into the same trap.

 

IM[/i]

[Algorithm]

Indy, that's a great write-up of the classic difference between 'IS' and 'BECOMES' conditions.

 

In ISY terms, the examples you provided show Status acting as an IS condition (TRUE as long as the condition is true), and Control acting as a BECOMES condition (TRUE only once). I would love for the UDI guys to provide a little more insight into how ISY handles these situations.

[yardman 49]

Great explanation. Mike. This really is a big help on understanding the proper uses for Status and Control.

 

Best wishes,

[IndyMike]

Joe and Frank,

Thank you for the accolades. This post was born out of my failure in presenting "good code" in my "Combining Timers and Events" post. It still ticks me off that I botched the original post in that thread.

 

I've made it a rule over the years to search for a way to turn a failure into something worthwhile. This was my attempt to do just that.

 

IM

[Michel Kohanim]

IndyMike,

 

Thanks so very much ... as a matter of fact, I am quite happy that you failed first otherwise we would've never had this wonderful topic.

 

Thanks again and with kind regards,

Michel

 

Joe and Frank,

Thank you for the accolades. This post was born out of my failure in presenting "good code" in my "Combining Timers and Events" post. It still ticks me off that I botched the original post in that thread.

 

I've made it a rule over the years to search for a way to turn a failure into something worthwhile. This was my attempt to do just that.

 

IM

[sfhutchi]

Since I continue to learn from other people's examples, why did you choose to do the multiple dims and then an 'off' rather than a long ramp to off. It seems that the current approach will make the 'steps' to off fairly pronounced.

[IndyMike]

sfhutchi,

 

You're exactly correct - the lights do step down while they are dimming. This is intended as a warning to my family members that the "off" program is about to extinguish the lights. If allows then to hit the override button if they wish.

 

This was a "quick and easy" program that works with my entire first floor scene (dimming the On lamp leaves the other Off lamps unaffected). I would have preferred to monitor and flash only the lamps that were activated. Just takes a lot more "individual" programs. I haven't gotten there yet.

 

By the way - Just another Joe and Rand had some very good "enhancements" for trigging the above. The post is located here:

 

Combining Timers and Events

 

IM

[sfhutchi]

Very interesting. I guess that is what the '1st Floor Timer Lock-out' is for.

Interesting idea. Neat concept to give advance warning on changes that people can override.

[Illusion]

IndyMike,

 

Can you explain a little more for a non-programmer type? I think this concept is a little beyond me but because it deals with 'control' and 'status' I think I need to really understand this before I get real deep into setting up programs.

 

I believe that my problems were due to the fact that a "status triggered" program is re-entrant.

What does this mean?

 

I do not understand why the second bit of code does not work but the first one did.

 

Indy, that's a great write-up of the classic difference between 'IS' and 'BECOMES' conditions.

 

In ISY terms, the examples you provided show Status acting as an IS condition (TRUE as long as the condition is true), and Control acting as a BECOMES condition (TRUE only once). I would love for the UDI guys to provide a little more insight into how ISY handles these situations.

 

Darrell, I am trying to understand why that is a great write-up of the classic difference between 'IS' and 'BECOMES'.

 

I know that most people get this stuff, but I do not. From reading other posts, I thought that a status change was the event, pretty much like control. It is evaluated at the time of a status change.

 

Darrell, I have read your other posts about programming and I can see that you are way skilled in this, so I think there is something missing here for the lay person. Normally I would not even bother to comment on a thread that is so far beyond me, but this one seems like a really valuable concept to fully understand.

 

P.S. Why do some refer to you a JAJ?

[Algorithm]

Hi Illusion,

 

In ISY programming, using Status in the condition tests the current state of the device: is it On? Is it Off? Is it at a particular level (eg. 48%)? And so forth. Using Control tests for a change in the status of the device: did it switch On? Did it switch Off? And so forth. [strictly speaking, Control does not actually require a change in status, since a switch can be off and still tested for being switched off. But it does require an event (eg. a paddle or button push, etc.), as opposed to Status which simply tests the current condition of the device.] Does that help clarify the difference between the two types of conditional tests?

 

By the way, thanks so much for the accolades, but there are many on this forum who are far, far more skilled than I! Some of them post frequently, and some rather infrequently.

[Illusion]

Okay,

 

That makes sense to me, thanks. I still do not understand why the programs aforementioned are failures though.

 

Also, you did not answer my question about JAJ.

[IndyMike]

Illusion,

 

Thank you for pointing out a rather glaring omission in my post. I never stated what the actual problem was. I've edited the original post to include this information. I'd be interested in your opinion.

 

The bottom line problem with my original program was the following -

1) I was using a status trigger on my "Master KPL 1st FL" to start the program.

2) The program modified the Scene '1st Floor Off'. The "Master KPL 1st FL" was a member of this scene, so it's status was changed.

3) The status change in the "Master KPL 1st FL" caused the program to re-trigger with some interesting results. This is what I was attempting to document.

 

All of the above is prevented by using a "Control" trigger. A control trigger is not affected by scene induced changes.

 

Sorry for the confusion,

IM

 

IndyMike,

 

Can you explain a little more for a non-programmer type? I think this concept is a little beyond me but because it deals with 'control' and 'status' I think I need to really understand this before I get real deep into setting up programs.

 

I believe that my problems were due to the fact that a "status triggered" program is re-entrant.

What does this mean?

 

I do not understand why the second bit of code does not work but the first one did.

 

[Illusion]

Wow, that one post clears everything up for me. Now it makes perfect sense! It also explains why Darrell thought this was an excellent example, and why Michel was so happy you wrote it.

 

Outstanding post, thanks for taking the time to document this and to answer my questions. I appreciate your time.