Getting Serious - When Comm issues strike

[IndyMike]

Hello ELA,

 

Extremely interesting traces. A number of questions and observations:

 

• 
  [*:22t0smnp] Ver 1.4 of the KPL (dimmer?) is rather old. This version predated the V.35 problem by around 2 years. Unfortunately I swapped out my older KPL's some time ago (had a habit of loosing their link tables) and have nothing to test.
  [*:22t0smnp] You mentioned that you had 2 "Signalincs" close to the problem KPL. Did you mean Switchlincs or Accesspoints? Either way they should be repeating the KPL signal since this is a standard message.
  [*:22t0smnp] If I understand you correctly, you are questioning why the repeated signals (1st, 2nd, 3rd hop) for the KPL are lower than that of the Outletlinc. There's no way to answer this without knowing exactly which devices are repeating and where they are located. I am wondering, however, whether it is the KPL that is repeating the outletlinc signal and producing the higher level. Would you mind "air-gapping" the KPL and running a trace on the Outletlinc?
  [*:22t0smnp] Measured at the PLM, the signal level of the KPL ACK is actually higher than that of the Outletlinc. This looks to be on the order of 100 - 150 mVp-p. That should be more than sufficient for the PLM to recognize the response regardless of what levels the hop1-3 transmissions are at. At one time I put my PLM behind a filter and determined it was able to detect transmissions through the filter at ~10 mVp-p. If you have a noise source nearby (could be out of band noise), the PLM may be activating its AGC and thereby ignoring the lower level signals as noise.

 

Could you try isolating the PLM and a Accesspoint on a filtered circuit? Note that if the noise is out of band, a filterlinc may not be very effective. A Leviton 6287 (Low pass) would be better. Note also that the CP-000 coupler (assume your still using this) will also roll off signals in the 60 Khz range. I've found this range to be typical for CFL's.

 

Very interested in your next steps. Let me know if you can think of a way that I can assist.

 

IM

 

Edit:Thank you for the layout diagram - Time to study!

 

I don't believe the following should be the case. If I understand the white paper correctly, the KPL should go mute after its acknowledge (I'm hoping that LeeG will correct me if I'm wrong here. Hops 1 -3 are handled by your Insteon network of repeaters. I don't understand why some would repeat while others would not.

As I see it the keypadlinc is intermittently failing to "sync up" with other devices on its hops. This results in too low of a signal level being returned to the sender on the ack message.

This can be seen by comparing to the nearby outletlincs hops levels.

[ELA]

Hi IndyMike,

Thanks for the reply, I made the "signallinc" correction (too many lincs

 

Yes this is an old device and I probably should just replace it.

 

What is more important is the level of the hops as measured closest too (not at) the PLM. They are much higher with the outletlinc.

Note the monitor location near the PLM is still 30ft away from it. I believe there is enough attenuation between there and the PLM that we are reliant on the hops, not the original send. I think this is confirmed by the traces with retries.

 

In my next test of air gapping the two switchlincs nearby I will also try air gapping the Keypadlinc and monitor the outletlinc in another test.

 

IndyMike said:

"Could you try isolating the PLM and a Accesspoint on a filtered circuit?"

 

not sure what you are getting at there?

[ELA]

 

If I understand the white paper correctly, the KPL should go mute after its acknowledge (I'm hoping that LeeG will correct me if I'm wrong here. Hops 1 -3 are handled by your Insteon network of repeaters. I don't understand why some would repeat while others would not.

 

IndyMike,

I think example 7 of the Insteon details explains that the Sender may go silent during the initial send hops but that the recipient will aid in the Ack msg. hops.

[IndyMike]

Hi ELA,

 

Responses and a few more questions -

 

Thanks for the reply, I made the "signallinc" correction (too many lincs

Actually, your diagram answered most of my questions (nicely done).

 

Q1) I can't tell from your diagram whether all of your devices are on the same phase or across phases. Please specify.

Q2) What is your primary mode of phase coupling (passive or Accesspoint).

 

I ask the above because I'm trying to find similar circuits in my home for comparison. Our homes are wired a bit differently. I used separate circuits for the lighting and outlets - coming up with an equivalent may be a challenge. I'm currently eying my family room which has high loading from the A/V components.

 

Yes this is an old device and I probably should just replace it.

 

I think we're alike in that we don't replace things unless we understand "why" they are a problem. At the moment, I'm a little hesitant to blame this on the KPL. However, if you can determine that this device doesn't "play well with others" it will change the approach that I take in trying to troubleshoot Insteon comms.

 

What is more important is the level of the hops as measured closest too (not at) the PLM. They are much higher with the outletlinc.

Note the monitor location near the PLM is still 30ft away from it. I believe there is enough attenuation between there and the PLM that we are reliant on the hops, not the original send. I think this is confirmed by the traces with retries.

 

In my experience, 30ft is not enough to present significant impedance at 130 kHz. If your experience is different, we have a fundamental different in the wire impedance between our homes. I'll agree that the PLM is having trouble discerning the signal level. I was indicating that this might be due to noise (possible out of band noise) activating the PLM AGC.

 

Q3) Do you have conduit in your home?

 

