Problems restoring a KeypadLinc

[andrewm]

I have 6 KPLs around the house. They are all set up in 8-button (/ switch) mode, but actually have 6-physical buttons - so it's sort of working in a hybrid manner. I find this gives me the best flexibility. One consequence of this setup is that I have to cross link many of the KPL switches - eg the local load on the large button at the top can be controlled by underlying switch A or B.

 

I recently had a KPL failure where the device went completely blank and unresponsive. I factory reset it and then restored it from ISY. Most functionality returned OK, but I found that the internal crosslinks within the KPL didn't work. I assumed the KPL had an unrecoverable fault so purchased a new one from SH, but that exhibited exactly the same behavior when I restored that. In both cases the device link table matches the ISY link table.

 

AT this point I used my ISY with the original KPL that failed to create scenes with crosslinks that worked fine. So I guess my SH purchase wasn't necessary:(

 

It's a long time since I set these KPLs up so I'm wondering if I've forgotten something, or does the ISY restore not work for local crosslinks? Or is this a potential bug.

 

FWIW My current ISY verson is 2.8.1 and the KPL that failed was 1.6.5

 

 

Thanks,

 

- Andrew

[Sub-Routine]

Hi Andrew,

 

Did you create the cross-linking in the ISY? If not I don't think ISY can read the manual settings.

 

Rand

[andrewm]

No. This was all done via ISY scenes.

[LeeG]

Unless Smartlabs has changed the way KPLs work in relationship to Secondary button control of the Primary load button, none of that is done with conventional button linking within the same KPL. If you follow the User Guide instructions for linking a KPL Secondary button to button A and then display the device link database you would not find any link records related to the Secondary button. All that cross-linking is done with settings in device configuration storage, not the link database. Some KPLs require a power cycle for the device configuration storage updates to take effect when set through HA software/firmware. That power cycle is not required if the Secondary button linking is done using the firmware in the KPL itself.

 

Are you trying to use some partial 6 button configuration, large On button with small buttons where the large Off button location would normally be. Don’t immediately see the benefit if you are using the normal 6 button mode buttons in 8 button mode.

[andrewm]

If a power-cycle is necessary I'd like to see ISY displaying a popup reminder to that effect. However I just tried air-gapping the KPL, and the crosslinks still aren't working.

 

Thanks for the detail wrt the device links table vis-a-vis crosslinks. This raises the issue then that, while the ability to compare the ISY links with the device links is useful, it doesn't tell the whole story - eg, in this case these crosslinks won't be shown and therefore won't be verified. In which case, how are you supposed to diagnose this?

 

At this point I think I'll work-round this partial-restore by just recreating the crosslinks manually in ISY. But lack of a reliable / verifiable restore is a PITA.

[LeeG]

Some KPL revisions have a command that will cause the device configuration information to become active. For other KPL revisions the same command does not activate the changes so a power cycle is necessary. My experience with Secondary button linking to the local load is primarily related to PowerHome2. Because Secondary button linking (to the same KPL local load) is not done with convention links PH2 has a KPL specific GUI to define which Secondary buttons (if any) will control the local load. Actually not sure how that is accomplished using the ISY GUI. Of course if a Secondary KPL button is controlling the load of a different KPL conventional linking is used. That falls in the category of standard Controller to Responder linking.

 

When a KPL button is pressed the link database is searched for responders linked to that button. Even if a link record was written for the KPL Secondary button it would have an Insteon responder address of itself since the responder is really button A (or ON if 6 button mode). No Insteon device can communicate with itself over the powerline. In fact if the KPL issues a command and the command finds its way back to the KPL due to Hops it is considered a failure as the responder failed to send the required ACK.

[andrewm]

I just got bitten by this one again on v3.1.17. Again I had a misbehaving KPL, so after verifying that the ISY & device link databases matched, I decided to reset the KPL to factory config then restore the device config from ISY.

 

After doing this, the local "intra-KPL" button operations weren't working - eg pressing my master ALL AREA OFF button (H) didn't change the local load button (A), nor did it change the state of another button (D) which controls a separate linked device (though it did turn off the device itself). Everything else not related to intra-KPL links worked fine. So I deleted the KPL controller buttons from those scenes and re-added them as controllers and everything worked correctly including intra-KPL links.

 

So the act of restoring the device fails to completely restore KPL functionality ("RESTORE"), but the subsequent act of deleting and re-adding the buttons as a scene controller succeeds in fully restoring capability("RE-ADD").

 

Earlier comments indicate that intra-KPL link functionality is not achieved using the regular device links table. This would seem to indicate ISY needs to be sending other commands as part of its device restore functionality in order to achieve success. The very fact that we can "re-add" the intra-KPL links manually via ISY shows that ISY has the capability to perform the required functionality. Having to manually delete and re-add controllers is a pita!

[Michel Kohanim]

Hi andrewm,

 

It would really help us if we have an event viewer output so that we can debug and find root cause. Or, at the minimum, some history such as:

1. How was this device added originally?

2. What was the nature of misbehavior?

 

Obviously, had we found the bug, it would have been fixed and thus not a pita.

 

I appreciate your help.

 

With kind regards,

Michel

[andrewm]

Hi Michel,

 

