Goose66

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.

Having the admin console available from the UD website is nice for recovering a corrupt ISY-99i, for example when an update goes wrong.

Do any of these devices have upgradable firmware?

So if the KPL buttons are simple responders, then why can't I send them ON or OFF commands in ISY programs like I can all other devices? Is this a limitation of their "responderness," or simply an oversight in the ISY programming?

While I am very new to the ISY, I have used Insteon for a number of years, and much of the discussion in this thread is not consistent with my understanding of how Insteon works. Perhaps someone can tell me where my understanding falls apart: Programs and Scenes are completely different things. Programs execute in the ISY/99i and send Insteon commands (On/Off to scenes or devices) based upon the specified conditions (time, scene or device status, weather data, etc.) If the ISY/99i is not connected or not powered, programs will not run. Scenes exist in the Insteon network, and consist of links between devices. In the case of the ISY/99i, every scene on the Insteon network is store in the PLM's link database. This provides a single place for the ISY/99i to read scene data and to turn scenes on and off. The scenes also exist in the link databases of each device in the scene. Therefore, scenes work without the ISY/99i present or connected, and even without the PLM connected, although controllers will report errors (flash) if the PLM is disconnected, because the PLM doesn't respond in the scene. KPL buttons exist as controllers in scenes. The status light in the KPL button (a really bad idea, IMO) responds to local pushes AND to the on/off of scenes for which they are linked as a controller. There is no Insteon command to turn the light of a KPL button on or off, like you can with a responder (a load). For example, if I setup a scene with a KPL button as the controller and an ApplicaneLinc as the responder, then I can control the ApplicanceLinc with the KPL button. If I turn on or off the scene from the ISY/99i, then the KPL button light correclty reflects the the outcome. However, if I turn on or off the ApplicanceLinc directly, the KPL button light does not respond. The KPL button lights are not tied to the status of the load, they are tied to the scene.

As far as "KPL -A On", KPL Button A is a controller, not a responder. You can't set a controller on, only responders. By setting up a scene in ISY/99i, you are creating a scene on the PLM that is cross-linked with the KPL button A, just as if you had two switches cross-linked. When the Scene is set to on, the cross-linked KPL A button changes status to reflect the status of the scene. Similarly, pressing the KPL A button will turn on or off the scene. Just to clear up an area of confusion, the main buttons on your KPL (the big on and off, if that is how it is configured) are controllers as well, automatically linked to the responder in the unit.