IndyMike

I was afraid of that. Given that you cannot reliably read a link table, please hold off on doing a factory reset on this device. I am not sure that you would be able to recover it. I Am away from home at the moment. I will review your files when I get back in the evening

@walkman9999, I added some comments to your event logs. In general, your communication looks fairly good (i.e. good hops remaining). Sequence of events: The ISY starts each write cycle by requesting a link table record from the device. In both cases (successful and unsuccessful writes) the device 2A.0B.38 acknowledges the request. Both times the device exhibits excellent communication. For some unknown reason, the device does not respond with the requested link record in the failed attempt. The ISY retries 2 the link record read additional times, and the device does not supply the link record. Questions: What exactly are you attempting to write to the device? Can you perform a link table read/compare and post the results? This is probably a case where you need to factory reset the KPL and restore it, but I'd like to see the link table comparison before we get ahead of ourselves.

@cmerlino, I know you said no Zwave. In the past I was of a similar mind. The new 700 series devices have changed my mind. Zooz has some very nice relay devices that should work for your application: https://www.getzooz.com/smart-relays/ I use the ZEN51 single relay behind a decora switch to control my milovolt fireplace gas valve. It's been flawless in my system. All of the devices in the link are 700 series EXCEPT the Zen16 (500 series). I would not recommend it for that reason.

@alixer - unfortunately this does this does not mean that the device is properly linked as a "scene controller" for the PLM. The 1st record in the Device link table is the Device Responder Link from the PLM. In my screenshot below, the "A2 00" indicates that my on/off module is a responder to group 00 (my plm). The second record is tagged "E2 01". This is telling my On/Off module it is a controller of group 01 and my PLM is a member. When you execute a "ON", or "Fast ON" your device communicates this to devices listed as being in Group 1 (00.00.01) as shown in the event log below. There is also a third component - the PLM. The PLM also needs controller and responder records for your devices. The PLM records for my ON/OFF Module are shown in the table below. I have a PLM responder record (A2) for device 54.A1.F5 (my On/Off module). ad fl gr id data 194 E2 0 54A1F5 23748 195 A2 1 54A1F5 23748 So where's the problem? Since you've already done link table comparisons and restores, the device and the ISY should agree. That leaves the PLM. If the device responder link does not exist in your PLM, you will not see transmissions from that device. In the past, this would occur when a user had too many PLM links (over 1023). The PLM would essentially write links that could not be accessed and stop listening to some devices. You may want to check how many PLM records you have. You'll need to disable programs and perform the test during a quiet time to prevent interrupts. In your case I would guess that you have an incomplete migration. Not all the link records were transferred to the PLM. Your process of including a device as a scene controller, then deleting the scene, is restoring the responder link in the PLM. Not sure whether it's worth doing a PLM Restore to write all the links. If you're only having problems with a couple devices, your workaround may suffice.

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 - 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. 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.

David, I had a feeling that a PLM change was involved. Let's walk through things one at a time. 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. 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. The Eisy adds new capabilities. It cannot correct for existing communication issues. 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. 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. 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, 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. 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.

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

@piconut, I was actually referring to the Log File (not the error log). When your program runs, and you use a Device Direct command to turn on a device (not s scene), an error should be logged if the device does not respond (Error 0 as shown above). @woodchip, I'm not much help with the error logs. I just regurgitate what others have posted without any real understanding of the errors: https://forum.universal-devices.com/topic/13665-understanding-error-logs/ https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Errors_And_Error_Messages