IndyMike said:

"Could you try isolating the PLM and a Accesspoint on a filtered circuit?"

not sure what you are getting at there?

 

This was an attempt to isolate the PLM from possible noise on the circuit. I actually should have asked whether this was a dual band PLM. I have never understood how dual-band devices determine which signal to use when confronted with both powerline and RF transmissions. I have encountered situations where there has been noise on the line at my PLM had problems dealing with. By placing the PLM on a filtered circuit with an Accesspoint I was able to restore communications via RF. You will loose 1 hop by going with this configuration.

 

As I alluded to in my previous post, the noise frequency is critical. A standard filterlinc may not reduce out of band noise significantly, thereby leading to the wrong conclusion.

 

IM

[Illusion]

Thanks so much for this post. It helps me to understand why I am having such a tough time troubleshooting a problem with 2 of my KPLs. Without detailed data such as you have, I pretty much am left to trial and error, which has not been working so well in my case.

 

I appreciate all the time that goes into producing a post like that last one.

[ELA]

Thank you for your post Illusion,

Hopefully we can all learn from each other and work together to make troubleshooting communications issues slightly easier than the trial and error method. I have had the luxury of being able to spend the (way too much) time it takes for this effort due to the slow economy.

If I were working full time again (soon I hope), I could not afford this kind of time.

[ELA]

IndyMike and I exchanged a few PM messages to address his questions.

 

One thing I wanted to highlight is the issue of when the sender aids in the hops and when it does not. I pointed to Example #7 in the Insteon Details doc with regard to the Acknowledge msg and that the Recipient will aid in the hops. I also mentioned that I think the Details doc we reference ( unless you are a developer) might be out of date and may not address all possible combination's of messaging.

 

