IndyMike

You do not need to reset your devices when you move the PLM. Keep in mind that this is a troubleshooting step to determine if there is noise on the circuit your PLM is currently plugged into. If you have Insteon plug-in devices (dimmers/on-off modules) you can also try plugging them into the same outlet as the PLM to see if you can communicate with them.

@John Chen I'm going to rephrase things a bit. If you send a direct command to a device from the ADMIN console and the device responds (turns on) but the PLM/ISY does not get and acknowledge - you will have a sync error between the device and the ISY. I believe that is what you were stating. In addition, you are stating that the device did not respond to the direct on/off command - Is this correct? I do not have a good explanation why a device would respond to a scene command and not a direct command from the admin console. The direct command should ALWAYS be more reliable because it requires the PLM to retry communications. This does sound like the PLM received the manual on from the device. Your device appear to be rather new (<5 years old). Both your switch and PLM should be dual band. They will communicate via powerline and RF - assuming there is another RF device in range. Please do try moving the PLM to another location. To test - Open the event viewer and set to level3. Right click on "My Lighting" on the admin console tree and select "query". Communication errors will result in POP UP windows showing the devices. If you can, post the contents of the even viewer.

Hello John, Your event logs are showing device timeout errors in response to a "DIRECT MESSAGE" from the admin console (On/Off). Direct messages require that the target device acknowledge the command. A normal ON command from the Admin Console would resemble the 1st log below. You are missing the "INST-SRX" entry which is the response from the device. The second example is after I removed the device. It shows the missing "INST-SRX" entry and the ERR1. Note that the ISY does not ALWAYS tag the no-response entries with the ERR1. Another important thing to note is that SCENES do not require a response from devices. The ISY sends scene commands and does not request a response from the target devices. It assumes that the devices responded properly and reflects that in the admin console status. From your desciption, your "Scenes" sometimes function, but you have problems with On/Off commands from the admin console (direct). That sounds like your devices can (sometimes) hear your PLM communication, but your PLM cannot hear your devices trying to respond. That could suggest a strong noise source/signal absorber near the PLM. Please inspect the electrical circuit where PLM is installed for possible offenders (PC's, UPS's, Chargers, Printers) and filter or move them to another circuit. Alternatively, you could temporarily move your PLM to another circuit to diagnose the issue (extension cord). Normal Direct ON command ISY Command to PLM Sun 06/02/2024 08:39:54 PM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 11 FF PLM Acknowledge Sun 06/02/2024 08:39:54 PM : [INST-ACK ] 02 62 54.A1.F5 0F 11 FF 06 LTONRR (FF) Device Acknowledge Sun 06/02/2024 08:39:54 PM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 2F 11 FF LTONRR (FF) Sun 06/02/2024 08:39:54 PM : [Std-Direct Ack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Direct ON command with No-response Timeout ISY Command to PLM Sun 06/02/2024 08:40:30 PM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 11 FF PLM Acknowledge Sun 06/02/2024 08:40:30 PM : [INST-ACK ] 02 62 54.A1.F5 0F 11 FF 06 LTONRR (FF) No Device Acknowledge Sun 06/02/2024 08:40:34 PM : [D2D EVENT ] Event [54 A1 F5 1] [ERR] [1] uom=0 prec=-1 Timeout error Sun 06/02/2024 08:40:34 PM : [ 54 A1 F5 1] ERR 1

@walkman9999, happy to hear that the replacement appears to have solved the problem. Not sure that I in any way helped with that... If it was in fact the KPL power supply that was failing, you may have uncovered a troubleshooting tool - link table reads. Link table reads/writes are performed on newer I2 devices using the "extended" communication mode. Normal on/off commands are performed using I1 "standard or direct" communication. Under normal conditions, I2 communications are more reliable since they transfer more information faster and with far fewer handshakes (less opportunities for failure). Your devices were exhibiting the opposite - I1 (direct) communication was more reliable than I2 (extended). Your on/off commands functioned OK while link table reads/writes failed miserably. Since I2 communication transfers 2.5x the number of data bytes, it also requires sustained power on the part of the KPL to transmit. It's possible that the power supply caps in your KPL are failing (similar to the PLM power supply failures) resulting in a lack of capacity to maintain the I2 communication.

Having a spare KPL is never a bad idea. I had considered that you might have a KPL with a failing power supply. It's doubtful that you have have 4 devices failing in a similar manner at the same time - unless you had a recent power event. I had also considered a failing PLM. The fact that you can communicate with your other devices and the communication problems are sporadic make this unlikely as well. You are correct that tracking does a noisy device can be difficult. This is particularly true when it's an intermittent source. I would start by looking at the devices that are being affected: Are the devices all on the same circuit - or widely spaced. If they are on the same circuit, begin disabling other devices on the circuit to eliminate possible offenders. Are the devices all on the same phase of your electrical system. Running a 4-tap beacon test can help you determine this. Noise will not normally cross an electrical phase - unless the offender is a 220V device like my A/C condenser. If you find that your devices are on the opposite phase from the PLM you can move the PLM, Improve the RF phase coupling, or add a passive coupler. I'm assuming that your issues are due to intermittent noise on the powerline. If you have plug-in LampLincs or range extenders, you could try to improve RF communication by moving one nearer to your problems device(s). Are your problem devices all dual band (I'm guessing they are since they appear to be I2 capable). If not, absolutely move a RF device (range extender or Lamp Link) nearer to the device. Alternatively, upgrade the device. Look at your PLM placement - are there noise generators/signal absorbers near by (UPS, PC, chargers). An easy test would be to move your PLM to a different circuit. Ask your self what type of demand devices you have that operate automatically (HVAC, Vent Fans, Well Pumps, Sump pumps, outdoor photocells). Look for correlation between the operation of these devices and your issues. There really aren't any great diagnostic tools for tracking down noise devices. Most troubleshooting uses the process of elimination (unplugging devices, turning off breakers) and observation (correlating problems with other device operation).

