Some thoughts on phase coupling in relation to Access Points

[Illusion]

Hi all.

 

I have been in terrible trouble shooting hell for months now. I have spent the better part of the day today further tracking down my problems. I have some interesting data points that I want to share with others so you may benefit from my pain.

 

I have been having trouble with scene reliability. Today I tested a simple scene with just one responder, a newer appliancelinc v.32. I triggered this from the ISY GUI on and off buttons over 2000 times today with varying conditions and for the most part kept track of the results.

 

No matter what I seemed to do, and I did lots let me tell you, I could not get that 99% reliability we strive for. At one point, I air gapped or killed breakers to many of my Insteon devices. I put an Access Point in the back of the PLM, and ran an extension cord to the back of the Appliancelinc (always on outlet) which was plugged into the desired outlet on a different phase than the PLM. Into this extension cord I plugged another Accesspoint and placed it within 6 inches of the AP in the PLM. And yet I still suffered a 15-27% failure rate at triggering the scene! I did some querying of the Appliancelinc and was coming up with terrible hop count returns.

 

I pulled both APs and ran another series of tests with poor hop counts on querying and a a 20% failure rate to trigger the scene! So the APs did not seem to help my situation even though they were within inches of each other.

 

Tests were preformed using older ver 1.0R APs and newer ver 1.6 APs. One series of test was done with one older AP and one newer AP. Failed hops and failures to trigger the scene were statistically similar between these situations:

 

1. No APs at all (20% scene triggering failure rate)

2. 1 ver 1.0R and 1 ver 1.6 AP (15% scene triggering failure rate)

3. 2 ver 1.0R APs (27% scene triggering failure rate)

4. 2 ver 1.6 APs (27% scene triggering failure rate)

 

Each setup had 40 attempted scene triggering events from the ISY GUI.

 

Now here it comes.....

 

With no APs in my house at all now, I dug one of my old passive X-10 couplers out and plugged that in and my hop count instantly improved dramatically (to perfection mind you). Scene triggering saw a 100% success rate in this environment.

 

I put my system back together. This included putting the APs back in so the motion detectors and remotelinc and thermostats have something to talk to, but I left the passive coupler in and the last 110 attempts to trigger the test scene is at 100% success.

 

All I can take from this at this point is that accesspoints may suck! The APs did not seem to couple my phases at all in this test. In fact, while I did not enumerate it here, my hop count on querying was better with no APs (situation #1) than any combination of APs.

[TJF1960]

Great post Illusion, thanks for sharing.

 

Its funny, I have been meaning to remove my x10 coupler from the panel figuring I didn’t need it any more. But now, after reading your post I think I will leave it in the system.

 

After we replaced our washer and dryer about a year ago my x10 reliability went down the drain, previous to that I have probably a 99% success rate. Turns out it was the electronics in the dryer controls which were sucking the x10 signal down by about 50%. Most major appliances now have some form of electronics in them. I am sure you already have eliminated them from your system during troubleshooting though.

 

Anyway, thanks for the info., and good luck with your system.

[brobin]

Maybe that's why I have such a reliable system. I still have an ACT repeater connected at one panel and I have an XTB-IIR connected at the other. My Insteon reliability is 100% as is the transmission of X10 now (thanks to the XTB-IIR). Can't beat hardwired bridging! Smarthome offers their X10 hardwired coupler in the Insteon section as well so maybe they're trying to tell us something.

[markens]

I also had terrible communications issues for awhile, which I tracked down to two very specific (and unexpected) devices:

 

1) An old computer, which was plugged in to a UPS which was plugged in to the wall outlet via a filterlinc. The power supply was so noisy that neither UPS nor filterlinc was able to isolate it (either of which "should" do so). I ended up retiring that computer.

 

2) A Compac laptop power supply plugged in to a surge-protected power strip. When plugged in to the wall outlet directly (or any other outlet), Insteon communication was fine. But not via the power strip.

 

In these situations, both of these devices completely killed my Insteon reliability. X10 was fine however.

 

Moral: don't discount devices in situations where you think they "should" be ok.

 

(BTW, I use a hardwired bridge between phases, not access points.)

 

--Mark

[bpwwer]

I had an X10 coupler that I removed a few months back and thought reliability suffered slightly after I did this. So maybe I wasn't just imagining it

 

I have two of the original signalincs coupling the phase and one access point for motion sensors/thermostat.

[Rob]

I have the hard-wired insteon phase coupler and that (along with moving the PLM close to the breaker) made a huge difference. I only have one AP on the main floor for my RF devices. I get a consistant 2 hops remaining on almost every device in the house. Comms was never this good with the AP's.

[nstein]

Thanks Guys!

 

I have been adding access points (and filters) in an attempt to increase reliability, it is good but not as good as I think it should be, and with a few troubled spots.

 

I am up to 8 access points but they seem to do little good. They don't seem to help even when putting them right on top of a two devices that have trouble with each other.

 

I just got a hardwired phase coupler, I just need to figure where to put it (Full breaker box).

 

I am glad I am not imagining things,

 

Nick

[IndyMike]

Hello Illusion,

 

I'm happy to hear that your troubleshooting paid off. Passive phase coupling can certainly be beneficial to many installations (I have a hardwired coupler at the panel as well). However, as is so often the case, we need to be careful not to apply this as an absolute.

 

1) Your X10 coupler is tuned for 120 Khz carrier while Insteon operates at 131 Khz. The coupler will present an increased impedance in coupling Insteon from one phase to another (signal levels will be reduced).

 

2) Passive phase coupling requires that there be an Insteon repeater within "hearing distance" on both phases.

 

