Insteon communication

[intellihome]

In an attempt to alleviate the occasional Insteon communication problems that my ISY reports from time to time (Failure to communicate with device xx.xx.xx.). I ran a new 12/2 circuit from the center of my 40 circuit main panel to my structured wiring closet dedicated to my ISY PLM.

 

I returned from work today and learned my work was in vain...Failure to communicate to device xx.xx.xx was the fruit of my labor

 

As usual, I do a query on the affected device and the red exclamation mark goes away and all is good. The device in question is about 3 feet from my panel box! makes no sense to me. Also, given the fact that I was not home there was very little ON in the way of lights or appliances.

[MarkJames]

I share your pain.

 

Though truthfully if I don't have admin console running I'm sure that errors occur - I just don't know about them.

 

Ignorance can be bliss!

[oberkc]

Forgive the stupid questions, but you do have access points, correct? One panel (nothing fancy like sub panels and multiple feeds into multiple panels)? Is the problem device on the same phase or different? Is it possible that the access point on the same phase as your PLM is failing to get good communication with your ISY?

 

I am not sure how good an idea this is, but it appears to have worked well for me. I, too, ran a dedicated circuit for the PLM, but immediately out of the panel (before the PLM outlet) I added a second outlet (with the outlet for the PLM powered from this one). In this "second" outlet nearest the panel, I put an access point for this phase of my power circuit. The other phase already had a plug close by (within several feet) and it was into this plug I put my second access point.

 

Perhaps you have already fooled around with access points, or even put one in the pass-through of your PLM. I just thought I would throw out some thoughts.

[intellihome]

I share your pain.

 

Though truthfully if I don't have admin console running I'm sure that errors occur - I just don't know about them.

 

Ignorance can be bliss!

 

You make a good point Mark. I think I'll shut down my admin console too!

[MarkJames]

Yeah,

 

I have well over a hundred devices, 3 hardwired signalincs, 8 access points. My PLM is on a home run less than 18" from the panel.

 

With all that I still have the odd comm failure. The important thing is that everything works. When you think about all the messaging and acknowledging that an insteon network performs it's hardly surprising that you get an occasional comm failure.

 

Mark

[IndyMike]

Hello Mark and Intellihome,

 

Are your "non-responsive" devices lamplincs/appliancelincs?

 

