IndyMike

Michel and UDI Team, Thank you for all the hard work. 3.1.13 Installed without issues. ELK Arm/Disarm, Exports, and Zone queries appear to be working nicely. I attempted to diagnose the problems reported by weunch and FRR regarding the ELK "connected" function and learned a couple of things - 1) Initially the program below indicated false. I assumed this was due to it not being triggered. 2) Fired up ELKRP2 and connected to the ELK. The program did not trigger. It was at this point that I realized that the ISY could still communicate with the ELK with ELKRP2 running. I didn't realize this was possible. Communication appears to be one-way. The ELK communicate state changes to the ISY, but ISY cannot Arm/Disarm the ELK. 3) Physically disconnected the ELK from the network. The ISY displayed a warning message in the top menu bar area and triggered the program. This appears to be automatic - the user does not need to manually query to determine the status. 4) Reconnecting to the Elk again triggered the program which now evaluated to True. If Elk System is Connected Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') I'm hoping that the source of the confusion is the fact that running ELKRP2 does not fully disconnect the ISY. IM

jetjock, There is a device mapping problem with the ELK export in 3.1.12. Please see Lou's post here - http://forum.universal-devices.com/viewtopic.php?f=25&t=7342. I exported with 3.1.12 and had the same issues that Lou reported. I f you have already exported/imported to the elk, please revert to 3.1.10, export/import, and things should be back to normal.

frustratednon-geek, Knowledgeable Fathers are a wonderful thing to have. I still consult my Father on electrical issues (he's in his mid 80's now). Spent 30 years in Aerospace and, as luck would have it, 10 years as Chief Engineer in a local Hospital. I have 30+ years in Aerospace, but I still listen and learn. I'm still a bit concerned about your fixture ratings - the switch must be rated for the fixture, not the installed bulbs. If your fixtures are rated for 60W bulbs, an 1800W switch is appropriate. If the fixture is rated for 90 or 100W bulbs you are at or over the switch rating. My chandeliers are rated for 6-100W bulbs (I have 60W installed). Even though my installed load is 360W, I use 1000W dimmers because that is what the fixture demands. Check yours to make sure. If the worst happens, you want to make sure that an insurance adjuster does not point to this switch.

Frank, Have a look at the ELK firmware as well. I had similar symptoms prior to upgrading to the latest M1 and EXP firmware. I also had to upgrade the ELKRP software to R2 (to support the new firmware). After upgrading, I get the security bar and the ELK can communicate with the ISY. Reverse (ISY to ELK) is still a problem. Current ELK Config: M1G Firmware: 5.2.8 Bootware: 3.3.6 Hardware: 0.13 XEP Firmware:1.3.28 Bootware: 1.2.0 Hardware: 1.0 Symptoms: 1) Events generated by the Elk are recognized by the ISY. 2) The Elk does not recognize Insteon lighting events. 3) The ISY cannot arm/disarm the ELK.

