IndyMike

Your LampLinc dimmer and IOlinc will both be susceptible (as suspected). Unfortunately it looks like I may have been incorrect in assuming that later Lamp dimmers/ ON-Off modules have had the command removed. I have thee 2635-222 On/Off modules version V.48 - all of them are susceptible. If someone in the community has a newer version Dimmer modules (2457D2) or On/Off Module (2635-222) it would be HELPFULL if they could verify whether the All-On/All-Off code has been removed. Changing your MS over to Zwave should be a good preventative measure. You questioned whether things have become worse with the EISY vs the ISY994. The phenomena was 1st identified years ago on the ISY994. I have had frequent events over the years. They have largely been mitigated by: Following the wiki suggestions - no KPL triggered programs changing secondary buttons on the same KPL. I actually do this in some programs, but I have healthy delays in place. Migrate away from Insteon motion sensors to prevent multiple RF communications (zwave, zigbee). Where Insteon MS are used, make them scene controllers. Do Not trigger programs. Where they can be tolerated - always use delays in programs. Include an all-on detector linked to the PLM (I use a plug in dimmer 2457d2 V.3B). Poll the device at xx minute intervals. If it is detected ON, assume an Event has occurred and execute an all-off. Never use an Insteon device (or any other HA) in critical applications without appropriate safeties installed. To your direct question as to whether "events" are more prevalent on the EISY - It is a faster device. If a program is triggered on the EISY it might respond more quickly than the ISY994. That could in turn make it more likely for the EISY to be sending out a communication at the same time a motion sensor repeat command is inbound. The above is a lot of ifs, ands, and buts - pure speculation. On the flip side, I have 40+ years of experience in troubleshooting systems that broke after a supplier "improved" an electrical component.

@jim_ Your log was extremely useful. Just prior to your garage door event it recorded the following: Sat 02/28/2026 10:57:49 : [INST-SRX ] 02 50 54.68.42 00.00.01 CF 11 01 LTONRR (01) - Motion sensor trigger Sat 02/28/2026 10:57:49 : [Std-Group ] 54.68.42-->Group=1, Max Hops=3, Hops Left=3 Sat 02/28/2026 10:57:49 : [D2D EVENT ] Event [54 68 42 1] [DON] [1] uom=0 prec=-1 Sat 02/28/2026 10:57:49 : [54 68 42 1 ] DON 1 Sat 02/28/2026 10:57:49 : [D2D-CMP 005D] CTL [54 68 42 1] [DON] op=is --> true - Program 005D trigger Sat 02/28/2026 10:57:49 : [ZWAVE-CTL-EVENT ] Basic Set from 23.0 unmapped (ignored) Sat 02/28/2026 10:57:50 : [INST-TX-I1 ] 02 62 00 00 21 CF 11 00 - Command from ISY to PLM to turn on group 21 Sat 02/28/2026 10:57:50 : [INST-ACK ] 02 62 CF.11.00 CF 11 00 06 LTONRR (00) Corrupted acknowledge from PLM to ISY - Execute On for group 00 (all devices) Your PLM should have echoed back the EXACT TX command that the ISY sent with an "06" added to the end. Instead it returned a corrupted command that I believe may have executed an group 0 on (all linked devices On). I'll try testing in the morning to verify. @kclenden appears to be the 1st to have noticed this in the event logs. His post is here https://forum.universal-devices.com/topic/45721-lights-switch-on-at-random-times/page/4/#findComment-399260. I'll confess that I do not understand why the PLM corrupted the command. It's interesting to note that the event viewer shows your motion sensor sending 1 On command to group 01 (02 50 54.68.42 00.00.01 CF 11 01). Motion sensors normally send 2. As said previously, delays in programs are normally used to prevent collisions. Your program 005d may have caused a collision at the PLM while the motion sensor was sending it's second ON communication. The other approach is your devices themselves. We had discussed that Smartlabs has been removing the all-on code from devices. Unfortunately that has NOT been done for IOLincs, they are still susceptible. If you can forward your model/revisions/date code for your LampLinc we can probably figure out if it is still susceptible. Try executing the All-on command from with ISY My Lighting window (hold onto your hat). Devices that turn on are susceptible (you have to verify this visually - the ISY will ASSUME all devices have turned on). If your LampLinc and IOLinc are the only offenders, replace them and get on with your life. I would highly suggest replacing the IOLinc regardless - I would post my opinion of these devices but the forum doesn't allow that type of language. Edit 3/1/25 AM: Performed testing using the command sequence 02 62 CF 11 00 CF 11 00. Confirmed that this sequence will turn on all group 0 devices linked to the PLM (basically every device). I used a spare PLM linked to 2 devices so I didn't turn on my entire house. You can test your system to see how many of your devices are susceptible by using the "All on"/"All Off" buttons on the My Lighting page of the admin console - https://forum.universal-devices.com/topic/42846-how-to-test-insteon-devices-for-all-on-vulnerability/#findComment-378245 Most susceptible devices can be replaced with newer versions that have had the command removed (no longer susceptible). The IOLinc has not been updated. Since you also appear to have Z-Wave devices, I would suggest the Zooz Zen51 dry contact relay as a replacement. The device has a specific "garage opener" mode for momentary contact closure. I've been using the Zen51 to activate my millivolt gas valve on my fireplace (overtemp safeties in place) for many years without a hitch.

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.