Random KPL programming issues

[MikeB]

I'm experiencing some very odd KPL programming issues here that I wanted to share, and see if anyone else was experiencing.

 

I haven't spent time to troubleshoot the way I should yet, but maybe if someone else is seeing something similar it will help me track it down.

 

The scenario usually plays out like this:

 

- I decide to make dramatic programming changes on a KPL or 2 for some reason (I replace it, I change the buttons around, etc.)

- I sometimes completely remove the device, add it, and reprogram the links.

- Everything works great, but hours later I will notice that a DIFFERENT KPL is all of a sudden having issues. Either some of the buttons are no longer controlling the devices they should be controlling, or they are no longer sending their status to the ISY, or they are lighting up at times when they should not be.

- Running a restore device on the KPL does not seem to fix it.

- Removing the KPL from the ISY, re-adding it, and reprogramming the links fixes it.

- Everything works great until the next time I need to make changes or reprogram a KPL

 

Standard links between SwitchLincs never seem to get disrupted.

 

Anyone seeing anything similar?

[Mark Sanctuary]

I have noticed this too. I have found that every time I do changes that will affect several of the many scenes that all my KPLs share I have to wipe all KPLs clean and redo all their programming from scratch.

 

What I have done to make this easier is I have made a backup of my setup without all the KPLs. I keep hoping at some point this will be found as a bug and be fixable.

[MikeB]

Thanks Mark -

 

Now I don't feel so alone. The ease of programming the ISY makes it so easy to fix - I can't imagine having to reprogram each one so often with any other method!

 

But, I wonder what is causing this.

[Chris Jahn]

I don't know what could be causing this, but the next time it happens, could you try resetting the affected KPLs (air gap), and then running 'Restore Device' on them. It may help identify where the problem is.

 

When you removed/re-added the KPL, are you talking about the one you made drastic changes to, or the different one that started having issues.

[MikeB]

Chris -

 