Hello frustratednon-geek, Since this is a commercial installation, please proceed carefully. The switch rating should be matched (exceed) to the maximum fixture load. The rated fixture load may well exceed the 60W bulbs that are currently installed. If you "trust" the original dimmer installation (1800W) do not install a device with a lower rating. If you are unsure about the installation, look up the max fixture rating or get out that ladder (that you don't yet have). I was not aware that SH was offering a 20A KPL. From the website, it lists a 1800W incandescent capacity. Again, please be careful and check the UL label on the back of the switch. I have switches that are rated differently from the information presented on the website/product manuals. An inspector will not care about websites or manuals - he will look at the UL label which indicates what the device was certified to.

Hello gatchel, Thank you for the info. I'll give the code a try. I had assumed that since it was working in previous revisions, the ISY "remembered" the code.

Michel, Caught your note regarding the ELK Firmware. After upgrading to 3.1.12, the ISY cannot communicate with my ELK (ELK addon module is not yet installed). I get looping retry errors in both the Event Monitor and the Error log: Event Monitor Thu 11/17/2011 07:34:51 PM : [Elk ] ELK-WAIT Waiting for retry 1 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:34:59 PM : [Elk ] ELK-WAIT Waiting for retry 2 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:35:08 PM : [Elk ] ELK-WAIT Waiting for retry 3 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:35:27 PM : [Elk ] ELK-WAIT Waiting for retry 1 of 3 [0Bsd18003005B\r\n] Thu 11/17/2011 07:35:35 PM : [Elk ] ELK-WAIT Waiting for retry 2 of 3 [0Bsd18003005B\r\n] Thu 11/17/2011 07:35:44 PM : [Elk ] ELK-WAIT Waiting for retry 3 of 3 [0Bsd18003005B\r\n] Error Log Thu 2011/11/17 07:33:16 PM System -170001 [Network] Established Thu 2011/11/17 07:34:28 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:32 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:37 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:41 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:46 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:50 PM System -170001 [uDSockets] HTTP:31 error:6 Reverting to 3.1.10 corrects the issue. My ELK firmware is at 5.1.20. Is the older firmware an issue even without the ELK Module Installed? I fully plan on purchasing the ELK module. Just trying to make sure I don't have a different problem. IM

Hello Lou, I was all set to chime in and agree that paralleling the passive coupler and Line to Neutral outlets off the 240V dryer branch was a definite code violation. Now I'm not at all that sure. The above qualifies as a multiwire branch circuit and is covered by Article 210.4 of the NEC code. There appear to have been a number of revisions to this section in recent years. 1999 NEC Code, 210.4 Multiwire Branch Circuits. [*:30rmpb4w](A) General. Branch circuits recognized by this article shall be permitted as multiwire circuits. A multiwire circuit shall be permitted to be considered as multiple circuits. All conductors shall originate from the same panelboard or similar distribution equipment. FPN: A 3-phase, 4-wire, wye-connected power system used to supply power to nonlinear loads may necessitate that the power system design allow for the possibility of high harmonic neutral currents. [*:30rmpb4w]( Devices or Equipment. Where a multiwire branch circuit supplies more than one device or equipment on the same yoke, a means shall be provided to disconnect simultaneously all ungrounded conductors supplying those devices or equipment at the point where the branch circuit originates. [*:30rmpb4w]© Line-to-Neutral Loads. Multiwire branch circuits shall supply only line-to-neutral loads. Exception No.1: A multiwire branch circuit that supplies only one utilization equipment. Exception No.2: Where all ungrounded conductors of the multiwire branch circuit are opened simultaneously by the branch-circuit overcurrent device. Your current dryer installation is covered under Exception #1 (Line to Line load - 240V). You are proposing to add Line to Neutral loads to this branch. This may be covered under Exception #2 if your breaker opens both legs of the circuit simultaneously due to an overcurrent in either leg. Code Updates - Found the following on the Mike Holt site (http://ecmweb.com/nec/code-basics/electric_branch_circuits_part/ Multiwire branch circuits. Multiwire branch circuits are circuits that have more than one ungrounded conductor sharing a common grounded (neutral) conductor. These circuits are very beneficial in that they use less material, result in a lower circuit voltage drop, and ultimately result in cost savings. They do, however, have some specific Code rules that can't be ignored. To prevent inductive heating and reduce conductor impedance for fault currents, all multiwire branch-circuit conductors must originate from the same panelboard or distribution equipment [210.4(A)]. Multiwire branch circuits must supply only line-to-neutral loads [210.4©]. [*:30rmpb4w]Exception 1: A multiwire branch circuit can supply line-to-line utilization equipment, such as a range or dryer. [*:30rmpb4w]Exception 2: A multiwire branch circuit can supply both line-to-line and line-to-neutral loads if the circuit is protected by a device (multipole circuit breaker) that opens all ungrounded conductors of the multiwire branch circuit simultaneously (common internal trip) under a fault condition. If the continuity of the grounded (neutral) conductor of a multiwire circuit is interrupted (open), the resultant over- or undervoltage could cause a fire and/or destruction of electrical equipment. See 300.13( for the requirements relating to the continuity of the grounded (neutral) conductor on multiwire circuits. From that above NEC code revision (date??) - you are allowed to combine Line to neutral and Line to Line devices on a multiwire branch circuit. You'll need to determine the following: 1) What revision of the code applies to your area. My area uses 1999 base code with pieces of recent code. While I believe it could be installed safely, I would expect a lot of flak from my local inspector. 2) Whether there is a code exclusion preventing the use of dedicated appliance circuits (dryer) with 120V line to neutral branches. I don't have a full copy of current code to verify this. 3) Whether your current installed breaker/wiring will support the addition of 120V legs. This is a multi-part question - [*:30rmpb4w] Your total loading on the conductor and breaker cannot exceed NEC requirements. This was a dedicated circuit to your dryer. You are now changing the application and different rules will apply. [*:30rmpb4w] Most importantly - you will need to ensure that your 120V (Line to Neutral) branches will trip the breaker in the event of a Line to Neutral overload. This is covered under 210.19 (A) (4) http://ecmweb.com/nec/code-basics/branch-circuits-nec-requirements-20110201/ In summary, I can't say this would be a violation. On the flip side, I can't say that it would be code compliant either. It depends on your local code and your particular installation. My advice would be to call someone knowledgeable in local code and installation - have any neighbors in the business?

I don't understand how you are coupling the phases. I believe my house is a fair amount smaller than yours. There are times when I can couple through the utility transformer well enough to communicate across phases. This is not reliable for long durations. Simply put, I would expect your performance to be worse than mine (with no coupling) given the increased size of your home. The XPCR is an X10 active repeater - it will not work for insteon. The repeater monitors X10 one one phase and then repeats it on the opposite phase. Since the repeater does not understand Insteon, it will not repeat the signal.

Hi Lou, From our previous conversations, I've got a fair idea of the size of your home and installed equipment... I have to say here that I'm in Lee's camp on this one - I'm surprised your system is functioning. The current Smarthome 2406 hardwired Insteon Phase coupler is an X10 coupler. It previously carried a different model # and was advertised as an X10 coupler - the internal components are identical. Some X10 couplers are a bit different - the ACT CP-000 uses twin tuned transformers to couple the signals across phases. Elegant, but it actually performs a bit worse than the Smarthome model. Your X10 coupler should help (assuming it's passive). Were it me, I would try locating it as close to your PLM as possible. I say should because I don't understand how things are functioning now. IM

Lou, You've already answered the question. Reading device link tables is a communication intensive action that takes a fair period of time. If your system was having communication problems you would likely have receive the dreaded "xxx failed to communicate" error. I have a excel macro that can post process the event viewer results from a link table scan. It rolls up statistics on the number of hops required throughout the process. If you're interested, PM me and I can give you instructions. Regarding your PLM - is it a dual band unit?

That was my point. The SWL didn't hear the ack in 1 hop (it took two) which resulted in the SWL message being sent to the PLM twice. On the second ACK from the PLM, it allowed for more hops, so it got through to the SWL. So I was trying to get the ACK to go through in one hop (not 2). Not knowing the path taken, I consisdered that the rf signal lincs may have been involved. If using a dual band plm takes one hop out versus two signal lincs, then that was my idea. My mistake - I thought you were trying to improve communications to the PLM when the problem is actually in the opposite direction. A dual band PLM communicating to a dual band SWL might eliminate one hop. A dual band PLM to a Accesspoint would (I believe) still require one hop. Based on my subjective experience, I can would say that the dual band PLM is not as effective a RF receiver as and accesspoint. I do not know how the two compare when transmitting. ELA and I have been having a sidebar conversation on this and he has brought up a good point. Insteon devices are characterized for 3.2 Vp-p into 5 ohms. If you had a local signal absorber (plug in device with a EMC cap) at or below 5 ohms it would reduce the output of your PLM. In short, please police your PLM circuit for potential absorbers. This is really interesting. You may be one of the lucky few that has a low impedance path through your utility transformer (rare but it does happen). I am able to communicate through the transformer "at times". If I stress my system (turn on various CFL loads) my I break the system. My phase coupling is through a hardwired passive coupler (similar to Tim's). I have also been playing with a accesspoint close coupled to the dual band PLM. I've been performing link table scans of some of my KPL's and post processing the Event viewer to determine communication efficiency. I'm still playing with this, but I have a number of test runs that indicate that adding the accesspoint increases PLM retries. I will confess that I do not understand how the accesspoints/dual band features operate and am struggling to come up with a theory why RF coms would result in retries. The best I can come up with is a difference in powerline data VS RF data causing the PLM to throw up it's hands and retry the transmission. Would you mind trying some link table scans on your SWL to see how reliable the comm's are? IM