If so, beware that these devices respond differently if the local load is off (at least my older LL's do).

 

If I switch the lamp off locally, the LL will report a failure when commanded on (it doesn't see the attached load). Curiously, if I query the device it reports OK.

 

A second possibility would be a dimmable CFL connected to a LL. The CFL many not load the LL enough to allow it to determine that a device is connected. The effective loading varies by CFL wattage and manufacturer.

[intellihome]

oberkc,

 

Thanks, I do have a couple of sub panels (garage and basement) however the devices in these circuits rarely have comm fails. I have four access points that I have moved around quite a bit with out really being able to say any one configuration yielded better results then the other.

 

As Mark has stated most everything works, the comm fails are not really causing scenes or programs to fail (for the most part; in my case).

 

IndyMike, My comm fails are KPL's and Yes...LL's and Yes again...when the load is off. I have experienced the same thing you have. I realized one particular LL was always popping up with a comm fail but a query always returned back OK. So I turned the LL ON through the console and the lamp did not come on, that's when I noticed it had been turned off manually at the lamp itself. I guess if we turn a lamp off manually we just need to ignore comm fails...hmmmm

[MarkJames]

I have no cfl's - they interfere too much with my IR systems plus I come from X-10 so cfl's were a lot of trouble.

 

I have no LL's either.

 

My comm fails are almost always motion sensors which Michel is helping me troubleshoot. The log looks correct - so I have to collect the level 3 event log for the failure. This is a little hard to do because it's intermittent.

 

I had some switchlinc and kpl comm failures a while back. They were related to older signalincs that I had (2442's - the earliest version of access point). Removing those fixed those comm problems.

 

I think comm problems can occur for so many reasons and under so many different circumstances that troubleshooting them can be extremely difficult. I suspect that some of them are related to differences in version numbers between access points as well.

 

So long as my network 'works' I've put diagnosing it on low priority

 

Mark

[intellihome]

"So long as my network 'works' I've put diagnosing it on low priority"

 

Same here, It's just taking me a little while to understand what matters and what doesn't. What I can improve and what I cannot.

 

My system works very well. I just need to learn to differentiate comm problems from inherent design problems and then I can have peace

 

The only pressing thing that I need to clear up is getting my KPL buttons to synch up. It's driving the wife crazy as well as I. I still have not figured out if they get out of synch because of comm issues or scene/program issues or device revision issues or ISY revision when devices were added to scene issues blah blah blah.

 

If it were not for the ISY, the UD folks and the guys on this Forum I quite frankly would have just went back to X10. My X10 system really served me quite well for over ten years. I understood the system and could trouble shoot it in short order. The best part about it, it didn't obsolete itself every six months!

 

Ok, I'll stop belly acheing, it's a new protocol with new challenges...We'll get there.

[MarkJames]

Well... I hate to backpedal but if your kpls are giving you comm errors I think I'd try a few obvious things and see if you can't make that go away. I don't know that I'd be happy about KPL's acting up as they're the 'core' of the system imho.

 

I can tell you some of the things that I went through for mine.

 

1. Make sure the KPL's contain the right links using the tools->diagnostic->device links and then comparing it to the ISY links with the compare button. Ideally they're all identical with one ignore at the end.

 

2. If they don't match then try resetting and restoring the KPL and trying again. Having incorrect/missing links will undoubtedly screw up the LED's being in synch. If you can't restore it properly you DEFINITELY have a problem. Either your KPL is messed up, your PLM is messed up, or your communication is messed up. You GOTTA deal with that.

 

3. Make sure you don't have scenes where you use an ON command to turn OFF a load that is also controlled by a KPL. Even if the KPL is part of the scene, the LED on the KPL will NOT turn off and you'll be out of synch immediately.

 

4. Look at your topology to make sure that your devices aren't part of scenes that you didn't realize you'd made them part of. I had a few like that where the light was turning off from a KPL in the garage but I hadn't linked the garage KPL to the other KPL's - so everything would go wacky

 

5. I'm a big believer in hard-wired signal bridges. While access points do it - signal bridges absolutely do it. My communication issues got 99.9% better when I installed hardwired signal bridges. I think the whole "access points make life better' mentality is a marketing scheme from Smarthome. Access points are only needed where you a)can't install a hardwired signal bridge or have RF devices that need to interface with the insteon network

 

6. Make sure your access points are the same versions. I had issues where access points of different versions were causing me trouble. This is probably not possible because they change versions so often but I'd be inclined to use the ones you have that match, pull the others, and see if your comm problems get better before adding them back. Then add them back one by one.

 

7. Make sure that nothing is plugged into the same outlet as your PLM.

 

8. Make sure you don't turn devices off directly from programs - always use scenes - that way the controllers will always match up too.

 

9. Make sure you don't have any pre-ISY links in your devices. The diagnostic will find those right away. I've had Insteon long before ISY came out so I had a lot of links already. I created a list of all my devices and ran a diagnostic on every single one - one by one - to make sure that all was in synch.

 

10. Make sure you don't have any X-10 links left. I used the event viewer on level 3 - went around to every single button on every single device and pressed it on and off then checked the viewer to see if an x-10 signal had been sent. X-10 links remaining will undoubtedly make you nuts and put your devices out of apparent sync.

 

 

I'm sure there's more but see if anything in here applies to you. Like I said before - my comm errors are pretty much confined to RF devices and I'm sure it's AP related. I would be looking at comm errors with KPL's especially if you have LED"s out of synch. I switched to Insteon at great expense to get AWAY from X-10. If you're tempted to even LOOK at your x-10 anymore you have insteon issues that CAN be fixed. I'd NEVER look at x-10 again.

 

mark

[IndyMike]

Mark,

 

I get occasional Motion sensor comm faults as well. I attribute this to the fact that I have 3 sensors in my Dinette/Kitchen which all converge on one Accesspoint (I have only one AP in my system). In this situation, there is a very real chance for near simultaneous triggers from the multiple sensors. Given the handshaking of the protocol, I've come to accept comm failures as a fact of life. I see no impact on the performance of the system.

 

In retrospect, I had the identical problem with multiple X10 motion sensor in the same area. The difference was, the X10 communication was slow enough that one sensor could corrupt another during transmission. Multiple transmissions would case the system to flat out fail.

 

My comm fails are almost always motion sensors which Michel is helping me troubleshoot. The log looks correct - so I have to collect the level 3 event log for the failure. This is a little hard to do because it's intermittent.

[intellihome]

Thanks Mark!

 

I'll work through your list and see where I stand.

 

I'll document each test or observation I make because I know how it can get confusing pretty quickly.

 

Thanks again!

[MarkJames]

Mark,

 

I get occasional Motion sensor comm faults as well. I attribute this to the fact that I have 3 sensors in my Dinette/Kitchen which all converge on one Accesspoint (I have only one AP in my system). In this situation, there is a very real chance for near simultaneous triggers from the multiple sensors. Given the handshaking of the protocol, I've come to accept comm failures as a fact of life. I see no impact on the performance of the system.

 

In retrospect, I had the identical problem with multiple X10 motion sensor in the same area. The difference was, the X10 communication was slow enough that one sensor could corrupt another during transmission. Multiple transmissions would case the system to flat out fail.

 

 

I'm glad to hear I'm not alone on that. The exact same reasoning went through my mind. I'm not familiar enough with the powerline interface part of insteon to understand if/how multiple access points can inject a signal 'simultaneously'. It seems that when a non-rf device sends a signal it can only send it once - however the multiple devices that repeat that signal are broadcasting it throughout the network seemingly without problem. I'm not sure how this differs from access points sending the same signal around - certainly not all on one zero-crossing. Nevertheless, it seems to be a problem.

 

Regardless, RF in insteon is so very much better than RF ever was in x-10 that it's silly. Actually, to my mind, every single aspect of insteon is so vastly superior to x-10. The learning curve for insteon is sure a lot steeper, but once you 'get it' it's pretty easy with the odd gotcha. My favorite part of insteon is that I never come in to a room that has a light on which was turned on by some stray signal. I actually 'trust' insteon - something I could never do with x-10.

[IndyMike]

Intellihome,

 

To start, I'd like to second Marks very thorough post. I'm a huge fan of the passive couplers as well. I attribute much of the success that I've had with Insteon over the years to the fact that I've had a coupler next to the panel since the "old days".

 

To that end - could you modify your 12/2 feed for the PLM? The idea here is to run 12/3 (or 14/3) 240V off a 15A dual breaker. This would allow you to place a 240V coupler at the PLM (your structured closet). A triple J-Box containing two outlets and the coupler would be ideal:

1) Left - 120V phase A outlet (PLM installed).

2) Center - passive coupler.

