IndyMike

Based on the log, your iolinc is triggering program 0015. Immediately after the trigger, the isy is turning on group (scene) 47. This appears to be a very large scene with 40+ members (I lost count) The program and scene appear to be executing correctly. Can you plm communicate reliably with these devices? The plm appears to hear other devices. Can it transmit to them?

It's a bit odd to have 4 devices with failing power supplies that can still control their loads. Is it possible you had a power event to damaged things? These are all powerline only devices. It's still possible that you have a noise source/absorber on the line that is preventing communication. Installing a dual band helper (LampLinc) or filtering suspect devices may help. Understand that replacing a single togglelinc isn't an option since you don't have a spare. You could try removing 1 switch and pigtailing to an appliance cord - plug in near the PLM to see if it communicates. Remember to CAP the red wire. Options for replacement aren't great. I would normally suggest Zooz Z-wave (Zen73 and Zen74) toggles, but I would NOT suggest these for the ISY994 since at best it's a 500 series z-wave (Polisy and Eisy support 700 and 800 series). If you determine that the switches are dying, and there are no good options for replacement, it is possible to replace the capacitors on the switch power supply. If you don't feel that adventurous, there were some people providing re-cap services for PLM's. There may be some available for Togglelincs as well.

I agree that inserting a delay would not be appropriate for hallway or star lighting. Pretty much defeats the purpose. Rather than use a program, create a scene with the hall light as a responder and the Motion sensor as a controller. Set the Motion sensor to ON/OFF and duration of your liking. You could also change your program from "Control" on to "Status" on. This would not prevent the re-triggering. It will not prevent the ISY from trying to issue the stair light command While the PLM is being hit with multiple RF motion sensor transmissions. Also, in my previous post I mentioned that the ISY was tagging some transmissions as "duplicate" and ignoring them. That doesn't mean that these aren't a problem. The PLM is still servicing these transmissions, again while the ISY is trying to send it's own commands. This is where we believe the problem occurs.

Unfortunately, I don't think the changes you made had an effect on the Motion sensor communications. I'm not sure why you only saw 3 communications during your test. Rest assured, the 6 communication event will return. Delays in you sensor triggered programs are your friend. They can prevent collisions as well as retrigger events. Highly recommended.

@jim_, now I need to back things up a bit: When a program is disabled, it will still show triggers in the event viewer. I find this rather frustrating. The disabled program WILL NOT execute then or else commands. Clear as mud, right? I see programs 0033 and 005D being triggered. If program 005D is disabled, the double trigger/ double scene call is coming from program 0033. As far as determining the program ID, I typically use the program summary - far right column is the program ID. I'm guessing that the "Parent" that you are referring to is the ID of the Folder the program is in.