@walkman9999, your logs appear to show intermittent communication problems. That's normally a noise source cycling on/off or varying it's frequency. Do you have any new variable frequency devices (variable speed blower or condenser)? I'm focusing on these items because I have a similar problem. When my nice new variable speed condenser turns on and hits a certain frequency it shuts down communication to 3 of my devices in a very similar fashion. What makes it tough to troubleshoot is the fact that it doesn't happen every time the device runs. As loading changes, so does the frequency of the motor drive. The problem only occurs at specific loads/frequencies. Post back if you have any new items like this.

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.

@GBrenkman - Perfect. Glad you got things working. Thank you for driving this to conclusion and notifying UDI of the issue (ticket 24444). That helps us all.

@GBrenkman, from what you are showing in the Device Links Table, your KPL secondary buttons should not show up in the Event Viewer when pressed. You have excellent communication - so that is not the issue here. In my opinion (which is worth very little), this is a bug. The ISY should have programmed each secondary button as a controller of the PLM. Not sure if this is an issue with your specific device firmware (V.58) or if it's something with your use case (most people do program scenes with their secondary buttons). Either way, your KPL is being initialized differently than from every other KPL out there (I1, I2, I2CS). You can likely get around this by generating dummy scenes using the secondary buttons (as you did before). As an alternative, you could generate a Ticket so UDI can be made aware of the issue. Thank you for taking the time to walk through the troubleshooting. Hopefully this will help others who encounter this issue.

Your Event log shows excellent communication and no errors restoring the device. Unfortunately, your device link table only shows controller links between buttons 1 and 2 and your PLM (highlighted below). You should not be able to receive keypresses from buttons 3&4. What blows my mind is that the EISY apparently thinks this is OK (not flagging missing records). By comparison @tmorse305's device has links to all 4 buttons and his PLM. This is how things should have been when the device was initially linked to the EISY. I know you're not supposed to fix what isn't broken, but... If it was me, I would delete the device from the EISY, perform a factory reset on the device, and then re-add.

Actually, that's my fault. I should have looked at your Link table - it clearly shows control links for your secondary buttons. What EISY firmware version are you running? @GBrenkman is on V5.8.3. Not sure if there were updates related to I3 devices.

Again, very odd. With the link table that you are showing, the ISY should not be able to control the device, and the device should not be talking to the ISY. I honestly can't explain what you are seeing. It's almost as if the ISY can't properly read the Device Link Table. @tmorse305 has demonstrated that the ISY can handle I3 devices and can read the link table. That leaves me confused. It's possible that your I3 KPL requires different communication than @tmorse305's device. If it is a bug, I would think we would have heard about it before now. The normal way to correct a Device link table would be to perform a device restore as @Techman suggested. Unfortunately, I think we have something else going on here. If you do perform a restore, please monitor the process using the event viewer (level 3) and post the results. If there are communication errors during the restore, they will be shown in the event viewer. If the restore does not work (and we don't see communication errors) it's probably time to open a ticket with UDI.