3) Passive couplers will also couple noise between the phases (AP's will not).

 

The above is intended for readers who may come across this post in the future. Illusion has gone through quite a bit of work verifying that this configuration works in his installation. This does not mean that a passive coupler is a cure-all. It may not improve performance for some, depending on signal absorption near the coupler and placement of Insteon repeaters. In rare cases (local noise) it may degrade performance.

 

With that said, I do believe that passive couplers can be very beneficial in many installations. We just need to be careful in interpreting the results.

 

All I can take from this at this point is that accesspoints may suck! The APs did not seem to couple my phases at all in this test. In fact, while I did not enumerate it here, my hop count on querying was better with no APs (situation #1) than any combination of APs.

 

What we can say here is that accesspoints do not appear to work well coupling the phases in your installation. While your extensive testing is entirely valid for your installation, it's a data point for the "community" as a whole. I firmly believe that AP's do work for many installs (I'm hoping that Steve Lee can chime in and expand on this).

 

Accesspoints can be critical to many "early adopters" who are just now installing I2 devices. The AP's are I2 capable and, for some, they may be the only I2 repeaters in the installation. Without the AP's, people may find that they are unable to program any of their newer devices.

 

Illusion - I have rewritten the above roughly 4 times and it still comes across as being critical. All I can say is that it is not intended to be. You've put in a lot of work verifying this in your installation and, given your methodical approach, I have no doubt that you've improved your reliability as a result. I'm simply concerned that others may view this as a "one size fits all" solution and may break their systems as a result.

 

IM

[Illusion]

No IndyMike, it is all good. I did not take it as critical. I do also see this as a data point for the community. That is why I took the time to write it up.

 

I will say this, my methodology was much more intricate than was fully described here. It would take hours to write up all the steps I took. I just wanted to share the rough results.

 

This event helps explain some of my very confusing trouble-shooting of the past months. I have a scene with 2 Lamplincs, 1 ApplianceLinc and one KPL on the same power strip (not surge suppressed of course). On this same strip I have an additional LampLinc that is not part of the scene. I have had terrible reliability triggering the scene from the ISY. I could never figure out why putting an AP in the same power strip did not fix my problems as I already had one in the back of the PLM. Well, this extensive testing seems to answer that! The AP was not doing its job in my case. I do not know why the APs do not seem to work for me.

 

1) Your X10 coupler is tuned for 120 Khz carrier while Insteon operates at 131 Khz. The coupler will present an increased impedance in coupling Insteon from one phase to another (signal levels will be reduced).

 

Maybe I will have to pick one of the new SignaLinc - INSTEON Phase Coupler, Hardwired on the next 20% off sale as this is tuned for 131 Khz.

[RatRanch]

Very informative thread! Here's a question. Can anyone who migrated from a mixed X10/Insteon environment comment about how removing *ALL* X10 devices from an installation affects Insteon reliability?

 

I still have a handful of X10 devices that perform their jobs with near 100% reliability but I understand that X10 circuitry attenuates Insteon signals (in theory, at least). Our current Insteon reliability is very good, but not perfect.

 

In the real world, is it worthwhile to remove all X10 from an Insteon installation?

 

Thanks,

-Jim

[IndyMike]

Illusion,

 

I do appreciate the amount of effort this took. I looked at the number of variables you were playing with and quickly understood you invested a lot of time investigating them.

 

Some time ago I ran similar power strip tests with the newly released I2 devices. I wanted to determine for certain whether my V1.0 AP's would repeat the powerline I2 during programming. I intentionally isolated the strip with a filter so that I could evaluate device to device communication separately from the rest of my installation.

 

Part of the above involved using RF to bridge from my house to the powerstrip (AP installed on the strip). Using this configuration I was unable to reliably program the I2 devices. Signal levels were good (as monitored by my scope) but the devices stubbornly refused to program properly.

 

Like your testing, the above is a data point. For some reason, the AP did not like the environment on the powerstrip. My AP's do function well in the house as I can disable my phase coupler and still maintain reliability (the passive coupler does save 1 hop from the opposite phase of my PLM).

 

I will say this, my methodology was much more intricate than was fully described here. It would take hours to write up all the steps I took. I just wanted to share the rough results.

 

This event helps explain some of my very confusing trouble-shooting of the past months. I have a scene with 2 Lamplincs, 1 ApplianceLinc and one KPL on the same power strip (not surge suppressed of course). On this same strip I have an additional LampLinc that is not part of the scene. I have had terrible reliability triggering the scene from the ISY. I could never figure out why putting an AP in the same power strip did not fix my problems as I already had one in the back of the PLM. Well, this extensive testing seems to answer that! The AP was not doing its job in my case. I do not know why the APs do not seem to work for me.

 

1) Your X10 coupler is tuned for 120 Khz carrier while Insteon operates at 131 Khz. The coupler will present an increased impedance in coupling Insteon from one phase to another (signal levels will be reduced).

 

Maybe I will have to pick one of the new SignaLinc - INSTEON Phase Coupler, Hardwired on the next 20% off sale as this is tuned for 131 Khz.

 

To be honest, I wouldn't mess with a good thing. Your testing indicated that your Insteon devices are close enough to the coupler to hear the transmissions and that you are not coupling excessive noise. You may find the need to resurrect one of your old X10 devices at some point (Christmas?). If so, the X10 will need all the help it can get.

 

Thanks for the post,

IM

[IndyMike]

Hello Jim,

 

I have a mixed X10/Insteon system as well. Assuming that your X10 devices are receivers (i.e. not 2-way devices) they will absorb less signal than a typical Insteon device. Two way X10 devices will absorb signals to a similar degree as Insteon.

 

At one time Smarthome actually listed the degree to which devices absorbed X10 signals. I can't seem to find that info anymore on their site. The best I could come up with is here: ToggleLinc Comparison

 

Very informative thread! Here's a question. Can anyone who migrated from a mixed X10/Insteon environment comment about how removing *ALL* X10 devices from an installation affects Insteon reliability?

 

I still have a handful of X10 devices that perform their jobs with near 100% reliability but I understand that X10 circuitry attenuates Insteon signals (in theory, at least). Our current Insteon reliability is very good, but not perfect.

 

In the real world, is it worthwhile to remove all X10 from an Insteon installation?

 

Thanks,

-Jim

[MikeB]

Thanks for the interesting post. While my system is rock solid (and has been for months), I have sitting on my shelf a 2406H hardwired coupler waiting to be installed whenever I have the time.

 

I currently use 4 APs - 2 in the basement near the panel to couple the power legs (one of them being right next to the PLM), and 2 others that helped resolve intermittent signals (1 out of 20 or so lost) in my 2nd floor bedrooms.

 

During past troubleshooting, I became convinced that, in my home, in many instances, adding Insteon devices simply eats up hop counts. I'm convinced at this point that in some cases using a passive hardwired coupler to bridge the power legs might improve things as it should save a hop count.

 

Though my system is solid, I can't help but want to improve it where I can.

[Illusion]

Two more long days of extensive scene testing. Too many situations and variables to list here. Thousands more scene activations, I stopped counting around 4000. Here are the highlights with some interesting data points for the community.

 

Extreme Scene Testing:

Hostile Insteon Environment.

 

Test #1 (100% failure rate)

No APs

No Air Conditioning or water heater coupling here or at the house closer to the transformer. I am two houses away from Xformer, so no coupling between me and the xformer. The next house further away is on the same transformer, but I cannot control their 220v devices.

No X-10 passive coupler

3 LampLincs v.33 and 3 ApplianceLincs v.32 plugged into 2 surge suppressed power-strips on same circuit 125' of wiring away from panel.

PLM on opposite phase, plugged in at panel

v2.7.5 ISY-26

v63 PLM

 

When I started this test I was going to tabulate each module's success or failure but after the first couple of attempts I saw that that would be far too time consuming for me. I instead decided that for it to count as a success, all the modules would have to respond correctly. This biases the results to high failure rate numbers because even if 5 of the six devices responded every time the report would show "100% failure rate" This seemed like an okay approach for my purposes because to me, if only some of the stuff responds to a scene command, it is a failure.

 

As expected, I got a 100% failure rate in this environment when triggered by the ISY. The funny thing is, no operation was a complete failure either. Some module would always respond correctly, just never all of them. I was surprised any ever responded.

 

Test #2 Add in a Non responder to try to repeat commands. (100% failure rate)

 

Added an Insteon module that was not part of the Extreme Scene. My thinking was that if some devices could hear the scene command, maybe a non responder in the circuit would hop it and get better results. Nope

 

Test #3 Put an AP in the circuit and in the PLM (100% failure rate)

 

As expected from my earlier post.

 

Test #4 Pulled Non-Responder Device (100% failure rate)

 

As expected

 

Test #5 Added Passive X-10 coupler to the system (11% failure rate)

Pulled the APs

Clearly showing the power of this little jewel

 

Test #6 Added Non-Responder back in (12% failure rate)

I guess I am not seeing much repeating going on in this test

Test #7 v.35 IconLinc Relays (4% failure rate)

Added 2 v.35 devices on each phase (these are my outside flood lights)

Removed the passive coupler

Removed Non Responder from circuit

 

I know there has been a bunch of negative talk about the awful v.35 devices, and I must tell you I was surprised by that result. I performed twice as many operations in this test expecting a run of failures to increase that failure rate, but no. Just posting my results. Not sure what to make of this with the problems other people are having with these devices.

Test #8 Add X-10 active coupler (6% failure rate)

Statistically insignificant difference

 

Test #9 Add X-10 Passive coupler back in (9% failure rate)

Statistically insignificant difference

 

Test #10 Try to trigger scene with a Controlinc plugged into same circuit as PLM (40% failure rate)

Showing two things. First that the PLM is not all that crappy at signal strength. Second, the Controlinc does not seem to be sending clean-up commands like I would have expected. See test #11

 

Test #11 Using a newer KPL plugged into same circuit as PLM to trigger scene (0% failure rate)

Yes that is right. Complete success. Funny stuff though. Clearly getting to that 100% with clean-up commands. It was funny watching one light come on after another. Complete scene execution could take several seconds.

 

EDIT 7-29-09: Flaw discoved in Test #10 and Test #11. The Controlinc and the KPL were plugged into a surge supressing powerstrip plugged into the same outlet as the PLM, this could have tainted these results.

 

Non-Hostile Insteon Environment.

 

Test #1(80% failure rate)

No APs

No Air Conditioning or water heater coupling here or at the house closer to the transformer.

No X-10 passive coupler

3 LampLincs and 3 ApplianceLincs plugged into same circuit 125' of wiring away from panel. Not Surge Suppressed this time

PLM on opposite phase.

v2.7.5 ISY-26

v63 PLM

 

Test #2 Put an AP in the circuit and in the PLM (90% failure rate)

Both v1.6

 

Test #3 Put an AP in the circuit and in the PLM (90% failure rate)

Both v1.0

 

Test #4 Put an AP in the circuit and in the PLM (100% failure rate)

One v1.6 and one v1.0

Statistically insignificant to test #2 and #3 based on only 10 attempts each of these tests,

Test #5 v.35 IconLinc Relays (30% failure rate)

Pulled the APs

Added in the same 4 v.35 devices from test #7 of the Hostile Environment Test above.

 

That is a big change from 4% in the hostile test, but I do not know what to make of it. As mentioned before, I do not control all aspects of my powerline.

Test #6 Passive X-10 coupler back in (12% failure rate)

killed the v.35 devices

 

Test #7 Add v.35 devices back in (11% failure rate)

 

Test #8 Put my whole system back together (3% failure rate)

Put my 3 APs back in their home.

Turn on my 220v devices

 

Now this surprised me a bunch. I performed at least twice as many operations here (100) looking for a failure streak. Clearly something was having some positive effect as that is a dramatic improvement.

 

This is where I could use some input from IndyMike. The only major change was putting the APs back in their homes, which was not on the circuit used for the test. One AP is on the PLM on Phase A and the other two are on Phase B, two different circuits and a different circuit than the Phase B circuit used for this test scene.

 

So I started thinking, maybe my APs are doing something for me in this setup. I had done another test in the Hostile Insteon Environment that was not listed. Actually I have dozens of test that are not mentioned here. I expected absolute failure in the Hostile Insteon Environment Test #1 but some of the devices always responded. Not always the same ones either, seemingly random, so I tried to isolate the circuit by putting a Leviton 6288 filter in before the power-strips but devices kept responding so I assumed that the filter was junk and pulled it and moved on. Well, now that my system is back together but with lower failure rates I decided to do another test. I isolated 2 of the modules after the 6288 filter. It worked. Total isolation and I could no longer control those devices. I added an AP after the filter and once again had control of the devices. Clearly APs do something, I just do not know why they do what I would expect in some situations and not in others.

 

IndyMike, could some components of the surge suppressing strips be de-tuning the 6288 filter? The filter did not seem to work very well when the strips were plugged into it, but when it was straight AC the filter seemed to be 100%

 

Summary:

I am not delineating between causation and correlation. I am only provided data points. I did find it interesting that in all these tests, different modules would respond each execution attempt. Very random. I was so surprised by the v.35 results I did another day of testing with just a single v.35 Switchlinc as the variable with over 1000 scene activations and I was unable to find any statistical influence on my system by the addition or removal of this device. I know others have had a terrible time with the v.35s, but I just could not get them to provide a consistent, repeatable, negative influence on my system. If anyone wants the raw data results of those 1000 tests, let me know and I will post another dissertation.

 

If you think this was a long post to read, think how long it took me to write. Or better yet, think of the hours spent setting up and performing the tests. I am done. No more testing for me for a while.

 

P.S. I only went through the trouble of this post because everyone seemed very interested in my original post. This is what happens when you encourage me.

[Michel Kohanim]

Hello Illusion,

 

Well, I actually did enjoy your post and I am so very surprised with your SWL 3.5 results. The main question I have is how far are these SWL 3.5s from your PLM and the next closest device to them?

 

Thanks for taking the time and providing this valuable feedback.

 

With kind regards,

Michel

[Illusion]

Careful there Michel, a question like that, centering around the v.35s leads right into my next full day of testing and another 1000 scene test. Tell you what, I have some other write ups to do by way of all this testing. When I am done with all those notes, and posts to the community, I will write up that test which does deal with proximity to the PLM

[TJF1960]

Hi Illusion,

 

That was a very thorough and informative post. Thank you for taking the time to post your results. I have been very interested in the outcome.

 

On the lighter side, Can you perform just 1 more test……

 

Thanks,

Tim

[Michel Kohanim]

Hi Illusion,

 

LOL ... Ok. I really do not want to create more work for you ...

 

With kind regards,

Michel

[Illusion]

Per your request, Michel.

 

Here are the test results from the v.35 centric testing. These tests were preformed in a more real world setting than the highly controlled set of circumstances of the previous test results posted.

 

Overall Test Environment:

My full system online.

3 APs at my house

2 APs at neighbors house (1 house closer to xformer)

About 15 X-10 devices

About 35 Insteon Devices

X-10 active coupler

X-10 passive coupler

4 v.35 IconLinc Relays (2 on each phase Apporx 25' of wire to the first one on each phase and about another 25' of wire to the other one on each phase.)

ISY 26 v2.7.5

PLM at panel v.63

 

Small Scene Test Sequence:

My AC and electric water heater disabled

3 LampLincs and 1 ApplianceLinc all on same circuit opposite phase from the PLM

Each scene execution repeated 100 times/scenario so 1000 total executions.

 

Test #1 Base Line (100% success rate)

 

Test #2 Add a v.35 SwitchLinc Relay (SWR) (100% success rate)

Added the SWR to same circuit as test modules (Non Responder to the scene and not installed as a device in the ISY)

 

Test #3 Move SWR v.35 to different circuit (97% success rate)

Different circuit but same phase as test modules.

While this circuit was on the opposite phase from the PLM, it was the nearest outlet I could get to the panel. I would guess 15' of wire away from the panel.

 

Test #4 Remove SWR v.35 and replace with SWR v.33 (99% success rate)

v.33 SWR not a responder to the scene and not a device in ISY

 

Test #5 Put SWR v.35 back in that circuit (98% success rate)

Added an additional AP to that same outlet

 

Test #6 Move SWR v.35 to same phase as PLM (99% success rate)

Removed added AP

 

The SWR was plugged into the nearest outlet on the same phase as the PLM without being that exact outlet. About 45' of wire away.

 

Test #7 Retest of Test#1 (98% success rate)

 

Test #8 Just the AP in close outlet (97% success rate)

Put an additional AP in the outlet about 15' away from panel

 

Test #9 v.35 SWR in same circuit as PLM (99% success rate)

 

Not a very valid test as I did not realize until later that the accessible plug in that circuit was a surge suppressing power-strip plugged into the same outlet as the PLM. I do not think it has much filtration as I have never had any issues with it, which is why I did not realize is was a suppressor until after all my testing was done. I have found it to have no measurable effect on Insteon. I cannot get a failed hop count through it, and it does not impede my control of devices plugged into it. But there it... is full disclosure.

 

Test #10 Retest of test #3 (99% success rate)

 

Large Scene Test Sequence:

17 -18 responders (depending on the inclusion the the test v.35 SWR) spread out over 2 houses and phases. Each house 1200 square feet each on 5000 square foot plots.

4 IconLinc Relays v.35

4 SWLs v.27

1 KPL v.2D

2 IconLinc Relays v.36

1 inLineLinc Relay v.33

2 ApplianceLincs v.32

3 LampLincs v.33

 

Each test repeated for 10 executions. These tests are not as statistically accurate as my higher execution test, but verifying the operation of 18 installed modules takes some time. The failure rate calculations done here are tallied differently that the in the previous post called Extreme Scene Testing. The failure rates are calculated by divided the number of device failures to respond by the number of devices that should have responded. So for a series of 10 executions with 18 responders where one device did not fire 5 times it would be 5/180 or 2.8% failure rate.

 

Test #1 With v.35 SWR as Responder. (2.8% failure rate)

SWR in opposite phase from PLM about 20' of wire away from panel

18 responders. 5 failures.

 

Test #2 With v.35 SWR as Responder (3.3% failure rate)

My AC always on

Neighbors AC always off *see note*

v.35 SWR on same phase as PLM about 45' of wire away from panel

18 responders 6 failures.

 

Test #3 No v.35 SWR (1.2% failure rate)

Pulled the v.35 SWR out of the game

My AC always on

Neighbors AC always off *see note*

17 responders 2 failures.

 

Test #4 Retest of Test #2 with AC different (2.8% failure rate)

My AC always on

Neighbors AC always on *see note*

v.35 SWR on same phase as PLM about 45' of wire away from panel

18 responders 5 failures.

 

*Note. I initially wanted to do real world testing without regard to phase coupling, but after Test #1, with 180 device executions, the only device failure was an ApplianceLinc at my neighbor's house. With only one device deciding the entire failure rate for the test I became concerned about the signal environment at that house tainting the results, so the next three test addressed this to some extent.

 

Very, very important little fact: In all these tests, with 710 device executions, only 1 module decided the failure rate. Every failure enumerated here was that ApplianceLinc v.32 at my neighbor's house. I had had a terrible time getting it into the scene to begin with. I have poor comms to that device. I had done some scene testing before I thought to add that ApplianceLinc in, and all those attempts were 100% successful though that was not shown in the test results. The other 17 modules responded perfectly in over 800 device activations, though they were not all tabulated here as I reset my count when I thought to add that ApplianceLinc in during Test#1.

 

Had I not put that ApplianceLinc in the scene, all results would have been 100% successful.

 

EDIT. 7-29-09 After testing had concluded my neighbor complained that she no longer had control of her lamp from her KPL. It was the offending ApplianceLinc in this test. I brought it back to my house and did a link compare on it, and it had a mismatched record. I factory reset it, restored it and put it back into service. I guess this calls this module's failures during this test further into question. I had mentioned I had a tough time adding it to the test scene. I tried, it failed, I restored it, which took forever as I left it at her house, and it failed again. I think it was the third try that worked, but I did not inspect the link tables until after the tests were complete and my neighbor complained that she could not turn it on anymore.

[Michel Kohanim]

Hi Illusion,

 

Thanks so very much for the detailed analysis. It seems that, for whatever reason, when you add the SWL .35 to a different circuit, the failure rate increases just slightly (1%). As such, I also believe that the original problem could NOT have been the SWL .35 but the ApplianceLinc. Is it under warranty?

 

Thanks again so very much.

 

With kind regards,

Michel

[IndyMike]

Hello Illusion,

 

I've been going over your data trying to come up with a reasonable explanation for the questions you posed (I've got plenty of unreasonable explanations). Unfortunately, I have more questions than answers.

 

