Goose66

In furtherance of the OP's original question: Since, as discussed above, the motion program gets evaluated at both an ON from the sensor AND at Sunset and Sunrise, why not put an OFF command in the Else brach of the program to handle the boundary condition. If From Sunset To Sunrise (next day) And Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else Set Scene 'Outdoor / Driveway Floods on Motion' Off This way, unless there is a motion sensor ON sent precisely at Sunrise, the flood light will be turned off at Sunrise and subsequent ONs from the motion sensor will be ignored. This seems to handle the boundary condition without the need for another program. Thus you have 1 program to respond to your motion sensor instead of 3, and no need for folder conditions.

I understand what you are trying to do (although I agree it is pretty damn complicated way to go about it). You have are 5 programs in the Re Dim folder that are all intended to be kicked-off at precisely the same time: whenever ReDimSwitch is set to True. Each program in the Re Dim folder has a corresponding normal mode program that establishes a dim level at a certain time. When the ReDimSwitch is set to True, one of the 5 programs conditions should be true, and that program restores the dim level by executing the Then branch of the correspoding normal mode program. A couple of questions: 1) How is ReDimSwitch activated? Is it linked to an Insteon switch, such as a KPL? 2) Is ReDimSwitch program in the "Re Dim" folder? I think your original supposition is correct, and this is indeed the lengthy and laborious topic of two other threads: http://forum.universal-devices.com/viewtopic.php?t=4236 http://forum.universal-devices.com/viewtopic.php?t=4332 What seems to be happening is that when the Re Dim Final runs the Then branch of the corresponding normal model program ("Front Final Shut Down"), it changes the status of the program to True (even if it was so already) causing the Re Dim Final to be run again, pre-empting execution of the previous instance of the program in favor of the new executing instance of the program. This creates your endless loop. What surprises me is, according to the Wiki and Rand, this shouldn't happen unless there is a Wait or Repeat in your program. Otherwise, the program should have behaved just as you expected. I think we need further clarification on how the program engine works as to evaluating conditions and triggering programs.

Also, my understanding is that much of this is only applicable if the THEN or ELSE branch contains a WAIT or a REPEAT. This was mentioned before, but was lost in the last few posts. So, just to make sure we are all clear, the only time a subsequent triggering of a program may occur that would pre-empty the currently running program is when there is a WAIT or a REPEAT, I think.

I wish they had offered an upgrade for those, similar to the V2 thermostat adapter.

To add to the original thread topic, most of my motion detectors are simply set to turn on the lights directly and turn them off after set period of time. Having the motion sensor and light in a scene seems to me to provide more instantaneous light on motion than the use of a program. The motion detector has a dusk/dawn detector that can be set as well. However, as you know, this may not work if the light is in the room with the motion detector, because the dusk dawn sensor may reset after the light is on for about 4 minutes (in my case). This was the problem I had on my driveway sensor. To alleviate that, I have implemented the following program: If From Sunset To Sunrise (next day) And Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - (To add one, press 'Action') However, as you know this creates the "boundary conditon" described above where the light may be left on at motion within 8 minutes from sunrise. To couteract that, I have another program that cleans-up my outdoor lighting: If From Sunset To Sunrise (next day) Then Set 'Outdoor / Front Lanterns' 80% Set 'Outdoor / Front Porch Lights' Off Set 'Outdoor / Garage Keypad-Driveway Flood' Off Else Set Scene 'Outdoor / Outdoor All Lights' Off This way nothing is left on at Sunrise. If something accidently gets turned on during the day, it is also cleaned up at Sunset. So, 2 programs instead of 3, with one program being a generic cleanup. This seems to be working, although only for a couple of days. But from the discussion above, it theoretically should work.

Yes, right-click on the program name in Program Details and select "Copy to Clipboard" from the context menu.

I would think it would impact you dramatically Seriously, the real answer is that is definitely a challenge with any change made to the firmware, whether the one I suggested or something completely different. However, I think it would be possible to write a function to extract triggers from existing IF statements. This would not alleviate impact on existing implementations, but may isolate the impact to a small number of programs. Besides, perhaps with this new implementation, you could have only hundreds (and not humdreds and hudreds) of programs to maintain, no?