3) Right - 120V phase B outlet.

 

Going over your previous posts, it seems that most of your problems with "synching" KPLs are in scenes that are initiated by other devices (not controlled by the PLM). A couple of observations/questions:

1) The PLM/ISY should not indicate a "device failure" for this situation. It can't hear or respond to a communication to a different device address.

2) From your previous posts, I've seen where you've tested the link tables and reset some of these devices. Are they programming OK now (do you have problems programming/restoring these KPLs)?

3) Since your status problems appear to be mostly device to device (as opposed to device to PLM) try to determine whether the controller/responder are on different phases. If so, I'd place even more emphasis on the hardwired passive coupler. If not, we'll need to look for noise sources/absorbers.

 

As a general comment, I'd like to lead you (and anyone else who will listen) away from the multiple Accesspoint installation (3 or more). Given the repeating nature of Insteon, a passive coupler at the panel should be all you need to have a system that is far superior to X10. With a coupler, a Accesspoint is only required for remote devices (motion sensors, remotelincs, etc).

 

The benefit on not having Accesspoints in your system is that you know exactly what path the signals are taking (just like in the X10 days). They must all return to the panel and go through the passive coupler. This greatly simplifies troubleshooting. You should be able to isolate low reception areas using the query/scene test diagnostics.

 

Said differently. if your system is working 100% multiple APs are invisible. If your system is not at 100%, multiple APs add a complexity that is very difficult to overcome.

 

One last note (and my lone disagreement with Marks post) - While I'll agree that eliminating all X10 codes from your devices will simplify troubleshooting, it should not be "required". On the contrary, if X10 signals can make it to a device that indicates that you do not have powerline problems at that device. I currently run a mixed X10/Insteon system and find it to be an advantage to be able to test the communication on both systems.

 

IM

[MarkJames]

One last note (and my lone disagreement with Marks post) - While I'll agree that eliminating all X10 codes from your devices will simplify troubleshooting, it should not be "required". On the contrary, if X10 signals can make it to a device that indicates that you do not have powerline problems at that device. I currently run a mixed X10/Insteon system and find it to be an advantage to be able to test the communication on both systems.

IM

 

Well said!

 

It's hard to get people off the 'access point bandwagon' because it's almost become a mantra that if you have problems then access points are the solution.

 

We don't disagree about X-10, Mike... I had just assumed that Intellihome had switched from an X-10 system to a 'pure' insteon system. Doing so without eliminating the x-10 codes in your home can be pretty confusing. I 100% agree with you that the two systems can peacefully co-exist.

 