I'm assuming that you were using the scene test to tabulate the success/failure of your communications - please confirm.

 

You mentioned that your initial test setup included 3 lamplincs and 3 applincs on two surge suppressed power strips.

 

1) Did you have loads connected to all of these devices - if so what type and wattage?

2) Did you perform the scene test with all the devices in the on state?

3) What was the mix of devices on each powerstrip (e.g were all LL on one strip)?

 

Extreme Scene Testing:

Hostile Insteon Environment.

 

Test #1 (100% failure rate)

No APs

No Air Conditioning or water heater coupling here or at the house closer to the transformer. I am two houses away from Xformer, so no coupling between me and the xformer. The next house further away is on the same transformer, but I cannot control their 220v devices.

No X-10 passive coupler

3 LampLincs v.33 and 3 ApplianceLincs v.32 plugged into 2 surge suppressed power-strips on same circuit 125' of wiring away from panel.

PLM on opposite phase, plugged in at panel

v2.7.5 ISY-26

v63 PLM

 

The following test I do not understand. Were you testing just the two V.35 relays or did you add these to the initial group of 6 devices?

 

Test #7 v.35 IconLinc Relays (4% failure rate)

Added 2 v.35 devices on each phase (these are my outside flood lights)

Removed the passive coupler

Removed Non Responder from circuit[/u]

 

