I have a random event which starts when a motion sensor (2844-222) triggers a scene for basement lights, but (not related) my garage door (IOLinc) opens and a light (LampLinc) turns on.

This is very rare event occurring once every 4 weeks ... The motion sensor is top of basement stairs and controls basement light scenes ...

Post event, looking through LOG (Tools) the motion sensor, the garage door (IOLinc) or the LampLinc do NOT appear when this event log and when I look at the LampLinc status, it shows off state, and If I look at a scene containing the LampLinc, it shows OFF status, but a mini remote button (4 Scene) shows ON associated with the LampLinc

I have run Tools / Diagnostics / Event Viewer for weeks hoping to catch what triggers this event ... no luck ...

Looking for direction on how to capture / diagnose this random event

Cheers

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:

Edited Tuesday at 06:39 PM3 days by IndyMike

8 minutes ago, IndyMike said:

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.

Appreciate the response and I think I understand what you are suggesting by "instigators", but there are no associations of my basement light control via programs, sensors or KPL's here to my garage door control or a standalone light ....

I also discovered today, the garage light was also turned on ... which is new

57 minutes ago, jim_ said:

Appreciate the response and I think I understand what you are suggesting by "instigators", but there are no associations of my basement light control via programs, sensors or KPL's here to my garage door control or a standalone light ....

I also discovered today, the garage light was also turned on ... which is new

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.

Insteon MS and other Insteon wireless devices are near the top of the instigators list.

Is the MS on batteries? In addition to the restore device suggestion, you can try factory resetting it and adding new batteries and then restore device. My experience is that lower the battery voltage gets on the MS, the more un predictable the behavior gets. I eventually put my MSs on a spring/fall battery rotation, ignoring the battery node from the device... and factory resetting them / restore device every time

1 hour ago, IndyMike said:

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.

learning enabled ... I understand a collision @ PLM, but not understanding "All-On" + "Devices that have not had the command removed will be affected" How does one remove the command "All-On" per device ?

1 hour ago, paulbates said:

Insteon MS and other Insteon wireless devices are near the top of the instigators list.

Is the MS on batteries? In addition to the restore device suggestion, you can try factory resetting it and adding new batteries and then restore device. My experience is that lower the battery voltage gets on the MS, the more un predictable the behavior gets. I eventually put my MSs on a spring/fall battery rotation, ignoring the battery node from the device... and factory resetting them / restore device every time

MS is hardwired to 5v and was factory reset ~ 6 months ago, but days after this random event was still occurring. I'm not convinced it's the MS as root cause ...

Since it's always the same devices affected (Lamp, Garage Door, and Garage Light (wife confirmed specifically these 3 only) and there is zero association with the MS / basement lights, we do know that when after 60 second-ish the MS is triggered, then these other 3 devices are affected. Since its not practical to share all my devices and related programs, but there are KPL's with control for this group of devices as well as others .... is it possible for data collision in a KPL ? (and yes the KPL(s) have been reset) ....

Back to the question of tools ... should I expect to see messaging in event viewer or is there other tools that I should explore or I'm SOL from a logging perspective ?

If it's workable, I'd pull the plug on the MS for the approximate amount of time it takes the ALL ON event to happen and see if it happens again. I had an MS 2 in my garage for a couple of years, on power not batteries. Worked perfectly during that time, ... until recently....

It recently started having problems and I tried all of the suggestions I gave above and had problems changing parameters such that they would stick. It was sending A LOT of messages for its motion sense. Factory resetting, etc had no effect so I replaced it with something else.

14 hours ago, jim_ said:

learning enabled ... I understand a collision @ PLM, but not understanding "All-On" + "Devices that have not had the command removed will be affected" How does one remove the command "All-On" per device ?

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.

15 hours ago, jim_ said:

lMS is hardwired to 5v and was factory reset ~ 6 months ago, but days after this random event was still occurring. I'm not convinced it's the MS as root cause ...

Since it's always the same devices affected (Lamp, Garage Door, and Garage Light (wife confirmed specifically these 3 only) and there is zero association with the MS / basement lights, we do know that when after 60 second-ish the MS is triggered, then these other 3 devices are affected. Since its not practical to share all my devices and related programs, but there are KPL's with control for this group of devices as well as others .... is it possible for data collision in a KPL ? (and yes the KPL(s) have been reset) ....

Back to the question of tools ... should I expect to see messaging in event viewer or is there other tools that I should explore or I'm SOL from a logging perspective ?

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.

Thanks for the descriptive reply, this helps me understand ....

2 hours ago, IndyMike said:

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.

Just to clarify .... request to post L3 events log > would this be a general capture (normal MS activation of basement lights ) or specific to the random event ?

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

Hey @IndyMike ... 24 hours of Event Viewer L3 attached ... And as per Murphy's Law, the random event did NOT occur

BTW, I understand standard IP protocol and use wireshark to isolate troubles, but was looking for an Insteon protocol cheat sheet ... the old UD wiki is to vague. Could you point me to any doc's ? (I have the original 2006 SmartLabs, Inc design doc, but there no procedure / state charts to review)

24 hour Event Viewer L3.txt

@jim_

Generally speaking all on events will not show up in the ISY logs as the ISY is not aware of the events.

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

I have been watching this post with interest. My experience very much mirrors those of @jim_ , including being associated with motion sensors in the basement.

I began to suspect motion sensors as an unexpected trigger for four other insteon devices. It was always the same four devices that responded, but not those particular footwear devices did not always turn on in response to a specific motion sensor. There were many times a suspected motion sensor would detect motion and not trigger the unexpected event.

I have since replaced all all insteon motion sensors with yolink. For now, I have no more insteon motion sensors in service at this point. I am pretty confident that this would solve the oft stated problem of signal collisions at the PLM. Unfortunately, the problem persists.

The only other culprit that I am suspecting now is is an iolink controlling a garage door. I am currently undecided How I am going to try to solve this problem. Whatever course of action I choose, it will certainly not happen until the weather warms up. For now, I am just choosing to live with the problem.

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

Edited 2 hours ago2 hr by IndyMike

TL;DR: Bottom line: get rid of all the old Insteon devices that respond to ALL ON.

I chased the phantom ALL ON event for years. Like the OP, it was also triggered when an Insteon battery-powered motion detector activated a program that turned on a scene. Most frequently caused LampLinc modules to turn on that had nothing to do with the scene that came on. It would also turn on older Insteon light switches (those that would show up with the tests mentioned earlier in this thread).

So, I replaced all of my Insteon plug-in modules with Matter-based on/off and dimmer modules (at a fraction of the price!). I also replaced the old Insteon wall switches with units running newer firmware. These changes eliminated 95% of the phantom ALL ON events, but every once in a while, they would still happen.

I am now using Eve Motion (Matter) sensors and moved all of my motion logic to Alexa as a temporary solution, while awaiting full Matter support for those sensors on EISY. See post here.

During the holidays, I do use some of the old Insteon modules for holiday lights and get an occasional ALL ON that turns some of them on. So, the signal is still happening. I just removed the old devices that listen for that event.