Goose66

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.

My ISY/99i throws an error every time I try to view the log. I finally rebooted, now its hardware locked (ERROR light flashing). I think I need another unit. Then I can try to work the Insteon instability problem out.

The Thermostat is a T1800 with a humidity sensor installed. While the temperatures and mode status in the ISY/99i for the thermostat always seem to be right, the humidity reading is hit or miss. Do you think the v2.0 thermostat adapter could be flooding my network with bad humidity data?

I have had a very stable Insteon installation for 2 to 3 years. v1 Thermostat, 2 v1 motion sensors, 3 KPLs, 8 or 9 SwitchLincs, and 8 to 10 light/appliance modules, 4 RAPs. While my previous software/PLC combination was never very stable or very good, the Insteon network itself has always been flawless, at least in the context of the flaws inherent in the system. A week ago I installed a v2 Thermostat and an ISY/99i PRO/PLM combo. While the ISY/99i itself works fairly well (it has some problems loading scenes completely from some devices), now my Insteon installation is starting to flake out a little. I have had two KPL buttons lose connetivity to their loads (at completely random times, not instatntly upon installation of the ISY/99), and one of the motion sensors now only occasionally turns its associated light on and off. I had zero problems with the motion sensor before the ISY/99i and v2 Thermostat. Even weirder, I have an old X10 switched light that I haven't used in years start coming on at random! I know the ISY/99i doesn't have to be operational or present for Insteon scenes to work, but does the PLM? Could a bad PLM be causing the flakyness (or the lack of the PLC in my system?) Does the ISY/99i affect the Remote Access Points at all or reset the topology for these? Has anyone else every had similar problems in conjunction with their ISY/99i?

Michel, Thanks for that. I did see that in another post and that will work in the near term. Instead of one state variable, I can have 6 programs for each state, and in the "Then" action section of each program, they can run the 'Else" action section of each of the other states, making the states exclusive. So running Sleep State Then will set Sleep State program to true, as well as set all the other states to false.

+ 1 for variables. It would be nice to persist state somewhere other than on a physical device. Even if it was as primitive as a fake device with an on/off state. I like to have a current state for my house, e.g. Morning, Day, Evening, Sleep, Vacation, Emergency. I can use the state in programs to determine how the response to certain actions should proceed. As far as a case statement, any ability to have nested IFs or Else Ifs would work. Else Ifs would also work in your GUI.