Lou, If I understand Lee's diagnosis correctly, this is not a HOP count situation - 1) The PLM heard your SWL on it's original broadcast and activated your program. The PLM attempted to acknowledge, but the cleanup command was sent with a Hop count of 1. The PLM had to respond with a hop count of 1. 2) The SWL did not hear the PLM's acknowledge, and sent a second cleanup message to the PLM with a Hop count of 2. This activated your program a second time and caused the unwanted effects. The PLM acknowledged a second time and your SWL apparently heard the acknowledge with a hop count of 2 (I didn't try a third time). These are separate communications. The issue is that your SWL can't hear the PLM with a hop count of 1. Noise and signal absorbers act differently on transmitters and receivers - 1) A signal absorber close to a transmitter will normally not prevent devices from hearing it's transmissions. This is because the transmitter is capable of driving the load of the absorber. 2) A signal absorber close to a receiver will draw down incoming signal levels due to the impedance (resistance) of your home wiring. 3) A noise source close to a transmitter will have little affect on it's ability to transmit effectively. 4) A noise source close to a receiver can interfere due to the decreased level of the inbound signal. From the sounds of things, your PLM can listen and transmit effectively. At the opposite end (your SWL) the signal is either being absorbed for interfered with by noise - normally both with exist. If your SWL is within RF signal range, you could try moving a accesspoint to the same circuit. This could improve the signal/noise ratio to the point where the SWL could hear the PLM on one Hop. Not a fix - but it would help to isolate the problem. IM Edit: To answer your question on a 0 hop configuration - The only way that I know to accomplish this is with a passive coupler in close proximity to the PLM. The signal will be coupled to the opposite phase on the initial transmission. This would allow devices on both phases to repeat the signal on the first HOP. Do you know whether your SWL is on the opposite phase from your PLM?

