Jump to content

Need help with troubleshooting protocol


Recommended Posts

Posted

Hello Illusion,

 

I'm freely admit that I've overused the baseball analogy. I actually haven't been much of a baseball fan in the past 40 years (White Sox - that should say a lot). Nonetheless, simply saying "another interception" or fumble just doesn't have the right ring to it.

 

You've referred to this as a possible Home Run. I have to point out that it's more likely an instance of "hit by pitch".

 

I sincerely hope that the photocell is your culprit. This tripped me up some ten years ago when a "bad" photocell took down my X10 system for roughly a week. I literally could not communicate with any of my X10 devices reliably and thought that I had thrown every breaker in the house. I had not tried the breaker for my outside lights because they were all incandescent (with one photocell). The photocell finally degraded to the point where it blew the breaker and allowed me to diagnose the problem.

 

Fast forward 10 years - with my current photocell enabled, my system becomes unreliable around dusk (controls 3 - 25W incandescents). I believe the detector has degraded to the point where it is oscillating under fading light conditions. I have not been able to measure the oscillation frequency but believe it to be well away from the 120 KHz range.

 

A few notes here -

1) Noise analyzers like the ESM1 can be extremely helpful in detecting noise in the X10/Insteon range. This noise will hurt you. Unfortunately, noise sources outside the detection range may affect the device AGC (automatic gain control) and also affect communication.

2) When troubleshooting, we all (myself included) need to recognize when we are not in control of the powerline environment. I hit this a few weeks ago when I was performing the V.2D testing for you. Things were running "peachy" until around 7:00 PM when everything went down the toilet. Nothing that I could readily change improved things. It was at this point that I recognized that I was dealing with a noise maker that was either automatically activated, or outside my home. Two days later I pinned it down to the post lamp by taping over the photocell.

 

I hope the photocell turns out to be your culprit. I plan to bypass mine and activate with an Icon relay. Two failures in 10 years is too many for me.

 

IM

  • 1 month later...
Posted

Well IM,

 

Not so good. I did a 17 day test without the photo-cell powered. 8 back-light adjust failures.

The following 17 days with the photo-cell re-enabled I had 4 back-light failures. I do not think I can definitively blame the photo-cell.

 

I am going to try throwing money at this for a while. I have replaced one of the problem KPLs with the new Dual Band KPL. We will see how that goes.

 

I also have a replacement for the wake 3AM KPL. I have added that to my system as a new device and it is powered through an appliance cord pluged in along with the known problem 3AM KPL device. I also factory reset and added back as a new device the removed KPL and put it on an appliance cord as well. So now my situation looks like this:

 

Location #1

 

Original:

6 button v2.D KPL

 

Now:

6 button v.40 Dual-Band KPL

 

Location #2

 

Original:

8 button v2.D KPL

 

Now:

8 button v.2D KPL (same one still)

8 button v.39 KPL (will replace above if it fixes problem)

6 button v2.D KPL (from location #1 factory reset and added as new device)

 

All three KPLs at location #2 are on appliance cords plugged into the same place. I am interested to see if one fails while the others do fine.

 

I also have purchased replacements for all my v.35 devices. I am not going to install those yet as I want the environment to be as similar as possible for the next couple of weeks of testing. Then I will replace those and do some more testing.

 

Finally, I would like to say, I have never been able to pin any issue on my v.35 devices and they are essentially 100% reliable. I actually feel like I am giving in to peer pressure replacing them. But I am trying to look at it as expediting troubleshooting as I will no longer have to exception them out whenever I do tests.

Posted

Hello Illusion,

 

I have to hand it to you - you are methodical. Rolling up communication statistics over a 17 day period (34 days for both conditions) would make Taguchi proud. You wouldn't happen to be an Industrial Engineer would you (control charts and that whole thing)?

 

I'm sorry that we couldn't pin this down to a particular culprit (photocell). Nonetheless, "throwing money" at the problem (as you described it) may not be a bad course of action here. ELA has been teaching me a number of new things about "newer" Insteon units and how the Insteon protocol has been enhanced over the years.

 

Case in point is the manner in which "newer" Insteon units respond to "Direct" commands. Per the White Paper, older units would not participate in the repeated messages (HOPS) if they were the recipient of the command. Newer units do participate and will repeat "direct" messages addressed to them. This could mean the difference between success and failure in a noisy or high signal load environment.

 

I do not know whether the "backlight" command qualifies as a direct command or not. I'm hoping that someone with more experience with this command can clarify.

 

I also do not know whether the V.2D units qualify as "old" or "new" protocol in this regard. I do have some of the V.2D KPL's . If someone can verify whether the "backlight" command is a direct command, I'd be willing to yank one for some tests.

 

IM

Posted

IM

 

All device configuration commands are Direct commands. The variation is whether a particular device is being configured with Standard I1 Peek/Poke commands or Extended I2 Set/Get commands. Do not know what the ISY uses on that level KPL. An Event Viewer with Device communications events selected tracing a LED change operation will show whether using I1 or I2.

 

Lee

Posted

Not an engineer. Skilled labor. As far as methodical and patient, I did not have a choice. I have been trying to figure this out for several months now. I do not have the skills/tools to do the kind of analysis of my system that you have, and certainly no where close to the skills/tools (especially tools... I want me a tester) ELA possesses. So I decided to do slow motion trial and error. It is the only thing I can think of with a problem that refuses to cooperate with concentrated testing.

 

It was actually ELA's posts that made me decide to try new modules. Thanks for all your support. I will of course post results of the tests here when I have them.

 

Actually, now that I think about it, I seem to do a lot of slow motion testing. The 2 year motion detector battery test, the ongoing 1 year ghost on issue, and now this...

Posted

How Timely :)

 