I think you summarized my sentiments in your comment below. No one controls all aspects of the powerline. Even so, the 30% failure rate of this configuration, with 0 phase coupling, is a marked improvement over the previous configurations.

 

Test #5 v.35 IconLinc Relays (30% failure rate)

Pulled the APs

Added in the same 4 v.35 devices from test #7 of the Hostile Environment Test above.[/u]

 

That is a big change from 4% in the hostile test, but I do not know what to make of it. As mentioned before, I do not control all aspects of my powerline.

 

I'm missing something in the data below. You had other test results that indicated similar performance. What leads you to believe that this is a marked improvement?

 

Test #8 Put my whole system back together (3% failure rate)

Put my 3 APs back in their home.

Turn on my 220v devices[/u]

 

Now this surprised me a bunch. I performed at least twice as many operations here (100) looking for a failure streak. Clearly something was having some positive effect as that is a dramatic improvement.

 

This is where I could use some input from IndyMike. The only major change was putting the APs back in their homes, which was not on the circuit used for the test. One AP is on the PLM on Phase A and the other two are on Phase B, two different circuits and a different circuit than the Phase B circuit used for this test scene.

 

In reference to the below - I started replying to your post yesterday and had a great explanation. I was thinking that the 6288 was a bandstop filter and had all kinds of nice details on how component tolerances can adversely affect the performance.

 

