August

Good news! The KPL factory reset and restore device procedure has solved the issue. The load is merely an incandescent lamp in my family room, but one that gets much use. I'm still uncertain what caused the odd behavior, but satisfied now that it's behind me. Your assistance is much appreciated! I will update my original post with the solution for future reference. -August

Thank you VERY much for your assistance and willingness to test this yourself. I'll continue to look into possible causes myself and post if I come up with anything. Is it possible that a reset, or restore would fix anything? I haven't had a need to do such a thing just yet and am unaware of the procedure and/or consequences... If you can, please advise. Thanks again!

It's a new KeypadLinc (2486D v.40), purchased through SmartHome about a month ago. Changing the 5-second timeout to 15-seconds makes no difference; same problem. I tried a query command (at both the scene and device level) after the Fade Stop command in step three. No luck. I also tried disabling the LED Update program I described in my initial post. No Luck. In doing so I found that it is actually unnecessary (for the load), although required for the remaining responders/buttons. Does this mean the KeypadLinc itself is faulty? The lamp in question (KPL "A" for that matter) is a responder for a few other scenes such as "All Off" and "Bedtime Shutdown." None of those scenes are being called to my knowledge, but is it possible that some scene is overriding the local control of KPL "A"?

This is the first time I've run those diagnostics--I've done my best to annotate them with my actions. It appears as if the stop command is being sent, but I inevitably get the 1% brightness upon power-up at the KPL afterwards. If there are any other glaring issues obvious from these diagnostics, please let me know : ) -August BEGINNING WITH A NORMALLY OPERATING KPL, AN 'ON' COMMAND IS SENT VIA KPL "A." THE LIGHT COMES ON AS EXPECTED. Thu 10/18/2012 11:24:40 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 11 00 LTONRR (00) Thu 10/18/2012 11:24:40 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:24:40 AM : [ 1C 8E 32 1] DON 0 Thu 10/18/2012 11:24:40 AM : [ 1C 8E 32 1] ST 255 Thu 10/18/2012 11:24:40 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 11 01 LTONRR (01) Thu 10/18/2012 11:24:40 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:24:40 AM : [iNST-DUP ] Previous message ignored. AN 'OFF' COMMAND IS SENT VIA KPL "A." THE LIGHT GOES OFF AS EXPECTED. Thu 10/18/2012 11:25:13 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 13 00 LTOFFRR(00) Thu 10/18/2012 11:25:13 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:25:13 AM : [ 1C 8E 32 1] DOF 0 Thu 10/18/2012 11:25:13 AM : [ 1C 8E 32 1] ST 0 Thu 10/18/2012 11:25:13 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 13 01 LTOFFRR(01) Thu 10/18/2012 11:25:13 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:25:13 AM : [iNST-DUP ] Previous message ignored. Thu 10/18/2012 11:25:14 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 13 00 Thu 10/18/2012 11:25:14 AM : [iNST-ACK ] 02 62 00.00.21 CF 13 00 06 LTOFFRR(00) THE IR COMMAND FOR 'FADE UP' IS SENT. THE LIGHT FADES UP AS EXPECTED. Thu 10/18/2012 11:25:28 AM : [ IR] 0001 Press Thu 10/18/2012 11:25:28 AM : [ Time] 11:25:30 2(0) Thu 10/18/2012 11:25:28 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 17 01 Thu 10/18/2012 11:25:28 AM : [iNST-ACK ] 02 62 00.00.21 CF 17 01 06 LTMCON (UP) Thu 10/18/2012 11:25:28 AM : [ Time] 11:25:30 2(0) Thu 10/18/2012 11:25:28 AM : [ Time] 11:25:30 2(0) THE IR COMMAND IS SENT AGAIN, TERMINATING THE FADE SEQUENCE IN MY PROGRAM. THE LIGHT STOPS FADING AS EXPECTED. Thu 10/18/2012 11:25:31 AM : [ IR] 0001 Press Thu 10/18/2012 11:25:31 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 18 00 Thu 10/18/2012 11:25:31 AM : [iNST-ACK ] 02 62 00.00.21 CF 18 00 06 LTMCOFF(00) Thu 10/18/2012 11:25:31 AM : [ Time] 11:25:33 2(0) Thu 10/18/2012 11:25:31 AM : [ 1C 8E 32 1] ST 147 Thu 10/18/2012 11:25:31 AM : [ Time] 11:25:33 2(0) THE IR COMMAND FOR 'FADE DOWN' IS SENT. THE LIGHT FADES DOWN AS EXPECTED (AND WILL DO SO UNTIL IT FADES OUT ENTIRELY) Thu 10/18/2012 11:25:41 AM : [ IR] 0002 Press Thu 10/18/2012 11:25:41 AM : [ Time] 11:25:43 2(0) Thu 10/18/2012 11:25:41 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 17 00 Thu 10/18/2012 11:25:41 AM : [iNST-ACK ] 02 62 00.00.21 CF 17 00 06 LTMCON (DOWN) Thu 10/18/2012 11:25:41 AM : [ Time] 11:25:43 2(0) Thu 10/18/2012 11:25:41 AM : [ Time] 11:25:43 2(0) NO FURTHER IR INPUT HAS BEEN SENT (WHICH WOULD SEND A 'FADE STOP' AT THIS POINT). INSTEAD THE PROGRAM'S BUILT-IN 5-SECOND TIMEOUT ACTIVATES THE SAME 'FADE STOP' AS EXPECTED. Thu 10/18/2012 11:25:46 AM : [ Time] 11:25:48 2(0) Thu 10/18/2012 11:25:46 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 18 00 Thu 10/18/2012 11:25:46 AM : [iNST-ACK ] 02 62 00.00.21 CF 18 00 06 LTMCOFF(00) Thu 10/18/2012 11:25:46 AM : [ Time] 11:25:48 2(0) Thu 10/18/2012 11:25:46 AM : [ 1C 8E 32 1] ST 0 Thu 10/18/2012 11:25:46 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 13 00 Thu 10/18/2012 11:25:46 AM : [ Time] 11:25:49 2(0) Thu 10/18/2012 11:25:46 AM : [iNST-ACK ] 02 62 00.00.21 CF 13 00 06 LTOFFRR(00) AN 'ON' COMMAND IS SENT VIA KPL "A." THE LIGHT UNEXPECTEDLY COMES ON TO JUST 1%. Thu 10/18/2012 11:26:05 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 11 00 LTONRR (00) Thu 10/18/2012 11:26:05 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:26:05 AM : [ 1C 8E 32 1] DON 0 Thu 10/18/2012 11:26:05 AM : [ 1C 8E 32 1] ST 255 Thu 10/18/2012 11:26:05 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 11 01 LTONRR (01) Thu 10/18/2012 11:26:05 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:26:05 AM : [iNST-DUP ] Previous message ignored. AN 'OFF' COMMAND IS SENT VIA KPL "A." THE LIGHT GOES OFF AS EXPECTED. Thu 10/18/2012 11:26:15 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 13 00 LTOFFRR(00) Thu 10/18/2012 11:26:15 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:26:15 AM : [ 1C 8E 32 1] DOF 0 Thu 10/18/2012 11:26:15 AM : [ 1C 8E 32 1] ST 0 Thu 10/18/2012 11:26:15 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 13 01 LTOFFRR(01) Thu 10/18/2012 11:26:15 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:26:15 AM : [iNST-DUP ] Previous message ignored. Thu 10/18/2012 11:26:16 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 13 00 Thu 10/18/2012 11:26:16 AM : [iNST-ACK ] 02 62 00.00.21 CF 13 00 06 LTOFFRR(00) A 'FAST ON' COMMAND IS SENT VIA KPL "A." THE LIGHT QUICKLY TURNS ON TO FULL BRIGHTNESS AS EXPECTED. Thu 10/18/2012 11:26:23 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 12 00 LTON-F (00) Thu 10/18/2012 11:26:23 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:26:23 AM : [ 1C 8E 32 1] DFON 0 Thu 10/18/2012 11:26:23 AM : [ 1C 8E 32 1] ST 255 Thu 10/18/2012 11:26:23 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 12 01 LTON-F (01) Thu 10/18/2012 11:26:23 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:26:23 AM : [iNST-DUP ] Previous message ignored. AN 'OFF' COMMAND IS SENT VIA KPL "A." THE LIGHT TURNS OFF AS EXPECTED. Thu 10/18/2012 11:26:29 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 13 00 LTOFFRR(00) Thu 10/18/2012 11:26:29 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:26:29 AM : [ 1C 8E 32 1] DOF 0 Thu 10/18/2012 11:26:29 AM : [ 1C 8E 32 1] ST 0 Thu 10/18/2012 11:26:29 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 13 01 LTOFFRR(01) Thu 10/18/2012 11:26:29 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:26:29 AM : [iNST-DUP ] Previous message ignored. Thu 10/18/2012 11:26:30 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 13 00 Thu 10/18/2012 11:26:30 AM : [iNST-ACK ] 02 62 00.00.21 CF 13 00 06 LTOFFRR(00) AFTER ~20 MIN AN 'ON' COMMAND IS SENT VIA KPL "A." THE LIGHT TURNS ON TO 100% AS EXPECTED. (THE 20 MIN. IS INSIGNIFICANT, I SIMPLY GOT AHEAD OF MYSELF AND BEGAN INTERPRETING THIS LOG BEFORE TESTING THE RESULT) Thu 10/18/2012 11:45:17 AM : [iNST-SRX ] 02 50 1C.8E.32 00.00.01 CB 11 00 LTONRR (00) Thu 10/18/2012 11:45:17 AM : [std-Group ] 1C.8E.32-->Group=1, Max Hops=3, Hops Left=2 Thu 10/18/2012 11:45:17 AM : [ 1C 8E 32 1] DON 0 Thu 10/18/2012 11:45:17 AM : [ 1C 8E 32 1] ST 255 Thu 10/18/2012 11:45:17 AM : [iNST-SRX ] 02 50 1C.8E.32 1E.48.26 41 11 01 LTONRR (01) Thu 10/18/2012 11:45:17 AM : [std-Cleanup ] 1C.8E.32-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 10/18/2012 11:45:17 AM : [iNST-DUP ] Previous message ignored.