@GBrenkman, Very odd that you have no entries in the link table. 2 questions: Do you have a ISY994, or Polisy/Eisy. I don't think the ISY994 firmware will work with I3 devices (although you may be proving me wrong). What happens when you click the "compare" button on the link table window. I would think it would show many missing links.

A blank event viewer is rather telling. Could you perform a Device link table read/compare and post the results. Trying to determine if your I3 device has the correct links or if it's just a problem child. Right click the device on the AC Tree and select diagnostics\show device links table You should see something similar to the following (older 8 button KPL). The 1st entry (A2 00) is a responder link from my PLM. The remaining links (E2 01, E2 02) are controller links to the PLM for each button. Edit: I do not have any I3 devices so I can't test on my end. If you do not see any "E2" controller links back to your PLM address, you could try creating a dummy scene with a secondary button as the controller. That should force the ISY to write a controller link to the I3 device.

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

I figured it was worth a try. I have a number of devices that send multiple messages when activated. The difference is the ISY IGNORES the follow on messages as shown below. I understand your reluctance to delete/re-add the device. The switch is performing correctly, it's just the level indication in the ISY that's off. That will absolutely mess with programs that are level dependent. If you don't have any, time to move on to something more relevant (mowing the lawn/ working on the better half's to do list). If you do choose to delete/re-add. Please do post back the results. I've never seen this, and I've had Insteon/ISY's for more than a few years. Thu 05/02/2024 08:45:54 PM : [INST-SRX ] 02 50 1A.4F.19 00.00.01 CF 11 00 LTONRR (00) Thu 05/02/2024 08:45:54 PM : [Std-Group ] 1A.4F.19-->Group=1, Max Hops=3, Hops Left=3 Thu 05/02/2024 08:45:54 PM : [D2D EVENT ] Event [1A 4F 19 1] [DON] [0] uom=0 prec=-1 Thu 05/02/2024 08:45:54 PM : [ 1A 4F 19 1] DON 0 Thu 05/02/2024 08:45:54 PM : [D2D EVENT ] Event [1A 4F 19 1] [ST] [82] uom=100 prec=0 Thu 05/02/2024 08:45:54 PM : [ 1A 4F 19 1] ST 82 (uom=100 prec=0) Thu 05/02/2024 08:45:54 PM : [INST-SRX ] 02 50 1A.4F.19 53.BC.3A 45 11 01 LTONRR (01) Thu 05/02/2024 08:45:54 PM : [Std-Cleanup ] 1A.4F.19-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Thu 05/02/2024 08:45:54 PM : [INST-DUP ] Previous message ignored.

@xlurkr, one last thought if you haven't deleted yet: try changing the device "On Level" from the Admin Console. Change to something like 70%, then click the "On Level" button to write the changes. I normally keep the Event Viewer open when doing this so I can see the changes being written to the device. Turn your switch on locally and see if the ISY responds correctly.

@xlurkr, in my opinion, there is nothing wrong with your KPL. There is a problem with the way that the ISY is processing the communication from the KPL. KPL's are rather complicated devices and they carry a lot of legacy baggage that isn't necessarily documented by the Insteon guides. Labels above: Transmission from the KPL commanding devices in group 1 (00.00.01) to go to their preprogrammed on levels (the PLM). Items in green are the ISY "interpeting" this command (on) to level (168). A second transmission from the KPL commanding devices in group 1 (xx.xx.01) to go to their preprogrammed on levels. This is responsible for your device indicating a "1" level in the AC. In my opinion, this transmission should have been ignored by the ISY. Third transmission, using a "reserved" command "06". This transmission is ignored (correctly). That's the good news. The bad news is I don't know why this happened. You could investigate further with the ISY team (open a ticket). There might be a way to trace back to when/how this occurred. Your other option would be to delete the device and re-add it to the ISY (painful).

@xlurkr - your event viewer trace is a bit odd in that the device does appear to report two separate status(s) to the same manual on. Your event viewer does not appear to be on "level 3". Can't see the actual device communication to the PLM. If the problem is still occurring, could you post a trace with the viewer set to "level 3"?

@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