The I remembered that the 6288 was a low pass filter - I hate it when reality strikes. I'm working on a couple of theories, but they're out there a bit. Your answers to the questions above will tell me whether I have a snowballs chance... or if I'm full of doodoo (smart money is on the latter).

 

So I started thinking, maybe my APs are doing something for me in this setup. I had done another test in the Hostile Insteon Environment that was not listed. Actually I have dozens of test that are not mentioned here. I expected absolute failure in the Hostile Insteon Environment Test #1 but some of the devices always responded. Not always the same ones either, seemingly random, so I tried to isolate the circuit by putting a Leviton 6288 filter in before the power-strips but devices kept responding so I assumed that the filter was junk and pulled it and moved on. Well, now that my system is back together but with lower failure rates I decided to do another test. I isolated 2 of the modules after the 6288 filter. It worked. Total isolation and I could no longer control those devices. I added an AP after the filter and once again had control of the devices. Clearly APs do something, I just do not know why they do what I would expect in some situations and not in others.

 

IndyMike, could some components of the surge suppressing strips be de-tuning the 6288 filter? The filter did not seem to work very well when the strips were plugged into it, but when it was straight AC the filter seemed to be 100%

 

Thanks for all the work, both testing and reporting. Unfortunately I think it's overstimulated my brain. I need to do something mind numbing for awhile...

 

IM

[Illusion]

Hello Illusion,

 

I've been going over your data trying to come up with a reasonable explanation for the questions you posed (I've got plenty of unreasonable explanations). Unfortunately, I have more questions than answers.

 