I will try that next time it occurs (probably within a week because I'll be installing some new KPLs soon). I did try a "Restore Device" without air gapping, and that did not work.

 

I removed/re-added the KPL that was not behaving correctly.

[yardman 49]

Mike, Mark, Chris:

 

What you're seeing is all part of the general KPL weirdness that I'va also been experiencing with KPLs and how they interact with the ISY ever since I switched to the ISY. So now I don't feel like it's just me.

 

Basically, it seems that any kind of extensive scene involving mixed KPL primaries and secondaries can get weird and stop working when it used to previously work, when changes are made to its link tables.

 

It also seems as though "Restore Device" (up to version 2.4.15) really did not completely overwrite the existing link tables. I would think that this would be the desirable thing for it to do. And I believe that this is supposed to be fixed in RC1, although I haven't tried RC1 yet myself. Could you comment on this, Chris?

 

At least from my way of thinking, it would be great for the ISY to have the ability to completely obliterate any existing link tables through "Restore Device" and "Restore Devices", and replace it with exactly what you see in the GUI, even obliterating any manual Insteon links. It would seem that this approach would be able to fix any broken links and make everything happy again.

 

Best wishes,

[Chris Jahn]

The ISY keeps a copy of the link database fore each device, and Restore devices has always completely rewritten every link (and removed any remaining ones).

 

As of RC1, Restore Devices does more than write out the links, it now removes duplicate links, links to unknown devices, updates old PLM links, and moves KPL LED Links to the front of the database.

 

Recreating the link table itself, based entirely on the relationships shown in the GUI is a good idea, but something that will have to wait for another release.

[yardman 49]

Hello Chris:

 

Thanks for your explanation. The changes to "Restore Devics" in RC1 sound really good. And thanks always taking the time to help out here in the forums. As always, it is really appreciated!

 

**********************************************

 

Mike:

 

You wrote:

 

The scenario usually plays out like this:

- I decide to make dramatic programming changes on a KPL or 2 for some reason (I replace it, I change the buttons around, etc.)

- I sometimes completely remove the device, add it, and reprogram the links.

- Everything works great, but hours later I will notice that a DIFFERENT KPL is all of a sudden having issues. Either some of the buttons are no longer controlling the devices they should be controlling, or they are no longer sending their status to the ISY, or they are lighting up at times when they should not be.

- Running a restore device on the KPL does not seem to fix it.

- Removing the KPL from the ISY, re-adding it, and reprogramming the links fixes it.

- Everything works great until the next time I need to make changes or reprogram a KPL

 

 

-> In regards to the bolded text above, have you tried running the Restore Device with RC1? Based on Chris' explanation, it would be good to see if the new "links cleanup" performed by Restore Devices helps these situations.

 

-> In regards to your comments about multiple KPLs in n-way scenes failing after a major change: sometimes I can get them to work again by just removing all of their buttons from the affected scenes, then adding them back in, with the primaries going back into the scene last.

 

-> In regards to cases where buttons are controlling the wrong lights: I've seen this also! So I'm not crazy! Chris' solution to this is to actually add the misbehaving button to the affected scene, then remove it again. This actually works quite well. But hopefully RC1 has now fixed this issue.

 

Maybe we can report back to this thread as we begin gaining experience with RC1, to see if some of these issues have been resolved.

 

 

Best wishes,

[MikeB]

Yes, I was using RC1 when I had the issue a few days back, and Restore Device did not help.

 

I plan on testing further next time I encounter the issue, which will be soon because I have some new KPLs coming in.

[buzz]

I just started using ISY yesterday and have been wondering whats going on. I have a few scenes setup and everytime i turn one of them on, the correct KPL button turns on but random other buttons on other KPLs turn on too. No idea why and it's really frustrating. I'm using RC1 and tried airgap, etc and nothing worked. I think it's happening because when i added the KPLs I added some of them with "keep existing links" thinking it'll spider my network easier. Restore devices does nothing cuz i think it remembered the existing links. What i need is a tool similar to what i used to use in Homeseer where i can just view the link table and kill off anything that i dont recognize.

[buzz]

Okay so i managed to get it fixed. It was still annoying but better than having to remove KPLs and reset them completely. What I did was: for buttons that weren't supposed to light up in a scene, I add them to the scene, then remove them. That seems to clear out that offending button. So in other words, scene A should only light up status button C, but actually lights up both C & G, I manually add G to the scene even though it's not in the GUI, flip the scene on and off (not sure if this is necessary), then remove G from the scene. Now when I light scene A, only button C comes on like its supposed to.

[Michel Kohanim]

Hello buzz,

 

I am so sorry to hear you've been having these issues. We do understand the value of diagnostics/debugging tools and we are working on some as we speak.

 

Question:

1. By "turning on a scene" do you mean activation through ISY or activation by pressing a button?

2. Just to understand it correctly so that we can pinpoint the problem: you added some KPLs without importing existing links and some others with importing existing links?

 

Thanks so very much for the feedback/workaround suggestion,

With kind regards,

Michel

 

I just started using ISY yesterday and have been wondering whats going on. I have a few scenes setup and everytime i turn one of them on, the correct KPL button turns on but random other buttons on other KPLs turn on too. No idea why and it's really frustrating. I'm using RC1 and tried airgap, etc and nothing worked. I think it's happening because when i added the KPLs I added some of them with "keep existing links" thinking it'll spider my network easier. Restore devices does nothing cuz i think it remembered the existing links. What i need is a tool similar to what i used to use in Homeseer where i can just view the link table and kill off anything that i dont recognize.

[jdva]

I too have seen a lot of strange behavior with the KPL's. I really like them but, of all my devices, the KPL's are the most finicky and unpredicatable. They are atleast 5 times more likely to generate a "Request Failed!" than any other device in my system. I have two situations where I have a KPL and a switchlinc in a 2 gang and the switchlinc will do anything I tell it too but the KPL's will fail or be unpredictable most of the time. Often I have to remove it completely and do a hard reset and even that doesn't always work. I have one v1.5 (the new etched buttons are nice) and it seems a little better but not by much. It is often button A (6 button) that seems to give me the most trouble. I was trying to add the A button from two different KPL's to the same scene. One succeeded and the other died in the process. So I created a scene solely for it and eventually I was able to get it in the scene and do a restore device on it. However, when I push the button, some devices from the scene that failed before activate. Go figure?

 

-jeff

[Guest]

I have lots of request failed messages and failures to communicate with random devices. I did not have anywhere near as many problems with the PLC and I think its the PLM and nothing to do with the ISY itself.

 

Over on Techmall someone mentioned that the new PLM's have problems and we should wait for the even newer ones in the works (Version 62 or higher??). Not sure of the detials or accuracy of that.

 

I am thinking going back to houselinc, reprogram everything, and then use the crawl method with the ISY. I guess that will make more of a mess though when the PLM cant talk to all of the devices.

 

Seems like no easy way out of this at the moment. The ball is in SH court once again.

[MikeB]

I am thinking going back to houselinc, reprogram everything, and then use the crawl method with the ISY.

 

Big mistake. Fix your communication issues, then use the ISY/PLM to program your switches. If you can't get them to even program with the ISY/PLM without comm errors, what good will the ISY do you?

[Guest]

I am thinking going back to houselinc, reprogram everything, and then use the crawl method with the ISY.

 

Big mistake. Fix your communication issues, then use the ISY/PLM to program your switches. If you can't get them to even program with the ISY/PLM without comm errors, what good will the ISY do you?

 

Not disagreeing........ teh PLM often misses commands and locks up.

 

The communication issues are the PLM.... and who knows how long it will take for SH to fix that.

 

And I bet you will say its not the PLM and that you have no problems. I am happy you have no problems but others do. If the PLC communicates with very few if any problems and the PLM does not my conclusion is he PLM is not as 'robust" in communicating as the PLC and SH should make them about equal in communication strength. (I tested by using the same outlet etc).

 

Disagree all you want that is my opinion and possibly others as well.

[jdva]

I don't have houselinc or a PLC so I am kind of stuck with the ISY/PLM besides, I kind of like it. I do, however, have a 6.2 PLM and have only seen marginal improvements with communications issues. Operationally, my system seems pretty reliable. In a "Query all", I am likley to see only one or two random communication errors, usually these are corrected on the second try. Configuring it is a whole different story. I get a lot of "Request faileds".

 

I know there is a lot of effort put into trying to make HA "Easy" for the consumer, however, getting a "Request Failed" only adds to ones frustration level. I have no idea what failed or what succeeded. Which devices were touched and which ones were not.

 

It would really help to have more granular control over this process coming from the ISY. By that I mean, a drill down that lets me see which links succeeded and which ones didn't. Perhaps even, a link "map" for each device so I can see whats in its memory and repair specific links. Restore Device is fine but some capability to repair specific links would be even better. This could even be a seperate utility. I think even better logging of configuration actions would help.

 

I hope this doesn't sound like a rant, it's more of a suggestion. I like the ISY and my system. It's real close and I am willing to work with "whomever" to get it over the top.

 

-jeff

[MikeB]

Not disagreeing........ teh PLM often misses commands and locks up.

 

The communication issues are the PLM.... and who knows how long it will take for SH to fix that.

 

And I bet you will say its not the PLM and that you have no problems. I am happy you have no problems but others do. If the PLC communicates with very few if any problems and the PLM does not my conclusion is he PLM is not as 'robust" in communicating as the PLC and SH should make them about equal in communication strength. (I tested by using the same outlet etc).

 

Disagree all you want that is my opinion and possibly others as well.

 

My PLM hasn't locked up since initial programming, and I rarely see a PLM lockup post on here with the ISY, so I am surprised you are getting PLM lockups so regularly. But, if you say so, I believe that you are. Maybe you simply have a defective PLM if it's locking up so often with the ISY?

 

But, in any case, I'm just saying if you're getting comm errors, it doesn't make sense to try and work around them by programming your switches with the PLC and HouseLinc - because once you have everything programmed, even if you do get them into your ISY/PLM, you're not going to have a good, working system because you never solved your comm problems!

 

The PLM may not be as strong as the PLC, but it can be made reliable by filtering devices on your powerline and placing AccessPoints strategically. I suggest that to be your goal.

[MikeB]

I have no idea what failed or what succeeded. Which devices were touched and which ones were not.

 

I think UDI has said they plan to offer more detailed error messages in a future update. I agree that would be helpful.

[Sub-Routine]

...

 

I know there is a lot of effort put into trying to make HA "Easy" for the consumer, however, getting a "Request Failed" only adds to ones frustration level. I have no idea what failed or what succeeded. Which devices were touched and which ones were not.

 

...

 

-jeff

 

This has been a burr under the saddle since ISY Zero. I know the team is working on this.

 

Rand

[Guest]

Not disagreeing........ teh PLM often misses commands and locks up.

 

The communication issues are the PLM.... and who knows how long it will take for SH to fix that.

 

And I bet you will say its not the PLM and that you have no problems. I am happy you have no problems but others do. If the PLC communicates with very few if any problems and the PLM does not my conclusion is he PLM is not as 'robust" in communicating as the PLC and SH should make them about equal in communication strength. (I tested by using the same outlet etc).

 

Disagree all you want that is my opinion and possibly others as well.

 

My PLM hasn't locked up since initial programming, and I rarely see a PLM lockup post on here with the ISY, so I am surprised you are getting PLM lockups so regularly. But, if you say so, I believe that you are. Maybe you simply have a defective PLM if it's locking up so often with the ISY?

 

But, in any case, I'm just saying if you're getting comm errors, it doesn't make sense to try and work around them by programming your switches with the PLC and HouseLinc - because once you have everything programmed, even if you do get them into your ISY/PLM, you're not going to have a good, working system because you never solved your comm problems!

 

The PLM may not be as strong as the PLC, but it can be made reliable by filtering devices on your powerline and placing AccessPoints strategically. I suggest that to be your goal.

 

Yes it locks every few days. I also noted that in the middle of the day or night I get a communication failure on the screen and then I note its locked. That or in the middle of "trying" to create a scene. But its the OLD PLM (about 2.5 weeks) and maybe the newer ones are better. I am debating buying one or waiting a few more versions.

 

If the PLC can communicate then why cant the PLM? Because they goofed in the design and they need to fix it. The PLM is supposed to be a dummied down version of the PLC. If that is true then why did they change the communications strength? Was it to get people who upgraded to "buy more" filters, accesspoints" etc.?

 

 

SH plays these marketing games to sell more products but seem to upset a lot of people. Look at the keypad buttons. People will be forced to spend $50 more a switch now to get custom labeling they used to get for free. And that $50 is almost pure profit. The buttons are "Cheap" to make (I am in the mfg business and we pay less than 40 or 50 cents fro something like that with engraving in LOW quantities (a few thousand).

 

If you have an alarm keypad teh nylon membrane with all of the keypad numbers etc is less than a dollar with silkscreening.

[Guest]

Well just tried to link my Dining Room switchlinc to my Living Room Keypad. "Request Failed" on 3 out of 3 attempts.

 

So I started up Houselinc and I was able to link the first time. The difference is the PLM Versus the PLC.

 

I am sure some people will dispute this but not everyone has the same problems and doesnt mean that because they dont have it others dont.

 

I do not see why SH shoudl force people to buy more Accesspoints to use the PLM. It should be EQUIVALENT to the PLC as far as signal strength.

 

One opption I have is a 50 foot ethernet cable to drag teh ISY around teh house. and plug it in next to the device. It would be a PIA but it would work.

 

That or manually link them (which also works)

[Michel Kohanim]

Hello Jeff,

 

I am so very sorry to hear about all the problems you're having. We have found that KPL 1.5 might exhibit some unintended behavior when ISY programs it. We are trying to find the root cause and will try to fix it (if it's an ISY bug) as soon as possible.

 

With kind regards,

Michel

 

I too have seen a lot of strange behavior with the KPL's. I really like them but, of all my devices, the KPL's are the most finicky and unpredicatable. They are atleast 5 times more likely to generate a "Request Failed!" than any other device in my system. I have two situations where I have a KPL and a switchlinc in a 2 gang and the switchlinc will do anything I tell it too but the KPL's will fail or be unpredictable most of the time. Often I have to remove it completely and do a hard reset and even that doesn't always work. I have one v1.5 (the new etched buttons are nice) and it seems a little better but not by much. It is often button A (6 button) that seems to give me the most trouble. I was trying to add the A button from two different KPL's to the same scene. One succeeded and the other died in the process. So I created a scene solely for it and eventually I was able to get it in the scene and do a restore device on it. However, when I push the button, some devices from the scene that failed before activate. Go figure?

 

-jeff

[MikeB]

One opption I have is a 50 foot ethernet cable to drag teh ISY around teh house. and plug it in next to the device. It would be a PIA but it would work.

 

That might help to create your initial links, but how will that help in the long term? Eventually you're going to need to park the ISY/PLM somewhere, and leave it there.

 

If you want to use the ISY and PLM, you'll need to find a good spot for it and make sure you have good communication from there.

[Michel Kohanim]

Hello All,

 

Currently, and as the first step, you can open your Java Console and checkout the status of everything that fails including the failing device.

 

As Rand had suggested a long time ago (ISY Zero), this is something we are working on but since it touches upon everything else (logging) we have to be very careful as to when to create a release for it without impacting the current functionality.

 

Thanks so very much for all the suggestions and furthermore thanks for your patience,

 

With kind regards,

Michel