In my testing I often have observed the original sender contributing (simulcasting) on its own msg hops, unlike what is shown in example 7 (old Aug ' 05 Insteon details doc).

 

Here is an example of one such exchange. This was performed with 1,2 and 3 repeaters, with the same result. It also appears that the result can be intermittently different, which occurred most often when using 2 repeaters, one sender and one recipient. This was in an isolated bench test setup (very reliable comm link).

[sanders2222]

All the posts by ELA are interesting reads just to help understand what may or may not be happening in our home environments. Thank you for your research.

 

A puzzling issue I find in my home is that about 50% of the time I access my ISY console, I get a "Cannot communicate with..." message. And the device identified seems to change randomly but are limited to my Outdoor shed, Outdoor driveway, entry stairs, Kitchen KPL and my EZRain controller.

 

Most of the time, if I check the devices under the Main tab, all seems to be reporting normally and statuses check out. I have seen red exclamation marks for the EZRain but if I query the device, that always clears up. I suspect at some point (before I call up the console), the ISY had trouble communicating with one of those devices, but without a clue where I may have Insteon suckers in my home, this is something I have to live with. (sigh)

 

It would be nice to identify which 'branch' the above devices are sitting on. Could it be the same one, though on different breakers? And where do I have Insteon suckers that I should fix, to improve the reliability?

[ELA]

Thank you Sanders2222,

I appreciate the feedback. As I work through my own issues I hope that it can be of some help to others as well.

 

It does sound like you have some communications issues to sort out as well.

 

From all that (I think) I have learned I believe the first item of importance is to identify the large signal suckers. Without a tool to do this it can be more difficult.

I hope to make this tool available to others some day if I can make it happen. In the mean time I would recommend software like houselinc that can run communications testing and generate reports. That can help you see what devices are performing worst. I do not own houselinc so I cannot provide a lot of direction there. My test device does this type of testing, and one better, in that it also reports marginal comms (where 100% of the messages are acknowledged, but using retries to do so).

 

Once you know who the worst performers are then you can run comm tests over and over on those devices while unplugging devices that might be suspect, looking for the success rate to increase. It can be very laborious and time consuming.

 

If you look through the various posts there are lists of items that may be signal suckers. Go for those first.

 

When I first started looking closer at communications issues I noted alot of people saying avoid surge protected plug strips. While this is true to some extent I would clarify, surge strips that incorporate an internal EMI filter (across the line capacitor) are the ones to avoid.

When buying a new plug strip make sure they do not advertise an attenuation figure (something like -40db from 150Kz - 1 mhz). I forget the exact text. If you already have them installed then it is more difficult to "know" if they have an internal capacitor, or how large it is, without a test device.

 

That being said, most of those are no where as bad as some TVs, receivers etc. that may incorporate even larger across the line capacitors.

 

How far reaching the negative effects of a signal sucker is can vary quite a bit depending upon where it is located and how severe of a sucker it is.

One approach would be to filter them all, but that may be prohibitive. It does become a lot of work to more selectively filter some and leave others unfiltered. Do focus on those that are on the same circuit (as problem devices) first, or if they are very close to the service cabinet.

 

I have not used all the diagnostic capabilities of the ISY99 that may be present in newer versions. Perhaps someone else can recommend how it can help? It would be great if it had a similar capability to the houselinc feature I mentioned?

[IndyMike]

ELA,

 

Your traces of the two PLM's interacting was extremely instructive. It clearly demonstrates that the "newer" Insteon PLM's are fully involved in repeating Insteon HOPs during both the send and receive. Your method of monitoring the PLM Microcontroller transmit pin was a stroke of genius. It further illustrates how sender and receiver "trade" HOP transmissions.

 

After seeing your post I became curious whether this was an enhancement that was included only on the PLMs, or whether it applied to all "newer" Insteon units.

 

I isolated my dual band PLM (V.92) and performed some tests on individual modules. Although I cannot monitor the transmit pin internally, I can see the presence/absence of hops due to the isolated nature of the system:

• 
  [*:1cildzwj]PLM linked to V1.2 KPL Relay (2486SWH6/firmware V.33/ Date Code 0903) - Similar results to your dual PLM Test. Fully populated HOPs with only two devices present - both devices participating in send/receive HOPs.
  [*:1cildzwj]PLM linked to V1.2 Icon Dimmer (2876DB/Date Code 0206) - No participation in Transmit hops. I hop repeated on Icon Acknowledge (PLM repeating?). This is similar to the White Paper description.
  [*:1cildzwj]PLM linked to V1.0 Icon Lamplinc (2856DB/Firmware V.28/Date Code 5205) - Identical participation to that of the Icon Dimmer.
  [*:1cildzwj]PLM link to Rev 4.15 ApplicanceLinc (2456S3/Firmware V.38/Date Code 0926) - Fully populated HOPs (Identical to your dual PLM setup.

 

As you had already surmised, SH appears to have "Enhanced" the communication protocol on the later modules (yes, the white paper is out of date). It's interesting to note that both of my modules that show "Full Participation" are also I2 capable and are date coded from the 2009 time frame.

 

Your V1.4 KPL is rather old (circa 2007?) and may not include the enhanced Hopping. This could explain some of what you were seeing in your traces on this unit.

 

Edit: I've deleted a portion of my earlier post as a result of additional testing using Scene Commands -

Just checked the "Hopping" of my old devices when used in a Scene. With the Icon LL and the PLM isolated, the scene command is fully repeated across the HOPs (1-3).

 

The plots below relate to "Direct Commands" which are not often used (other than from the ADMIN console). Scene commands should be fully repeated using both old and new units.

 

Thanks again for your help in deciphering current protocol. I'm six years into this and still learning,

 

IM

 

PLM Direct on command to V.33 KPL Relay - Full HOP Participation

 

PLM Direct on command to V1.2 Icon Dimmer - No HOP Participation

[sanders2222]

IndyMike

 

Thanks for your descriptions regarding the new/old PLM's. I am still using an old one and unknowingly solved my initial communication issues another way. After installing a Venstar thermostat I could not establish a good link between my ISY and the T-stat. But by moving one of my Access Points around to various outlets, I discovered that link became rock solid simply by plugging the AP directly into the PLM. If I understand things correctly, the AP should be more involved in receiving/transmitting signals that the PLM can hear. It would seem a dual band plug-in device could do the same thing.

 

Over the years I have added onto my devices and while things seem pretty reliable, recently I find Communication error messages cropping up whenever I come back to my Admin Console after leaving it awhile. These errors must be temporary in nature as any time I query that device, communication devices respond as they should. I find this puzzling but based on ELA's research, I probably have some signal suckers that are not obvious or easily identifiable.

 

Jim

[IndyMike]

Hello Jim,

 

From your description, you appear to have the older 2412S PLM (120V socket on front). I have both the 2412S and the 2413S (dual band) and don't honestly seen a difference in communication capabilities. There are definite differences in the link table memory and the processor speed between the two devices (the 2413S is faster and can access the link table quicker).

 

Beyond that, I do not have the Venstar thermostats and can't offer much help with troubleshooting here. I can see where Accesspoint placement could be critical here. In my experience, the accesspoints offer better range than the dual band devices.

 

In regard to the "nuisance" Communication error messages - are these associated with your RF devices (Venstar, motion sensor, etc) or wired devices? I do occasionally get communication errors with RF devices. I attribute this to the fact that I have 3 motion sensors in the kitchen (do NOT want to turn off the lights on the better half when she's working) that can all trip at the same time.

 

It is very rare that I have issues with wired devices. These should only occur after a "query" of the system. Do you have a program that periodically queries "My Lighting"?

[ELA]

Jim,

When I started this project my very first prototype was using a 5010K Ezbridge ( 2412S equiv.).

Qualifying that I only have a sample size of one here:

 

The 2412 was only 1/2 the output of the 2413 when driven into the same load (one switchlinc).

 

 

Throughout my development testing, using several test units I have been using ( (3) 2413S, appliancelinc, (1)indoor , (1) outdoor, lamplinc, access point, & (1) switchlinc .... I have found that all transmitters are not created equal.

 

I highly recommend a 2413 as a replacement for a 2412. You also get the dual band side benefit.

[ELA]

I have had intermittent comm issues with my original keypadlinc for a long time. The errors were very intermittent and did not cause a lot of headaches so I lived with it. Now that I am getting serious, and have the tools to do so, I looked into this issue.

 

First I ran tons of communications reliability testing on the suspect unit (in my home network) and found that even though the communications completion rate showed 100% there were retries often being used in order to complete the exchange.

I then monitored the signal with the Oscope and found that even though 3 hops were being allowed, the return message from the suspect device often only included one hop. If there were three hops present they would often be greatly reduced in amplitude.

 

I ran testing during all times of the day and got very intermittent results with no clear contributor (no signal sucking or noise issues).

The test would be 100% (no retries) for an hour or two, then it would experience a rash of retries and an occasional outright failed exchange.

 

My best guess was that the keypadlinc transmitter was failing to "sync up" with repeaters. I had no explanation for why other nearby devices would sometimes repeat that keypadlincs response message and sometimes they would not. After eliminating signal attenuation or noise sources as the cause, I elected to replace this unit.

 

I ordered a new keypadlinc and installed it. So far works fine. I have not had time to run reliability tests on it as of yet but will in the next few days.

 

What I did find time to do was to put the old unit I removed into a small isolated network and ran reliability tests on it. The small network consisted of a PLM tester as the sender, a switchlinc, a lamplinc, an appliancelinc and the suspect keypadlinc.

Initially it ran fine at 100% (no retries). I could see on the scope that once again there was often only one hop on the return message even though the sender was allowing for 3.

 

After about 10 minutes run time I started seeing retries. It then got a rash of them in a short time. I was able to observe on the scope that sometimes nobody would repeat the keypadlincs original message! Given that this is a very small isolated network, the originators transmit signal is still very strong (4-5V p-p). This should have been plenty for the receiver to recognize it. This leads me to further believe that the keypadlincs transmitter is possibly drifting in phase or just putting out an unrecognizable bit stream such that repeaters/receivers do not recognize it.

 

One thing I am sure of at this point is that this keypadlinc will never be re-installed again. It doesn't really even make a very good test unit since it is so intermittent.

I have recently been very focused on signal suckers and possible noise issue testing. I did not expect to find a flat out intermittently defective unit!

[Illusion]

Maybe you mentioned it somewhere, but I missed it...

 

What is the KPL version number (both hardware and ISY Firmware reported)?

 

I am also running tests on what I at this point believe to be intermittent KPLs, having run out of other ideas.

 

V2.D Firmware V1.8 Hardware

[ELA]

Hi Illusion,

R1.4 hardware, v29 firmware.

 

Last night I ran over 1200 send/receives over a 3 hour period on the newly installed Keypadlinc with 100% completion rate, no retries and as far as I know it never required more than 1 hop to complete ( That is currently a real time statistic in my code and I was not watching all the time ... this is a statistic I will now log in my code.)

 

I felt I was probably spending too much time testing and retesting before I decided to replace the switch. I wanted to be definite about the need before I did. With this followup testing I am now sure of the need and very happy with the new performance.

 

While there is no doubt that my older version keypad was an issue in my network I am not ready to claim that it might be more wide spread. I am doing a little more bench testing on the old keypadlinc.

 

In a previous discussion IndyMike and I had discussed the fact that newer revision devices are using a different variation of the hop scheme than what appears in the old version of the Insteon Details doc. The newer versions retransmit much more often (aid in hopping their own sends) than the older versions.

 

I have confirmed that my older keypadlinc does not assist in hopping of its own sends. If I run it with just one other device that becomes very obvious. I am a little suspect there could be a code issue associated with this keypadlincs failures but I cannot say for sure. I do not want to speculate on that any further.

 

I would recommend to anyone with keypadlinc issues, using older versions, to simply consider that the device itself may be at issue rather than your environment. As I said I tended to focus on signal suckers and potential noise issues and did not expect this.

Yet that being said I do not think this particular keypad ever performed up to par.

 

I want to caution that I am only speaking from a sample size of one here. So there are no assurances this issue is more widespread than my own experience. I look forward to hearing how you progress fighting your issue.

 

Best of luck

[ELA]

I just received a new PLM for a future 3rd prototype. I ran a quick test on it in the isolated test environment. Interesting results. This new PLM is newer than the other two PLMs I have built into ELAMs. The first two units are R1.4 hardware and V92 firmware. The newest PLM is R1.5 and V98!

That's a big jump in less than a year?

 

In the very same test setup I used PLM#1 to communicate with only one other device. I first used PLM#2 as the receiver, next is the new PLM#3, and last is that nasty Keypadlinc V29.

 

Below are the scope traces. Makes me wonder now about even newer enhancements?

 

 

Note how well the newest PLM3 "syncs" and adds to PLM1 in the hops. Quite a large signal level result.

 

I included the bottom for a visual to see how the Older keypadlinc does not participate in helping either the originators send hops or its own hops.

I left the bottom condition running for a while and it had terrible results. Out of 280 msg exxchanges only 73% completion, 40 completions required retries. Good riddance to that keypadlinc!

[IndyMike]

ELA and Illusion,

 

Recent events are leading me to believe that you both made the correct choice in replacing your older KPL's. Illusion and I had perform a good amount of comparison testing of our V.2d KPL's. We did this by compiling statistics on the number of HOP counts a KPL required during the course of a link table scan. A "Good" responding device would exhibit 90% or better responses with 2 HOPs remaining.

 

Illusions KPL's would exhibit variations between 100% 2-HOP responses down to out and out failures. There didn't appear to be any rhyme or reason to the failed link scans - things would simply degrade and then time out on re-tries.

 

I have been attributing this to noise present at the PLM causing it to activate it's AGC and thereby loose communications with the KPL. I've had similar events that I've traced to my post lamp photocell (oscillating at dusk). The point failure during this noise is the PLM. Moving the PLM to the opposite phase restores communications.

 

ELA's testing has taught me that the more recent Insteon units use an enhanced protocol which allows them to participate in responses. This has the effect of increasing the response signal level, and again allowing more responders to hear and participate in the communication.

 

I am still sticking with the "noise at the PLM theory". What I did not fully appreciate is the ability of the newer devices to respond properly (higher signal level) in the presence of noise.

 

Recent Events

• 
  [*:2xxolz6n]I finally yanked my oscillating photocell and installed a relay switch to activate my post lamp. After removing the photocell, I verified that my "dusk communication phenomena" was gone.
  [*:2xxolz6n]Installed a fancy "french door" refrigerator for the boss lady. No immediate impact on Insteon performance, until I began tabulating Link scan data again. I noted that my 2-HOP responses could very wildly from one run to the next. Units were still responding, but not as well as they had previously.
  [*:2xxolz6n]I realized that the refrigerator was again on the same phase as the PLM. Moving the PLM to the opposite phase cured the problem. This, in my mind, again indicated that noise at the PLM was interfering with it's ability to receive messages

 

The Test

Although moving the PLM to the opposite phase was a quick and easy way to resolve the noise issue, I was curious...I moved the PLM back to the "noisy phase" and began testing my various KPL's around the home. Most of these units are V.2B to V.2D vintage. I encountered sporadic issues while performing scans on all of these devices.

 

I realized that I had one new (V.8E) and one older (V.2C) KPL installed on the same circuit in my Master bedroom. I decided to perform head to head testing on these devices to see how they performed with my new noisemaker refrigerator.

 

Room Setup

• 
  [*:2xxolz6n] Master bedroom on dedicated breaker ~ 60' from panel.
  [*:2xxolz6n] Insteon devices - 1 V.2C KPL dimmer; 1 V.8E KPL dimmer; 1 V.28 Icon Switch
  [*:2xxolz6n] Loads: Panasonic 32" LCD, DVD, VCR, Motorolla Phone, 2 Clock Radios - no filters, no accesspoints.

 

Link Scan Setup

• 
  [*:2xxolz6n]The KPL's contain different numbers of link records. To normalize this, I manually scanned 256 memory locations (32 link records) from each device. In this way the time for each scan was the same and the devices were therefor subject to noise intrusion for the same period.
  [*:2xxolz6n]13 runs were conducted on each device. The runs were interleaved (Device A, Device in an attempt to normalize noise presence.
  [*:2xxolz6n]The Event viewer was saved after each run and analyzed using an Excel macro. Device hop count responses were tabulated - 512 HOP-2 responses results in 100%. Any hop 1 or 0 responses lower the communication percentage.

 

Results

The results are shown in the plot below and pretty much speak for themselves. Since I'm in a "wordy" mood, I'll go through them:

• 
  [*:2xxolz6n]In the absence of noise, both devices communicate with near 100% HOP-2 responses. You can't ask for better here.
  [*:2xxolz6n]Sporadically, the older (V.2C) KPL HOP count responses would degrade.
  [*:2xxolz6n]Link read failures were encountered during periods of noise (low hop count responses) and X10 communication. The combination resulted in re-tries and an eventual timeout.
  [*:2xxolz6n]Throughout the above, the V.8E KPL maintained 98% + Hop-2 communication reliability.

 

I still believe that noise at the PLM is the real culprit here. Since I'm still running an X10 system as well, I need to correct this. The improvements in the newer Insteon devices may not be a cure all, but they sure appear to offer communication improvements in the presence of noise.

 

 

[Illusion]

Thanks for all that work, IM. Very interesting reading and quite a profound chart.

[ELA]

ELA and Illusion,

 

Recent events are leading me to believe that you both made the correct choice in replacing your older KPL's. Illusion and I had perform a good amount of comparison testing of our V.2d KPL's. We did this by compiling statistics on the number of HOP counts a KPL required during the course of a link table scan. A "Good" responding device would exhibit 90% or better responses with 2 HOPs remaining.

 

Hi IndyMike,

I would say that a good device should exhibit 100% responses with 2 hops remaining and no retries required. I am not talking at the ISY level of retries but at the PLM level.

That is one of the advantages of my tester is that I monitor retries at the PLM level. As I posted I often observed 100% completions rates, yet retries were being used to accomplish this (at the PLM level, not at the ISY level).

 

 

I am still sticking with the "noise at the PLM theory". What I did not fully appreciate is the ability of the newer devices to respond properly (higher signal level) in the presence of noise.

 

I understand that you think noise is your issue. I am very confident that noise was not my issue. The keypadlinc is intermittently defective (in addition to using a weaker hop participation protocol .

 

[*]Installed a fancy "french door" refrigerator for the boss lady.

I still believe that noise at the PLM is the real culprit here. Since I'm still running an X10 system as well, I need to correct this. The improvements in the newer Insteon devices may not be a cure all, but they sure appear to offer communication improvements in the presence of noise.

 

Have you monitored the suspected offending noise? As I mentioned in a previous discussion I believe my refrigerator to be potential signal sucker that I am yet to investigate. I would not assume noise.

 

I also mentioned the potential "resonant" condition on that refrigerator circuit. One thing I did do is to confirm that if I add an additional Insteon load to that circuit that the suspect outlet location then reads a much lessor "suck value". I believe this again points to a resonant condition that is detuned by additional loads.

I will investigate this once I have time to remove the refrigerator.

 

I am now totally distracted by my recent ISY upgrade and resultant issues eating into my free time.

[ELA]

I have gone through the entire house and characterized each receptacle in terms of the "Standard Insteon load equivalent" that my test device measures when driving from that location. Via this process I have identified all known signal suckers. I have added one filterlinc and elected to leave a few known suckers unfiltered due to there being in a non critical area, or in an area with a number of Insteon devices, together able to overcome the sucker. Communications reliability tests then confirmed this decision.

 

In the course of this issue I ran into one receptacle that stood out over all others in the home as the worst case sucker. Yet this kitchen circuit had no Insteon devices on it and only a very limited number of appliance loads. I was able to unplug all loads on this circuit with the exception of the refrigerator. With only the refrigerator plugged in this location still measures a very unusually high "suck value". Up Until now the only reason I could think of to explain this phenomenon was a possible resonance at this location? Possibly caused by the refrigerator located upstream?

This was theorizing that the refrigerator represented a reactive load along with the circuit conductors.

From my experience thus far, and confirmed by readings at pt B, the refrigerator alone is not sucking that much!

 

I did not see this phenomenon anywhere else in the house except here. This is only a theory at this point until I am able to remove the refrigerator and test its suck factor directly (isolated from the circuit).

 

While testing This circuit I found that I had to expand the range of my tester. No where else house did I read anything over 6.5 Insteon loads. This test point was maxing out the device. I changed the design just for this instance twice upward until I no longer was maxing out the tester.

 

((Current maximum set at 10 Standard Insteon loads.

Note: I would not expect this level to be encountered under normal conditions due to wire impedance between devices, normally reducing the loading. ))

 

I wanted to put this out there as a very interesting situation, as of yet not totally understood. I do not want to speculate too far ahead until I can test the refrigerator directly.

Thought some might find it intriguing ?

 

Here is the layout and values recorded at each outlet on this circuit:

 

 

I decided to add a lamplinc to the end of this circuit for a test (and because I do want to switch a lamp located there). What I found as a result is very interesting. Notice how all the load readings went down substantially from point C outward. The readings closest to the refrigerator were mostly unaffected.

Seems like a resonant condition to me, when only one device (the test PLM) is in the circuit. With more devices the resonance is detuned and values change drastically.

In initial communications reliability tests I found this location E does relatively well (added lamplinc is a dual band device). Not perfect, but maybe good enough for now.

 

Once I find time to remove the refrigerator for testing I will have some decisions to make. If the refrigerator is a signal sucker, as I suspect, I may elect to filter it , but I would rather not if I can get away with it. There are space and a high current filter requirement to deal with.

 

I may find something else but that is my best theory at this point.

 

I will be interested to see what you find on your new refrigerator IM, if you should elect to look at it closer.

[ELA]

 

Room Setup

• 
  [*:2blthmdc] Master bedroom on dedicated breaker ~ 60' from panel.
  [*:2blthmdc] Insteon devices - 1 V.2C KPL dimmer; 1 V.8E KPL dimmer; 1 V.28 Icon Switch
  [*:2blthmdc] Loads: Panasonic 32" LCD, DVD, VCR, Motorolla Phone, 2 Clock Radios - no filters, no accesspoints.

 

 

IndyMike,

I have read your post several times now. I am curious where the LCD TV is in relation to the two keypadlincs?

I have a Panasonic 32" LCD in my master bedroom. It was one of three substantial signal suckers in the room.

I measured it at 3.5 Standard Insteon Loads. Depending upon its relative location it may be a good candidate for a filterlinc!

 

I elected not to filter mine as the TV was near the end of the line (downstream from Insteon devices). Also because I was trying to be conservative on filter use, being that I did have to add one to the satellite receiver in that room (that was at the head of the home run).

 

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

While testing my Kitchen cir. issue I was using my wife's laptop. I noticed that when I plugged it in that it also "detuned" my suspected resonance condition (before adding the lamplinc device).

 

This laptop power supply is a signal sucker registering 3.1 Standard Insteon loads.

 

I wanted to put this out there in case anyone might be in the habit of moving a laptop about in their home. It could create temporary localized communications issues. I was able to view the hops used increase in a comm test to the lamplinc when the laptop was plugged in.

[Rob]

I elected not to filter mine as the TV was near the end of the line (downstream from Insteon devices). Also because I was trying to be conservative on filter use, being that I did have to add one to the satellite receiver in that room (that was at the head of the home run).

 

Can you please explain why you are trying to minimize filter use? Is it simply due to the cost or is there some drawback to using too many?

 

Thanks

Rob

[IndyMike]

Hello ELA,

 

Apologies for the tardy response. It looks like I have a lot of ground to cover. This will be my first pass.

 

Hi IndyMike,

I would say that a good device should exhibit 100% responses with 2 hops remaining and no retries required. I am not talking at the ISY level of retries but at the PLM level.

That is one of the advantages of my tester is that I monitor retries at the PLM level. As I posted I often observed 100% completions rates, yet retries were being used to accomplish this (at the PLM level, not at the ISY level).

 

I both agree and disagree with the above:

• 
  [*:3i6apt5b]100% responses with 2 hops remaining: The data I presented was for device link table scans that required roughly 4 minutes to perform. This was a "real world test" with my family of 5 turning on devices, activating motion sensors, refrigerators, freezers, and well pumps. Given this normal amount of "transient" activity, I have no problem with the hop count dropping during the powerline transients. I have performed tests at 4:00 AM (my wake time) and they are 100% - but they are not real world.
  [*:3i6apt5b]no retries required: Here I do agree. To be honest, I had thought that ISY and PLM retries were one in the same. In looking at the ISY retries, I can see that a lot of time elapses between retires. I'm inferring that the PLM is performing retries in this time period and not informing the ISY. How are you monitoring PLM retires?
  

Thu 09/22/2011 07:26:12 PM : [iNST-ACK    ] 02 62 0A.DB.0B 0F 28 0F 06        SET-MSB(0F)
Thu 09/22/2011 07:26:21 PM : [iNST-ACK    ] 02 62 0A.DB.0B 0F 28 0F 06        SET-MSB(0F)
Thu 09/22/2011 07:26:30 PM : [iNST-ACK    ] 02 62 0A.DB.0B 0F 28 0F 06        SET-MSB(0F)	

 

I am still sticking with the "noise at the PLM theory". What I did not fully appreciate is the ability of the newer devices to respond properly (higher signal level) in the presence of noise.

I understand that you think noise is your issue. I am very confident that noise was not my issue. The keypadlinc is intermittently defective (in addition to using a weaker hop participation protocol .

 

As we have discussed, out systems appear to perform very differently. Yes I am confident that the communication degradation on my KPL is related to noise at the PLM. In fact, the noise affects all of my devices on that phase to a certain degree (a fact that I did not share). I can't accept the fact that all of my older KPL's are intermittently failing at a similar point in time. Therefor I attribute the failure to noise at the PLM (single point of failure).

 

I would be willing to exchange my KPL for your unit if you are willing to perform comparison testing. I have quite a bit of data on my master bedroom KPL. I would bolster this over a period of a week if necessary to come to a statistically significant criteria (26 + runs scattered over time). PM me if you are interested.

 

[*]Installed a fancy "french door" refrigerator for the boss lady.

I still believe that noise at the PLM is the real culprit here. Since I'm still running an X10 system as well, I need to correct this. The improvements in the newer Insteon devices may not be a cure all, but they sure appear to offer communication improvements in the presence of noise.

Have you monitored the suspected offending noise? As I mentioned in a previous discussion I believe my refrigerator to be potential signal sucker that I am yet to investigate. I would not assume noise.

 

I also mentioned the potential "resonant" condition on that refrigerator circuit. One thing I did do is to confirm that if I add an additional Insteon load to that circuit that the suspect outlet location then reads a much lessor "suck value". I believe this again points to a resonant condition that is detuned by additional loads.

I will investigate this once I have time to remove the refrigerator.

 

I have tried to monitor the noise but have been unsuccessful. Far too intermittent to catch with the oscilloscope. The Jury is still out on this one.

 

As far as the refrigerator circuit is concerned, our home wiring is again very different. I have a 15 amp dedicated circuit to the refrigerator alone (no GFCI). Code in 1999 required GFCI in the kitchen, with an exception that a dedicated appliance circuit could be non-GFCI. I took this route to prevent possible nuisance trips on the Fridge circuit. While this circuit is rather long, 130 Khz resonances should not be an issue since they would be terminated into the "very" low impedance at my panel.

 

IM

[Michel Kohanim]

Hi IM,

 

Just a quick note: PLM and ISY retries are completely different and independent from one another. You can configure ISY retries in the shell (CR) the default of which is now 2 (total of 3). The time elapsed between retries is configured by Protocol Timeout in the shell (CP) the default of which is 4 seconds. We do not know anything nor are we notified of PLM retries.

 

With kind regards,

Michel