I'm assuming that you were using the scene test to tabulate the success/failure of your communications - please confirm.

 

Hi IndyMike,

 

No, not using scene test. Using the on and off buttons for the scene in the ISY GUI. Using visual for tabulation with the exclusive exception being Large Scene Test Sequence where I used a query on the scene to tabulate results. Some background is required here. When I started this thread, it was because I came up with some interesting results related to the APs that I wanted to share with the community, but this was not the point of my testing. As mentioned, I have been having a terrible time trouble-shooting poor reliability with scene activation. After hours on the phone with 3 guys from UD, Michel became convinced that my problems stemmed from my v.35 devices. I decided the only way for me to verify that was to start extensive testing. I had not intended posting many of the results that I did post in the end. I had not expected the community to be very interested in all that, but I reevaluated this after receiving so many responses to the initial post.

 

I avoided scene test for several reasons. First, I had read that the hop count used in scene test may not be the same as normal scene activation. Second, I am not sure that the scene test uses the same command to trigger a scene. It may be using the group command and the normal scene activation in the ISY I do not think uses that. I am a little out of my league on this point so I just tried to avoid it. Third, I was trying to send the very commands I was having so much trouble with so I could see what would fix it. I figured the GUI buttons for the scene would do that. The basic tenant of the test was to create a high probability of failures due to system design so I could get some statistically significant data on the effect of adding v.35 devices to a system that was right on the edge of working to begin with. This is because I had read that many installations with lots of v.35 switches were not having problems, yet some others had their entire system reliability trashed by adding a few v.35s. I figured a barely working system would clearly show the detrimental effects of the terrible v.35 devices and then I would feel justified calling Smarthome and demanding replacement for their defective products. My testing thwarted that. I will not be requesting replacements for these items based on my test results.

 

You mentioned that your initial test setup included 3 lamplincs and 3 applincs on two surge suppressed power strips.

 

1) Did you have loads connected to all of these devices - if so what type and wattage?

2) Did you perform the scene test with all the devices in the on state?

3) What was the mix of devices on each powerstrip (e.g were all LL on one strip)?

 

1) 60W - 100W incandescent light bulb loads connected to each module.

2) No scene test. On button counted as 1 execution, Off button counted as one execution. Also, please note that not every test got the same number of attempted tabulated executions. While this may not seem scientific, I have a good reason for it. For those first tests with 0% failure rate, each test only got 10 tabulated attempted executions. But for a tabulated execution all the lights would have to be off, then an on scene execution would have to turn all the lights on to get counted as a success, or conversely, all the lights would have to be on and then turn off in response to an off scene execution. For those first few test I could have done 1000 tabulated results and it still would have been a 0% success rate. To get from the first attempt (turning the scene on) to the second attempt (turning the scene off) I needed to get all the lights on first. That took like an extra 8 triggers of the scene. Same thing for every attempt, and this is why I gave up on the full tabulation. I would have no way of knowing who was responding or not for all those extra attempts. For the later tests, where I was actually seeing some success and not having to spend all that extra time reseting for another attempt, I did perform more tabulated results for better metrics.

3) One powerstrip had 2 LampLincs and 1 ApplianceLinc and the other had 2 ApplianceLincs and 1 LampLinc. Powerstrips were identical models plugged into a current tap plugged into extension cord plugged into outlet.

 

 

The following test I do not understand. Were you testing just the two V.35 relays or did you add these to the initial group of 6 devices?

 

Test #7 v.35 IconLinc Relays (4% failure rate)

Added 2 v.35 devices on each phase (these are my outside flood lights)

Removed the passive coupler

Removed Non Responder from circuit[/u]

 

I added my exterior floodlights v.35 devices to the power-line. (non-responders to the scene)

 

I'm missing something in the data below. You had other test results that indicated similar performance. What leads you to believe that this is a marked improvement?

 

Test #8 Put my whole system back together (3% failure rate)

Put my 3 APs back in their home.

Turn on my 220v devices

 

Now this surprised me a bunch. I performed at least twice as many operations here (100) looking for a failure streak. Clearly something was having some positive effect as that is a dramatic improvement.

 

This is where I could use some input from IndyMike. The only major change was putting the APs back in their homes, which was not on the circuit used for the test. One AP is on the PLM on Phase A and the other two are on Phase B, two different circuits and a different circuit than the Phase B circuit used for this test scene.

 

Yea, you are right. I suppose I should not be as surprised but here is what I was looking at: The only thing I had that was close to that was the 4% in the Hostile Insteon Environment Test. I took the 4% as an anomaly because it quickly degraded in subsequent tests that I thought should improve communications. Further, and far more significant, was Non-Hostile Insteon Environment Test #5 was a repeat of Hostile Insteon Environment Test #7. Logic says I should have had better numbers here, but they were massively worse. In addition to this, I had done queries of the scenes in several of these tests. The results:

 

Hostile Insteon Environment.

Test #3 24 failed hops

Test #5 6 failed hops

Test #7 15 failed hops

 

Non-Hostile Insteon Environment.

Test #4 25 failed hops

Test #5 15 failed hops

Test #6 0 failed hops

 

I preformed thousands of executions in dozens tests that were not posted here, and historically higher failed hop counts on queries resulted in higher failure rates for the tests. The 15 failed hops in Non-Hostile Insteon Environment Test #5 closely correlates to the expected 30% failure rate. The 4% failure rate of Hostile Insteon Environment Test #7 does not correlate very well at all with 15 failed hops. I do not know what was going on there but I call it an anomaly. I perfromed the test and moved on. Non-Hostile Insteon Environment Test #8 was not an anomaly. It was an extended test with more than twice as many attempted activations as any other test over an extended period of time. It was more than twice as reliable as any other test performed save that weird Hostile Insteon Environment Test #7

 

In reference to the below - I started replying to your post yesterday and had a great explanation. I was thinking that the 6288 was a bandstop filter and had all kinds of nice details on how component tolerances can adversely affect the performance.

 

The I remembered that the 6288 was a low pass filter - I hate it when reality strikes. I'm working on a couple of theories, but they're out there a bit. Your answers to the questions above will tell me whether I have a snowballs chance... or if I'm full of doodoo (smart money is on the latter).

 

