Automatically Control Vacation Lighting

[dnl]

I am new to ISY programming. I wrote a couple programs to turn a light on when a house is not occupied but I am not sure if the programs will always work the way I want. I would appreciate some comments and suggestions if there are better ways to do it.

 

I have a motion sensor and one light to control.

 

If there has been no motion for 24 hours, I want to start controlling the light by schedule. When there is motion, I want to keep the light on if already on but immediately stop automatic control.

 

That is simple enough but I would like one additional feature. The motion sensor sometimes get stuck "ON" even when there has been no motion for a long time. I am working to solve this problem but in the meantime I want a failsafe for this situation by monitoring the light being turned on manually. If the light has not been turned on for 24 hours, I want to begin controlling the light by schedule just as if there has been no motion for 24 hours.

 

I wrote two programs to do this:

 

Program 1: Occupancy Detector

If
       Status  'Motion Sensor' is On
    Or Control 'Living Room Light' is switched On

Then
       Disable Program 'Night Lighting'

Else
       Wait  24 hours 
       Enable Program 'Night Lighting'
       Run Program 'Night Lighting' (If)

 

Program 2: Night Lighting

If
       From    Sunset  - 15 minutes
       To      10:30:00PM (same day)

Then
       Set 'Living Room Light' On

Else
       Wait  60 minutes  (Random)
       Set 'Living Room Light' Off

 

Will these programs work as intended? Are there situations where they will not work as intended?

 

In the else clause of program 1, should program 2 be enabled and executed or just enabled?

 

Will these programs continue to work the same when this one light in program 2 is replaced by a scene? In other words, program 1 continues to monitor the one light for manual operation but multiple devices are controlled in program 2.

 

Thanks for any help you can give me.

[oberkc]

I did not spend a lot of time looking at this, but I wonder if your problem is that, at sunset - 15 minutes, the "then" statement of your night lighting program causes your first program to immediately disable it for 24 hours. This results in your night lighting program not running the "then" path at 10:30?

[apostolakisl]

The else section of your first program will start running every time the motion sensor goes from "on" to "off" (I assume it can only be on/off) or if someone physically controls the switch to anything but "on". So if your motion sensor is on the fritz, then someone controlling the light to anything but "on" won't disable your second program. You might add "or control living room light is switched off" which will cause the program to run the "then" anytime anyone physically touches the switch at all.

 

With that done you will have the opposite problem in that if the motion detector is stuck "on" the else section will never have call to run. If you add to your "then" statement "run program occupancy detector else" it will have the effect of disabling the night lighting program every time someone touches the switch and causes the else to starts its 24 hour countdown to switching the lights to auto. The only question I have is if a "then" clause can run an "else" clause of the same program. You might need to copy that else clause to a whole different program if that is the case.

 

Other than that, I can't figure a way to mess it up.

 

Addendum: You can have the "then" section run the "else" section of the same program.

 

Addendum 2: It ocurred to me that since nothing else is referencing the "else" clause, you wouldn't need the "then" clause to run the "else" clause, you would just add the "else" clause contents to the end of the "then" clause.

 

So in short, anytime the motion detector changed state, or the switch was pushed, the program would disable the night lighting program and reset the countdown to re-enabling the night lighting program for another 24 hours.

[dnl]

Thank you for the replies and suggestions.

 

Oberkc, your comment is in line with what I originally thought might happen. The problem does not seem to occur. My testing indicates the statement

IF Control 'XXX' is Switched On

does not detect 'On' commands sent by a program but detects only a manual turning on. It would be great if someone could confirm this is true.

 

Apostolakisl, thank you for the suggestion. This simplifies the logic and with a small change can also handle the situation where the motion detector is stuck "OFF". I believe simpler programs are less likely to something unintended.

 

With your suggested changes, the 'Occpuancy Detector' program becomes ...

If
       Status  'Motion Sensor' is On
    Or Status  'Motion Sensor' is Off
    Or Control 'Living Room Light' is switched On
    Or Control 'Living Room Light' is switched Off

Then
       Disable Program 'Night Lighting'
       Wait  24 hours
       Enable Program 'Night Lighting'
       Run Program 'Night Lighting' (If)
Else
  - No Actions - (To add one, press 'Action')

Do you know if it is necessary to both enable and run the 'Night Lighting' program?

[oberkc]

It would be great if someone could confirm this is true.

