Funky KPL comm. - what does this error tell me?

[ergodic]

I have a KPL which on occasion gives me a comm error pop-up in the ISY. ("Unable to communicate with...") This KPL is a V.2D. It is tied to an incandescent load. It mainly operates though a scene that is activated by an MS.

 

The error indicates no problem you see. The KPL seems to work fine regardless. So I never know the error's been logged until I actually go into the ISY console. But tonight it popped up while I was in. So in an uncharacteristic burst of ambition I decided to try and track it down.

 

When I operated the KPL locally or via the MS program in the ISY, it would respond and the ISY cleared the error flag. But when I then tried to query the KPL, the ISY would send three INST-ACKs getting no response and re-flag it "!". I tried this several times - consistent each time.

 

So I next factory-reset and then restored the KPL from the ISY console. Click-click-click right on through the reprogram. No delays, no errors. Nothing else going on in the house of course. And now a query works fine. Only problem is that I've tried the reset/restore several times before and sooner or later it always starts generating the sporadic comm error pop-up again.

 

I can't really add this up to much of anything. There's an SL dimmer in the same box which works fine and gives no error. It's a deep-well box with a fair amount of wiring running in and through it, but I've checked and re-crimped that box in the past and it's fine. I replaced all my V.35 buggy SLs over a year ago so I don't have that problem.

 

So what does this suggest?

 

1) The KPL is bad?

 

2) Some ISY/PLM issue?

 

3) Another device interfering?

 

4) Something else? Some other test to try?

[oberkc]

Is your error message always "unable to communicate with KPL", or is the communication error sometimes related to some other device, such as the motion sensor?

 

I vote for option 3. Have you tried a scene test on this scene or any others?

 

The thoughts going through my head is that is most likely a communication problem between your PLM and keypad. The problem could be interference at your PLM, so make sure your PLM is on a clean circuit.

 

On the other hand, if this problem is isolated only to this device/scene, and all others are showing no signs of slow communication, I would be tempted to identify everything that is on the circuit containing the keypad and removing loads, observing any improvement with the communication.

[LeeG]

ergodic

 

Replace the KeypadLinc with a new one. Tests by ELA show the latest devices are better at handling powerline interference and replacing the device is definitive. If that location continues to fail the device has been eliminated. Other sources of interference can be looked for.

 

Lee

[ergodic]

oberkc / LeeG: Thanks much for your suggestions.

 

There is nothing else on this branch or anywhere else with any chronic problem that I know of. It is a dedicated lighting circuit so at least there can't be anything new 'plugged in'. And I suppose this KPL isn't really having a "problem" either -- other than the sporadic comm message and the ISY query problem when that happens. It continues to respond fine to all scene requests, the ISY MS program, and other linked devices.

 

Seems an odd failure mode, but it wouldn't be the first time for that. So I think I'll try LeeGs suggestion first to replace the KPL with one of the spares I keep around. I don't have a "new" new one, I also don't relish the thought of going back into that j-box, but at least it should tell me something.

 

If that doesn't work maybe I should try a PLM restore? The links tables appear to match so I haven't done that yet.

 

FWIW this morning it had popped up again with the comm message so the reset/restore didn't 'take' for long.

[Illusion]

. I don't have a "new" new one, I also don't relish the thought of going back into that j-box, but at least it should tell me something.

 

 

This post has inspired me to write a new post:

 

viewtopic.php?p=53635#p53635

[ergodic]

I replaced the KPL, and immediately noticed the ISY was having problems trying to reprogram it. This is now quickly devolving into one of those pull-out-your-hair, no-kidding-really, Insteon comm problems.

 

This box has the KPL and another primary SL dimmer controlling two incandescent light loads. There are two more hot branches in the box going off to SL dimmers nearby. These other two dimmers are just for multiway control of the respective lights -- the load line on them is nutted off. (All dimmers are V.38, no V.35 stuff anywhere.)

 

So.... I disconnect both remote lines leaving just the two primary devices in the box, and everything works fine. A reprogram on the KPL runs right through with no problems.

 

Now If I connect either one of those two remote 'travelers', things degrade: one time it completed a restore-device on the KPL but with a lot of delays, and once it died with a failure to communicate. If I connect up BOTH remote device lines, the ISY can't complete a restore-device on the KPL (two tries with that). I'll have to repeat this experiment some more to be really sure of all this, but that's how it seems to stack up.

 

On one of the remote dimmers I hooked up the line and disconnected it at that dimmer, but it still had comm problems. Huh? What's up with that? I am pretty sure there's nothing else on these two spurs besides those SL dimmers.

 

So.... is this maybe some kind of marginal signal level on that branch? Seems strange if so, the run isn't that long and the two remote dimmers aren't more than 10' away. I've got APs all over the place and the house is only about 2000 sq. ft.

[ergodic]

This finally turns out to have been a failing access point.

 

I have two AC receptacles dropped down from both sides of the electrical panel in my garage. An access point is plugged into each. It turns out to have been most unfortunate to hide these behind the washing machine.

 

I'd given up on ever figuring this problem out. But I happened to look back there the other day and noticed one of the access point's lights was flickering madly, dimly and continuously and the other phase wasn't doing anything.

 

Replaced that AP and now everything is back talking at 100% again. It has also mostly ended the mysterious "unable to communicate" motion sensor pop-ups in the ISY.

 

So add 'failing access point' to 'RFI', 'V.35,' 'bad PLM,' and the other "X" communication factors to check when the problem is impossible to explain by signal quality issues alone.

 

BTW does anyone know why access points have Insteon hardware address labels?

[LeeG]

Every Insteon device has a PLM and that PLM has an Insteon address. There are commands that can be sent to an Access Point which requires the AP Insteon address.

[ergodic]

I suppose that's my question: what commands could you possibly send to an AP?

 

I did disassemble it this evening, and noticed it is clearly designed to accept a daughterboard. So possibly it can be morphed into something more advanced? And then that something else might need a hardware address.

[LeeG]

Many of the pluggable devices are built on that basic model. A PLM shell with the capability of adding a daughter card for individual device function. Many of the Simplehomenet devices are built around the basic Insteon pluggable device shell with a daughter card that provides the SHN device specific function.

 

There is nothing an application like an ISY sends to an Access Point. That is why Access Points are not defined as devices. They contain no link records and are not configurable. A developer subscription is needed to gain access to the confidential list of commands. Some information always leaks out. There are a few user hosted sites that list some of the Access Point commands. I saw one site document a method for querying an AP to determine which phase it is plugged into. Never tried the commands to see if the information was accurate. Some of the information is outdated and may no longer apply.