Failing PLM Causing Comm Errors?

[TechieLights]

Hi,

I've just recently started getting communications errors to some devices in my home. My first thought is that it's a failing PLM - it's been about 2 years since I replaced it. But the incidence of the comm errors makes me question that conclusion.

The problems are mostly showing up when a program tries to turn off the devices - 3 of them, one after the other. Any one of the 3 may experience the comm error, but the first one gets the problem more frequently (about 2 times more). The then portion of the program looks like

Then
        Set 'Sun Room Desk Lamp - 27.CB.04' Off
        Set 'LR Lamp - 27.CE.C0.1' Off
        Set 'Front Outdoor LEDs' Off
 

 

The program that turns these on is working as the lights are on when I get home from work. But the off program is not turning them all off. Sometimes 1, sometimes 2, and sometimes all 3 don't go off.

Using the admin console I turn the lights on, and then run the off program (run then), and the console reports

But if I use the console to turn the light on and off, it works, mostly. If I tum the scene on and off, it works every time, and the action is immediate. If I turn the device on and off, the action is delayed at least a second, sometimes 2 or more seconds. In some infrequent cases I will get the comm error when turning the device on or off using the admin console. But the program off has problems almost every time.

So do you think the PLM is the likely cause? Or is something else more likely to blame?

These issues started Jan 17. I haven't changed any programs, or settings, or devices in some months. The devices have been in place for years. The PLM is v2.3, date code 4216, and version v9E. The software is:

The devices are 1 Dualband SwitchLinc v.43 (2477S), and 2 On/Off module v.46 (2635-222).

Any help is appreciated.

Thanks,

Bob

 

[larryllix]

Welcome to the UDI forums!

 

Just to complicate things.

I started having much worse problems just before Christmas. Things seemed to get worse every day. Finally I swapped my old working PLM back in, and spent the day updating things back to work with the older PLM again. When almost done, I realised these problems coincided with a new battery operated garage door opener my wife bought me for Christmas.

Luckily the worse comm problems were on the same circuit as the GDO and I realised I have had problems with this same KPL since the first GDO was installed, years ago, even though it was an AC motor and a completely different technology. Easy test! I unplugged both GDOs and ran a few manual operations from ISY. Then I extension corded both GDOs to another circuit receptacle and things seemed to work fine again.

Two FilterLincs resolved the problem and things are plugged back into their original receptacles. A GDO kit,  IO/Linc is plugged into the back of one  FilterLinc with absolutely no problems now.

In short you may want to try dumping breakers and trying to see if you can isolate the comm to a noise maker(s).
OTOH: A spare PLM may not be a bad idea to have on hand, just-in-case, and for later usage....and a FilterLinc or two for troubleshooting.

[Techman]

If the load turns on but doesn't turn off then there's a good possibility that the load is creating noise on the powerline which is interfering with the Insteon signal. I highly doubt that your PLM is the problem

What type of load is on the devices you're having problems with, i.e.; CFL, LED or Incandescent bulbs?

Set your event viewer to level 3 then try to turn off the lights. You should be able to see which device is causing the problem.

 

[TechieLights]

Hmm. Thanks for the suggestions. There are 2 lamps with CFLs and one with outdoor LED fixtures.

I tried leaving the the lights all off and running the off program to see if the comm errors occur without those loads active. I still see comm errors, on all 3 but not at the same time. One CFL lamp which is the farthest away (sunroom) from the PLM seems to be affected more frequently.

With all lamps off, here are different off events:

Turning off the sunroom lamp scene (containing only the sunroom lamp) 3 times gives these event logs:

Mon 01/28/2019 15:08:39 : [INST-TX-I1  ] 02 62 00 00 11 CF 13 00
Mon 01/28/2019 15:08:39 : [INST-ACK    ] 02 62 00.00.11 CF 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:08:46 : [INST-TX-I1  ] 02 62 00 00 11 CF 13 00
Mon 01/28/2019 15:08:46 : [INST-ACK    ] 02 62 00.00.11 CF 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:08:49 : [        Time] 15:08:59 0(0)
Mon 01/28/2019 15:08:56 : [INST-TX-I1  ] 02 62 00 00 11 CF 13 00
Mon 01/28/2019 15:08:56 : [INST-ACK    ] 02 62 00.00.11 CF 13 00 06          LTOFFRR(00)

Turning off the sunroom lamp device 3 times gives these event logs:

Mon 01/28/2019 15:11:16 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:11:16 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:11:17 : [INST-SRX    ] 02 50 27.CB.04 44.2F.7C 2B 13 00    LTOFFRR(00)
Mon 01/28/2019 15:11:17 : [Std-Direct Ack] 27.CB.04-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 01/28/2019 15:11:23 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:11:23 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:11:23 : [INST-SRX    ] 02 50 27.CB.04 44.2F.7C 2B 13 00    LTOFFRR(00)
Mon 01/28/2019 15:11:23 : [Std-Direct Ack] 27.CB.04-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 01/28/2019 15:11:28 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:11:28 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:11:29 : [INST-SRX    ] 02 50 27.CB.04 44.2F.7C 2B 13 00    LTOFFRR(00)
Mon 01/28/2019 15:11:29 : [Std-Direct Ack] 27.CB.04-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

I'm not sure why there are more logs in the second case. Is it normal?

Turning off all 3 using the off program (starting with lamps already off so (hopefully) not making noise:

Mon 01/28/2019 15:14:23 : [        Time] 15:14:34 0(0)
Mon 01/28/2019 15:14:23 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:14:23 : [INST-TX-I1  ] 02 62 27 CE C0 0F 13 00
Mon 01/28/2019 15:14:23 : [INST-TX-I1  ] 02 62 28 BB 86 0F 13 00
Mon 01/28/2019 15:14:23 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:24 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:24 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:14:24 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:24 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:14:25 : [INST-SRX    ] 02 50 28.BB.86 44.2F.7C 2F 13 00    LTOFFRR(00)
Mon 01/28/2019 15:14:25 : [Std-Direct Ack] 28.BB.86-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 01/28/2019 15:14:29 : [D2D EVENT   ] Event [27 CB 4 1] [ERR] [1] uom=0 prec=-1
Mon 01/28/2019 15:14:29 : [   27 CB 4 1]      ERR   1
Mon 01/28/2019 15:14:51 : [        Time] 15:15:02 0(0)
Mon 01/28/2019 15:14:51 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:14:51 : [INST-TX-I1  ] 02 62 27 CE C0 0F 13 00
Mon 01/28/2019 15:14:51 : [INST-TX-I1  ] 02 62 28 BB 86 0F 13 00
Mon 01/28/2019 15:14:51 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:51 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:51 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:14:52 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:14:52 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:14:53 : [INST-SRX    ] 02 50 28.BB.86 44.2F.7C 2F 13 00    LTOFFRR(00)
Mon 01/28/2019 15:14:53 : [Std-Direct Ack] 28.BB.86-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 01/28/2019 15:15:21 : [        Time] 15:15:32 0(0)
Mon 01/28/2019 15:15:21 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:15:21 : [INST-TX-I1  ] 02 62 27 CE C0 0F 13 00
Mon 01/28/2019 15:15:21 : [INST-TX-I1  ] 02 62 28 BB 86 0F 13 00
Mon 01/28/2019 15:15:21 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:15:21 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:15:21 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:15:21 : [INST-SRX    ] 02 50 27.CE.C0 44.2F.7C 2F 13 00    LTOFFRR(00)
Mon 01/28/2019 15:15:21 : [Std-Direct Ack] 27.CE.C0-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 01/28/2019 15:15:22 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:15:22 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:15:25 : [INST-SRX    ] 02 50 28.BB.86 44.2F.7C 2F 13 00    LTOFFRR(00)
Mon 01/28/2019 15:15:25 : [Std-Direct Ack] 28.BB.86-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

The first off run produced a comm error on the sunroom CFL lamp (at 15:14:29) but all lamps were already off. All 3 show duplicate ACKs for the other 2 lamps. I'm not sure what the duplicate ACKs imply about this problem (if anything).

Here's one other comm error on the outdoor LEDs from a few minutes later:

Mon 01/28/2019 15:34:28 : [        Time] 15:34:31 0(0)
Mon 01/28/2019 15:34:28 : [INST-TX-I1  ] 02 62 27 CB 04 0F 13 00
Mon 01/28/2019 15:34:28 : [INST-TX-I1  ] 02 62 27 CE C0 0F 13 00
Mon 01/28/2019 15:34:28 : [INST-TX-I1  ] 02 62 28 BB 86 0F 13 00
Mon 01/28/2019 15:34:28 : [INST-ACK    ] 02 62 27.CB.04 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:34:29 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:34:29 : [INST-ACK    ] 02 62 27.CE.C0 0F 13 00 06          LTOFFRR(00):  Duplicate or ACK for a different device 
Mon 01/28/2019 15:34:29 : [INST-SRX    ] 02 50 27.CB.04 44.2F.7C 2B 13 00    LTOFFRR(00)
Mon 01/28/2019 15:34:29 : [Std-Direct Ack] 27.CB.04-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 01/28/2019 15:34:29 : [INST-ACK    ] 02 62 28.BB.86 0F 13 00 06          LTOFFRR(00)
Mon 01/28/2019 15:34:33 : [D2D EVENT   ] Event [28 BB 86 1] [ERR] [1] uom=0 prec=-1
Mon 01/28/2019 15:34:33 : [  28 BB 86 1]      ERR   1
Mon 01/28/2019 15:34:33 : [INST-SRX    ] 02 50 28.BB.86 44.2F.7C 2F 13 00    LTOFFRR(00)
Mon 01/28/2019 15:34:33 : [Std-Direct Ack] 28.BB.86-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 01/28/2019 15:34:33 : [D2D EVENT   ] Event [28 BB 86 1] [ERR] [0] uom=0 prec=-1
Mon 01/28/2019 15:34:33 : [  28 BB 86 1]      ERR   0

The outdoor LEDs are switched with the Dualband SwitchLinc which is just 8 feet away from the PLM, but on a different circuit.

If the PLM is wearing out (those capacitors?) could it generate noise itself?

Are these logs showing helpful information? I'm not sure how to interpret them.

Bob

 

[TechieLights]

I turned on the sunroom lamp and ran the off program and repeated this a few times. I got the comm error about half the time. I switched the CFL to an LED and repeated the tests. About the same - the comm error occurred about half the time if the lamp was on. In one case the other CFL (which was off, and in the same room as the PLM) had the comm error.

Bob

 

[larryllix]

51 minutes ago, TechieLights said:

I turned on the sunroom lamp and ran the off program and repeated this a few times. I got the comm error about half the time. I switched the CFL to an LED and repeated the tests. About the same - the comm error occurred about half the time if the lamp was on. In one case the other CFL (which was off, and in the same room as the PLM) had the comm error.

Bob

 

Try restoring the device in question.

In the admin console, right click on the device name in the device tree. Select Restore. Wait until the indicators stops flashing and is done writing to the device.
Now try it again. At time some links can get missed or destroyed by noise on your powerline confusing updates etc..

This works for any Insteon device but battery devices must be put into linking mode first. That is a battery saver technique for Insteon battery devices.

[kclenden]

1 hour ago, larryllix said:

Try restoring the device in question.

I would go a step further and first factory reset the Sun Room Desk Lamp device.  Then use the ISY to restore the device per larryllix's instructions.  I have a KeypadLinc that starts having communication problems 2-3 times a year.  Factory resetting it and a restore usually fixes the problem for a while.  I've got a new KPL to replace it with, but have been too lazy to get around to it.  Shows just how easy a factory reset and device restore really is.  ?

[Techman]

Quote

 

 

1 hour ago, TechieLights said:

I turned on the sunroom lamp and ran the off program and repeated this a few times. I got the comm error about half the time. I switched the CFL to an LED and repeated the tests. About the same - the comm error occurred about half the time if the lamp was on. In one case the other CFL (which was off, and in the same room as the PLM) had the comm error.

Bob

 

Are you switches dual band, if not you may want to consider upgrading them.

Are both sides of your powerline bridged?   Take a look at this article    https://wiki.universal-devices.com/index.php?title=INSTEON:_Troubleshooting_Communications_Errors

Did you add any new electrical devices or appliances around the time your problem started?

 

 

 

[kclenden]

To answer some of your questions about the Event Viewer log:

• You see fewer entries when you turn a scene on/off because the ISY does not ask for an acknowledgement from devices when using a scene command.  When directly commanding a device, the ISY sends the command and then the device sends an acknowledgement.
• The Duplicate ACKs that you see are due to the nature of a mesh network.  Each device also acts as a repeater.  So when a device acknowledges a command from the ISY, other devices repeat that acknowledgement to increase the reliability of the communication.  The ISY simply ignores the duplicate ACKs.
• In all of your logs, the ACKs from the Sun Room Desk Lamp consistently show "Hops Left=2".  This could merely  be the luck of the the log entries you posted, but if it's always the case that the "Hops Left" is always "2" it means that the Sun Room Desk Lamp acknowledgements are only getting back to the ISY after they have been repeated and never directly from the Sun Room Desk Lamp.  This usually happens when an RF ONLY devices is out of RF range of the PLM and has to depend on a dual-band powerline device to repeat it's communication.  If the Sun Room Desk Lamp device is not an RF ONLY device, then I would suspect either a problem with it, or something between (on the power line) it and the PLM.  Edit: Techman mentioned bridging in his post above.  Bridging could explain why a power line device consistently has "Hops Left=2" and wouldn't necessarily imply an actual communication problem.

[paulbates]

I don’t think I saw this in the other suggestions. If you have to device commands back to back in a program, it’s problematic because it doesn’t leave room for the return acknowledgment from the devices. Even though it may have worked in the past, a two second wait command between devices should help, or use a scene as I think others have suggested

Paul


Sent from my iPhone using Tapatalk

[larryllix]

1 hour ago, paulbates said:

I don’t think I saw this in the other suggestions. If you have to device commands back to back in a program, it’s problematic because it doesn’t leave room for the return acknowledgment from the devices. Even though it may have worked in the past, a two second wait command between devices should help, or use a scene as I think others have suggested

Paul


Sent from my iPhone using Tapatalk

This is not supposed to happen with the protocol by  Insteon protocol definitions but....

...if your house has a lot of noise the protocol gets confused and destroy device links or  clobber other signals. We have seen this with the All-On syndrome in the past.

If your devices are getting messed up from time to time then Insteon disturbance noise should be investigated.

Paul's suggestions is a good work around I have used for years, or put the offending device at the end of the list, so it comes last.

[paulbates]

Yes, isy programs are a special case. ISY programs send commands to the plm, and it acts. The plm is not smart enough to know to wait for returning acks from previous program statements; it will send new Insteon commands from an ISY Program right on top of a returning acknowledgment, creating retries and eventual failures.

 

The 2 second wait command between back to back Insteon device commands handles it.

 

Paul

 

 

Sent from my iPhone using Tapatalk

 

[TechieLights]

Thanks for all the helpful input. I have some work to do with these.

Regarding some questions asked: The devices in the logs are all dual band. Two are on/off modules (2635-222) and one is a SwitchLinc (2477S). The SwitchLInc and one On/Off module are in the same room as the PLM, one at 8 feet from the PLM and the other at 18 feet. The closer one has a clear line of sight from the PLM. The farther one has a couch and a speaker along the line of sight. Both are getting some comm errors these days that they weren't getting before. The third device is the sun room module and it's 2 rooms away from the PLM, so getting an extra hop is quite possible.

I'm not sure if I have both sides of the powerline bridged. I'll have to look into this more. I'm not sure how to identify the "sides". I don't have any devices installed just for that purpose (e.g. AccessPoints).

There are no new electrical appliances or devices this month. There were some in December, but my comm problems started Jan 17. Nothing in my house is giving me problems that might make me suspect it might be causing noise now that is wasn't before, but I suppose something might be getting noisy without other noticeable indicators.

I'll go off and try the suggestions offered - add wait times to the program; reset and restore devices; try using scenes.

Thanks again for the input. Much appreciated.

Bob

[TechieLights]

So I've done the following, but there hasn't been any improvement:

• Added a 3 second wait between the program lines to turn off the devices.
• Factory reset each of the 3 devices and restored each.

I'm seeing comm errors on all 3 devices, in about equal incidence. Yesterday the sun room lamp seemed to be affected more frequently but today it seems to be more equal across the 3 devices.

I'm going to experiment with scenes now.

Bob

[Techman]

1 hour ago, TechieLights said:

Thanks for all the helpful input. I have some work to do with these.

Regarding some questions asked: The devices in the logs are all dual band. Two are on/off modules (2635-222) and one is a SwitchLinc (2477S). The SwitchLInc and one On/Off module are in the same room as the PLM, one at 8 feet from the PLM and the other at 18 feet. The closer one has a clear line of sight from the PLM. The farther one has a couch and a speaker along the line of sight. Both are getting some comm errors these days that they weren't getting before. The third device is the sun room module and it's 2 rooms away from the PLM, so getting an extra hop is quite possible.

I'm not sure if I have both sides of the powerline bridged. I'll have to look into this more. I'm not sure how to identify the "sides". I don't have any devices installed just for that purpose (e.g. AccessPoints).

There are no new electrical appliances or devices this month. There were some in December, but my comm problems started Jan 17. Nothing in my house is giving me problems that might make me suspect it might be causing noise now that is wasn't before, but I suppose something might be getting noisy without other noticeable indicators.

I'll go off and try the suggestions offered - add wait times to the program; reset and restore devices; try using scenes.

Thanks again for the input. Much appreciated.

Bob

 

Did you review the troubleshooting link I sent you?

You need to verify that the two sides of your powerline are bridged. This can be accomplished by using the 4 tap test on one of your newer plug in modules.

Do you have any CFL lights that were on at the time you noticed the problems?  CFL bulbs can cause interference on the powerline.

[TechieLights]

29 minutes ago, Techman said:

 

Did you review the troubleshooting link I sent you?

You need to verify that the two sides of your powerline are bridged. This can be accomplished by using the 4 tap test on one of your newer plug in modules.

Do you have any CFL lights that were on at the time you noticed the problems?  CFL bulbs can cause interference on the powerline.

Yes I read the troubleshooting link, but I am unfamiliar with "sides" of my "powerline", so I need to learn about  this. If the two sides aren't bridged,  I wonder how is it I've been running so long (years) without having these comm errors. I will try the 4 tap test if my plugin module supports it. How new do they need to be?

I had CFLs in 2 of the lamps, but I've now replaced them with LEDs. I'm still getting comm errors on all 3 devices. Noise must be coming from another source.

Bob

[larryllix]

I usually credit dimming LED bulbs for less noise but only based on previous electronic experience and not reality. Either way, LED bulbs can be bad, as well as any electronics especially those little switching Walmart adapters. Even motors with split laminations create harmonics

 

Plugging your PLM and/or ISY into some ac splitters/power bars can be a problem with signal suckers and spike clippers inside.

 

You powerline has two sides or phases that are 120 volts each. Together they make 240 volts for big items like your electric stove and dryer.

Signals would have to transverse from you PLM out to your street transformer and back to your plugin device.

 

Insteon came up with a smart solution by making devices dual band using RF to also communicate. By repeating signals over rf device signals can span to 'the other side'.

 

The four tap test can make other devices flash codes to identify if they are on the same or opposite side and whether they hear signals at all

 

 

 

 

[TechieLights]

I've created a scene and put the 3 devices into it. I can use the console to turn the scene on and off at will. so far I haven't seen a case where the lamps haven't switched as expected.

So I've set up 4 programs - 2 for the scene (scene-on and scene-off), and 2 for the devices individually (devs-on and devs-off).  Scene-on and scene-off both run almost flawlessly. There was one run where one lamp didn't switch, but no comm errors were reported, and the lamp switched just fine after that.

Devs-on and Devs-off both switch the devices on or off, one at a time, with a 3-second wait time in between. These 2 programs both have issues with comm errors fairly frequently - like every 3rd or 4th run.

So I'm thinking that the issue appears to affect messages from the devices to the ISY/PLM more than messages from ISY/PLM to the devices. The scene programs work very well and for those the ISY sends commands to the devices and doesn't worry about replies or ACKs. The devs programs don't work so well and for those the ISY/PLM are expecting responses from the devices and when they don't get them, they report a comm error.

So something (noise I suppose) is impairing the ability of the PLM to hear the messages from the devices, but not the ability of the devices to hear messages from the PLM.

I'll revise my "production" programs to use the new scene and avoid using the devices directly.

Bob

[TechieLights]

2 minutes ago, larryllix said:

I usually credit dimming LED bulbs for less noise but only based on previous electronic experience and not reality. Either way, LED bulbs can be bad, as well as any electronics especially those little switching Walmart adapters. Even motors with split laminations create harmonics

Plugging your PLM and/or ISY into some ac splitters/power bars can be a problem with signal suckers and spike clippers inside.

Sent from my SM-G930W8 using Tapatalk
 

My PLM isn't on a splitter/power bar. The LED bulbs I just put in to replace the CFLs are non-dimming. Since the comm errors occur with both CFLs and LEDs, I believe the source of noise is something else.

Bob

[Techman]

24 minutes ago, TechieLights said:

My PLM isn't on a splitter/power bar. The LED bulbs I just put in to replace the CFLs are non-dimming. Since the comm errors occur with both CFLs and LEDs, I believe the source of noise is something else.

Bob

Give this a try   https://wiki.universal-devices.com/index.php?title=INSTEON_Signal_/_Noise_Troubleshooting

 

[TechieLights]

8 minutes ago, Techman said:

Give this a try   https://wiki.universal-devices.com/index.php?title=INSTEON_Signal_/_Noise_Troubleshooting

 

Thank you. That will help.

Bob

[larryllix]

My PLM isn't on a splitter/power bar. The LED bulbs I just put in to replace the CFLs are non-dimming. Since the comm errors occur with both CFLs and LEDs, I believe the source of noise is something else.
Bob

To completely eliminate this try incandescents in the sockets so you can move forward

Sent from my SM-G930W8 using Tapatalk