Hello Lou, Yes - I believe that in a RF coupled system, A device that transmits from the opposite phase will be heard by the PLM on the 1st hop. Here's a bit better chart - A dual band PLM could conceivably hear a RF transmitter during the original transmit (HOP 0). This wouldn't buy you anything in terms of system response since no commands are transmitted with a hop count less than 1 (that I'm aware of). The PLM must wait until the HOP count expires before it can respond to the transmission. I also do not know what the PLM (or any RF device) will do if confronted with RF and Powerline information that doesn't agree. Hope that helps, IM

Hi Lou, I believe it requires 1 Hop for the Insteon RF couple. Using the chart below: 1) Initial transmit requires 5 zero crossings of the 60 Hz AC. 2) Between the Initial transmit and the 1st hop transmit there is one "open" zero crossing. The RF devices communicate during this half cycle. 3) RF devices will then transceive the RF info onto the powerline during the 1st HOP.

Hi Lou, As Lee indicated, the InsteonDetails guide gives you the formatting and bit structure of the messages transmitted over the powerline. The information displayed in the Event Viewer is actually Modem responses back to the ISY. The ISY tries to add descriptors of the information being received. The transmitted/received messages are preceded with codes like: "02 62": modem acknowledging a standard message from the ISY. ISY tags with the [iNST-ACK] "02 50": standard message received from a device. ISY tags with the [iNST-SRX] Thu 09/29/2011 08:24:14 PM : [iNST-ACK ] 02 62 0A.DB.0B 0F 2B 05 06 PEEK (05) Thu 09/29/2011 08:24:14 PM : [iNST-SRX ] 02 50 0A.DB.0B 13.22.F9 2B 2B 00 PEEK (00) Some of these codes are included in the modem developers guide: http://www.smarthome.com/manuals/2412sdevguide.pdf The Insteondetails paper defines the formatting of the remainder of the message. It does not give the actual command1 and command2 codes. Some of these are included in the Insteon command tables document: http://www.insteon.net/pdf/INSTEON_Command_Tables_20070925a.pdf From the example presented above, command1 is 0x2B which indicates that this is a peek operation - reading a device link table (tagged that way by the ISY). Command2 is 0x05 which is address that location that is being requested (again indicated by the ISY. Clear as mud, right? Unfortunately there is no single guide for this. You need to understand the protocol, modem commands, and device commands/responses as one package. Sorry but that's about the best I can do. I'm not proficient at reading this stuff either. Lee is - when he speaks, I listen and try to learn. I have learned from this thread. If Lee convened a course on the topic, I'd attend. IM

Hi Lou, I tried your program and am sorry to report that I receive the same results as reported by Tim. I tried multiple ramp rates, on/off/fast on combination's - worked correctly every time (100+ attempts). Is it possible that you're getting a "double bounce" via RF? I have only one accesspoint installed. Not sure whether "many" AP's could produce a bounce that the ISY would read as a second press on the switch. If Status 'Basement / BSMT Fam Cans' is Off And Control 'Basement / BSMT Fam Cans' is switched Off Then Set 'Basement / BSMT Fam Cans' 25% Else - No Actions - (To add one, press 'Action')