I am trying to replace my suspect keypadlinc with a newly installed 2487S? I am not finding the option to replace the old 2486D?

I am running 3.1.6. Do i need 3.1.7?

 

After tons of testing I too am throwing money at the suspect keypadlinc :(

 

I will follow it up with bench testing of the unit I remove when I have time.

Posted
How Timely :)

 

I am trying to replace my suspect keypadlinc with a newly installed 2487S? I am not finding the option to replace the old 2486D?

I am running 3.1.6. Do i need 3.1.7?

 

After tons of testing I too am throwing money at the suspect keypadlinc :(

 

I will follow it up with bench testing of the unit I remove when I have time.

 

I do not think they let you replace a dimmer with a relay. I had to do it manually, painfully.

Posted

Thanks for the quick response.

Not the answer I wanted to hear though :(

 

41 links to reproduce would be painful indeed. Please tell me it isn't so. I was hoping to make the changeover a quick one. If I have to re-create everthing that will have to wait for another day. May have to put the old one back in for a while !

Posted

Lee,

 

Thank you for the quick response on the protocol for the device configuration commands. I verified that my V.2D units use I1 programming for both Link interrogation and Backlighting.

 

Illusion,

 

I'll try the V.2D units on an Isolated strip to determine if they will "participate" in the direct command HOPS. Today is shot - welding a door skin on my daughters mini-van (it is electrical work). I'll try to get to this next week.

 

ELA,

 

Ditto on replacing the "Dimmer" with a "Switch". The ISY restricts you to the same device type for replacement.

 

Thank you for pointing out the "enhancements" in the operation of the newer Insteon devices.

 

IM

  • 1 month later...
Posted
Well IM,

 

Not so good. I did a 17 day test without the photo-cell powered. 8 back-light adjust failures.

The following 17 days with the photo-cell re-enabled I had 4 back-light failures. I do not think I can definitively blame the photo-cell.

 

I am going to try throwing money at this for a while. I have replaced one of the problem KPLs with the new Dual Band KPL. We will see how that goes.

 

I also have a replacement for the wake 3AM KPL. I have added that to my system as a new device and it is powered through an appliance cord pluged in along with the known problem 3AM KPL device. I also factory reset and added back as a new device the removed KPL and put it on an appliance cord as well. So now my situation looks like this:

 

Location #1

 

Original:

6 button v2.D KPL

 

Now:

6 button v.40 Dual-Band KPL

 

Location #2

 

Original:

8 button v2.D KPL

 

Now:

8 button v.2D KPL (same one still)

8 button v.39 KPL (will replace above if it fixes problem)

6 button v2.D KPL (from location #1 factory reset and added as new device)

 

All three KPLs at location #2 are on appliance cords plugged into the same place. I am interested to see if one fails while the others do fine.

 

I also have purchased replacements for all my v.35 devices. I am not going to install those yet as I want the environment to be as similar as possible for the next couple of weeks of testing. Then I will replace those and do some more testing.

 

Finally, I would like to say, I have never been able to pin any issue on my v.35 devices and they are essentially 100% reliable. I actually feel like I am giving in to peer pressure replacing them. But I am trying to look at it as expediting troubleshooting as I will no longer have to exception them out whenever I do tests.

 

33 days of testing in as much the same system as I could maintain. The few changes I did make clearly made a big improvement though.

 

Results:

 

Location #1

 

The dual-band replacement had no failures.

 

Location #2

 

Original 8 button v2.D KPL had 3 failures

6 button v2.D KPL (from location #1 factory reset and added as new device) had 1 failure

8 button v.39 KPL had no failures.

 

Findings:

Either replacing one of the offenders with a dual-band device, or adding 2 more devices in with the other offender, or a combination of both dramatically improved communications.

 

Clearly the newer KPLs have superior communications. 3 devices plugged in inches from each other on the same circuit there were 4 failures of the v2.D devices with 0 failures of the new v.39 device right next to them.

 

At the completion of this testing I have also replace all my v.35 devices. I again maintain that I never found any failure I could attribute to them in tens of thousands of tests. In fact they were some of my most reliable devices. I am only swapping them because of the continued time necessary to exception them out any time I have a comm issue to troubleshoot.

 

So it looks like new KPLs in both locations is going to fix my issue. Probably cheaper that ELA's tester will be and I would have probalby had to buy replacement KPLs in the end anyway.

 

Final thought:

 

Once again, all these issues were caused by adding more Insteon devices (on a completely different circuit) to a perfectly functional system. Again, more Insteon devices is not necessarily better as the documentation would have you believe. Although sometimes it does make things better.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...