I don't question your desire to improve the product and I appreciate the openess of the forum. I just don't want to keep belaboring my point when I am clearly failing to communicate my point. I am not really asking a question or asking for explanation on how to do something with the current implementation. I get that. Generally, my suggestion is that once the program has triggered, then changes in status-type conditions should not stop the program. I don't see where that is useful. This also goes hand-in-hand with the dicussion regarding the (unrecognized in the current implementation) differences between triggers and statuses. Rand suggested the example where a subsequent execution of a program delays the expiration of a timer, e.g. when i receive a subsequent ON from a motion detector. But that is not the status of something changing, it is a subsequent trigger of the program (with the same condition). A simple example for our discussion: IF 'Garage - Motion' ON is Received (trigger) AND Time is between Sunset and Sunrise (status) THEN Turn 'Garage - Light' ON WAIT 5 minutes Turn 'Garage - Light' OFF In this case, it would be handy to have each subsequent occurrence of ON from the motion detector (a trigger) reset the WAIT so that the light would stay on as long as there is motion. The light would eventually turn off, 5 minutes after the last motion that occurred between Sunset and Sunrise. However, the problem is that if the status (Time is between Sunset and Sunrise) changes, then the WAIT is also canceled, which means the light may get stuck on if motion was occurring right up to Sunrise. If status-type conditions didn't cancel the running program then, the program would work as writted. And you could have 1 program to implement this simple procedure, not 3 programs as suggested above. Now, this requires the ability to differentiate between Status conditions and Trigger conditions. This could be done a number of ways. Perhaps all Controls and Time = could be considered trigger conditions and everything else status conditions, but this may be confusing. I thought Rand was explaining to me that putting conditions on a folder was essentially implementing status conditions that would not be evaluated after a WAIT, but that turned out not to be the case, either. So we return to my original suggestion, first made in my first post in the other thread: Each program should specify both trigger conditions (which would be inherently ORed) and status conditions (which would be in the existing IF statment). Trigger conditions could include receiving an ON or OFF, a change in the status of a device, the time equalling a specific time value, and the like. Status conditions would be status of a device equalling ON or OFF, time being between some values, and the like. Subsequent triggers would essentially restart running programs that were in a WAIT. Changes to the conditions in the IF statement would have no effect once the program THEN or ELSE branch is running. This, again in my opinion, would be easier to understand and just as flexible (if not more so) than the current implementation. It may require some seemingly redundant program code, e.g.: Trigger: Status of A changes IF: Status of A = ON but it makes more sense (to me) and would provide more flexibility. Plus we could have 1 program to control our motion sensors, not 3. EDIT: BTW, I love my ISY 99i Pro/IR, I love the folks at UDI, love all around.

Your supplied code just shows how to deal with the fact that the program is cancelled during a WAIT (and thus needing this seperate 'OFF' program), but it does not illustrate how cancelling the program during the WAIT upon changes in the conditions is useful. That being said, I am afraid our interaction between the two threads has become pointless. I guess I will have to learn to live with the ISY the way it is instead of trying to suggest ways of making it better.

Maybe a better question is: What are the uses for cancelling a currently running program (in WAIT state) when the folder condition changes? Or even when the IF conditions change? That is what I am not seeing.

I understand that the programs would become disabled in that they would not run. But if they are already running, why cancel the program when the folder condition changes? Doesn't this belie your argument that the condition/status seperation we discussed can be accomplished with folder conditions? If folder conditions and IF conditions behave the same way, then how is using folder conditions different from just putting all the conditions in the IF statement? Seems like program folders and conditions are just a means for organization. If, however, changes in folder conditions did not stop running programs, then what the OP was trying to accomplish could be done in one program, not 3: Folder condition: Sunset to Sunrise IF condition: Control Motion Detector On THEN: Action Light ON Wait 1 MIN 30 SEC Action Light OFF In this case, each time motion occurrs, the WAIT timer would reset (as discussed above) and the light would remain on 1 MIN 30 SEC after last motion. Plus once started, the light would turn off regardless of sunset to sunrise.

Rand, Are you saying that a program that is currently running (in a WAIT) will cancel if the folder condition for a folder it is in changes? What's up with that?

I as well have observed different behavior than described. For instance: If Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - (To add one, press 'Action') When motion is detected, the Outdoor floods switch on. Each subsequent motion ON seems to reset the wait timer. This is amply demonstrated in the fact that 4 minutes after the light is turned on, the dusk/dawn system kicks off and no more motion ONs are sent. The log clearly shows the floods OFF is sent 12 minutes after the initial motion, not 8 minutes after the initial motion. Each subsequent ON does appear to reset the timer, even though the condition remains the same. Again, its not that this isn't handy behavior; in this case it actually is. However, it is not clear or intuitive behavior. That is my point.