J0dan, Chris, Michel, Lou, and anyone else who's time I wasted with my post - My apologies - it was a complete cluster... I was attempting to show a program variable used as a latch - I butchered it. For what it's worth, the following is what I should have posted. Lou's approach using variables is superior. On Program with Latch If ( Status '1st Floor / Bar Cans' > Off Or Status '1st Floor / Bar Lamp' is On Or Status '1st Floor / Dinnette SWL' is On Or Status '1st Floor / Fam Room / Fam Fan' is On Or Status '1st Floor / Fam Room / Family Room LampLinc' > Off Or Status '1st Floor / Fam Room / Family Room Lamplinc' > Off Or Status '1st Floor / Fam Room / Fireplace Spots' > Off Or Status '1st Floor / Foyer' > Off Or Status '1st Floor / Fam Room / Fam KPL 1 - Wall' > Off ) And Program '1st Floor Status On Latch' is False Then Run Program '1st Floor Status On Latch' (Then Path) Set Scene 'SC 1st Floor Status On' On Else - No Actions - (To add one, press 'Action') Status off Program with Latch If ( Status '1st Floor / Bar Cans' is Off And Status '1st Floor / Bar Lamp' is Off And Status '1st Floor / Dinnette SWL' is Off And Status '1st Floor / Fam Room / Fam Fan' is Off And Status '1st Floor / Fam Room / Family Room LampLinc' is Off And Status '1st Floor / Fam Room / Family Room Lamplinc' is Off And Status '1st Floor / Fam Room / Fireplace Spots' is Off And Status '1st Floor / Foyer' is Off And Status '1st Floor / Fam Room / Fam KPL 1 - Wall' is Off ) And Program '1st Floor Status On Latch' is True Then Run Program '1st Floor Status On Latch' (Else Path) Set Scene 'SC 1st Floor Status On' Off Else - No Actions - (To add one, press 'Action') Program Latch If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')

Michel, I tested the above code in a few "status" programs that I use. Curiously, the program summary shows the Program executing the "Then" statement even though the condition Program state is shown as "true". Watching the event viewer, I can see that the Then clause is not being executed - but the program summary page indicates that it is. Am I setting up a transient condition that is confusing the ISY?

Hello j0dan, If you are issuing the LED command from within the Then statement, the following "Lockout" should work. The program will execute the Then statement when the first lamp is turned on and the Program status will become "True". Turning on subsequent lamps will not execute the Then statement since the program is already "True".

Upgrade went smoothly (V3.1.6 to V3.1.7). Some good results, some not so good - 1) Verified that the irrigation calculation persists through ISY resets - thank you. 2) Verified that Generic X10 Devices (non-queryable) are not interrogated during "my lighting" query - thank you again. 3) Lost the "batch write control" capability that was a feature of the PRO version. The control buttons are missing in the GUI and I do not see a method of activating things through the menu system. I really hope this feature hasn't been eliminated - I used it constantly. IM

Hello ELA, It's probably very naive on my part, but I don't normally think of a refrigerator (motor load) as being a problem device for Insteon. I say naive because manufacturers are constantly adding new bells and whistles to appliances. It's very possible that the new generation refrigerators do appear capacitive as opposed to my 25 year old Kenmore. I'll find out soon enough - my better half is keen to replace the Kenmore. Beyond the above, I don't doubt for an instant what you are seeing. I'm simply questioning whether a true resonant condition can exist for any significant period of time with other loads being activated. While I'm sure that it can and does happen, I've never been able the capture this condition "in the act". Looking forward to your conclusion when you get to moving the refrigerator (not a task I take lightly). IM

EDIT: I've just re-read your post and am not sure whether your outlets are on the same breaker (branch) or different breakers. If the outlets are on different breakers it's also possible that you are measuring different phases. Voltage differences across the phases are not uncommon when there is a load imbalance (one phase heavily loaded, the other lightly). If your comfortable with it, try measuring the voltage at the load panel for each phase. If you have no loads installed on your outlets, the voltage at the panel should be the same as the outlet voltage. If it is not, you either have a very bad connection or a device drawing significant current. The resonances that ELA and I were referring to apply at the Insteon frequencies of 130 KHz. They do not apply to the 60 Hz power distribution within your home. Original message below- Mark, I am very much hoping that you simply had a bad connection to your voltmeter when you measured the 114V. Assuming that there was no load on the outlet at the time, a 3 volt drop (117 to 114) would qualify as an extremely bad connection. Your meter should be high impedance and therefor be drawing an insignificant amount of current and no noticeable voltage drop. Please inspect/tighten the connections to this outlet and retest. If the drop is occurring at the wire attachment, it will generate heat (i.e. dangerous). It's possible that the receptacle "prongs" were simply oxidized and not allowing your meter to make a good connection. The acid test would be to apply a light load (60 watt incandescent) and monitor for a voltage drop. Again, a 60W load should be insignificant. If you measure a drop with the load installed, replace the outlet and re-test. IM

