schda12 Posted March 27 Posted March 27 I have read that newer PLM's are much more sensitive to electrical noise and their signal is much weaker than the old ones. I've been trying various locations with my new Eisy and PLM (2413S). I am surprised that the PLM typically failed to communicate with a Switchlink Dimmer (2477D) when the PLM is plugged into a receptacle in the same (plastic) electrical box and circuit as the switch. The Eisy event viewer shows three INST-TX-I1 requests with no responses. At the same time the switch responds as usual to the scene requests from a 6-button controller across the room. The interference pattern changes mysteriously and the query works along with on and off requests from Eisy. Possible intermittent noise sources are an Aprilaire Steam Generator on a different circuit about 10 feet away and a geothermal heat pump also about 10 feet away. Sometimes it seems to help to add an extension cord to the PLM to keep it away from the tiny Eisy power supply in the same receptacle. It also fails that way. Am I describing a typical PLM failure or an extreme one that suggests a bad PLM? Do other electrical devices often block both the powerline signals and the RF signals? Are there additional diagnostic steps that might reveal something useful? Thanks, David
hart2hart Posted March 27 Posted March 27 Not a direct response… I don’t know if they’re sold now but I have Filterlincs on all noisy devices.
Techman Posted March 27 Posted March 27 Filterlinc is still available: Powerline Noise Filter – Insteon Also take a look at these links: INSTEON Signal / Noise Troubleshooting - Universal Devices, Inc. Wiki (universal-devices.com) INSTEON: Troubleshooting Communications Errors - Universal Devices, Inc. Wiki (universal-devices.com) 1
IndyMike Posted March 28 Posted March 28 23 hours ago, schda12 said: I have read that newer PLM's are much more sensitive to electrical noise and their signal is much weaker than the old ones. I've been trying various locations with my new Eisy and PLM (2413S). I am surprised that the PLM typically failed to communicate with a Switchlink Dimmer (2477D) when the PLM is plugged into a receptacle in the same (plastic) electrical box and circuit as the switch. I have not seen anything indicating that newer PLM's are more sensitive to noise or lower power. Could you point me to these reference? Thank you 2
schda12 Posted March 29 Author Posted March 29 22 hours ago, IndyMike said: I have not seen anything indicating that newer PLM's are more sensitive to noise or lower power. Could you point me to these reference? I got this impression from the following: This above is an old post. It includes "2) We know that the current PLMs (starting with Firm52) only put out about 75% of the signal that the previous PLMs did. I tested both the Firm52 and Firm58 beta PLMs, and the results were about the same for both of them." My experience replacing an old PLM (not sure how old or which one) with a new 2413S was a dramatic reduction in communication reliability. This reinforced my suspicion that my experience was caused by a product quality reduction. Why else would the same set of interference issues trigger a substantial reduction in PLM communication reliability?
Brian H Posted March 29 Posted March 29 Both of the firmware revisions are in the old 2412S power line only PLM. Comparison to a presently sold and completely different electronics 2413S firmware 9E. May not be a good comparison. 2
schda12 Posted March 31 Author Posted March 31 Thanks Brian. Since newer PLM's are not supposed to perform far worse than older ones, does that mean I have a bad PLM or might there be other factors accounting for a substantial drop in reliability for me?
IndyMike Posted April 1 Posted April 1 @schda12, I read through a couple of your earlier posts regarding your ISY994 install and migration to the Eisy. Summarizing: Your ISY994/PLM install was in a bad location. So much so, that you had to relocate the PLM to write configuration changes to Insteon devices. You migrated to the Eisy, but are having intermittent issues communicating with devices. You are using the same PLM? In the same location? Normally intermittent communication failures do NOT indicate a PLM failure. The intermittent nature is due to problem devices turning on/off. I am also trying to determine if you are having new problems due to a partial migration. Your 2477D that did not respond with the PLM plugged in next to it sounds like a device that was not migrated properly. Is this device intermittent or 100% non-responsive. If 100% non-responsive to the PLM, it's likely a configuration problem. You could try restoring the device. You mentioned your Aprilaire steam generator - I wouldn't normally think of this as a problem item, but it does pull significant power. Try turning it off to see if you notice a difference in communication. Your heat pump is likely a 220V device that is run off a dedicated circuit breaker in your panel - i.e. not on the same circuit. Not sure if you can correlate the heat pump on/off cycles with communication problems. Not sure I would recommend powering off the heat pump (some of the HVAC systems get mad if they can't communicate with the components). You could try changing the setpoint so the system doesn't run for an extended period - then try running communication tests. When you are running tests, performing queries are the most reliable communication method. Said differently, if a query fails you are having severe communication problems (or you have a device configuration issue). The PLM will retry communication 5x and the Eisy will retry 3x. Your description below was the Eisy re-trying the query 3x with no response. On 3/27/2024 at 5:32 PM, schda12 said: The Eisy event viewer shows three INST-TX-I1 requests with no responses. At the same time the switch responds as usual to the scene requests from a 6-button controller across the room. You can query individual devices, scenes, or your entire installation by right clicking the Admin Console device tree and selecting "query". By performing the query on "My Lighting" you will get every device known to the Eisy. This can be helpful if you are trying to localize a problem. The following is a event viewer query (level 3) of my 1st floor scene devices. The "[Std-Direct Ack]" is a summary of the device communication back to the PLM. "Hops Left" of 2 or 3 is good. Lower Hops remaining is worse. Just to make things confusing, I managed to capture some system Echo's (Device 0C.C2.32 and 58.B0.74). These devices show 2 responses: one with 3 hops remaining and one with 0 hops. I refer to these as echo's - probably from the opposite electrical phase. The second query is showing failures to 3 ISY retries (device is not installed). Mon 04/01/2024 07:54:16 AM : [INST-TX-I1 ] 02 62 1A 5D C7 0F 19 00 Mon 04/01/2024 07:54:16 AM : [INST-ACK ] 02 62 1A.5D.C7 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:16 AM : [INST-SRX ] 02 50 1A.5D.C7 53.BC.3A 2B 00 F7 (F7) Mon 04/01/2024 07:54:16 AM : [Std-Direct Ack] 1A.5D.C7-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 04/01/2024 07:54:16 AM : [INST-TX-I1 ] 02 62 0C C2 32 0F 19 00 Mon 04/01/2024 07:54:16 AM : [INST-ACK ] 02 62 0C.C2.32 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:17 AM : [INST-SRX ] 02 50 0C.C2.32 53.BC.3A 2F 31 FF (FF) Mon 04/01/2024 07:54:17 AM : [Std-Direct Ack] 0C.C2.32-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 04/01/2024 07:54:17 AM : [INST-TX-I1 ] 02 62 58 B0 74 0F 19 00 Mon 04/01/2024 07:54:17 AM : [INST-SRX ] 02 50 0C.C2.32 53.BC.3A 23 31 FF (FF) Mon 04/01/2024 07:54:17 AM : [Std-Direct Ack] 0C.C2.32-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Mon 04/01/2024 07:54:17 AM : [INST-ACK ] 02 62 58.B0.74 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:17 AM : [INST-SRX ] 02 50 58.B0.74 53.BC.3A 2F 00 00 (00) Mon 04/01/2024 07:54:17 AM : [Std-Direct Ack] 58.B0.74-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 04/01/2024 07:54:17 AM : [INST-TX-I1 ] 02 62 16 CD 80 0F 19 00 Mon 04/01/2024 07:54:17 AM : [INST-ACK ] 02 62 16.CD.80 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:17 AM : [INST-SRX ] 02 50 58.B0.74 53.BC.3A 23 00 00 (00) Mon 04/01/2024 07:54:17 AM : [Std-Direct Ack] 58.B0.74-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Mon 04/01/2024 07:54:18 AM : [INST-SRX ] 02 50 16.CD.80 53.BC.3A 2B 00 00 (00) Mon 04/01/2024 07:54:18 AM : [Std-Direct Ack] 16.CD.80-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 04/01/2024 07:54:18 AM : [INST-TX-I1 ] 02 62 41 29 3D 0F 19 00 Mon 04/01/2024 07:54:18 AM : [INST-ACK ] 02 62 41.29.3D 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:18 AM : [INST-SRX ] 02 50 41.29.3D 53.BC.3A 2F 00 00 (00) Mon 04/01/2024 07:54:18 AM : [Std-Direct Ack] 41.29.3D-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 04/01/2024 07:54:18 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 19 00 Mon 04/01/2024 07:54:18 AM : [INST-ACK ] 02 62 05.4B.4B 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:19 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 24 00 (00) Mon 04/01/2024 07:54:19 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 04/01/2024 07:54:19 AM : [INST-TX-I1 ] 02 62 58 CB 74 0F 19 00 Mon 04/01/2024 07:54:19 AM : [INST-ACK ] 02 62 58.CB.74 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 07:54:19 AM : [INST-SRX ] 02 50 58.CB.74 53.BC.3A 2F 00 00 (00) Mon 04/01/2024 07:54:19 AM : [Std-Direct Ack] 58.CB.74-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Device no-response to 3 ISY retries Mon 04/01/2024 08:14:16 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 04/01/2024 08:14:16 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 08:14:25 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 04/01/2024 08:14:25 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 04/01/2024 08:14:34 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 04/01/2024 08:14:34 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Give us a bit more information on your system and play around a bit to try localizing things. Intermittent problems are difficult, but this should be solvable.
schda12 Posted April 1 Author Posted April 1 IndyMike, Thanks for your help. I think you missed the essence of my situation as refined through Brian H. Let me summarize. 1. Before my PLM failed, I had adequate but imperfect communication using ISY. The simple programs to turn on/off 5 circuits at various times worked reliably. That was my only dependence on reliability from the PLM / ISY. When changing some Insteon scenes I had to move the ISY and PLM. This was annoying but infrequent. Presumably my issue was noise. I did not try to identify or mitigate that noise. 2. With the new/replacement PLM there was no reliability from either the old location or any other I attempted. The timer programs performed so unreliably as to be useless. Due to the age of the ISY, UD and Insteon were unwilling to help. 3. I upgraded to a new Eisy and the PLM issues remained unchanged. 4. The example I described at the top of this thread seemed like a noteworthy type of PLM failure because: a. The PLM was adjacent to an Insteon device. Even with severe power line communication noise, I would expect reliable RF communication. b. The Insteon device responds reliably to scenes initiated from Insteon controllers much farther than the PLM, including at the same time the PLM is failing. c. The PLM alternated between successful and failed query with that Insteon device. The pattern of success and failure may or may not be related to what equipment is running at the time. I was initiating a device query and not attempting a scene or all-device query. I did observe the three attempts from Eisy. I confirmed that the Eisy status for the PLM was OK. 5. Since the pain point is the time-based programs, I plan to migrate from Insteon to Leviton for those circuits. Fortunately they do not particulate in Insteon scenes. Nevertheless, it would be helpful to restore the level of PLM reliability I used to have. 6. If there is evidence of that the PLM itself is the problem, I would like to try to get a replacement from Insteon. Thanks, David
IndyMike Posted April 1 Posted April 1 David, I had a feeling that a PLM change was involved. Let's walk through things one at a time. 2 hours ago, schda12 said: 1. Before my PLM failed, I had adequate but imperfect communication using ISY. The simple programs to turn on/off 5 circuits at various times worked reliably. That was my only dependence on reliability from the PLM / ISY. When changing some Insteon scenes I had to move the ISY and PLM. This was annoying but infrequent. Presumably my issue was noise. I did not try to identify or mitigate that noise. This could have been noise or a signal absorber. The fact that you had to move your PLM to re-program scenes indicates this was a rather severe problem. 2 hours ago, schda12 said: 2. With the new/replacement PLM there was no reliability from either the old location or any other I attempted. The timer programs performed so unreliably as to be useless. Due to the age of the ISY, UD and Insteon were unwilling to help. Upgrading to a new PLM is a communication intensive process. Every device needs to be re-written with the new PLM address (many times). I'm assuming that this process didn't complete correctly and is the root of some of your problems. 2 hours ago, schda12 said: 3. I upgraded to a new Eisy and the PLM issues remained unchanged. The Eisy adds new capabilities. It cannot correct for existing communication issues. 2 hours ago, schda12 said: 4. The example I described at the top of this thread seemed like a noteworthy type of PLM failure because: a. The PLM was adjacent to an Insteon device. Even with severe power line communication noise, I would expect reliable RF communication. b. The Insteon device responds reliably to scenes initiated from Insteon controllers much farther than the PLM, including at the same time the PLM is failing. c. The PLM alternated between successful and failed query with that Insteon device. The pattern of success and failure may or may not be related to what equipment is running at the time. I was initiating a device query and not attempting a scene or all-device query. I did observe the three attempts from Eisy. I confirmed that the Eisy status for the PLM was OK. RF communication does not necessarily ensure that a device will respond. Noise and/or marginal powerline communication can override the RF. If a device refuses to respond the the PLM, while responding to other devices, I would normally say that there was a configuration error with the device (device was not programmed with the PLM address). Restoring the device would be the normal recovery (see 3). I don't have a good explanation for a device that is intermittent in responding to a PLM that is plugged in next to it. I do have a couple of observations - Devices that are in the "same J box" are not necessarily on the same electrical circuit. Multi-gang electrical boxes are often used for devices at the "end" of 3-way switch installations. These are frequently on different circuits. It is also common to wire multi-gang J boxes with 220V. In this instance 14-3 romex is brought into the box (220v) and is split into separate 110V circuits. It's a very efficient method of wiring that I've used myself. A strong noise source in the Insteon frequency range (including X10), can "fool" the PLM into thinking that there is traffic on the powerline. The PLM May refuse to transmit if it thinks that other devices are communicating. 2 hours ago, schda12 said: 5. Since the pain point is the time-based programs, I plan to migrate from Insteon to Leviton for those circuits. Fortunately they do not particulate in Insteon scenes. Nevertheless, it would be helpful to restore the level of PLM reliability I used to have. If your time based programs are scene based, you can improve reliability be communicating directly with the devices (a patch at best). Post your programs and the forum can help with this. I'm assuming that you are looking at Z-wave units. Leviton makes good hardware. I have used many leviton X10 units over the years. I have not used their Z-wave line. I have used Zooz Hubs, Switches, Dimmers, Motion sensors, and Temperature sensors - I'm a fan. Be advised that you need a certain number of Z-wave units to form a mesh for reliability. Distance from your Z-wave hub determines the number of units required - not and exact science due to RF propagation issues. Don't want you to jump from the frying pan into the fire. 3 hours ago, schda12 said: 6. If there is evidence of that the PLM itself is the problem, I would like to try to get a replacement from Insteon. At this point, I do not believe that your PLM is the problem. I also believe that Insteon is the most reliable and synchronized communication protocol for lighting. I'd hate to see you jump to another technology and create more problems. Having said the above, there are environments where powerline communication simply isn't viable. If that is the case in your installation, Z-wave or Zigbee may be a way around the problem.
schda12 Posted April 3 Author Posted April 3 Thanks again IndyMike, The Leviton products I purchased (D215S and D26HD) use bluetooth to setup and Wifi for control from the app. Since they store time-related programs in each device, there is no communication needed to execute the time-based programs. There are no scenes involved, which is why the partial converstion from Insteon was practical. I don't know what protocol they use for scenes. There is no equivalent of the Instean 6-button control for both scenes and a load. Until that is offered, migrating the rest from Insteon seems pointless. So far, I am impressed with the Leviton products. They are far more consumer-oriented than Insteon. On 4/1/2024 at 4:50 PM, IndyMike said: This could have been noise or a signal absorber. The fact that you had to move your PLM to re-program scenes indicates this was a rather severe problem. I agree but it was workable. Changing scenes is infrequent. Eisy makes that part easier because the wifi is onboard. On 4/1/2024 at 4:50 PM, IndyMike said: Upgrading to a new PLM is a communication intensive process. Every device needs to be re-written with the new PLM address (many times). I'm assuming that this process didn't complete correctly and is the root of some of your problems. With the old ISY, I'm fairly sure I enabled the new PLM with all the old devices. It took a while from different places. Since I was able to get the Eisy to control devices at least some of the time, does that not mean the new PLM was connected to the devices at the time communication was successful? During the demise of the old PLM it may have added some phantom data that was preserved during backup and restore. Perhaps that is having some lingering impact, even if it does not explain all the communication issues. Is there a procedure for removing suspect links and other data which is reasonable to attempt? On 4/1/2024 at 4:50 PM, IndyMike said: Devices that are in the "same J box" are not necessarily on the same electrical circuit. I forgot to mention that the Insteon device and the receptacle for the PLM were on the same breaker/circuit during that testing. On 4/1/2024 at 4:50 PM, IndyMike said: A strong noise source in the Insteon frequency range (including X10), can "fool" the PLM into thinking that there is traffic on the powerline. The PLM May refuse to transmit if it thinks that other devices are communicating. Because PLM communication used to be reliable for the time-oriented programs, I doubt if the pattern of interference changed during the transition to the new PLM when used at the original location. I wonder if the new PLM is more cautious than the old one about stepping on other transmissions.
Techman Posted April 3 Posted April 3 (edited) I've attached an article on powerline noise.The article was written for X10 but it applies to Insteon as well. Powerline noise.pdf Edited April 3 by Techman 2
Brian H Posted April 4 Posted April 4 Jeff at JV Digital also has a great set of tutorials on things like noise. On X10 issues and many apply to Insteon Noise also. https://jvde.us/x10-troubleshooting/ 2
IndyMike Posted April 4 Posted April 4 (edited) 23 hours ago, schda12 said: With the old ISY, I'm fairly sure I enabled the new PLM with all the old devices. It took a while from different places. Since I was able to get the Eisy to control devices at least some of the time, does that not mean the new PLM was connected to the devices at the time communication was successful? During the demise of the old PLM it may have added some phantom data that was preserved during backup and restore. Perhaps that is having some lingering impact, even if it does not explain all the communication issues. Is there a procedure for removing suspect links and other data which is reasonable to attempt? I forgot to mention that the Insteon device and the receptacle for the PLM were on the same breaker/circuit during that testing. Because PLM communication used to be reliable for the time-oriented programs, I doubt if the pattern of interference changed during the transition to the new PLM when used at the original location. I wonder if the new PLM is more cautious than the old one about stepping on other transmissions. Based on your description, I believe your PLM replacement was at least partially corrupted by noise issues. When talking about how devices react, we need to talk in specifics. Different generation devices (I1, I2, I2CS) have different programming requirements and will respond differently to mis-programmed link tables: 1) Old I1 devices use a peek/poke programming process that is very communication intensive. This makes it very difficult to program the devices in a noisy environment. On the flip side, these same devices will respond to a query from just about anything. 2) I2 devices use "extended communication protocol" during programming. The process requires far fewer reads/writes to the device and requires far less time making it more reliable. 3) I2CS devices require a special "secure linking" process. If this process isn't performed correctly (noise) the device will refuse to communicate with your PLM. For devices in categories 1 &2, Device Direct commands will work even if the device is factory reset (no link table whatsoever). This means the device will respond to queries, on/off, fast on/fast off, etc even with a vacant link table. All the plm/Eisy need is the device address (which they have). These devices will NOT respond to Scene commands unless the specific link table entry exists for that scene. I2CS devices will not respond to direct commands unless the device was properly linked to the PLM. This means that the device should NEVER respond to on/off, etc. from the PLM. It is entirely possible for this device to respond to "other" properly linked controllers while refusing to communicate with the PLM. -- caveat: I have found some I2CS devices that will respond to queries even if they are not linked. The above can make it extremely confusing when dealing with link table programming problems. With that said, I would like to focus on your example 2477D. This device may be I2 or I2CS category. If you can give us the firmware and version we should be able to figure out which. If you can resurrect your configuration with the PLM plugged into the same Jbox as the 2477D - 1) Verify if this device is completely non-responsive to the PLM. It NEVER responds to on/off commands. Try performing a Device Link Table Read (right click device in the tree, select diagnostics/show device links table). If you see a Nack response as below, you have a I2CS device that is not properly linked to the PLM. Factory reset/restore the device. Note that you will not be able to write the device if it has the red ! error next to it. Try querying the device 1st to eliminate the ! Link table read on 2635-222 On/Off module not linked to PLM: Device responds with Nack Thu 04/04/2024 09:25:21 AM : [INST-TX-I2CS] 02 62 54 A1 F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Thu 04/04/2024 09:25:21 AM : [INST-ACK ] 02 62 54.A1.F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Thu 04/04/2024 09:25:21 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A AF 2F FF (FF) Thu 04/04/2024 09:25:21 AM : [Std-Direct Nack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 04/04/2024 09:25:30 AM : [INST-TX-I2CS] 02 62 54 A1 F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Thu 04/04/2024 09:25:30 AM : [INST-ACK ] 02 62 54.A1.F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Thu 04/04/2024 09:25:31 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A AF 2F FF (FF) Thu 04/04/2024 09:25:31 AM : [Std-Direct Nack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 04/04/2024 09:25:40 AM : [INST-TX-I2CS] 02 62 54 A1 F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Thu 04/04/2024 09:25:40 AM : [INST-ACK ] 02 62 54.A1.F5 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Thu 04/04/2024 09:25:40 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A AF 2F FF (FF) Thu 04/04/2024 09:25:40 AM : [Std-Direct Nack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 04/04/2024 09:25:44 AM : [All ] Writing 0 bytes to devices Thu 04/04/2024 09:25:45 AM : [All ] Writing 0 bytes to devices 2) Device "sometimes responds" to on/off commands from the PLM - you have some type of severe noise/absorption issue. The references that @Brian H and @Techman provided should be used to isolate/filter the offender. Let us know what you find with this experiment. We can figure out which direction to head from there. Edit: realized that I didn't respond to 2 of your questions - Quote Is there a procedure for removing suspect links and other data which is reasonable to attempt? This normally takes the form of device link table errors as I described above. In extreme cases, the device may need to be removed from the ISY/PLM and re-added. Quote I wonder if the new PLM is more cautious than the old one about stepping on other transmissions. Difficult to say for sure. I have many PLM's and have noted numerous changes in hardware and firmware (protocol) over the years. These have been improvements. I have not noted changes in collision avoidance (and I have intentionally jammed devices with noise signals), but I certainly haven't performed exhaustive testing. X10 signals can absolutely jam an Insteon network. If you see frequent X10 communications in the event viewer, this can cause issues. Edited April 4 by IndyMike 2
schda12 Posted April 5 Author Posted April 5 Thanks for all your suggestions. I'll pursue once I get the remaining new Leviton devices installed.
Recommended Posts