I think my point is missed. But let me belabor it further: It's not about a specific program I am trying to accomplish. It is about how counterintuitive the implementation of "programs" are in the ISY. As a programmer, I think of it this way: When an event happens, execute a program. This is not structured this way in the ISY. The IF statement contains both triggers for the program (inherently ORed) and conditions for the THEN branch (which may be ORed or ANDed). There are many other counterintuitive aspects as well. For instance, the way the IF is reevaluated at the end of a WAIT or REPEAT takes most if not all ISY users by surprise. Adding the layers of folders on the programs also is counterintuitive, as the above question suggests. Why would the conditions for the IF inside the program come before the trigger for the program? That's pretty wacky, and not what kingwr intended at all. I am sure there are reasons it is done the way it is done (I imagine it stems from how the programs are serialized in the XML). But a much better implementation for me would be let me write a script, and then tie that script to events that occur on the ISY. It may take more programming to accomplish some of the same things, but it is a model that can be understood intuitively by all.

I bet you that is simply an icon switch with the red load lead cut.

I don't think handling the load is a major part of the cost. You have the 1) mechanical switch mechanism and status LEDs, 2) the power supply for the Insteon circuit, 3) the Insteon circuit itself (which is pretty generic across all devices), and 4) a triac or relay to switch the load. Those triacs are probably less than a dollar per unit. I don't know what else you could get rid of in a non-load switch.

I would suggest the 8 button if there is no local load, as well. You would not have to program button C to turn them all off, necessarily, because button A could be use to turn all three on an off (toggle mode) and button B could be use to turn off the two (non-toggle mode off). You would then want to add a seperate scene with button A as a responder to your ISY and also a program that, upon press of button B also turns off the seperate scene with button A responder. In this way, button A would turn all the lights on (and toggle the status light to the ON state automatically), then button A could turn off all three (and toggle the status light to the OFF state automatically) OR button B could turn off two of the lights and toggle the status light of button A to the OFF state as well.

This documents presents a perfect example: If ( Status 'Light 1' is On Or Status 'Light 2' is On Or Status 'Light 3' is On ) And Control 'Switch 1' is switched On Then Set 'Light 4' On Else - No Actions - In this example, it is clear that the intent is to only have the program run when an ON command from Switch 1 is received, no? Further, I think the desired status for the program would be what was the outcome of the evaluation of Light 1 is ON or Light 2 is ON or Light 3 is ON the last time the program ran. Can we agree on that? However, in the current implementation, the program will be run whenever Switch 1 is turned on AND whenever the status of Light 1, Light 2, or Light 3 changes. This is probably not desired and would be unexpected by the uninformed. Further, upon change in status of Light 1, Light 2, and Light 3, the status of the program will necessarily be FALSE, because the Control Switch 1 condition will fail. This also creates situations that differ from teh expected result, IMO. Please know that I understand and can work with the current implementation just fine, and this conversation and the posted references should help everyone. I am not criticizing the current implementation, either. I see some advantages to it, especially in that the program conditions are more concise. But, because this forum and UD has been so open to suggestions, I wanted to express my opinion that having trigger conditions and if statements as seperate items would be a clearer implementation with less unexpected results.

If you use the multi-linking mode of the SwitchLinc, are you not able to link one group of responders to ON and another group of responders to OFF (unlike regular linking)? In other words, instead of using the regular linking procedure to link the non-load SwitchLinc (SL) to the other 3 loads, perform multi-linking for the ON position of the non-load SL and add the 3 loads in ON condition, then perform multi-linking procedure for OFF position of the non-load SL and add the 2 loads in OFF condition. I haven't done this, but it seems theoretically possible. It would also be interesting to see how this then loads into the ISY as scenes.

That's my point about triggers and status conditions being the same thing in the current implementation. There are some things I want to be triggers for programs (like time of day, commands, and, yes, maybe status changes), but other things I just want to check without having it trigger the program. In a more primitive implementation (or more advanced, depending on your viewpoint), I would assign triggers to a script (they would be inherently ORed), and then in the script I could execute as many If statments and commands desired. The current implementation may remove a lot of redundancy from programs, e.g. a list of triggers and a list of if conditions may be the same: Triggers: Status change of X, Status change of Y, Status Change of X If: X = Off AND Y=Off AND Z=Off Then: A OFF Else: A On But, I just think seperating the two would be a cleaner way of thinking about programs.