Hello Mark, Let me start by saying that I like your description of the PLM communicating into the load panel. Assuming that PLM is close coupled to the panel, it will attempt to drive the loading at that point to the full 3.2 Vp-p. The load at the panel is a complex composite of all of the loads in your home reflected back to the panel. I say attempt because it's possible that the signal loading at the panel is high enough that the PLM can't drive it to full level. The signal will then fan out across the branch connections on that phase. Signal degradation on a given branch can usually be viewed on a branch by branch basis. If you have a passive coupler that the panel, the PLM signal will be coupled in phase at a lower level and also fan out on that phase. If you are using a RF coupler, the PLM signal will be coupled on the next hop, but again at whatever level the RF coupler can drive into the load it "sees" (presumably 3.2Vp-p). ELA is exactly correct that the signal propagation through the branch circuits can be an extremely complex "transmission" with resonances and nodes as the R-L-C characteristics interact. That said, ELA and I share similar backgrounds and tend to think in these terms (EMI/EMC background - other engineers consider us to be "geeks"). Not speaking for ELA, but I sometimes drift off into complex theories of what might happen rather than gathering all the facts and focusing on what is happening. For most installations, you can consider the powerline as a simple resistive divider circuit. The longer the line, the more series resistance. The more loads installed, the lower the resistance to return (more signal degradation). This resonance condition was exactly what I was thinking of when you described the following: Since your SWL responded well to an off command, I was theorizing that you had a long transmission line and the added Inductive load of the transformer(s) was changing the powerline impedance and effectively killing a resonance at that point. I had hoped that you would install a incandescent lamp at the IOLinc location (not at the switchlinc) and thereby change the R-L-C loading for both the On and Off cases. Although you mis-interpreted the intent, you may have provided enough information to disprove this theory: 1) Your Switchlinc is close coupled to your media center and both are close coupled to the panel (18 inches - not a long line). 2) Your PLM is close coupled to the panel. 3) Is your PLM on the same phase as the SWL, or at least bridged at the panel? If your PLM is on the same phase (or coupled at the panel), your distances should be too short to set up a resonant condition (low line impedance). Adding an incandescent load would not have accomplished anything. A more likely scenario would be - 1) Your media center components are significant "signal suckers". Since these are close to the panel, they could be degrading signals from distant transmitters. 2) You have some noise on this circuit. The combination of noise and "signal suck" are degrading the inbound PLM signal to the point where it is marginal. When the SWL is turned on, you are adding the inductive load of the transformer and effectively filtering some of the noise at the SWL location. This allows the device to hear to the "off" command. Since your media center does appear to be a source of loading/noise (and it's close to the panel), I would agree with the others that filtering this circuit would be wise to prevent possible problems at the PLM. I am also curious whether you swapped to the opposite phase when you reconnected your SWL. In regard to your last comment: What ELA stated is absolutely true in a very strict controlled environment. Resonances will happen, particularly on long lines. In the home, this is normally a "transient" condition since the impedance of our home powerlines are constantly changing (every time we switch on or plug in a device we change the impedance). While I've been able to setup and measure resonances under controlled conditions, I have never observed one in the home. I have witnessed 2 instances of "global signal damagers": 1) The Boosterlinc - these devices actively interfere with insteon signals. The newer "Insteon blessed" devices are better than the old models, but still interfere with low level Insteon signals (unless there is a Rev 3.0 out there). 2) Oscillating power devices - These can be triac dimmer outputs that are "unhappy" with the load (CFL) or other power outputs that are on their last legs. While oscillating, these devices can draw significant power and radiate long distances (lower frequency than Insteon). Noise produced by these devices can activate the Automatic Gain Control (AGC) on Insteon devices and render them "deaf" to valid transmissions. Not sure whether this helps or simply confuses things further... IM

Hi Mark, I've been watching from a distance and have not had anything to add because Lee's diagnosis has (as usual) been excellent. You're last post indicated that the "off command" may be working properly, while the "on command" shows the delay. This is rather odd unless the powerline is interacting with the installed devices on this circuit. [*:14x3knq3]Is this a GFCI or AFCI circuit? [*:14x3knq3]If turning on the LED transformer does improve communications, it could be performing the function of a line terminator. Could you try plugging in a Incandescent lamp in the IOlinc location?