So I started thinking, maybe my APs are doing something for me in this setup. I had done another test in the Hostile Insteon Environment that was not listed. Actually I have dozens of test that are not mentioned here. I expected absolute failure in the Hostile Insteon Environment Test #1 but some of the devices always responded. Not always the same ones either, seemingly random, so I tried to isolate the circuit by putting a Leviton 6288 filter in before the power-strips but devices kept responding so I assumed that the filter was junk and pulled it and moved on. Well, now that my system is back together but with lower failure rates I decided to do another test. I isolated 2 of the modules after the 6288 filter. It worked. Total isolation and I could no longer control those devices. I added an AP after the filter and once again had control of the devices. Clearly APs do something, I just do not know why they do what I would expect in some situations and not in others.

 

IndyMike, could some components of the surge suppressing strips be de-tuning the 6288 filter? The filter did not seem to work very well when the strips were plugged into it, but when it was straight AC the filter seemed to be 100%

 

Thanks for all the work, both testing and reporting. Unfortunately I think it's overstimulated my brain. I need to do something mind numbing for awhile...

 

IM

 

Which brings me to my next point. It seems like the APs are doing something when I bring my full system online and put the APs back on their home circuits. Insteon is a mystery to me. I cannot figure what is going on. My gut tells me that I do not fully understand message repeats. From my hours and hours of extensive testing I feel like the scene execution command from the ISY (whatever that command is, group, or something else) is not always getting repeated, or maybe not getting repeated by certain devices. I have never figured out why a test that shows a perfect hop count, and multiple devices, both responders and non responders on the same circuit, can have devices that do not respond. Unless of course the command is not getting repeated.

 

An excerpt from a PM I had with Darrell Peters:

 

I have been performing repeated querys on the bedroom floodlight. I have good communications, but interestingly I see a varibale max hop count on different querys.

 

2009/07/14 10:46:32 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=2, Hops Left=1

 

2009/07/14 10:47:02 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

 

2009/07/14 11:01:41 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

So we know that the ISY sometimes sends messages with different hop counts. Could something like this be happening with scenes. I do not know of any way of testing device repeats, but in my system it sure feels like sometimes it is not. The best example is my office scene triggered by the ISY. I always show really good hop counts, and I have an additional non-responder on that circuit, but still I sometimes have devices that fail to trigger.

 

The other likely possibility is that this is just consumer level product, with the attendant consumer level reliability. This is strongly buttressed by my Hostile Insteon Environment tests. When I was having trouble getting all the modules on or off in preparation for another tabulated test it was always random which modules would respond. And when I would perform another tabulated test, again it was always random which modules would respond and which ones would not.

 

So maybe sometimes this consumer level stuff does not repeat the commands, and maybe sometimes this consumer level stuff just does not respond to commands. The slightest change in signal or noise or impedance could make the difference even for devices right next to each other. In fact that may even add to the negative effect as many people have pointed out: Sometimes adding additional Insteon devices degrades system performance in direct contradiction to the marketing material.

 

Let me know your thoughts on my confusing 6288 findings.

 

How's THAT for a long post!

[bpwwer]

Which brings me to my next point. It seems like the APs are doing something when I bring my full system online and put the APs back on their home circuits. Insteon is a mystery to me. I cannot figure what is going on. My gut tells me that I do not fully understand message repeats. From my hours and hours of extensive testing I feel like the scene execution command from the ISY (whatever that command is, group, or something else) is not always getting repeated, or maybe not getting repeated by certain devices. I have never figured out why a test that shows a perfect hop count, and multiple devices, both responders and non responders on the same circuit, can have devices that do not respond. Unless of course the command is not getting repeated.

 

I think what you may be missing is the fan out aspect of message repeating. I think this is right, but I don't have any direct knowledge of the Insteon device firmware.

 

Start with single device (D1). The hop count doesn't matter because there are no other devices to repeat the message. It will re-try the send 3 times so the message ends up on the power line three times.

- D1 sends message (no response)

- D1 sends message (no response)

- D1 sends message (no response)

 

Now add a second device.(D2)

- D1 sends message (no response)

- D2 sees message and repeats it with hop count decremented) (no response)

- D1 sends message (no response)

- D2 sees message and repeats it with hop count decremented) (no response)

- D1 sends message (no response)

- D2 sees message and repeats it with hop count decremented) (no response)

 

So by adding one device, the number of messages on the power line doubled. I'm not going to keep typing expended versions of this but consider:

 

D1 sends message to D7

D2 repeats message

D3 repeats message

D4 repeats message

D5 sees D2's message and repeats it

D6 sees D3's message and repeats it

D7 sees the message that D6 had repeated and sends an ACK

D8 sees D5's message but doesn't repeat it because the hop count is now zero

 

The devices try to filter out some of these repeated messages so when D1 sees D2's repeat of it's message, it just ignores it.

 

But the fact that D2, D3, and D4 all saw the original message and repeated, should mean the repeated message is now stronger and propagates farther on the power line.

 

The basic idea behind Insteon, is that flooding the power line with messages gives it a better chance of the message getting through. However, there's also a good chance that some of these message will collide and corrupt.

 

Contrast this with X10 where D1 sends the message and if D7 doesn't see it, too bad. D2, D3, D4, D5, D6, and D8 would all ignore the message.

 

I think this is mostly correct for direct device-to-device messages. For scene (group broadcast) messages, things are different. Since the sending device doesn't expect a response, I believe it sends the message only once. So the message goes out and gets repeated (until the hop count is zero) and that's it. The idea with a broadcast is that it should cause a group of devices to all respond at roughly the same time and respond quickly (it's giving up reliability for hopefully quicker response).

 

How AP work with this, I'm not sure. I don't think a message moving from one AP to another counts as a hop, but I'm not sure. So consider a message taking two paths; one directly via the power line and one routed through a pair of AP's. It's possible that the the message going through the AP's is slightly delayed or out of sync with the message on the power line and they end up colliding and corrupting the message. This may explain why some tests with the AP are showing worse results.

[IndyMike]

Hello Illusion,

 

Thank you for the detailed answers. I had been working the theory that the Lamplincs themselves had become noise generators when installed on your powerstrip. The triac output on these devices does generate noise. If plugged into a high impedance source (your powerstip) I could envision a situation where the Lamplincs could generate enough local noise to prevent communication.

 

Anyway, you blew me out of the water when you indicated you were testing both on and off conditions. The lamplincs can't generate noise in the off condition.

 

You had also asked about the Leviton filter function being affected by the powerstrip (e.g. your test where adding the filter appeared to improve communications). I'm again at a loss to explain this. Any noise reduction benefit the filter could have provided should have been more than offset by the Insteon signal loss through the filter. Is it possible this was another anomaly?

 

In terms of message hopping and Accesspoint coupling of the phases, I do firmly believe that the passive coupler saves 1 message hop.

 

1) A single standard Insteon message occupies 6 zero crossings of the 60 Hz line.