@jim_ , It looks like you have a motion sensor at address 54.68.42 that is used as a control in two programs (0033 and 005D). Motion sensors send out multiple communication for each trigger event. Yours is sending out 6 separate messages. 4 of the messages the ISY has recognized as duplicates and is ignoring. Unfortunately two of the messages are being processed causing your programs to re-trigger rapidly. The result is multiple scene 21 on commands. You may want to add a lockout to your programs (to prevent re-triggering) as well as a delay to prevent the ISY from trying to send out commands while the motion sensor is hammering the PLM with 6 separate communications. Thu 02/05/2026 11:04:58 : [INST-SRX ] 02 50 54.68.42 00.00.01 CF 11 01 LTONRR (01) Motion Sensor On #1 - ISY Triggers Program Thu 02/05/2026 11:04:58 : [Std-Group ] 54.68.42-->Group=1, Max Hops=3, Hops Left=3 Thu 02/05/2026 11:04:58 : [D2D EVENT ] Event [54 68 42 1] [DON] [1] uom=0 prec=-1 Thu 02/05/2026 11:04:58 : [54 68 42 1 ] DON 1 Thu 02/05/2026 11:04:58 : [D2D-CMP 005D] CTL [54 68 42 1] [DON] op=is --> true Program 005D Control Trigger 1 Thu 02/05/2026 11:04:58 : [D2D-CMP 0033] CTL [54 68 42 1] [DON] op=is --> true Program 0033 Control Trigger 1 Thu 02/05/2026 11:04:59 : [INST-SRX ] 02 50 54.68.42 00.00.01 CF 11 01 LTONRR (01) Motion Sensor On #2 - ISY Re-triggers Program Thu 02/05/2026 11:04:59 : [Std-Group ] 54.68.42-->Group=1, Max Hops=3, Hops Left=3 Thu 02/05/2026 11:04:59 : [INST-SRX ] 02 50 54.68.42 71.1C.76 40 11 01 LTONRR (01) Motion Sensor On #3 (ISY ignores) Thu 02/05/2026 11:04:59 : [Std-Cleanup ] 54.68.42-->ISY/PLM Group=1, Max Hops=0, Hops Left=0 Thu 02/05/2026 11:04:59 : [INST-DUP 2 ] Previous message ignored. Thu 02/05/2026 11:04:59 : [INST-TX-I1 ] 02 62 00 00 21 CF 11 00 Scene 21 On Thu 02/05/2026 11:04:59 : [D2D EVENT ] Event [54 68 42 1] [DON] [1] uom=0 prec=-1 Thu 02/05/2026 11:04:59 : [54 68 42 1 ] DON 1 Thu 02/05/2026 11:04:59 : [D2D-CMP 005D] CTL [54 68 42 1] [DON] op=is --> true Program 005D Control Re-Trigger Thu 02/05/2026 11:04:59 : [D2D-CMP 0033] CTL [54 68 42 1] [DON] op=is --> true Program 0033 Control Re-Trigger Thu 02/05/2026 11:04:59 : [INST-TX-I1 ] 02 62 00 00 21 CF 11 00 Scene 21 On (repeat) Thu 02/05/2026 11:04:59 : [INST-ACK ] 02 62 00.00.21 CF 11 00 06 LTONRR (00) Modem ack scene 21 On Thu 02/05/2026 11:05:00 : [INST-ACK ] 02 62 00.00.21 CF 11 00 06 LTONRR (00) Modem ack scene 21 On (repeat) Thu 02/05/2026 11:05:00 : [INST-SRX ] 02 50 54.68.42 71.1C.76 43 11 01 LTONRR (01) Motion Sensor On #4 (ISY Ignores) Thu 02/05/2026 11:05:00 : [Std-Cleanup ] 54.68.42-->ISY/PLM Group=1, Max Hops=3, Hops Left=0 Thu 02/05/2026 11:05:00 : [INST-DUP 2 ] Previous message ignored. Thu 02/05/2026 11:05:00 : [INST-SRX ] 02 50 54.68.42 11.01.01 CB 06 00 (00) Motion Sensor On #5 (ISY Ignores) Thu 02/05/2026 11:05:01 : [Std-Group ] 54.68.42-->11.01.01, Max Hops=3, Hops Left=2 Thu 02/05/2026 11:05:01 : [INST-INFO ] Previous message ignored. Thu 02/05/2026 11:05:01 : Create REST U7 [/rest/profiles/ns/1/connection] Thu 02/05/2026 11:05:01 : Create REST U7 [/rest/profiles/ns/0/connection] Thu 02/05/2026 11:05:01 : [INST-SRX ] 02 50 54.68.42 11.01.01 CF 06 00 (00) Motion Sensor On #6 (ISY Ignores) Thu 02/05/2026 11:05:01 : [Std-Group ] 54.68.42-->11.01.01, Max Hops=3, Hops Left=3 Thu 02/05/2026 11:05:01 : [INST-INFO ] Previous message ignored.