So, the good news is that with 95 dual band devices you should have no worries about phase coupling... The ISY994 PRO is capable of handling 1000 nodes and 1000 programs. Since you are not using Scenes, you should be comfortably below the node limit. The PLM is capable of handling 1000 links. You should be below that limit as well. Even if you were above the limit (yes it's possible to be over the limit) the symptoms would be different. That's all the good news. You'll need your Sherlock Holmes cap to watch for patterns and experiment with possible problem devices. Since your programs turn devices on/off directly (not in scenes), an error should be generated when a device doesn't respond. Errors should also be generated if devices don't respond during the 3 am query. These will be in the Log file "Error 0". You may be able to use these errors to localize your communication problem (particular circuit or area in your home). Other than the log file, the best that I can offer at the moment is unplugging possible offenders near the PLM or problem devices to see if things improve. Difficult when things are intermittent. Generated the following error log by issuing an ON command to a device that I had unplugged

It sounds like you are having intermittent communication issues with a number of devices. The fact that they happen individually and "heal" would seem to indicate that the problem is not the PLM. Not sure what type devices we are dealing with here and what the makeup of your installation looks like - If you have an older installation with primarily powerline devices (NOT dual band) it's possible that you lost a phase coupling device. This would cause a reduced signal level on the phase opposite of your PLM. If your devices are newer dual band then your phases are likely well coupled. Multiple unit issues are normally due to a degraded PLM or SIGNAL ABSORBER near the PLM. Always possible that you have a noise source/signal absorber that is only active at certain times of the day. Try to look for patterns in the communication problems. If you think you are having issues communicating with a device, run a query on it. The ISY will try 3 times to communicate and then tag the device as "failed to communicate with.." Intermittent problems are the worst. Very difficult to track down and be sure that you've found the culprit. Give us a bit more detail and what your system looks like and what devices you are having problems with (i.e. 2477 dimmer vs 2476 dimmer) Edit: Realized that I did not answer your question about replacing the PLM. @Techman provided the PLM replacement procedure above... The only "Risk" in replacing your PLM is the possibility that there is something else in your system causing the problems. If that is the case you may have difficulty in writing the new PLM information to your devices (1011 tags). Aside from that, you will need to wake your battery devices to update them with the new PLM links. If you have motion sensors in difficult to reach areas, UD provided a method to program these when motion is sensed. I typically disable these programs when not in use, otherwise they will trigger every time motion is sense. Motion Sensor Update Program: BSMT Sensor Program - [ID 004A][Parent 0066][Not Enabled] If 'Motion/RF / BSMT-Sensor' is switched On Or 'Motion/RF / BSMT-Sensor' is switched Off Then Set 'Motion/RF / BSMT-Sensor' Write Changes Else - No Actions - (To add one, press 'Action')

Similar to @Goose66's approach - you can create a "conditional folder" use the "status" of your Ecobee thermostat to enable it. Place your trigger program in the conditional folder. This will give you a visual of when the folder is enabled (Green - Enabled, Red - Disabled). Running a disabled program will absolutely work, but I'm old and often forget that some programs SHOULD be disabled (it hurts my brain).

@gregkinney, Glad to hear you tracked the offender down. For the other forum readers, would you mind providing a few more details on how you located/isolate the PC as the problem? Intermittent problems are normally the worst. It can be extremely difficult to isolate the problem to a circuit or device.

Hi @piconut, Paul and Techman both have good points. I am however curious about two things: You stated that your devices are controlled by programs - not in scenes. The fact that the ISY "thinks" that your devices are at one lighting level when they are actually at another make it sound like you are using scenes. Could you post your programs? Normally the ISY polls all devices @3:00am. If your PLM is failing, this query will fail miserably. You will be greeted by a host of "cannot communicate with...device" when you log in. If you are not seeing these communication failures and the (!) on your devices, I would say that your PLM has not given up (yet). Have you seen signs that the ISY has tagged devices as being offline?

Since you are having very isolated problems (3 devices out of 100's) it is likely that the noise/signal absorber is on the same circuit. If you can determine which circuit(s) are having issues, begin removing loads (chargers, UPS, TV's) until the problem cleans. If you are looking at circuits in your breaker panel - remember that the phases are the same horizontal and alternate as you go down the panel vertically. Typical Panel Layout

1500VA is a large UPS. Unless you are willing to build your own, the only thing that I know of that is currently available is the XTB-F15+ from Jeff Volp. The filter is advertised for X10, but will work for Insteon as well. https://jvde.us/xtb-f10/ Insteon is very good at bridging the phases - assuming you have dual band modules. X10, on the other hand, will have great difficulties in crossing phases without a dedicated coupler or 220V resistive path (oven, dryer). Again, not sure if the UPS is absorbing Insteon signals to the point where they are at the noise floor, or generating noise in the Insteon band (or both). It's certainly worth testing by moving one of the two to another circuit.

The UPS is a relevant piece of information. Most of them have a EMI filter that will absorb Insteon signals. Other units have been found to be noise generators. Either way it should probably be installed on a filterlinc. Check the current draw of the UPS before installing a filter. If you don't want to move your PLM to the garage circuit, you could move your UPS and equipment to that circuit as a test.

As Paul indicated, this doesn't necessarily have to be an Insteon device producing the traffic. I had an old (10+ years) Homelink receiver in my garage that was capable of Transmitting X10 - It went nuts one day and began spamming the powerline on housecode P. It happens. You could try air gapping (not resetting) your Insteon devices to see if the communication stops. Unfortunately there are two that are difficult to access. I still think your best approach is to turn off breakers one at a time until the noise goes away. If you cycle through all the breakers except the circuit the PLM is on and still have the noise - move the PLM to another circuit and check the breaker on the former.

I might agree that there is a Low risk in doing a device restore. Unfortunately it WILL NOT eliminate X10 address programming and it is likely to fail with the X10 traffic present on your system. AFAIK, the ISY cannot "un-program" an X10 address. There are devices that can (Houselinc) but you don't have them. The "easy" way to eliminate a X10 address in an Insteon device would be to perform a factory reset (eliminate the x10 address) and then restore it. I would not factory reset anything while the X10 traffic is present. As I said above, the restore is likely to fail (just as your queries are failing). You need to locate the source of the traffic and eliminate it. Since this just started happening recently, chances are that you have a device that is dying or just in an unhappy state. Cycling power may correct things. I think the best approach is to shut off breakers until the offender goes silent. As far as why Insteon devices would have X10 addresses - there was a period of time where new devices were received with X10 address from the factory. Not sure why, test escapes or whatever. It became so prevalent that "best practice" was to factory reset every device prior to installation. This was probably many years ago (seems like yesterday), not sure if it applies to any of your devices. Used devices could have had X10 addresses programmed by their previous owners. The addresses would NOT be eliminated by linking to the Eisy. They are in a section of memory that is separate from the device link table.

Wow, that's a lot of X10 traffic. That alone can bring your system to it's knees. It may also explain why wireless devices function while powerline is intermittent. The Status request isn't a normal X10 device - that's a controller function. If you don't have any X10 controllers installed (garage door, alarm panel, etc) you may have an Insteon device that's failing (although I've never seen one put out Status requests). Unless you can come up with a list of likely suspects, the normal way of isolating is to start turning off breakers until the X10 transmission stops. One you find the suspect circuit inspect/remove devices until you find the culprit. It's time consuming, but now all that hard. Best to do when family members are not around to avoid plummeting approval factors.

Paul's suggestion of checking the PLM links is a good one. It will give you a general idea of the health of your PLM. In order to get an accurate count of the PLM links, you need to keep the system quiet (disable programs, no powerline or RF activity). That's not necessary here as you are simply trying to asses if the PLM has totally dumped it's link table (10 link records = bad, over 100 link records probably ok). The 3 Inst-TX messages that you see in the event viewer sound like the Eisy is sending messages and getting no-response (timeout) and retrying the transmission. For each TX you should see an INST-ACK (plm Acknowledging) as follows. This is a query of a device that I removed from my system: Mon 03/04/2024 08:52:10 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:10 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:19 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:19 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:28 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Mon 03/04/2024 08:52:28 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Mon 03/04/2024 08:52:32 AM : [D2D EVENT ] Event [54 A1 F5 1] [ERR] [1] uom=0 prec=-1 Mon 03/04/2024 08:52:32 AM : [ 54 A1 F5 1] ERR 1 Please post an example of your event viewer query (level 3). If you are not seeing the ACK's, try power cycling the PLM. Also post examples of the periodic X10 communication. I never like seeing this in a system with no X10 devices. At best, it slows down insteon communication. At worst, it corrupts the powerline. Since you are seeing widespread communication issues, the most likely culprit is the PLM - or at least something near it. You could try moving the PLM, or using an extension cord to plug it in somewhere else.

If your switch is the controller of a Scene - the flashing red is indicating that it can't communicate with one (or more) of the scene members. If your switch is NOT a scene controller - the flashing red indicates that it can't communicate with the PLM. If you were to say "isn't the dual band Insteon feature supposed to eliminate this?", you would be absolutely correct. Unfortunately, nothing is perfect. There are situations where noise/signal absorption will prevent a device from hearing both powerline/rf. Looking into the HdHomeRun and Garage LED's are both solid ideas as you know that these have changed. Don't discount the possibility that you have a device that's on it's last legs (failing EMI capacitor, failing triac, etc) that is causing this (#2 on the list to check). If all else fails you'll need to identify which circuits (breaker panel) are being affected and what devices are installed - the old process of elimination. Best of luck - let us know how your experiments go.

I'm sorry, but the above statement is simply incorrect. In a "perfect home installation" with a PLM and 100 devices - activating the "Beacon Test" on the PLM would cause 50 devices to flash green (opposite phase) and 50 devices to flash red (same phase). Red flashing does not imply improper bridging.

@Techman - the document you linked is for the range extenders and it is dealing with "bridging" the phases. In that context it's rather misleading. A Red flashing LED indicates the receiving device is on the SAME PHASE as the transmitter. A Green flashing LED indicates the receiving device is on the OPPOSITE PHASE. It's a bit more clear in the On/Off Module Manual: Phase Bridge Detect Beacon/RF Range Test On/Off Outdoor Module automatically bridges the electrical phases in your home (via communications with other dual-band devices on the “other phase”). This is only important in 2-phase homes with powerline-only INSTEON products or buildings with both 2- and 3- phase circuits. The phase bridge detect beacon can also be used as an RF range test to see if your devices are within communication range. You will need at least one other INSTEON dual-band device installed. 1) Quickly tap Set button four times On/Off Outdoor Module will start beeping once per second LED will turn solid green 2) Check the LED behavior of other dual-band devices Phase Bridge Detect Beacon • If the other dual-band device is blinking green, it is on the other phase: Device provides a phase bridge to Micro module • If the other dual-band device is blinking red, it is on the same phase: Device does not provide a phase bridge to Micro module Relocate if necessary (and practical) • If the other dual-band device is not blinking: Device is not within RF range of Micro module so it does not provide a phase bridge Relocate if necessary (and practical) or add an additional dual-band device RF Range Test • RF range test: if LED is blinking: Device is within RF communication range • RF range test: if LED is not blinking: Device is not within RF communication range Relocate if necessary (and practical) or add an additional dual-band device 3) Tap Set button On/Off Outdoor Module will stop beeping Other device LEDs will stop blinking https://cache.insteon.com/documentation/2634-222-en.pdf

The AirTV and HDHomeRun are different devices with different power supplies. I have used the HDHomeRun and it wasn't problematic for me. The may have changed the power supply. 110V Led shop lights also use power supplies. They would be my main suspect. Since your problem appears intermittent, look for chargers and things that move around or are activated at particular times of day. This doesn't necessarily have to be a new device. I've had multiple solar sensors die on my post lamp. When they nosing over they tend to flood the powerline with noise. I've stopped using them and switched to a bulb with a solar sensor. The 4 tap test in the PLM is still a good troublshooting tool. Tap the button 4 times rapidly and all dual band devices in range will flash red or green. If a device does not flash, it's either old or it can't hear the PLM. Try this with your problem devices when they are working properly to see how it functions. When things stop operating correctly, try it again. The start looking for items on the circuit that could be absorbing the signal or generating noise.