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

Thanks for the review @IndyMike I'm glad you were able to find the cause

As requested ... my LampLinc B2457D2 BiPhy V.41 & IOLinc 2450 = V.41

One comment, while its clear the code between PLM and ISY has not changed in many years, and a lot of my Insteon installation is pre V.45 ... I never saw this when the 994 was in control. I'm not suggesting this is a EISY issue, just mentioning as it's an interesting point. I plan on swapping the stairwell MD out to a Shelly Zwave solution hopefully this week. And I'll check out the Zooz ....

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.