1. The device was added initially via ISY - I don't do any non-ISY linking!

 

2. I can't be 100% accurate on characterizing the misbehavior. Iirc one aspect was that button A failed to operate the local load, whereas button B (which is linked to button A) would; I know that makes no sense, but I've seen that behavior on more than one KPL. The KPL is in 8-button mode.

 

Sorry, the earlier posts made me think it was being viewed as a feature rather than a bug, so I never thought to include logs. I'll have to remember in future if the problem recurs, or maybe purposefully factory reset a KPL and go through the procedure again but this time capturing logs. As things stand at the moment the devices are functioning correctly.

 

- Andrew

[ronbo]

Funny to come across this post. I had the clever idea that since everything was working so good, and I hadn't had to tweak any of my ISY settings lately, I would do a restore on my KPL's (Shoot me now!!). I lost contoll of all my scenes from my KPL's. It took me almost 5 hours to restore all of my Scenes. I had to go to any scene where I kad a KPL button as a controller to the scene. Remove the button from the scene, and then add it back. I then used the scene test functionality to assure it was restored. Also running 3.1.17 here

 

Ron

[Michel Kohanim]

Hi Andrew,

 

Thanks so very much for the detailed explanation. ISY does store everything that has to be restored in a configuration file including memory locations. An Event Viewer trace would be of great importance in finding any bugs.

 

Hi ronbo,

 

I am so very sorry to hear. Before restoring your KPL, did you do a compare to see if there are any mismatches? Also, what was the root cause of any problems before restoring the KPL?

 

With kind regards,

Michel

[andrewm]

We recently had a power outage here that resulted in me having to reset one of my KPL's and restore it. As expected from earlier in this thread the cross links didn't work post-restore, and required manual removal and re-creation.

 

However this time I logged the restore operation, as requested by Michel, and have attached it.

 

This was originally a 6-button KPL and now operates in 8-button mode. Iirc (I'm not near the device) buttons B, G & H all operate the local load (A) - others do as well, but I don't recall which off hand.

 

Hope the log helps nail this one.

 

- Andrew

EventLog.zip

[Michel Kohanim]

Hi Andrew, thanks so very much.

 

Can you tell me which firmware version is running in your ISY?

 

With kind regards,

Michel

[andrewm]

It should be 3.2.6

[Michel Kohanim]

Thank you Andrew.

 

Based on the event log, I think our next release will help (3.3.3). We were going to release it on Friday but had to postpone to fix a bug for DirecTV crashing the system.

 

With kind regards,

Michel

[andrewm]

Thanks. I'll look out for it.

[andrewm]

This happened yet again to me on two different KPL devices over the last few days. I'm now using rev 4.2.1, and had a power outage here causing failures on 2 KPL requiring reset / restore (as also documented in this other thread).

 

The link databases were compared after restore, but cross linked buttons in the same KPL didn't operate correctly and had to be deleted from scenes and re-added. Unfortunately I'd forgotten about this issue so didn't take logs.

[Michel Kohanim]

Hi andrewm,

 

Just to be sure what we are looking at:

Restore restored linkages between the KPL and other devices but not the linkages between the local buttons?

 

With kind regards,

Michel

[andrewm]

That's correct.

[Michel Kohanim]

Hello andrewm,

 

Thanks so very much. Do you have a KPL that we can possibly use for testing? i.e. change button groupings locally on the KPL and then try a restore?

 

The reason I ask is that I just tested this and could not reproduce. What's your KPL firmware version?

 

With kind regards,

Michel

[andrewm]

Isy reports 2486D v.2C. for both devices. I see I added additional notes for the devices into Isy that say "Purchased: 12/12/2006. Re-flashed by SmartLabs Jan 2008". So they're old - I'm amazed they still work!

 

I don't use button groupings but I can reset one of them and restore it and log the restore as well as any required additional delete/re-adds. Would that work for you?

[Michel Kohanim]

Hi andrewm,

 

Thank you.

 

I am so very sorry, what do you mean by "I don't use button groupings"? If not, then what's the issue (please see my previous post to which the answer was affirmative). In short, button grouping is equal to putting the buttons from the same KPL into the same scene.

 

With kind regards,

Michel

[andrewm]

"Button grouping" is an additional dialog accessed via the Isy admin screen for Keypads. It allows things like mutual exclusivity. I don't use that dialog

 

I do have buttons from the same KPL in the same scene.

 

If these are equivalent I didn't realize. Certainly looking now at a button grouping dialog, there's nothing that suggests to me that things are grouped in any way, but I may be misreading that dialog as I'm unfamiliar with it and I don't find the operation intuitive.

 

Does that clarify?

[Michel Kohanim]

Hi andrewm,

 

Thank you.

 

They are identical. The only advantage of putting buttons in the scene is that ISY can infer their status.

 

With kind regards,

Michel

[andrewm]

Based on what you're saying about these being identical I'd actually expect the button group dialog to change based on the scene membership of the KPL buttons. But that's not what I see - all the button grouping dialogs I checked in my system report the same 'basic' configuration - each button has a greyed out mark indicating it's a controller and no other buttons are checked at all as responders.

 

But that's really off topic as it looks like I'm doing things correctly by using scenes. Do you still want me to reset a KPL and log the restore?

 

- Andrew