I have such a convoluted home (5 panels, 2 meters) that I have eliminated my x-10. I had a very large installation of it and I could never get it to work 'right'. With that said, though, I am keeping my Stargate in order to run telephone keypad commands interfaced into the insteon system and will also be keeping it as a controller for my sprinkler. I have a relay box that runs one whole housecode on relays so it gives me 16 sprinkler zones in one box. To this point I haven't found a comparable insteon device for this purpose - and doubt I'll find one at a reasonable price anytime soon. I chose housecode J for my sprinkler and never used anything with J anywhere else so the sprinkler pretty much works properly - other than when it misses the signal and doesn't turn on/off. Avoiding that problem is a simple matter of sending 5 ons to turn it on and 5 offs to turn it off. It's overkill but it works.

 

mark

[IndyMike]

Hey Mark,

 

I don't think the problem with the motion sensors is due to the Powerline "simulcasting". This is all done in synch with the 60Hz zero crossing.

 

I think it's a problem with multiple RF devices trying to communicate at (or nearly) the same time. This is completely asynchronous, and as a result, will produce interference. Insteon is superior in that the communication takes less time per device. I think it's the handshaking that winds up getting interrupted and therefore produces errors (no impact on performance).

 

I'm glad to hear I'm not alone on that. The exact same reasoning went through my mind. I'm not familiar enough with the powerline interface part of insteon to understand if/how multiple access points can inject a signal 'simultaneously'. It seems that when a non-rf device sends a signal it can only send it once - however the multiple devices that repeat that signal are broadcasting it throughout the network seemingly without problem. I'm not sure how this differs from access points sending the same signal around - certainly not all on one zero-crossing. Nevertheless, it seems to be a problem.

 

Regardless, RF in insteon is so very much better than RF ever was in x-10 that it's silly. Actually, to my mind, every single aspect of insteon is so vastly superior to x-10. The learning curve for insteon is sure a lot steeper, but once you 'get it' it's pretty easy with the odd gotcha. My favorite part of insteon is that I never come in to a room that has a light on which was turned on by some stray signal. I actually 'trust' insteon - something I could never do with x-10.

 

I'm sorry, but I have to disagree on the learning curve. I came from a X10 system that used 2-Activehomepro CM15A's coupled by RF (no powerline communication between the two). As I began to add KPL devices (X10 mode only) the complexity of my status macros grew geometrically. It got to the point where adding a single device to the system would require hours of coding/testing/debugging.

 

When I finally installed the ISY and converted the KPL's to insteon (mostly) I was able to do so in an afternoon. While I understood the power of the ISY scene and programming ability, I didn't grasp the time savings it afforded. I (and my family) are so much happier now that I'm not spending hours tracking down that KPL button that didn't light when it should have...

 

IM

[IndyMike]

OK Mark,

 

You're a lot quicker typer (or thinker) than I am. I need to get this in fast.

 