This is something that is pretty easy to confirm yourself, should you care to do so. Under the program summary tab, you can see the status of your programs. Watch the status of your program "occupancy detector" after "night lighting - then" path has run. If you see "occupancy detector turn from "false" to "true", then you have confirmed your original (and my current) theories.

 

I don't use this type of logic in any of my programs, or else I would confirm this myself.

 

Update: I would not be too quick to discount your original theory. I just created a simple program, looking something like:

 

if
status "light" is on
then
else

I then sent commands from the admin panel to device "light" (a togglelinc). The program changed status as a result of commands from the ISY to turn the light on or off. It required no physical press of the switch. I take this as tentative confirmation that actions from a program can cause an evaluation of another program, with resulting status based on evaluation results.

[dnl]

Hi oberkc,

 

I did some testing along the lines you suggested when I first tried my programs. The results of that testing were the basis of my conclusions. I was thinking it would be nice if someone who knows with certainty could confirm.

 

Michel K. did confirm in a reply to one of your messages about Is Not Switched On.

 

I believe it was you who also wrote in another thread that 'Control' depends on physical/manual actions but 'Status' does not; that the results of a 'Status' condition is not affected by what/how a switched is turned on/off. Your comment in that thread confirms what I observed in my tests.

 

As others have written, the program logic of IF statements in ISY programs is a bit different than many other programming languages. For example, the logic of this statement ...

If
       Status 'XXX' Is On
    Or Status 'XXX' Is Off
Then

in many languages would be true at all times (hence pointless to test for both conditions). Not the case for ISY. I think I am beginning to understand -- I hope I am.

 

As for the enable/run question, I will assume both are needed until someone tells me otherwise. I assume 'enable' is needed to allow the program to run and the 'run' command is needed to actually cause its execution.

[oberkc]

I just ran another experiment with "control" rather than "status". Indeed, the program did NOT change conditions as a result of a remote command.

 

I believe it was you who also wrote in another thread that 'Control' depends on physical/manual actions but 'Status' does not;

I don't recall writing such a thing, but it appears that I was correct, if I did.

 

Regardless, I did not have a lot of time to try to understand your problem earlier. Now that I have looked a little harder, I realize that I misunderstood (I thought your livingroom light stayed on forever, but it was your motion sensor that was getting stuck on). Given my current understanding of your desires (and based on our experiments), I am now wondering if the following addition to your first program would solve your needs:

 

If
       Status  'Motion Sensor' is On
    Or Control 'Living Room Light' is switched On

Then
       Disable Program 'Night Lighting'
       Wait  24 hours
       Enable Program 'Night Lighting'
       Run Program 'Night Lighting' (If) 

Else

       Wait  24 hours
       Enable Program 'Night Lighting'
       Run Program 'Night Lighting' (If)

Every time the motion sensor sends "on" or every time the living room light is turned on, the program (then path) will disable the second program and start a countdown. If no motion activity of any kind is sensed (even if the motion detector fails to send an "off" command) for the next 24 hours, the night lighting program will start.

 

If the motion sensor is turned off, then a new 24 hour countdown starts. Each 24-hour period would be interrupted by a motion "on" or a manual turning of the light "on", starting a new 24 hour countdown.

 

Thoughts?

[dnl]

Hi oberkc,

 

The most recent code you suggest seems to be almost identical in effect to the last one I mentioned. The only difference I see is that a change in motion sensor to OFF or a manual switch to OFF does not disable the Night Lighting program.

 

Assuming there is no subsequent change in motion sensor or switch, if the NL program is already disabled, there is no difference in effect because both code would have NL disabled for 24 hours before enabling and running it. If the NL program is enabled when the change to OFF occurs, then it would remain enabled and running for 24 hours; then the enable and run commands would not have any effect because it would already be enabled and running according to schedule.

 

I do not think this is the better logic. If motion sensor or switch control changes to OFF, I would interpret that as someone being present. The NL program should be disabled immediately.

 

So, I think your first suggestion is the better one -- test for any change in motion sensor status or switch control and if it occurs, start a fresh 24 hour period in which the NL program is disabled. Manual control of the switch is handled the same as motion sensing. I like it.

 

Of course, this assumes I understand correctly how the program works.

[oberkc]

The only difference I see is that a change in motion sensor to OFF or a manual switch to OFF does not disable the Night Lighting program.

If motion sensor or switch control changes to OFF, I would interpret that as someone being present.