From your description it sounds like you did indeed use the "Delete Modem" command. Since your current PLM was not listed as a group 0 controller, newer devices should have responded with a NAK for anything other than a simple on/off (many won't respond to an on/off either). Unless all of your devices are older (pre- 2012), I'm not sure how your system functioned. Aside from that, it sounds like the ISY now has the correct information to allow it to correctly restore your devices/scenes. It may be painful, but not nearly as painful as rebuilding all the scenes/programs.

Glad to hear you are narrowing in on things. One thing to note - since your devices had the "old" PLM links in their tables, they would have been trying to communicate (and timing out) on a device that was not available. Now that you have eliminated the old links, your system should be far more responsive. This is why you should ALWAYS delete devices that you are removing from the system (I.E failed). If you leave "orphaned" links in devices they will try to communicate (retries, etc) with a device that no longer exists. It can really bog down a system.

@jim_ , no smoking guns in your event viewer. I have a python program that parses the event viewer looking for errors. It specifically looks for INST-TX communications from the ISY to the PLM followed by INST-ACK responses from the PLM. I modeled this after a description provided by @kclenden . He was the 1st (to the best of my knowledge) to observe ISY/PLM communication errors in the Event Viewer A normal TX/ACK for a scene looks like the following (on command to group 21: 10039 Fri 02/06/2026 12:53:36 : [INST-TX-I1 ] 02 62 00 00 21 CF 11 00 10041 Fri 02/06/2026 12:53:37 : [INST-ACK ] 02 62 00 00 21 CF 11 00 06 LTONRR (00) A device direct command includes a response from the device itself. My program does not test the responses: 9629 Fri 02/06/2026 12:51:08 : [INST-TX-I1 ] 02 62 42 D7 2C 0F 11 FF 9633 Fri 02/06/2026 12:51:08 : [INST-ACK ] 02 62 42 D7 2C 0F 11 FF 06 LTONRR (FF) 9634 Fri 02/06/2026 12:51:08 : [INST-SRX ] 02 50 42 D7 2C 71 1C 76 2F 11 FF LTONRR (FF) 9635 Fri 02/06/2026 12:51:08 : [Std-Direct Ack] 42 D7 2C-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Your event viewer contained 918 total I1 communications. There were no errors (an error is where the INST-ACK <> the INST-TX). There was one "Unknown" error, and 3 timeouts (modem did not respond with a ACK). Your event viewer did not contain any I2 communications. #'s: I1ackerr: 0 I2ackerr: 0 Timeout1: 3 Timeout2: 0 Unknownerr: 1 I1Good: 918 I2Good: 0 The Unknown error came at a time when there wasn't a lot going on. No good explanation for the error. The ISY was attempting to turn on group 21. The line labeled with a "U" should have been an INST-ACK 02 62. This command did not go through. Not sure whether the ISY retried the command. There is another ON command processed 13 seconds later. 2419 Thu 02/05/2026 14:17:45 : [INST-TX-I1 ] 02 62 00 00 21 CF 11 00 U 2420 Thu 02/05/2026 14:17:45 : [UNKNOWN ] 02 00 The timeout errors also came at time where there wasn't a lot going on. The INST-TX command below should have been ACKnowledged within seconds (INST-ACK 02 62 00 00 1F CF 13 00 06). No communications were received by the ISY in 1:10 after the command. 8449 Fri 02/06/2026 12:25:39 : [INST-TX-I1 ] 02 62 00 00 1F CF 13 00 T1 8450 Fri 02/06/2026 12:26:50 : [INST-SRX ] 02 50 54 68 42 00 00 01 CF 11 01 LTONRR (01) I did see some areas where there was very high activity. In the section below 3 devices and 6 scenes are turned off in rapid succession. I've never seen that many INST-TX commands "stacked" without a response from the PLM. The PLM did eventually ACK all of these, I am truly surprised. This is most likely a program executing an OFF to multiple members (it could be an external REST command). You may want to look at adding some delays to prevent overloading the PLM. 4898 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 58 CA 24 0F 13 00 4899 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 33 7A 65 0F 13 00 4900 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 4E B1 E0 0F 13 00 4901 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 1B CF 13 00 4902 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 14 CF 13 00 4903 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 12 CF 13 00 4904 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 1C CF 13 00 4905 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 16 CF 13 00 4906 Fri 02/06/2026 07:16:55 : [INST-TX-I1 ] 02 62 00 00 1E CF 13 00 4907 Fri 02/06/2026 07:16:55 : [ZW-TX-A 01253 2 0 ] [ZY002_1] Binary Switch Set val=0 duration=255 You have some scenes where the command is repeated. The below shows an ON command to group 11 being sent twice. Multiple commands to a scene can improve it's reliability but there should be some delay between the commands. 3807 Thu 02/05/2026 17:21:25 : [INST-TX-I1 ] 02 62 00 00 1F CF 11 00 3808 Thu 02/05/2026 17:21:25 : [INST-TX-I1 ] 02 62 00 00 1F CF 11 00 3809 Thu 02/05/2026 17:21:25 : [INST-ACK ] 02 62 00 00 1F CF 11 00 06 LTONRR (00) In summary, this is mostly good news. You have good communication in general (Hops left = 3 in most cases) and 0 communication errors. If you happen to capture an "all-on" event in the viewer, I would be happy to look at it. Aside from that, I would suggest inspecting your programs from proper delays, particularly where motion sensors are being used. You can always post your programs as well. Many forum members with far more programming experience than myself. EDIT: I should have asked earlier - can you provide the addresses of the devices that are turning on? If many devices, you can provide a few.

@jim_ , no worries. We'll have a look and see whether errors are occurring. There's no "easy" doc to explain the communication protocol shown in the event viewer. What you are seeing is the Host to Modem communication + a lot of ISY notations and program diagnostics. If you are using PG3 (or whatever it's call these days), things get even more confusing. For understand the raw Host to Modem protocol, my favorite doc is the following: https://madreporite.com/insteon/Insteon2412s_modem_dev_guide.pdf There are newer docs (written for the HUB) but the above does a nice job of explaining the protocol without adding too much fat. Many thanks to the Madreprite site for continuing to make this information available. There is other good Insteon information on the site as well.

Possible that you didn't power cycle your ISY after replacing the PLM. The ISY reads the PLM address on powerup/reset. If you replaced the PLM and ran a restore modem (PLM) without the powercycle, the ISY would still have the OLD PLM address - it wrote OLD information to your devices. The Delete Modem command is normally used to remove the PLM address from all of your Insteon devices. Since your current PLM address is not in the device(s) link table(s), I'm not at all sure what the command would do. Instead, proceed as you would if replacing the modem normall: Backup your ISY - just because... Power cycle the ISY to make sure is has your current PLM address (or verify using the show plm info tool). Perform the "Restore Modem (PLM)" function. The ISY will write changes to your PLM and all of your attached Devices. Your link tables should update with the current PLM address. Remember to put your battery devices into linking mode. Assuming things work and you verify that your current PLM address is written to the devices - backup your ISY again. Give it a novel name to indicate this backup has the NEW PLM.

@jim_ , a log that spans the actual event would be optimal. Since that may be difficult, a log spanning say 24 hours would help us to understand if there are errors occurring regularly (not all errors produce events).

The All-On is a valid Insteon command. When a communication collision at the PLM occurs, a valid outgoing scene command is corrupted into an "All-ON or All-Off" scene command. All older Linked Units will respond In recent years, Smartlabs began removing the "All-On/All-Off" command from individual devices. Many dimmers/relays with firmware newer than V.45 have had the command removed and will Not respond. One of the links I provided describes how to test for this. While it's possible to have a data collision at the KPL, it shouldn't produce an "all-on". The reason are rather dry and technical. It is completely possible for the KPL to cause a collision at the PLM. This typically occurs when the KPL is a scene controller and also triggers a program. MS's are high on the list of instigators because they have the annoying of sending multiple communications to the PLM (increasing the likelihood of a collision). To your last question on messaging - is this is a true "all-on" event you will not see evidence in the event viewer. You may be able to isolate the trigger event through the process of elimination (as you are doing), the the event will look like a normal trigger. Having said the above, one of our forum members has noted communication errors between the PLM and EISY ( @kclenden ). Would you mind posting a level 3 event viewer capture? We could go through the PLM/ISY communications to see if errors exist.

The "Random" event is caused by a communication collision at the PLM. The result of the collision is an Insteon "All-On" command sent to all devices. Devices that have not had the command removed will be affected.

If the ISY has no knowledge of the event, and the Event Viewer isn't showing anything, this would appear to qualify as an "all on"event. Motion sensors and KPL's calling programs that in turn call scenes involving the triggering device are known instigators. The Wiki Guidance is below. There are also numerous posts on the forum. Smartlabs has removed the all-on command from some recently produced devices (V.45). Your IOLinc is probably susceptible. The second link below shows how to test for susceptibility. The 3rd link shows devices that have been tested for susceptibility and have passed. As a precaution, you should probably perform a "restore device" on your problem units to make sure no extraneous links have crept in over time. Wiki link on preventing all on events https://wiki.universal-devices.com/INSTEON_Random_All_On_Events You can test for susceptible all on devices as shown here:

I decided to give this a run on my used/refurb Mini-PC (HP Elitedesk 800) with Win11 Pro and 32G ram/ 1T SDD. My 1st run using IOX, and no Java customizations. We are at 4 days running at the moment with the event viewer open. The MiniPC does have a hardwired LAN connection, but otherwise is a rather minimalist system and extremely inexpensive. It runs most of my automation well including Home Assistant, Houselinc, and (now) IOX. As @Geddy indicated, hardwired LAN is greatly preferred. Beyond that, I saw that you were using MacOS in another thread - I have no experience.

I'm not aware of any timeout on the Admin Console (or forgot). I simply let it run

I've been able to leave the event viewer running on my laptop for that long. Longest file I appear to have is 8 days ~122K lines. I've obviously turned off sleep and hibernate (win11). Not sure if it matters, but I increase the java memory allocation to 512M (-Xmx512m parameter). https://wiki.universal-devices.com/index.php?title=Main_Page#Admin_Console_is_very_slow_or_hangs

@andrew77 , after seeing your event viewer info, it appears you have 1 - 8 button KPL and 1 SWL relay in your scene. I reconfigured my test setup to be similar (1-8 button KPL + 1 SWL dimmer). Since your devices are sending the correct information to the PLM, and you have excellent communication, that leaves us with a link table problem. This will most likely be in the KPL since the "H" button is not following the SWL. Please perform a "Link table read" by right clicking on the KPL and the selecting "Diagnostics/Show Device Links Table" from the drop down list. See the graphic below. The ISY will take some time communicating with your KPL and will fill in the table on the far right. Once the process is complete, click on the "Compare" button toward to bottom right of the window. In response, the ISY will present a second table showing what it believes "should be" in the KPL link table. It will also highlight any errors. Please perform a screen copy of the tables and post to the forum. iX Address Flag Group Device D1 D2 Button 0 FF8 A2 0 53BC3A FF 1F 01 1 FF0 E2 1 53BC3A 1 00 01 2 FE8 E2 2 53BC3A 1 00 02 3 FE0 E2 3 53BC3A 1 00 03 4 FD8 E2 4 53BC3A 1 00 04 5 FD0 E2 5 53BC3A 1 00 05 6 FC8 E2 6 53BC3A 1 00 06 7 FC0 E2 7 53BC3A 1 00 07 8 FB8 E2 8 53BC3A 1 00 08 9 FB0 A2 5A 53BC3A FF 1F 07 A FA8 E2 7 16CE23 1 00 07 B FA0 A2 1 16CE23 FF 1F 07 C F98 0 0 0 0 00 0 I've created the table above from the data in my KPL. The items at address FA8 and FA0 are what allow the KPL to control and respond to my SWL @16.CE.23 Note: your KPL will likely have far more links. The addresses will be different. Your SWL address is also different @70.65.71. Even so, this information must be there in order for the KPL to control/respond to the SWL. Your KPL should have a record matching the following. The "E2" flag indicates that the KPL is a controller of the listed device (your SWL). The 7 in the last column indicates KPL Button G E2 7 70.65.71 1 00 07 The second link with the "A2" Flag indicates that the KPL is a responder to the listed device. This allows your SWL @70.65.71 to control button G on the KPL. A2 1 70.65.71 FF 1F 07 Assuming things are incorrect, recovery may be as easy as deleting the device from the scene and re-adding. Worst case would be deleting the device and re-linking (painful for a KPL). The reason we are going through this somewhat painful exercise is to determine whether the link table is in fact Incorrect. If so, we'll know how to proceed. The other possibility is that your KPL cannot hear the SWL. We've established that both devices can communicate well with the PLM. That does not guarantee that they can communicate with each other (different phases, etc).

It's possible you have a new noisemaker/signal absorber near the PLM. The Holidays are rather famous for these. Try moving your PLM to a different circuit. You can use an extension cord if necessary. If your communications improve, inspect the original circuit for problem devices (UPS, Printers, PC's, chargers). If your communications do not improve, try plugging in a Insteon Lamplinc (or similar) as a helper. If the PLM can't communicate with the LL, it's probably time to go shopping...

As @oberkc indicated, your Alexa command is turning on the SWL device ONLY - not the scene. Your KPL button will not change because you are commanding the specific device, not the scene. I an completely Alexa ignorant. I'm assuming there is a way to turn on your Scene rather than the specific SWL device.

@andrew77 , thank you for the Log. Your devices are communicating very well. Your SWL @70.65.71 is communicating everything with the PLM correctly. It also has excellent communications (Max Hops =3, Hops Left =3) SWL Switch Off 70.65.71 Group 1 On Tue 01/20/2026 12:32:00 PM : [INST-SRX ] 02 50 70.65.71 00.00.01 CF 11 00 LTONRR (00) Tue 01/20/2026 12:32:00 PM : [Std-Group ] 70.65.71-->Group=1, Max Hops=3, Hops Left=3 SWL to PLM Group Cleanup SWL @ 70.65.71 Issuing cleanup to PLM @71.1B.2E Tue 01/20/2026 12:32:00 PM : [INST-SRX ] 02 50 70.65.71 71.1B.2E 40 11 01 LTONRR (01) Tue 01/20/2026 12:32:00 PM : [Std-Cleanup ] 70.65.71-->ISY/PLM Group=1, Max Hops=0, Hops Left=0 SWL Switch 70.65.71 Group 1 Off Tue 01/20/2026 12:32:11 PM : [INST-SRX ] 02 50 70.65.71 00.00.01 CF 13 00 LTOFFRR(00) Tue 01/20/2026 12:32:11 PM : [Std-Group ] 70.65.71-->Group=1, Max Hops=3, Hops Left=3 SWL to PLM Group Cleanup SWL @ 70.65.71 Issuing cleanup to PLM @71.1B.2E Tue 01/20/2026 12:32:11 PM : [INST-SRX ] 02 50 70.65.71 71.1B.2E 45 13 01 LTOFFRR(01) Tue 01/20/2026 12:32:11 PM : [Std-Cleanup ] 70.65.71-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Your Alexa command was processed correctly. However, it was directed to the SWL @71.1B.2E, not your scene. This command will only turn on that specific device. Alexa (Rest) SWL Command ON Alexa turning device 07.65.71 On Tue 01/20/2026 12:32:26 PM : Create REST U7 [/rest/nodes/70%2065%2071%201/cmd/DON] Tue 01/20/2026 12:32:26 PM : U7 Rest: submitCmd([70 65 71 1],[DON],[<NULL>]) Tue 01/20/2026 12:32:26 PM : [INST-TX-I1 ] 02 62 70 65 71 0F 11 FF Tue 01/20/2026 12:32:26 PM : [INST-ACK ] 02 62 70.65.71 0F 11 FF 06 LTONRR (FF) Tue 01/20/2026 12:32:26 PM : [INST-SRX ] 02 50 70.65.71 71.1B.2E 2F 11 FF LTONRR (FF) Tue 01/20/2026 12:32:26 PM : [Std-Direct Ack] 70.65.71-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Your KPL button appears to be button "G" on an 8 button KPL (group 7). It also performed correctly in communicating to the PLM and had excellent communications (Max Hops=3, Hops Left=3). KPL Button H On - 8 button KPL turning on group 7 KPL Button G @70.9C.CE Tue 01/20/2026 12:33:48 PM : [INST-SRX ] 02 50 70.9C.CE 00.00.07 CF 11 00 LTONRR (00) Tue 01/20/2026 12:33:48 PM : [Std-Group ] 70.9C.CE-->Group=7, Max Hops=3, Hops Left=3 KPL Button G to PLM Group Cleanup Tue 01/20/2026 12:33:49 PM : [INST-SRX ] 02 50 70.9C.CE 71.1B.2E 4A 11 07 LTONRR (07) Tue 01/20/2026 12:33:49 PM : [Std-Cleanup ] 70.9C.CE-->ISY/PLM Group=7, Max Hops=2, Hops Left=2 In summary, your devices appear to be communicating correctly and well with the PLM. While it's possible that your SWL isn't communicating well with your KPL, that's unlikely. My guess would be that you have a link table error in one or both of your devices. Could your post The scene that you are using for these devices? It should look something like the following. Failing a scene membership issue, we'll need to look at the link tables in the devices themselves. We'll leave that for another post...

@andrew77 , my go to for troubleshooting problems of this nature is using the Event Viewer on Level 3. I generated a test Scene that contains a KPL, LampLinc, and a SWL Dimmer. All 3 devices are controllers. Any of the 3 devices will turn the scene On/Off and the KPL Button "A" will track the On/Off. I did this to show you what you "should" be seeing in the event viewer when you activate the scene devices. If you think you are seeing something different, you likely have a device link table error or communication issues. Post back and we can work through those. When you activate a "Device" in a scene it should communicate with group members through Group 01 (for simple devices) or Groups 1 - 8 for KPL's. This will show up in the event viewer as shown below. Request a group cleanup from group members to verify they received the command. This includes your PLM. In the following I am showing addresses for my devices: 16.CE.23 is my SWL Dimmer (your dimmer address will be different. The Group # 00.00.01 should be present in your event viewer. My PLM is at Address 53.BC.3A (yours will obviously be different). The group 1 cleanup commands between your device and your PLM should be present. I used KPL button "A" as the controller for my Scene (6 button mode). This works out to be group 3 when the device activates the scene. If you use a different button (or are using 8 button mode) the group # will be different. TAP SWL Dimmer Off (Superfluous ISY Information Dim) SWL Dimmer @16.CE.23 Turning Group 1 off Tue 01/20/2026 09:23:33 AM : [INST-SRX ] 02 50 16.CE.23 00.00.01 CB 13 00 LTOFFRR(00) Tue 01/20/2026 09:23:33 AM : [Std-Group ] 16.CE.23-->Group=1, Max Hops=3, Hops Left=2 Tue 01/20/2026 09:23:33 AM : [D2D EVENT ] Event [16 CE 23 1] [DOF] [0] uom=0 prec=-1 Tue 01/20/2026 09:23:33 AM : [ 16 CE 23 1] DOF 0 Tue 01/20/2026 09:23:33 AM : [D2D EVENT ] Event [16 CE 23 1] [ST] [0] uom=100 prec=0 Tue 01/20/2026 09:23:33 AM : [ 16 CE 23 1] ST 0 (uom=100 prec=0) Tue 01/20/2026 09:23:33 AM : [D2D EVENT ] Event [18 93 83 1] [ST] [0] uom=100 prec=0 Tue 01/20/2026 09:23:33 AM : [ 18 93 83 1] ST 0 (uom=100 prec=0) Tue 01/20/2026 09:23:33 AM : [D2D EVENT ] Event [19 21 5C 3] [ST] [0] uom=100 prec=0 Tue 01/20/2026 09:23:33 AM : [ 19 21 5C 3] ST 0 (uom=100 prec=0) SWL Dimmer @16.CE.23 Requesting PLM Cleanup @53.BC.3A Tue 01/20/2026 09:23:33 AM : [INST-SRX ] 02 50 16.CE.23 53.BC.3A 41 13 01 LTOFFRR(01) Tue 01/20/2026 09:23:33 AM : [Std-Cleanup ] 16.CE.23-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Tap SWL Dimmer On (Superfluous ISY Information Removed) SWL Dimmer @16.CE.23 Turning Group 1 on Tue 01/20/2026 09:24:23 AM : [INST-SRX ] 02 50 16.CE.23 00.00.01 CB 11 00 LTONRR (00) Tue 01/20/2026 09:24:23 AM : [Std-Group ] 16.CE.23-->Group=1, Max Hops=3, Hops Left=2 SWL Dimmer @16.CE.23 Performing cleanup on PLM@53.BC.3A Tue 01/20/2026 09:24:23 AM : [INST-SRX ] 02 50 16.CE.23 53.BC.3A 46 11 01 LTONRR (01) Tue 01/20/2026 09:24:23 AM : [Std-Cleanup ] 16.CE.23-->ISY/PLM Group=1, Max Hops=2, Hops Left=1 LampLinc On Lamplinc On @18.93.83 turning Group 1 On Tue 01/20/2026 09:31:09 AM : [INST-SRX ] 02 50 18.93.83 00.00.01 CF 11 00 LTONRR (00) Tue 01/20/2026 09:31:09 AM : [Std-Group ] 18.93.83-->Group=1, Max Hops=3, Hops Left=3 Lamplinc On @18.93.83 Requesting PLM Cleanup @53.BC.3A Tue 01/20/2026 09:31:09 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 4A 11 01 LTONRR (01) Tue 01/20/2026 09:31:09 AM : [Std-Cleanup ] 18.93.83-->ISY/PLM Group=1, Max Hops=2, Hops Left=2 Lamplinc Off Lamplinc Off @18.93.83 turning Group 1 Off Tue 01/20/2026 09:36:20 AM : [INST-SRX ] 02 50 18.93.83 00.00.01 CF 13 00 LTOFFRR(00) Tue 01/20/2026 09:36:20 AM : [Std-Group ] 18.93.83-->Group=1, Max Hops=3, Hops Left=3 Lamplinc Off @18.93.83 Requesting PLM Cleanup @53.BC.3A Tue 01/20/2026 09:36:20 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 45 13 01 LTOFFRR(01) Tue 01/20/2026 09:36:20 AM : [Std-Cleanup ] 18.93.83-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 KPL Button "A" Off KPL @19.21.5C turning Group 3 (KPL Button A) Off Tue 01/20/2026 09:38:09 AM : [INST-SRX ] 02 50 19.21.5C 00.00.03 CF 11 00 LTONRR (00) Tue 01/20/2026 09:38:09 AM : [Std-Group ] 19.21.5C-->Group=3, Max Hops=3, Hops Left=3 Button "A" Off @19.21.5C Requesting PLM Cleanup @53.BC.3A Tue 01/20/2026 09:38:09 AM : [INST-SRX ] 02 50 19.21.5C 53.BC.3A 45 11 03 LTONRR (03) Tue 01/20/2026 09:38:09 AM : [Std-Cleanup ] 19.21.5C-->ISY/PLM Group=3, Max Hops=1, Hops Left=1

Using a device to trigger a program that in turn sends commands back to the trigger device, has been documented to cause collisions that can produce all-on/all-off events. In short, it's an ISY no-no. The 3 second delay that I show in my program is intended to eliminate the collisions. https://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events If you want to eliminate the program delays, I would suggest 2 separate KPL buttons controlling 2 separate scenes: KPL button 1/scene 1. KPL button 1 is a "Non-Toggle" On button that is controller for your scene 1. It will ONLY send "on" commands to the scene. Include KPL button 2 in this scene as a responder. KPL button 2/scene 2. KPL button 2 is a "Non-Toggle" Off button that is controller for your scene 2. If will ONLY send "off" commands to the scene. Include KPL button 1 in this scene as a responder. This should eliminate the delays associated with programs while also preventing communication problems. You can access the KPL "Buttons Toggle Mode" at the buttom of your KPL screen in the Admin Console. I have many instances where I use the Non-Toggle [off] on KPL's. I use them as monitors around the house (Outside, basement, 1st floor, 2nd floor and House). If the button is ON, pushing it sends an Off to all scene members (1st floor as an example). Helps when I leave something on in the basement and I'm going to bed. I can hit a button on my bedroom KPL rather than "running the stairs".

@andrew77 , the SWL and Lamplinc also need to be CONTROLERS of the scene. If they are Responders, they will not send the On/Off/Dim commands to other scene members.