Your 5-panel/2-meter system beats my 3-panel/1-meter system hands down (didn't realize we were playing 7-card).

 

My hats off to you for getting reliable communication (Insteon or X10) across two meters. That's something I've never tacked.

 

I better end things here before you get a post in ahead of me.

 

Well done!

[MarkJames]

When I finally installed the ISY and converted the KPL's to insteon (mostly) I was able to do so in an afternoon. While I understood the power of the ISY scene and programming ability, I didn't grasp the time savings it afforded. I (and my family) are so much happier now that I'm not spending hours tracking down that KPL button that didn't light when it should have...IM

 

The power of the 'scene' is pretty impressive - and you're right - it saves hours and hours of time. It's a huge plus being able to just drag a new controller into an existing scene and not have to walk around the house in linking mode for an hour trying to remember everything that belongs. In my case I have lots of inlinelincs too so I'd be pulling potlights out of the ceiling to get to them when I wanted to relink.

 

Gotta hand it to the designers of both insteon and the ISY. It's not too often that a product comes along where you didn't see just how much you needed or wanted it until you actually understood what the designer had in mind.

 

I'm both glad there are such bright minds out there, and humbled that they can leave me feeling pretty 'average' for not seeing what they saw.

 

mark

 

[edit]

lol - yes - we played a bit of high-speed post-tag there for a bit. I've been outside all day, came in to make a phone call and got sidetracked when I saw your post(s) They just begged to be responded to! I don't really live in front of the PC - despite what my wife might say!

[intellihome]

IM and Mark - Sorry for the slow response. You gave me a lot to digest and to be honest, I'm still digesting.

 

While still trying to get an understanding of how my KPL LED buttons are

"supposed" to work (or stay in sync), I can clearly see the benefit of a clean phase coupled starting point. I thought I did that with the 12/2 dedicated circuit. Arghhh...I just finished putting all the insulation back up in the basement ceiling

 

I will home run (it's about a 50 foot run) a 14/3 from the last two breakers in my main panel to my structured wiring closet and wire in the passive filter (for the PLM). It makes perfect sense to start with a clean circuit, phase coupled right at the PLM. After all this is not a temporary install.

 

Out of curiosity, are either of you familiar with the X10 trick for phase coupling. a .1uF 600V Capacitor across a 220 breaker? I've had one installed in my house for ten years and know many others that installed them with immediate results. I wonder if they do anything for Insteon.

[IndyMike]

Hello Intellihome,

 

Excuse me for replying to your post "out of sequence".

Out of curiosity, are either of you familiar with the X10 trick for phase coupling. a .1uF 600V Capacitor across a 220 breaker? I've had one installed in my house for ten years and know many others that installed them with immediate results. I wonder if they do anything for Insteon.

 

Actually, the .1 uF Cap trick was used successfully for many years until we started clogging our homes with devices that generate noise/absorb frequencies in the 120 kHz range. By the number is should work even better for Insteon generating ~ 12 ohms of impedance at 130 kHz (Z=1/(2*PI*f*C).

 

The passive coupler adds an inductor in series. Values are selected so that the circuit resonates at 120 kHz (130 kHz for Insteon) and presents a much lower impedance than the 12 ohms above. The benefits are:

1) higher coupled signal levels

2) less phase shift

3) blocking of frequencies away from the resonant point.

 

Jeff Volp put together a nice tutorial on this some time back: http://jeffvolp.home.att.net/x10_info/x10_couplers.htm

 

With the above said, I'm a bit surprised that the 0.1 uF cap isn't working for you. There's a possibility that you have some heavy line loading that is reducing the signal coupling through the cap. It's also possible that the phase shift is actually interfering somewhat with your AP's.

 

You may want to try removing the cap to see if things improve/degrade.

 

I will home run (it's about a 50 foot run) a 14/3 from the last two breakers in my main panel to my structured wiring closet and wire in the passive filter (for the PLM). It makes perfect sense to start with a clean circuit, phase coupled right at the PLM. After all this is not a temporary install.

 

Just one comment on the above - please use a "ganged" 15A breaker for this. It's far safer (both 120V legs are disabled at the same time) and may even be code for your area. If you can't find a 15a ganged breaker (they're not that common), consider running 12/3 with a 20A ganged breaker.

 

IM

[Brian H]

Be very carefully with a .1uf 600 DC volt cap.

If it is not rated for across AC power line use. It can explode from the constant AC across it.

When I had one it was dual rated. 600 volts DC and 275 volts across AC use.

 

I now have Jeff Volp's XTB-IIR X10 repeater for my remaining X10 devices. It knows Insteon and quietly ignores it. Some X10 repeaters see the part of the Insteon signal at Zero Crossing and try and resend a bogus X10 signal.

[intellihome]

3. Make sure you don't have scenes where you use an ON command to turn OFF a load that is also controlled by a KPL. Even if the KPL is part of the scene, the LED on the KPL will NOT turn off and you'll be out of synch immediately.

 

Mark, could you please elaborate on this item? I can't quite grasp what your saying.

Could you provide an example?

[Sub-Routine]

What Mark means is that if you have a device controlled by a KPL button and you use a scene to turn that device off when the scene is called On the device will turn off and the KPL button will remain on, or turn on if it is included in the scene.

 

You can use a program to turn the button off when the status of the device is Off. You have to put the button in a scene to control it.

 

I do this with scenes I use in timed programs. In my scheduled program I turn off KPL buttons before I turn on the scene. The scene includes KPL buttons of devices that will turn on. The scene doesn't include buttons of devices that will turn off within the scene.

 

Since using programs to control KPL buttons requires extra signals + processor time the idea works great with schedule programs. You will notice button presses have a slight delay in syncing the other buttons.

 

Rand

 

3. Make sure you don't have scenes where you use an ON command to turn OFF a load that is also controlled by a KPL. Even if the KPL is part of the scene, the LED on the KPL will NOT turn off and you'll be out of synch immediately.

 

Mark, could you please elaborate on this item? I can't quite grasp what your saying.

Could you provide an example?