I am not so sure that the motion sensor changing to "off" is an indication of someone being present, but if that is what you want, then I am starting to understand the approach you took.

 

The only other question remaining in my mind is whether there would be any difference if you used "control" rather than "status" to track your motion sensors. In your case, based on my understanding, my guess is no.

 

Thanks for the dialog. i found it interesting and enlightening. Some people enjoy Sudoku. I enjoy logic. I am hoping it keeps my mind fresh. I don't use my mind as much as I should.

[dnl]

Hi oberkc,

 

I am not so sure that the motion sensor changing to "off" is an indication of someone being present, but if that is what you want, then I am starting to understand the approach you took.

If the motion sensor is operating properly (as well as RF communications, which I think is my problem -- I should know later today), a change to OFF occurs at a specific time after motion stops. In my case, I set the sensor for 30 seconds. So technically you are correct, OFF does not mean motion but it should mean motion recently occurred.

 

I can safely ignore OFF if everything is operating properly. The question that I cannot answer with certainty is what should be done if the motion sensor or communications do not operate properly. I am willing to assume motion recently occurred if the motion sensor transitions to OFF. The only example I can give is the ISY thinks the motion sensor is stuck ON even though I think the sensor itself is operating correctly and then the ISY sees a change to OFF.

 

The only other question remaining in my mind is whether there would be any difference if you used "control" rather than "status" to track your motion sensors. In your case, based on my understanding, my guess is no.

This an interesting question that I cannot easily test at this moment because the ISY thinks the sensor is stuck ON. I expect that there are no changes in control status because the motion sensor is not controlled like a switch is controlled.

 

A change in control status for the switch changes in response to a manual push on the switch rather than an actual change in its status. For example, if the switch is pushed upward, the IF condition for status ON triggers regardless whether the switch is already ON or is OFF. (For my situation, this is exactly what I want.)

 

Some people enjoy Sudoku. I enjoy logic.

Yes, me too. And thank you for your interest and comments.

[Goose66]

I can confirm that Control conditions in the IF statement of a program will only cause the program to run if the device issues the corresponding command.

 

Here is what I suggest:

 

Program 1 'NoOccupancyState' - a "flag" program with no statements.

 

Program 2 'ResetOccupancyState' - resets the 'NoOccupancyState' flag for 24 hours after any motion detected or manual control of the switch:

 

If 
       Control 'Motion Sensor' is switched On 
   Or Control 'Living Room Light' is switched On
   Or Control 'Living Room Light' is not switched On
Then 
       Run Program 'NoOccupancyState' (Else Branch)
       Wait  24 hours 
       Run Program 'NoOccupancyState' (Then Branch)
Else 
       -- No Statements --

Program 3 'NightLightingOn' - turns the living room light on when no occupancy of the room:

 

If 
       From    Sunset  - 15 minutes 
       To      10:30:00PM (same day) 
   And Program 'NoOccupancyState' is True
Then 
       Set 'Living Room Light' On 
Else
       -- No Statements --

Program 4 'NightLightingOff' - turns the living room light off when no occupancy of the room:

 

If 
       Time is 10:30:00PM
   And Program 'NoOccupancyState' is True
Then 
       Wait  60 minutes  (Random) 
       Set 'Living Room Light' Off 
Else
       -- No Statements --

Note that if the 24 hour period expires between Sunset and 10:30, the changing of the status of the 'NoOccupancyState' program will cause the 'NightLightingOn' program to run and turn the light on. Then the 'NightLightingOff' program will clean it up at 10:30. Similarly, if the light is turned on because of no occupancy, but then occupancy occurs (either motion or switch activated), the the 'NightLightingOff' will not run at 10:30 and the light will remain in the state set by the occupant. This seems likle desireable functionality.

 

I tend not to use ELSE statements because of the amount of analysis that is involved in determining when the ELSE statement may execute. Because you cannot seperate trigger events and IF conditions in a program on the ISY, the use of ELSE statements is rarely ideal.

[apostolakisl]

The only difference I see is that a change in motion sensor to OFF or a manual switch to OFF does not disable the Night Lighting program.

If motion sensor or switch control changes to OFF, I would interpret that as someone being present.

I am not so sure that the motion sensor changing to "off" is an indication of someone being present, but if that is what you want, then I am starting to understand the approach you took.

 

The only other question remaining in my mind is whether there would be any difference if you used "control" rather than "status" to track your motion sensors. In your case, based on my understanding, my guess is no.

 