Excellent! For anyone stumbling upon this in the future... By adjusting the On Levels of the two scenes at the scene-level, such that my 'Home' Scene has responder 'Home' set to 100% and responder 'Away' set to 0% (and vice-versa for the 'Away' Scene), I was able to eliminate the situation of both turning ON. I left my two programs described above as-is, and that eliminates the problem of both turning OFF. I did not test your second option, but that information is helpful to know. Thanks!!! ...I may now depart without fear of limbo, being neither home nor away. (Yet the alternative of being home while away at work is rather appealing...)

Previous posts have led me to that very line of thinking, and I feel that my program accommodates the required fade stop. The last step of a three-part chain is summarized as follows: If IR input (to terminate an already-active fade) is received Then Fade Stop Else Wait 5 Seconds Run [this program's] Then Path I felt the five second else statement would avoid any instance of a light fading out without receiving a proper stop command. For clarification, if it matters the entire procedure is accomplished as follows: (This is likely far more complex than needed, but its what I experimented with and found to work--until now.) Step One: (Look for light-specific IR input to fade up or down.) Per device, two programs look for IR input. One looks for an IR 'fade up,' another for IR 'fade down'. Once recognized, either program will run the Then Path of a light-specific Fade Up or Fade Down program described in Step Two. At this point, these two original programs are disabled, such that any further IR input is only fed to the Fade Stop program in Step Three. Step Two: (Initiate Fade) The Fade Up or Fade Down program runs, initiating a Fade command. The Fade Stop program used in Step Three (which is disabled by default) is now enabled. Step Three: (Look for secondary IR input to terminate fade) Once secondary IR input is detected, it tells the scene to stop fading. The original two programs from step one are re-enabled, and the step three program is returned to its default of disabled.

Thank you for your reply! I made those scenes and that will certainly work for me... However, in an effort to idiot-proof my setup (is there such a thing?!) I'd like to eliminate the possibility of having both "home" and "away" buttons turned off. I noticed this will occur if the lit button, whichever it may be, is pressed again. I thought that this program (along with a duplicate where home/away are swapped) would help: If Status 'Home Button' is off and Control 'Away Button' is switched off Then Set Scene 'Home' On Instead, if the lit button is pressed, both buttons go dark, and then immediately BOTH home and away come on... Is there a better way of achieving the desired effect?

The Fade Down command is being sent--I will correct the original post.

I'd like to setup two mutually exclusive buttons on my KPL for 'Home' and 'Away' that will update respective state variables. I'm a bit confused by my options--the wiki and UI seem to offer conflicting advice. The wiki entry describes a "Mutually Exclusive Buttons" button/window/process that I'm either overlooking, or has been changed. When I click the button that IS available to me, "Buttons Grouping," a window pops up warning me against proceeding, and advising me to create a scene instead. I'm not sure I understand how to do this via a scene, or whether the warning applies to my situation. I'm running firmware/UI v3.3.3. Thanks! -August

Edit: This issue has been resolved following a factory reset of the KPL and Restore Device through the ISY. Hello everyone! I've spent a month with the ISY and am very pleased. Following the advice of many, I went ahead and picked it up with my initial HA purchase. After lurking the forum a bit, I've decided to post with my first question/issue. I have a KPL-8 controlling several lamps individually, one per button. However, each of these lamps are most often turned off via a FADE DOWN command issued through their own ISY programs. The button LED statuses are set to update once their responder fades to 0% (see below) and that works fine. The problem is, after the KPL load (Lamp 1) is faded to 0% via a program (or the GUI), the physical KPL "A" button no longer turns on the load to my designated On Level (100%). It faintly powers on the light, and the ISY claims it is at 100%... But if I query the KPL while in this state, the ISY updates the Current State from the incorrect 100% to the actual 1%. This only happens with the load; all other lamps (and their respective scenes) controlled by the KPL are setup/programmed in the same manner*, and behave as I expect: after a program fades them to 0%, the button light goes off, and the next press of the button turns on the lamp to its scene-designated On Level. Why does the load behave differently, and is there a workaround? *The only difference is the 'Lamp 1' scene contains just 'Lamp 1' (KPL load), whereas the 'Lamp 2', 3, etc. scenes contain both the Lamps themselves and their respective KPL controller button. A few observations: -After becoming stuck at 1%, I can still FAST ON the load via the KPL, and this restores the expected 100%/0% toggle until the next time a FADE DOWN command is issued and allowed to fall to 0%. -If I interrupt the FADE DOWN with a STOP, the KPL remembers the load level and toggles between OFF and this remembered state. I've followed Rand's 2008 suggestion, and setup a program for each button LED to turn OFF as follows: (Is this technique outdated?) If Status 'Lamp 1' is off Then Set Scene 'Lamp 1' off Thanks in advance! -August