2) Data is transmitted during the first 5 zero crossings. 2 bytes per crossing for a total of 10 bytes.

3) The sixth zero crossing is used to allow the Accesspoints to communicate via RF.

4) The Accesspoints then transmit their communicated information during the next message hop.

 

The following is my understanding of how message hopping functions in a passively coupled system VS a RF coupled system.

 

The layout below is a construct to show the differences in how passive/AP coupled system would function. Although it is a construct, I'm trying to apply the rules consistently between the two systems.

 

1) L1 and C1 on the left side of the panel form a passive phase coupler.

2) The PLM is on a dedicated circuit (same as the passive coupler).

3) The three branch lines are all 400 feet long with units at 100 ft intervals.

4) Line 1 (top) is on phase A - same as the PLM

5) Line 2 (middle) is on phase B - opposite the PLM (identical devices to line 1)

6) Line 3 (bottom) is on phase B and has a heavy EMC load (I1) between device 1 and 2

 

Initial Transmission

1) Branch 1 : SW 1 and 2 are within range of the PLM and hear the initial transmission. SW3 is out of range (300 ft).

2) Branch 2 : Due to signal losses in the passive coupler, only Sw5 hears the initial transmission.

3) Branch 3 : Only SW9 hears initial transmission.

 

Passive Coupled HOP1

1) Branches 1 and 2 - Units within range of the initial transmission become repeaters. All of the remaining devices on branch 1 and 2 receive the HOP1 transmission.

2) Branch 3 - SW9 becomes a repeater. Due to the heavy EMC load, only SW10 is within range.

 

 

Passive Coupled HOP2

1) Branches 1 and 2 - Units flip roles (repeaters become listeners). note that per the specification, addressed units should not repeat.

2) Branch 3 - SW10 becomes a repeater. All Branch 3 units hear this transmission.

 

All units have now received the transmission.

 

 

Passive Coupled HOP3

1) Units flip roles (repeaters become listeners). This is an an unneeded hop since all units have received the message. It is required since the message was sent with 3 hops.

 

 

 

 

Accesspoint coupling

1) L1 and C1 replaced with Accesspoints

2) The PLM is on a dedicated circuit (same as the AP1).

3) Branch circuited unchanged.

 

Accesspoint Initial

1) Branch 1 - SW1 and 2 are within range of the initial PLM transmission (consistent with passive coupled config above).

2) Branch 2 and 3 - The PLM is unable to communicate through the transformer to phase B. No devices on phase B hear the initial transmission.

3) AP1 communicates with AP2 during the last powerline communication "window". These APs are now set to transmit during HOP1.

 

 

Accesspoint HOP1

1) Accesspoints become repeaters

2) Branch 1 - SW1 and 2 become repeaters. SW 3 and 4 within range

3) Branch 2 - SW 5, 6 and 7 within range of AP2. Note - I should not have included SW 7 as being within range. This conflicts with the Branch 1 rules.

4) Branch 3 - Due to the EMC load, only SW9 hears AP2

 

 

Accesspoint HOP2

1) Accesspoints become listeners. I have them shown as re-synching at the end of the powerline transmission. Not certain of this, but it seems reasonable.

2) Branch 1 - Units flip (repeaters become listeners)

3) Branch 2 - SW 5, 6 and 7 become repeaters. SW 8 within range. All branch 2 units have now received the PLM transmission.

4) Branch 3 - SW9 becomes a repeater. Due to the EMC load, only SW10 and AP2 are within range.

 

 

Accesspoint HOP3

1) Accesspoints become repeaters.

2) Branches 1 and 2 - Units flip (repeaters become listeners)

3) Branch 3 - SW9 becomes a repeater. All Branch 3 units are within range. Transmission complete on Branch 3.

 

 

Using the above configuration, you can play some interesting games by changing the initial transmitter (Use SW 12 as the initial, etc). Just try to develop a set of rules, and apply them consistently.

 

If anyone sees problems with the above, I'd be happy to hear them (I'm constantly "refining").

 

I do have a theory on why AP's (and devices in general) may have a problem operating as repeaters, but I've gone on long enough for one post. As a teaser, it has to do with localized noise and devices improperly detecting the 60 Hz zero crossing.

 

IM

[Sub-Routine]

These are the hop counts at the PLM from the message sent by the device.

The ISY cannot tell you how many hops are left when it's signal reaches the responder.

 

Illusion wrote:

I have been performing repeated querys on the bedroom floodlight. I have good communications, but interestingly I see a varibale max hop count on different querys.

 

2009/07/14 10:46:32 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=2, Hops Left=1

 

2009/07/14 10:47:02 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

 

2009/07/14 11:01:41 : [Extended-Direct][0A.81.32-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Let's look at one query on a similar device.

 

 

This is all a guess on my part.

We see a Status Request sent and the device responds with the current On Level using a standard transmission. 3 hops max, 1 left.

Then, to me, it appears the device sends the Local Level and Ramp Rate extended message with a Max Hops=1. The ISY received it and processed it.

Perhaps the device did not see a response and so it resends with 2 hops where it appears to be repeated once. Then it sends with 3 hops and three devices repeat the message.

 

IM,

 

Thanks so much for all that information. From what I recall of the developer's guide I was led to believe that an AccessPoint repeats a command from the power line to the RF without subtracting a hop and vice-versa. Then it subtracts a hop and repeats back on the method it received on. I am going to have to search for that again.

 

Rand