August Posted October 18, 2012 Share Posted October 18, 2012 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 Link to comment
LeeG Posted October 18, 2012 Share Posted October 18, 2012 Is the DIM command being used or Fade Down command? Link to comment
August Posted October 18, 2012 Author Share Posted October 18, 2012 The Fade Down command is being sent--I will correct the original post. Link to comment
LeeG Posted October 18, 2012 Share Posted October 18, 2012 Thanks for the additional information. Fade Up/Down should be paired with a Fade Stop. Otherwise the Fade function is left half done with unpredictable results. When a button/paddle is pressed and held the device sends a Start Manual Change command, either Up or Down, to the Responders. The functional equivalent in an ISY Program is Fade Up or Fade Down. When the button/paddle is released a Stop Manual Change command is sent to the Responders. The functional equivalent in an ISY Program is Fade Stop. There are no exceptions. When a device initiates a Fade Up/Down operation it is always terminated with a Fade Stop. An ISY Program must follow the requirement and issue a Fade Stop at the end of a Fade Up/Down. What happens at a device if the Fade Stop is not issued varies from type to type. That is an exception condition, not documented or committed as to result. Link to comment
August Posted October 18, 2012 Author Share Posted October 18, 2012 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. Link to comment
LeeG Posted October 18, 2012 Share Posted October 18, 2012 Run Tools | Diagnostics | Event Viewer at Level 3. Run the various scenarios with the event trace running. It will show the commands executed. Any time the Fade Stop is not issued immediately after the Fade Up/Down (with appropriate Wait in between) it leaves the device exposed. Link to comment
August Posted October 18, 2012 Author Share Posted October 18, 2012 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. Link to comment
LeeG Posted October 18, 2012 Share Posted October 18, 2012 The commands are being executed according to the event trace. That means it is a KeypadLinc issue. Not much you can do about that unless it is a timing issue. What is the KPL firmware? The KPL firmware level is displayed below the device name in the right pane when the primary node is selected in the My Lighting tree. I test on that level if I have one. I tested this on a v29 KPL which is pretty old. It does not turn the load on to 100% when the Fade Stop is not issued. Works okay when I issue the Fade Stop 15 seconds after the Fade Down. Link to comment
August Posted October 18, 2012 Author Share Posted October 18, 2012 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"? Link to comment
LeeG Posted October 18, 2012 Share Posted October 18, 2012 I doubt the KPL is defective. I do have a KPL dimmer at v40. I'll see if I can recreate. It sounds like the Fade Stop Scene command did not make it to the KPL. No explanation why that Scene command would not arrive unless some other device activity generated some interference. I'll post back the results of my testing with a v40 KPL Link to comment
LeeG Posted October 19, 2012 Share Posted October 19, 2012 You may have a defective KPL or something else is in play that has not been recognized yet. When I issue a Fade Down (without a Fade Stop), using both a Scene with Main A as a Controller or with a Direct command Fade Down to Main A, the load fades down, the Main A button LED turns Off, and when I press Main A the load turns On to 100% On. It is a KeypadLinc 8 button Dimmer at v.40 with hardware revision 5.9. EDIT: forgot to add this variation. Adding a Wait 5 seconds followed by a Fade Stop does not change the result. Main A LED goes out, pressing Main A turns load on to 100% Link to comment
August Posted October 19, 2012 Author Share Posted October 19, 2012 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! Link to comment
LeeG Posted October 19, 2012 Share Posted October 19, 2012 I was thinking about a Factory reset of the KPL (KPL User Guide covers the procedure) followed by a Restore Device. Right click the KeypadLinc Primary node, select Restore Device. That will rebuild the link database that was erased by the Factory reset of KPL. I am continuing to test as well but I don't know what might be the key. Let me know the results if you do decide to do a Factory reset of the KPL. There is no issue beyond needing to Restore Device to rebuild the link database. What type of load is connected to the KPL? Link to comment
August Posted October 19, 2012 Author Share Posted October 19, 2012 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 Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.