Thanks for the dialog. i found it interesting and enlightening. Some people enjoy Sudoku. I enjoy logic. I am hoping it keeps my mind fresh. I don't use my mind as much as I should.

 

I don't have any insteon motion sensors, but I assume that they flip "on" when motion is detected and then after a few seconds of no motion flip "off". I also am going to assume that a motion detector changing state is a "control" command from ISY perspective (in other words, the same as physically pushing a switch).

 

If your motion detector was working properly, I would think that having both lines about flipping "off" OR flipping "on" would be unnecessary since every time it flips "on" you would expect it to flip "off" a few seconds later when motion stops. But with it on the fritz maybe it gets stuck on way or the other and having both lines would help it to work better.

 

When I saw your question, it basically made me think about using a regular switch as an occupancy detector. In other words, someone physically pushing it would put your ISY into an "occupied" frame of running. That means only using "control" in the if language since your "unoccupied" programs turn the switch on and off (which would cause "status" programs to erroneously put the house into occupied mode).

 

So in short, I thought it would be nice to use the "is not" language together with "control" to mean that someone pushed the switch in any way (and thus the house has a person in it). But, to my surprise, "control" plus "is not" logic is not what I had expected. So, you would need to use multiple "control" lines separated by "or" for every possible physical action one might take at the switch (on,off,fade up,fade down).

 

A program does not have to be enabled for another program to call its "then" or "else" section. Only the "if" section is shut down when a program is disabled.

 

Thanks for the question, I enjoyed playing with it and learned some new stuff.

[oberkc]

When I saw your question, it basically made me think about using a regular switch as an occupancy detector.

 

I use a keypad button to define occupancy (home or away).

 

I don't have any insteon motion sensors, but I assume that they flip "on" when motion is detected and then after a few seconds of no motion flip "off". I also am going to assume that a motion detector changing state is a "control" command from ISY perspective (in other words, the same as physically pushing a switch).

I don't have them, either. Mine are X-10. However, I understand the same as you...they issue commands like any other insteon device. Perhaps they operate most like the Remotelinc. I also understand that there are several jumpers which can be used to define certain characteristics of the sensor.

 

But, to my surprise, "control" plus "is not" logic is not what I had expected.

I have been following your two threads on this subject, with interest. Given the responses, I wonder about the value of one line in kingwr's logic:

 

Or Control 'Living Room Light' is not switched On

 