I have to say that, as a programmer of 15 years, the programming model of the ISY 99i is confusing to me as well. It is nice that you can say something like "If Time is Sunset to Sunrise" Then "Turn Outside Lights On" Else "Turn Outside Lights Off." However, the fact that trigger conditions (conditions that occur that can initiate a program) and status conditions (conditions that represent the status of devices at the time a program is initiated) are in the same If statement throws me off. Also, status conditions also act as trigger conditions. A future enhancement, at least IMO, would be for every program to have a set of triggers, e.g. "Time is" or "Command X (device, scene, etc.) received," and a seperate if statement, e.g. device staus, time of day, weather info, etc. The if condition would only be evaluated on the occurrence of one of the triggers, and the status of the program would be the last result of the evaluation of the if statement for the program run. For example: Trigger: @ 11:45 PM If: 'Amp' Status is On Then: Set 'Amp' Off Wait 7 Hours Set 'Amp' On Else: Subsequent runs of the same program would cancel any pending waits in the previously executing program: Trigger: Garage Motion 'On' Received If: Then: Set 'Garage Light' On Wait 5 minutes Set 'Garage Light' Off Else: Seperating these things out would make everything clearer (again, IMO) , may remove the confusion regarding the program status not reflecting what one may think it should be, and seems to me would make the programming engine easier to implement and maintain (although, too late for that advantage).

is "iLinc" you are referring to "MobiLinc Pro" now in the App Store? If so, can anyone out there compare eKeypad ($49.95) to MobiLinc ($19.95). I wish MobiLinc Lite were more functional so I could get a better feel for the app. Even though it is not as expensive as eKeypad, it is still a significant investment (by iPhone app standards) and for $50 or $20 I want the best of the two.

Sorry that my explanation was not clear. I have 4 lights (2 SwitchLincs and 2 In-LineLincs) in my bedroom. I also have a 6-button KPL Relay that is not connected to a load. The KPL Relay presents as 5 buttons to the ISY: Main, A, B, C, and D. Buttons A, B, C, D are used to control various states and functions in the house and are in toggle mode. Main (On and Off) buttons are controllers in a scene that includes all 4 lights in the bedroom. All this works just fine. It is the button status LEDs (not backlight) that are the problem. The buttons A,B,C,D are in toggle mode and the status LEDs work correctly. The Main buttons(On and Off), however don't respond as desired, in that when the On button is pressed, and all lights are turned on, the status LED for the On button illuminates. But then, if some or all of the lights are turned off, the status LED for the On button remains illuminated. What I was hoping for was that the status LEDs on these two buttons On and Off would never illuminate, since their status cannot be determined. Ideally, I could set the On button to non-toggle On mode, and the Off button to non-toggle Off mode, but this doesn't seem to be possible. I was trying to find out if there is a program workaround to implement this functionality, i.e. keep the status LEDs for the On and Off buttons from illuminating (or remaining illuminated). If this is not possible, then the program idea you provided is at least a more accurate representation of the staus than what I have now. However, ideally I could have no status lights at all. At this point, I think I may get an 8-button conversion kit for $8 and that would solve all my problems (hopefully).

I have a 6-button KPL relay that I recently retasked and moved to my bedroom. The KPL relay does not have a load attached. I wanted to use the main buttons as All-On and All-Off for the various lights in the bedroom. This was no problem to setup, but the problem is the LED status lights. For example, when you turn all the lights on, the ON button on the KPL illuminates. However, it stays on even if all the lights are turned off, for example by using All-Off on my ControlLinc or turning off the lights individually. Is there anyway to either make the lights on the main buttons ON and OFF on the KPL not illuminate, or to reset them if the scene is activated? Just adding the button to its own scene and controlling it programatically is no good, because then the OFF button will illuminate, and I don't want that either. Also, setting the On LED level is out, because I want the other buttons A-D to toggle on and off to reflect the status of specific conditions. Thanks.

I assume the button works to control the scene, meaning I assume the databases in all the devices are correct. I don't think the KPL button needs to be a responder. Just a controller. The KPL has the group (scene) in its database, and when it hears the group command, it should update its light accordingly. This is my understanding of how the KPL works, and that seems to be backed up by my installation.