In the back of my head, I also keep thinking about how people often complain of a "feature" of ISY programming...halting program execution (with wait or repeat) when an input condition changes. I find it interesting that this type of programming actually exploits this feature. I am curious about your (and other's) thoughts on this.

[apostolakisl]

In the back of my head, I also keep thinking about how people often complain of a "feature" of ISY programming...halting program execution (with wait or repeat) when an input condition changes. I find it interesting that this type of programming actually exploits this feature. I am curious about your (and other's) thoughts on this.

 

I think the interupt feature is very useful, but, to the novice a bit unexpected. It might be a nice feature to have a way to "protect" a then statement from interuption, but I have found you can get around this by putting your "then" clause into a separate program that the first program calls. It protects the "then" from getting terminated by the "if" turning false, but it still won't stop it from getting reset if the "if" gets revaluated to true again.

 

I use a keypad button to define occupancy (home or away).

 

 

That works perfectly, but requires the user to know to push it. Having a light switch usage indicate that the house is occupied works no matter who walks in.

 

I have been following your two threads on this subject, with interest. Given the responses, I wonder about the value of one line in kingwr's logic:

 

Code:

Or Control 'Living Room Light' is not switched On

 

 

 

It appears that kingwr thought as I had. I actually wrote that program first then tested it and it didn't work. That's what prompted the other thread. kingwr knows his ISY pretty well and I bet he will appreciate this little tidbit. I have yet to figure out how to make the tidbit useful, however. I am sure there is a situation. Thanks to Indymike on somehow having a brain that works backwards to know that.

[Goose66]

I also like the fact that subsequent trigger events halt the current running instance of a program in favor of a new instance. While it may not be obvious to a new programmer, I think it is essential for novices, because it prevents them from having to think in terms of multi-threaded execution and semaphores or other mechanisms for synchronizing the execution of multiple instances of the same program.

 

It also makes occupancy sensing much easier with motion sensors that are jumpered to only send ON commands (occupancy mode), which is how I like to use them.

 

As far as the "If 'Device' is not switched On" not working as expected, I am flabbergasted and almost certain that I have at least one program that is not operating as I expect because of it.

[dnl]

Thanks to kingwr, oberkc and apostolakisl for comments and suggestions.

 

Kingwr, I have modified my programs as you suggested. Will you explain these statements a bit more?

 

I tend not to use ELSE statements because of the amount of analysis that is involved in determining when the ELSE statement may execute. Because you cannot seperate trigger events and IF conditions in a program on the ISY, the use of ELSE statements is rarely ideal.

I have seen other posts advise not to use the ELSE clause but with no explanation why. I am intrigued by what you wrote. I would have thought there is no additional processing needed to evaluate IF conditions when the ELSE clause is used.

 

If for example we have one program of the form ...

IF condition1 AND condition2
THEN do this
ELSE do that

I would have thought the two conditions are evaluated only when there is a state change and the use of ELSE statements would not affect that evaluation.

 

On the other hand, if we have two programs like ...

IF condition1 and condition2
THEN do this
ELSE 

IF not-condition1 or not-condition2
THEN do that
ELSE 

I would think this causes the two conditions to be evaluated twice, once for each program. (Note that the "not-condition1 or" expression ... is the Boolean inverse of the "and" expression.)

 

Also, please excuse more bonehead questions, when you wrote "you cannot separate trigger events and IF conditions," what is meant by "separate" and what is the consequence of not being able to do it?

[Goose66]

You find many topics in these forums regarding unexpected behavior in programs, and much of it stems from the way the current ISY programming model works regarding trigger events for a program.

 

The trigger events for a program are extracted from the IF condition. So if I have the statement "If Status 'Device' is On" in a program, then the ISY extracts a trigger event for the program to be a status change for 'Device' and if I have the statement "If Control 'Device' is not switched Off" then the the ISY adds a trigger event of command received from 'Device.' Note that the trigger events are inherently ORed, even though the actual IF conditions may be ANDed or ORed.

 

Now, I think most would agree that this fact causes confusion for many new ISY programmers. A classic case is:

 

If 
       Control 'Motion Sensor' is switched On 
   And Status 'Living Room Light' is Off 
Then 
       Set 'Living Room Light' On
       Wait 5 minutes
       Set 'Living Room Light' Off
Else 
       -- No Statements -- 

You see this over and over again, and it makes sense on first blush. What many don't realize is that in addition to the program running when the ON is recieved from the motion sensor, the program is going to run everytime the status of the living room light changes as well. In this particular case, when the program sets the living room light ON, that changes the status of the living room light, causing the program to be run again, this time causing the ELSE branch to run. So the 5 minute WAIT gets cancelled, the light is never turned OFF.

 

Another classic example is:

 

If 
       Control 'Motion Sensor' is switched On 
   And From Sunset 
       To Sunrise (next day) 
Then 
       Set 'Living Room Light' 20%
       Wait 5 minutes
       Set 'Living Room Light' Off
Else 
       Set 'Living Room Light' On
       Wait 5 minutes
       Set 'Living Room Light' Off

Here, the object is to have the light turn on one level when it is dark outside, and a different level in the day time. The problem here is that this program also runs at Sunset and at Sunrise the next day, which from the grammatical reading of the IF statement is not expected. The ELSE branch will be executed at these times, even if no motion control was received.

 

I submit that if I could specify trigger events for a program seperately from the IF conditions, much of this confusion could be avoided. In a conventional event driven environment, you specify the events that will trigger the program explicitly. For example, for the ISY you would specify that you want the program to run when a command is received from 'Device' (either a specific command or any command, perhaps), when the status of 'Device' changes, when a specific time occurs, etc. These events are inherently ORed together. Seperately, you would specify the IF conditions for executiong of the THEN or ELSE branches of your program, which could include status of devices, times within specific ranges, etc.

 

If this were the programming model for the ISY, you would find ELSE branches much more useful, because you wouldn't have the program triggering at different times and entering the ELSE branch just because you included specific conditions in your IF statement. That is why you find that people seldom use ELSE branches when they have multiple conditions.

[Chris Jahn]

I submit that if I could specify trigger events for a program seperately from the IF conditions, much of this confusion could be avoided. In a conventional event driven environment, you specify the events that will trigger the program explicitly. For example, for the ISY you would specify that you want the program to run when a command is received from 'Device' (either a specific command or any command, perhaps), when the status of 'Device' changes, when a specific time occurs, etc. These events are inherently ORed together. Seperately, you would specify the IF conditions for executiong of the THEN or ELSE branches of your program, which could include status of devices, times within specific ranges, etc.

 

If this were the programming model for the ISY, you would find ELSE branches much more useful, because you wouldn't have the program triggering at different times and entering the ELSE branch just because you included specific conditions in your IF statement. That is why you find that people seldom use ELSE branches when they have multiple conditions.

 

Kingwr,

 

I think you are arguing the merits of having this all contained within one program, but just to be clear, you can separate triggers and If conditions with the ISY (see this post), it just requires a separate program.

[dnl]

Hi kingwr,

 

Thank you for the detailed reply.

 

Your first example illustrates the difference between Status and Control. I believe I understand how these two conditions differ.

 

Your second example answers the question about separation. I note Chris Jahn's answer. Could you not also achieve what you describe by putting programs in a folder and specifying the conditions for the folder?

 

In any case, I still do not understand what is the problem (or disadvantage) of the ELSE statements I had in my programs. I do not understand what is the advantage of dividing the IF-THEN-ELSE structure I had into two programs that have only IF-THEN. It still seems that we end up with the same conditions in two programs to monitor rather than those conditions in just one program.

[dnl]

This thread may be almost dead. The issue regarding ELSE is still not resolved for me but it may be with more experience.

 

I wanted to add what may be the last entry to point out a potential problem with the last proposed solution. If two different programs are used to turn on and turn off the lights, and if the occupancy detector changed its state to 'unoccupied' at exactly 10:30 pm, both the ON and the OFF programs would run their THEN clauses but either program might ran last. If the ON program ran last, the lights would be left on for 24 hours. The event is very unlikely but I would rather ensure the event could not cause a problem.

 

I believe this problem can be avoided by setting the off time in the ON program to an earlier time (one minute earlier would suffice) but it would require me to remember this and change both programs if the shutoff time was to be changed.

 

One program with both THEN and ELSE clauses avoids the problem. For that reason, I decided to return to that approach -- at least until the day I understand why it is better to avoid ELSE clauses.

 

Thanks again for all who posted comments. They were very helpful to me.

[Goose66]

One program with both THEN and ELSE clauses avoids the problem. For that reason, I decided to return to that approach -- at least until the day I understand why it is better to avoid ELSE clauses.

I think you understand it but your preference is to continue to use it. That's fine.

 

ELSE clauses are confusing in the ISY programming model because every condition in the IF statement implies a trigger event for the program, and that may not be clear to the novice programmer. So the novice programmer may find that the ELSE clause of their programs are being executed at unexpected and inappropriate times.

 

I consider myself not to be a novice programmer, but I probably use ELSE clauses in 1 out of 15 ISY programs because of this behavior. It is my preference.

 

It is my contention that if trigger events and IF conditions were seperated, I would use ELSE statements much more often, I would probably have half the number of programs I have now, the programming model would be much less limiting, and the whole thing would be cleaner and easier to understand.

[dnl]

Thank you kingwr for the reply.

 

I expect as the complexity of my programs increase, I will begin to see the wisdom in what you describe. I also value what you appear to value, which is a program that is easier to understand and that does what you think it does (without an inordinate amount of thinking?).

[oberkc]

I have always accepted that there is a trade-off between simplicity/intuitive and flexibility/power. Maybe such a trade is not necessary, but I have always taken it as a a granted. Given this trade, I will take flexibility/power every time.

 

My suspicion is that if you are able to find a way to get both, you will be rich.

[apostolakisl]

It is my contention that if trigger events and IF conditions were seperated, I would use ELSE statements much more often, I would probably have half the number of programs I have now, the programming model would be much less limiting, and the whole thing would be cleaner and easier to understand.

 

That would be very nice. Two little check boxes next to each item 1) use as trigger, 2) use as condition. They would default to being checked.

 

My suspicion is, however, that doing this would be like throwing a gigantic monkey wrench into the guts of the ISY code.

[oberkc]

That would be very nice. Two little check boxes next to each item 1) use as trigger, 2) use as condition. They would default to being checked.

 

Of course, this is already achievable by disabling programs. The remaining question is whether you believe this would be more "intuitive". I cannot help but wonder if there would be fewer or greater numbers of questions and confusion. My suspicion is that neither (existing or proposed) option is inherently more intuitive than the other.