1 hour ago, IndyMike said:

Your earlier "Event Viewer" post showed that the EISY was receiving REST commands instructing it to turn on/off device  60.41.6B.

That is the EISY simply responding to an external command.  Not a fault of the EISY or the PLM.  It's a valid command that is being received through the network interface.  

I don't use Alexa or PG3 so I am not much help in troubleshooting.  I suppose you could try eliminating specific device links (60.41.6b) from Alexa to see if that corrects the behavior for that specific device.

You can also disconnect the EISY from your network during the night (rather than unplugging it).  Without a network connection, the Rest interface should not be operative.   

This is a partial summary of the things I have done.

Thanks for your further explanation/suggestions. When I posted the log, it was for only one instance of a random on, and it happened to be the I3 switch (60.41.6B).  After that, I factory reset the switch, but the behavior did not change.  About every Instean device (old switches, outlets, and the new I3 switch is randomly switching. (I also have another I3 switch I installed at the same time as 60.41.6B, which seems, so far, immune to randomly switching). I reset three Insteon devices, and the behavior continued. The three included an old switch, a new I3 switch, and an outlet. All of them continued errant behavior after factory resets. Would I "air gap" a switch to take it offline to see if it stops the undesired behavior?  And, if it did, what would be the remedy, as I suspect the origin of the REST command is still unknown?

When you suggest disconnecting the EISY rather than removing power, are you suggesting the removal of the USB cable connecting to the PLM?  I think I did that, but I will try it again. As I recall, it did not eliminate the undesired behavior.  I am suspecting that I will continue to lack the "smoking gun", i.e., the source of the REST command.

I have now also disabled all of my programs. I deleted some that I was not using.

general question for anyone. Is there some way to remove/reset the association between my eisy and my echo's? Is it included in the document entitled ISY Portal Amazon Echo Integration V3 - Universal Devices, Inc. Wiki? I have attached a copy that addresses the addition of the integration. I have not throughly read it yet.

I am posting a 7-minute level 3 communication log from my system at 11 am in case there are additional clues.  It has several REST commands.

 

ISY-Eventslevel 3 comm -Log.v6.0.0__Sun 2025.10.12 11.09.14 AM.txt ISY Portal Amazon Echo Integration V3 - Universal Devices, Inc. Wiki.pdf

13 minutes ago, jlloyd_UD said:

This is a partial summary of the things I have done.

Thanks for your further explanation/suggestions. When I posted the log, it was for only one instance of a random on, and it happened to be the I3 switch (60.41.6B).  After that, I factory reset the switch, but the behavior did not change.  About every Instean device (old switches, outlets, and the new I3 switch is randomly switching. (I also have another I3 switch I installed at the same time as 60.41.6B, which seems, so far, immune to randomly switching). I reset three Insteon devices, and the behavior continued. The three included an old switch, a new I3 switch, and an outlet. All of them continued errant behavior after factory resets. Would I "air gap" a switch to take it offline to see if it stops the undesired behavior?  And, if it did, what would be the remedy, as I suspect the origin of the REST command is still unknown?

When you suggest disconnecting the EISY rather than removing power, are you suggesting the removal of the USB cable connecting to the PLM?  I think I did that, but I will try it again. As I recall, it did not eliminate the undesired behavior.  I am suspecting that I will continue to lack the "smoking gun", i.e., the source of the REST command.

I have now also disabled all of my programs. I deleted some that I was not using.

general question for anyone. Is there some way to remove/reset the association between my eisy and my echo's? Is it included in the document entitled ISY Portal Amazon Echo Integration V3 - Universal Devices, Inc. Wiki? I have attached a copy that addresses the addition of the integration. I have not throughly read it yet.

I am posting a 7-minute level 3 communication log from my system at 11 am in case there are additional clues.  It has several REST commands.

 

ISY-Eventslevel 3 comm -Log.v6.0.0__Sun 2025.10.12 11.09.14 AM.txt 1014 B · 4 downloads ISY Portal Amazon Echo Integration V3 - Universal Devices, Inc. Wiki.pdf 179.28 kB · 0 downloads

@jlloyd_UD, Resetting your switches will not help.  Base on your event viewer, they are responding to valid communications from the PLM/EISY.  

The EISY is, in turn, responding to a valid REST command instructing it to turn ON/OFF an Insteon device.  

Your latest Event Log doesn't offer any new insight (at least for me). 

1. You have 3 reset "profile" commands that I can't identify. 
2. At 11:07:00 AM the EISY receives a valid Rest command to turn OFF device 40.16.5C (highlighted RED)
3.  The Violet Entries are the ISY/PLM/Device communicating the OFF command sequence.
4. The green entry is the ISY summarizing the OFF command communication.  Good news is that you have very good communication to this device.

When I suggested disconnecting the EISY, I was proposing disconnecting it from your network (RJ45 network connector) not the PLM.  This was intended to be easier then powering down the EISY completely.  It would allow your programs and other EISY events to run while eliminating Rest commands. 

 

un 10/12/2025 11:00:42 AM : Create REST U7 [/rest/profiles/ns/0/connection]

Sun 10/12/2025 11:05:32 AM : Create REST U7 [/rest/profiles/ns/0/connection]

Sun 10/12/2025 11:05:44 AM : Create REST U7 [/rest/profiles/ns/0/connection]

Sun 10/12/2025 11:07:00 AM : Create REST U7 [/rest/nodes/40%2016%205C%201/cmd/DOF]

Sun 10/12/2025 11:07:00 AM : U7 Rest:  submitCmd([40 16 5C 1],[DOF],[<NULL>])

Sun 10/12/2025 11:07:00 AM : [INST-TX-I1  ] 02 62 40 16 5C 0F 13 00

Sun 10/12/2025 11:07:00 AM : [INST-ACK    ] 02 62 40.16.5C 0F 13 00 06          LTOFFRR(00)

Sun 10/12/2025 11:07:00 AM : [INST-SRX    ] 02 50 40.16.5C 48.EC.F5 2F 13 00    LTOFFRR(00)

Sun 10/12/2025 11:07:00 AM : [Std-Direct Ack] 40.16.5C-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

1 hour ago, someguy said:

I’m having a similar problem: my bathroom light goes on at random times in the middle of the night (which wakes me up). 
 

I recently upgraded to Eisy, I’m on 6.0.0 and I also upgraded to “Alexa plus”.  I’ve been following this thread to see what @jlloyd_UD figures out. 
 

i will run my event viewer at night at some point and see if i can figure out “who” is to blame.  
 

I have a comment for @IndyMike:  if I just go into the portal and remove a device from the Amazon echo list, does it instantly remove the echo/alexa control of that device?  I’m thinking not.  I’ve had many devices that have duplicates and many challenges with trying to remove these duplicate devices. 

@someguy, please do post any event viewer info that appears pertinent.  

Unfortunately, I am not knowledgeable on the Alexa control/integration.  I am simply reading the event viewer logs and interpreting what the EISY is receiving. 

@Geddy had earlier posted a link pertaining to the Amazon Integration. 

1 hour ago, IndyMike said:

@jlloyd_UD, Resetting your switches will not help.  Base on your event viewer, they are responding to valid communications from the PLM/EISY.  

When I suggested disconnecting the EISY, I was proposing disconnecting it from your network (RJ45 network connector) not the PLM.  This was intended to be easier then powering down the EISY completely.  It would allow your programs and other EISY events to run while eliminating Rest commands. 

I thought the same about resetting the switches, but I was not sure. I am glad to hear the switches are properly responding to the mysterious origin rest (reset) commands. I determined that simply air gapping the switch probably disables comm but it also disables the capability of physically using the rocker to turn on/off the connected light! It places a permanent air gap in the physical wiring.

To be clear, disconnecting the eisy from the plm means removing (one end or the other) the special USB-RJ45 serial cable?  I presume it only needs to be connected if I add new devices, change settings on switches, add scenes or programming?  If so, that is good as I was fearing too much wear and tear on the small USB female power connector on the eisy. It is mechanically not overly robust and probably not something I want failing.

3 minutes ago, jlloyd_UD said:

I thought the same about resetting the switches, but I was not sure. I am glad to hear the switches are properly responding to the mysterious origin rest (reset) commands. I determined that simply air gapping the switch probably disables comm but it also disables the capability of physically using the rocker to turn on/off the connected light! It places a permanent air gap in the physical wiring.

To be clear, disconnecting the eisy from the plm means removing (one end or the other) the special USB-RJ45 serial cable?  I presume it only needs to be connected if I add new devices, change settings on switches, add scenes or programming?  If so, that is good as I was fearing too much wear and tear on the small USB female power connector on the eisy. It is mechanically not overly robust and probably not something I want failing.

Oops. Disconnecting that cable negates the use of the Alexa portal (spokens). Maybe that is a solution for when I go to bed after putting all Alexa-linked devices to sleep. It's one small step better than unhooking the more fragile power connector; it would put wear and tear on connectors, as it needs to be done each night, and does not resolve the fundamental problem of the generation of unwanted reset commands originating from who knows where.

You can shut down/disable the eisy by pressing the button on the front until the led turns red, no need to unplug anything

Pulling out the set button on a device disconnects the a/c power to the device.

4 hours ago, jlloyd_UD said:

Oops. Disconnecting that cable negates the use of the Alexa portal (spokens). Maybe that is a solution for when I go to bed after putting all Alexa-linked devices to sleep. It's one small step better than unhooking the more fragile power connector; it would put wear and tear on connectors, as it needs to be done each night, and does not resolve the fundamental problem of the generation of unwanted reset commands originating from who knows where.

Correct - this was intended as a stopgap/troubleshooting step until you resolved the root cause.  It allows programs and schedules to run on the EISY while preventing Rest commands.

I would not call the RJ45 network connection fragile, but agree you would not want to disconnect/re-connect as a long term solution.  If you are concerned about this, most routers allow you to "pause" a network connection to specific devices.  

Either way, it's far better than continuously performing power cycles on the EISY. 

2 hours ago, Techman said:

You can shut down/disable the eisy by pressing the button on the front until the led turns red, no need to unplug anything

Pulling out the set button on a device disconnects the a/c power to the device.

Thanks, my eisy came with a card with a QR code on it. I opened it and found nothing similar to an instruction pamphlet, but you are correct. If one looks closely at that tiny blue LED button on the front panel of the eisy, one will see that it illuminates a silhouette of a power switch symbol.  Like you said, if you press and hold it, the LED turns red but does not power down the eisy.  By the way, that button is called a multi-function button, and it has 6 functions depending on how many times it is pressed, according to https://www.universal-devices.com/eisy (there is no depiction of the eisy and description for the location of switch buttons or ports). To shut down the eisy, the button has to be depressed 6 times. Now I am concerned about eventual wearout on that button!  🙂 I am not sure what depressing the button once does.

There has to be a solution that renders my system functional once again.  Maybe the next firmware version update will resolve it?

Also, I saw elsewhere that the term "plug-in" replaced the term "node server."  It's "magic" reading the wiki.

10 hours ago, jlloyd_UD said:

There has to be a solution that renders my system functional once again.

The log available via "Tools->Error Log" should be able to tell you the IP address of whatever device is sending the random "rest" commands.  After you save it, open it with a text editor and use the date/time to find the ON command that arrived via a "rest" command and the line above should show you the IP address of the device that sent the command.  Here's an example of when I used a "rest" command from the browser of my desktop to get the value of one of my state variables.

Mon 2025/10/13 06:32:58 AM      0       -170001 [HTTP:6-9] ::ffff:192.168.2.166:2259->64288
Mon 2025/10/13 06:32:58 AM      0       -170001 [HTTP:6-9]: GET-->/rest/vars/get/2/25
Mon 2025/10/13 06:32:58 AM      0       -170001 [HTTP:6-9] Closing socket normally

 

okay, my light went on at around 5am, for unknown reason. here is a snip from my log. does this tell anyone why it turned on? the light that turned on was: 48.15.F2. also: my PLM is 71.17.AC by the way.

Mon 10/13/2025 04:59:20 : U7 Rest:  submitCmd([48 15 F2 1],[DON],[<NULL>])
Mon 10/13/2025 04:59:20 : [INST-TX-I1  ] 02 62 48 15 F2 0F 11 CC
Mon 10/13/2025 04:59:20 : [INST-ACK    ] 02 62 48.15.F2 0F 11 CC 06          LTONRR (CC)
Mon 10/13/2025 04:59:20 : [INST-SRX    ] 02 50 48.15.F2 71.17.AC 2F 11 CC    LTONRR (CC)
Mon 10/13/2025 04:59:20 : [Std-Direct Ack] 48.15.F2-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 10/13/2025 04:59:20 : [D2D EVENT       ] Event [48 15 F2 1] [ST] [204] uom=100 prec=0
Mon 10/13/2025 04:59:20 : [48 15 F2 1      ]            ST 204 (uom=100 prec=0)
Mon 10/13/2025 04:59:20 : [D2D-CMP 000B] STS [48 15 F2 1] ST Converted values Event=80 Condition=80 prec=0

I appreciate any help.

9 minutes ago, someguy said:

okay, my light went on at around 5am, for unknown reason. here is a snip from my log. does this tell anyone why it turned on? the light that turned on was: 48.15.F2. also: my PLM is 71.17.AC by the way.

Mon 10/13/2025 04:59:20 : U7 Rest:  submitCmd([48 15 F2 1],[DON],[<NULL>])
Mon 10/13/2025 04:59:20 : [INST-TX-I1  ] 02 62 48 15 F2 0F 11 CC
Mon 10/13/2025 04:59:20 : [INST-ACK    ] 02 62 48.15.F2 0F 11 CC 06          LTONRR (CC)
Mon 10/13/2025 04:59:20 : [INST-SRX    ] 02 50 48.15.F2 71.17.AC 2F 11 CC    LTONRR (CC)
Mon 10/13/2025 04:59:20 : [Std-Direct Ack] 48.15.F2-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 10/13/2025 04:59:20 : [D2D EVENT       ] Event [48 15 F2 1] [ST] [204] uom=100 prec=0
Mon 10/13/2025 04:59:20 : [48 15 F2 1      ]            ST 204 (uom=100 prec=0)
Mon 10/13/2025 04:59:20 : [D2D-CMP 000B] STS [48 15 F2 1] ST Converted values Event=80 Condition=80 prec=0

I appreciate any help.

The post just above yours describes how you might be able to determine where the 'on' signal came from. Take a look at that.

58 minutes ago, someguy said:

okay, my light went on at around 5am, for unknown reason. here is a snip from my log. does this tell anyone why it turned on? the light that turned on was: 48.15.F2. also: my PLM is 71.17.AC by the way.

Mon 10/13/2025 04:59:20 : U7 Rest:  submitCmd([48 15 F2 1],[DON],[<NULL>])
Mon 10/13/2025 04:59:20 : [INST-TX-I1  ] 02 62 48 15 F2 0F 11 CC
Mon 10/13/2025 04:59:20 : [INST-ACK    ] 02 62 48.15.F2 0F 11 CC 06          LTONRR (CC)
Mon 10/13/2025 04:59:20 : [INST-SRX    ] 02 50 48.15.F2 71.17.AC 2F 11 CC    LTONRR (CC)
Mon 10/13/2025 04:59:20 : [Std-Direct Ack] 48.15.F2-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Mon 10/13/2025 04:59:20 : [D2D EVENT       ] Event [48 15 F2 1] [ST] [204] uom=100 prec=0
Mon 10/13/2025 04:59:20 : [48 15 F2 1      ]            ST 204 (uom=100 prec=0)
Mon 10/13/2025 04:59:20 : [D2D-CMP 000B] STS [48 15 F2 1] ST Converted values Event=80 Condition=80 prec=0

I appreciate any help.

Hey Someguy,

The 48.15.F2 device is absolutely being turned on by a Rest command. An external device is instructing your EISY to turn on the device. Where the command originated from I can't tell you. @kclenden posted a method above on how to interrogate the Error log file to find the IP address of the sender.

Aside from that, all of the commands that I've seen posted are device direct commands. In other words the commands are targeting specific device addresses (no scenes). I am not a Alexa user. I am not sure whether that information helps.

here is the info from the error log for the same time. my light went on, according to the event log at "Monday 10/13/2025 04:59:20".

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5]

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5]: GET-->/rest/ns/1/nodes/n001_87521/report/status/CLITEMP/67

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5]: GET-->/rest/ns/1/nodes/n001_87521/report/status/HEATIX/67.

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5]: GET-->/rest/ns/1/nodes/n001_87521/report/status/WINDCH/67.

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5]: GET-->/rest/ns/1/nodes/n001_87521/report/status/CLIHUM/87.

Mon 2025/10/13 04:59:00 0 -170001 [HTTP:8-5] Closing socket normally

Mon 2025/10/13 04:59:02 0 -170001 [HTTP:7-5] ??J

Mon 2025/10/13 04:59:02 0 -170001 [HTTP:7-5]: GET-->/rest/ns/14/nodes/n014_controller/report/status/ST/1

Mon 2025/10/13 04:59:02 0 -170001 [HTTP:7-5] Closing socket normally

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_controller/report/cmd/DON

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_t531672041584/report/status/S

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_t531672041584/report/status/V

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_t531672041584/report/status/C

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_t531672041584/report/status/G

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_rs_j46n/report/status/ST/68.8

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_rs_f9s2/report/status/ST/69.7

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_rs_8qcz/report/status/ST/68.9

Mon 2025/10/13 04:59:04 0 -170001 [HTTP:9-5] Closing socket normally

Mon 2025/10/13 04:59:43 0 -170001 [HTTP:8-5]

Does this tell us "who" turned on the light?

10 hours ago, someguy said:

Does this tell us "who" turned on the light?

Sort of.

10 hours ago, someguy said:

Mon 2025/10/13 04:59:03 0 -170001 [HTTP:9-5]: GET-->/rest/ns/10/nodes/n010_controller/report/cmd/DON

That is the only command in the lines that you posted. All the other lines are status updates. I think the fact that it doesn't show an IP address means it wasn't an external device that issued the command, but rather something running on your ISY/Polisy/eISY. I'm not really fluent in node servers (or whatever they're called now), but the line seems to indicate that whatever plugin is in slot 10 of your Polyglot3 setup is involved. If you launch Polyglot V3 and go to the "Dashboard", look for the plug-in that ends in (10).

Updated:

You can also find out what's in slot #10 via "Plugins->Configure->[01] to [20]->[10]..."

Edited October 16Oct 16 by kclenden
Added different method to lookup plugin slot

I am still working on this, in my spare time. I am still finding devices turned on when ISY thinks they are off. This has been happening for years, really. I previously figured that my ISY/Polisy/Eisy this was just a communication issue: the ISY would try to turn the device off and the device just didn't get the message. I am now noticing that they are on when it seems that no one (and no program) actually turned them on. as I look into this further, I find that they are all similar devices with similar Insteon Addresses:

of note, the one called "BB Fan" is one that I swapped to a new switch and it hasn't happened since. My current thought is that something is sending an on to them and I haven't been able to confirm what it is yet. I theorize that it is an alexa, but I also wonder, although seemingly extremely unlikely, that it could be a miscommunication through the REST system. the reason I believe this is because of the similarity of their addresses.

I made some programs to occasionally check the devices for being on when the Eisy thinks they are actually off and then I'll look in the "Error Log" as suggested above by @kclenden and see what I can figure out.

any other thoughts?

1 hour ago, someguy said:

I am still working on this, in my spare time. I am still finding devices turned on when ISY thinks they are off. This has been happening for years, really. I previously figured that my ISY/Polisy/Eisy this was just a communication issue: the ISY would try to turn the device off and the device just didn't get the message. I am now noticing that they are on when it seems that no one (and no program) actually turned them on. as I look into this further, I find that they are all similar devices with similar Insteon Addresses:

of note, the one called "BB Fan" is one that I swapped to a new switch and it hasn't happened since. My current thought is that something is sending an on to them and I haven't been able to confirm what it is yet. I theorize that it is an alexa, but I also wonder, although seemingly extremely unlikely, that it could be a miscommunication through the REST system. the reason I believe this is because of the similarity of their addresses.

I made some programs to occasionally check the devices for being on when the Eisy thinks they are actually off and then I'll look in the "Error Log" as suggested above by @kclenden and see what I can figure out.

any other thoughts?

My kneejerk reaction is that this is (again) alexa commanding your devices on using the rest interface. The event viewer posts that you have made showed a rest command instructing the EISY to turn on the device @48.15.F2. That's a very specific device direct command. If this is still occurring, you should be able to view with the event viewer and the EISY log.

I am not Alexa knowledgeable. It's possible that when you upgraded your BB Fan device you also eliminated the link in Alexa.

I do use the rest interface extensively between my ISY994 and Home Assistant. I have not seen problems with miscommunication and am not sure what that would look like.

My last comment relates to the age of your Insteon devices. The are older Icon powerline only devices (I still have several). I did get tripped up a while ago by a light that began responding to an X10 command (2876S V.28 Device). I still have some X10 floods that activate and announce motion. My driveway flood began turning the icon device on/off. The ISY994 was completely blind to this. A factory reset/restore eliminated the X10 address in the switch.

The ISY does not (to my knowledge) give us a way to check whether devices have X10 addresses programmed. It's kind of a blind spot and the reason that I bring it up. For years protocol dictated that you factory reset every device out of the box to prevent X10 addresses that might exist from factory programming.

Having said the above, it would be extremely unlikely that you happen to have 4 icon devices with X10 addresses programmed. If you suspect this is the case, let us know. They are ways of testing using x10 all-on house codes.

That sounds correct. The ISY will not show an X10 address in a module. If there is an X10 command it should show in the log or if active in the Event Viewer.

22 hours ago, someguy said:

I am still finding devices turned on when ISY thinks they are off. This has been happening for years, really. I previously figured that my ISY/Polisy/Eisy this was just a communication issue: the ISY would try to turn the device off and the device just didn't get the message. I am now noticing that they are on when it seems that no one (and no program) actually turned them on. as I look into this further, I find that they are all similar devices with similar Insteon Addresses

22 hours ago, someguy said:

My current thought is that something is sending an on to them and I haven't been able to confirm what it is yet.

Does it seem like you're seeing these devices be randomly On more often now that you're using an eISY than when you were using an ISY?

Since switching from an ISY to an eISY I have been having significantly more All-On events and some All-Off events. I actually captured two instances of an All-On event and one instance of an All-Off event in an Event Viewer Log. In all three cases, what I saw was the eISY send the correct message to the PLM, but the PLM echo back a corrupted message where the FLAGS portion of the message had been changed from a Direct message to a Broadcast message. Besides causing All-On / All-Off events, messages corrupted by the PLM could cause individual devices to randomly go On / Off.

Because of that learning, I wrote a program to scan through Event Viewer logs to check for instances where the message echoed back from the PLM did not match what was sent by the eISY. An Event Viewer log that I recently created over 7 days shows 71 instances of mismatched messages. That's not as bad as it looks because the eISY can send multiple messages to the PLM before receiving an acknowledgement so some of those 71 instances are merely the fact that my program isn't yet sophisticated enough to match up acknowledgements that come back out of order. However, a quick scan through the mismatches would seem to indicate that at least 50% are true mismatches. I plan to enhance my program so that it can handle out of order acknowledgements and not report them as mismatches.

Not knowing whether these mismatches are being caused by the eISY or the PLM, I found an Event Viewer Log that spanned 7 days from Sept 2020 when I was still using an ISY. Running my scanner against that file only showed 10 mismatches, of which 5 were actual mismatches. This is relevant for multiple reasons:

• The Event Viewer log was created by a different hub (ISY vs eISY) using a different PLM

• The number of mismatches from the eISY log is roughly 7X more than the eISY log which matches my observational experience of an increase in All-On events since using the eISY

• If there really is an increase in mismatches when using the eISY vs the ISY, it could indicate that the speed of the device sending messages to the PLM is a contributing factor, and that the path to a solution lies in the communication code that sends messages from the ISY/Polisy/eISY to the PLM

• If these mismatches really are errors, the ISY/Polisy/eISY should track and report them

• Both PLMs that I used to create the Event Viewer logs are Serial devices. It would be very helpful to be able to scan an Event Viewer log that was created using an USB PLM.

All of the above is based on my understanding that when the ISY/Polisy/eISY sends a message to the PLM, the PLM should echo that message back exactly with just an "06" appended. If my understanding isn't correct, then everything above is garbage.

I'm interested in your thoughts. I will be collecting more Event Viewer Logs from my system to try to really quantify the number of times the PLM echoes back a corrupted message. While I think my reasoning is sound that having scanned a log created by an eISY with a new PLM, and one from an ISY with an old PLM means that my hardware is not at fault, perhaps I am missing something. With that in mind, eventually I'm hoping to enlist some of you to capture an Event Viewer log over several days and then either send it to me to scan, or use my program to scan it yourself. If we acquire enough data to indicate that something weird is going on with the communication between the ISY/Polisy/eISY and the PLM, then we can submit it to UD in hopes that it will allow them to track down the root cause.

31 minutes ago, kclenden said:

Does it seem like you're seeing these devices be randomly On more often now that you're using an eISY than when you were using an ISY?

Since switching from an ISY to an eISY I have been having significantly more All-On events and some All-Off events. I actually captured two instances of an All-On event and one instance of an All-Off event in an Event Viewer Log. In all three cases, what I saw was the eISY send the correct message to the PLM, but the PLM echo back a corrupted message where the FLAGS portion of the message had been changed from a Direct message to a Broadcast message. Besides causing All-On / All-Off events, messages corrupted by the PLM could cause individual devices to randomly go On / Off.

Because of that learning, I wrote a program to scan through Event Viewer logs to check for instances where the message echoed back from the PLM did not match what was sent by the eISY. An Event Viewer log that I recently created over 7 days shows 71 instances of mismatched messages. That's not as bad as it looks because the eISY can send multiple messages to the PLM before receiving an acknowledgement so some of those 71 instances are merely the fact that my program isn't yet sophisticated enough to match up acknowledgements that come back out of order. However, a quick scan through the mismatches would seem to indicate that at least 50% are true mismatches. I plan to enhance my program so that it can handle out of order acknowledgements and not report them as mismatches.

Not knowing whether these mismatches are being caused by the eISY or the PLM, I found an Event Viewer Log that spanned 7 days from Sept 2020 when I was still using an ISY. Running my scanner against that file only showed 10 mismatches, of which 5 were actual mismatches. This is relevant for multiple reasons:

• The Event Viewer log was created by a different hub (ISY vs eISY) using a different PLM

• The number of mismatches from the eISY log is roughly 7X more than the eISY log which matches my observational experience of an increase in All-On events since using the eISY

• If there really is an increase in mismatches when using the eISY vs the ISY, it could indicate that the speed of the device sending messages to the PLM is a contributing factor, and that the path to a solution lies in the communication code that sends messages from the ISY/Polisy/eISY to the PLM

• If these mismatches really are errors, the ISY/Polisy/eISY should track and report them

• Both PLMs that I used to create the Event Viewer logs are Serial devices. It would be very helpful to be able to scan an Event Viewer log that was created using an USB PLM.

All of the above is based on my understanding that when the ISY/Polisy/eISY sends a message to the PLM, the PLM should echo that message back exactly with just an "06" appended. If my understanding isn't correct, then everything above is garbage.

I'm interested in your thoughts. I will be collecting more Event Viewer Logs from my system to try to really quantify the number of times the PLM echoes back a corrupted message. While I think my reasoning is sound that having scanned a log created by an eISY with a new PLM, and one from an ISY with an old PLM means that my hardware is not at fault, perhaps I am missing something. With that in mind, eventually I'm hoping to enlist some of you to capture an Event Viewer log over several days and then either send it to me to scan, or use my program to scan it yourself. If we acquire enough data to indicate that something weird is going on with the communication between the ISY/Polisy/eISY and the PLM, then we can submit it to UD in hopes that it will allow them to track down the root cause.

My random lights on (not All ON, but 5 or 6 lights randomly) started only after recently upgrading my isy994 to an eisy, and then not immediately. It seemed to start after I "upgraded" Google Alexa to a "smarter" version. I reversed the upgrade to Alexa without any change in the "individual lights on randomly" case. I have resorted these past few weeks to unplugging my eisy from the network while asleep at night to stop the seemingly random and unprovoked, by me, command activity. Initially, commenters suggested my PLM was approaching the "end of life," but the situation with Alexa, if not totally coincidental, has me wondering. I want to get to the root cause, but I am not proficient in tracing individual commands. My eisy seems to work properly otherwise. My Alexa also responds to vocals like it should. I use it to shut off the errant lighting when it happens, but it annoys me to have to do that every 30 minutes or more often throughout the day. I have a serial PLM that worked perfectly with the isy994, so I don't want to "throw parts" at the problem yet. I have already purchased the special serial cable to retrofit the old serial PLM. The PLM is around 8 years old. What can I do to help you pursue your plan to isolate the source of this problem so it can be resolved? I can certainly send you the logs and the duration of logging you need to troubleshoot.

1 hour ago, kclenden said:

Does it seem like you're seeing these devices be randomly On more often now that you're using an eISY than when you were using an ISY?

Since switching from an ISY to an eISY I have been having significantly more All-On events and some All-Off events. I actually captured two instances of an All-On event and one instance of an All-Off event in an Event Viewer Log. In all three cases, what I saw was the eISY send the correct message to the PLM, but the PLM echo back a corrupted message where the FLAGS portion of the message had been changed from a Direct message to a Broadcast message. Besides causing All-On / All-Off events, messages corrupted by the PLM could cause individual devices to randomly go On / Off.

Wow - that is exactly what I've been theorizing was occurring at the PLM serial interface. It didn't seem logical that a powerline collision could reproduce the proper bit coding/timing/and checksums. A collision at the serial interface has far fewer checks and balances. Alas, I have never actually seen this in the event viewer (don't have a EISY).

I would love to see any examples of echo back errors that you may have. I have not had any All-on events for some time, but I have been adding delays and eliminating Insteon Motion sensors tying to make the system more reliable. I would be willing to take things in the opposite direction to actively try to break the system in order to troubleshoot.

On 10/26/2025 at 5:07 AM, kclenden said:

I actually captured two instances of an All-On event and one instance of an All-Off event in an Event Viewer Log. In all three cases, what I saw was the eISY send the correct message to the PLM, but the PLM echo back a corrupted message where the FLAGS portion of the message had been changed from a Direct message to a Broadcast message. Besides causing All-On / All-Off events, messages corrupted by the PLM could cause individual devices to randomly go On / Off.

Hello Kclended,

Could you please post an example of your capture where you see the corrupted echo?

Out of curiosity, how log is your cable from eISY to the PLM?

2 hours ago, ELA said:

Could you please post an example of your capture where you see the corrupted echo?

Here's the output from the log scanner that I wrote when run against a six day period Event Viewer Log. The last mismatch shown actually caused an All Off event. What is listed is the actual Event Viewer Log lines prefaced by the log line # so that you can easily go to the corresponding line in the log file (which I've attached).

1683 Thu 10/09/2025 05:02:50 AM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
1685 Thu 10/09/2025 05:02:50 AM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
1687 Thu 10/09/2025 05:02:50 AM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
1689 Thu 10/09/2025 05:02:50 AM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
1691 Thu 10/09/2025 05:02:50 AM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
1693 Thu 10/09/2025 05:02:50 AM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
1695 Thu 10/09/2025 05:02:50 AM : [INST-ACK    ] 02 62 00.00.20 00 13 00 06          LTOFFRR(00)

4111 Thu 10/09/2025 12:10:00 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
4113 Thu 10/09/2025 12:10:00 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
4115 Thu 10/09/2025 12:10:00 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
4117 Thu 10/09/2025 12:10:00 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
4119 Thu 10/09/2025 12:10:00 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
4121 Thu 10/09/2025 12:10:00 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
4123 Thu 10/09/2025 12:10:00 PM : [INST-ACK    ] 02 62 00.00.20 CF 00 00 06                 (00)

4435 Thu 10/09/2025 12:53:35 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
4437 Thu 10/09/2025 12:53:35 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
4439 Thu 10/09/2025 12:53:35 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
4441 Thu 10/09/2025 12:53:35 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
4443 Thu 10/09/2025 12:53:35 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
4445 Thu 10/09/2025 12:53:35 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
4447 Thu 10/09/2025 12:53:35 PM : [INST-ACK    ] 02 62 00.00.13 00 13 00 06          LTOFFRR(00)

17351 Fri 10/10/2025 07:14:08 AM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
17353 Fri 10/10/2025 07:14:08 AM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
17355 Fri 10/10/2025 07:14:08 AM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
17357 Fri 10/10/2025 07:14:08 AM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
17359 Fri 10/10/2025 07:14:08 AM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
17361 Fri 10/10/2025 07:14:08 AM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
17363 Fri 10/10/2025 07:14:08 AM : [INST-ACK    ] 02 62 20.CF.13 00 13 00 06          LTOFFRR(00)

23301 Fri 10/10/2025 09:49:33 PM : [INST-TX-I1  ] 02 62 00 00 1B CF 11 00
23303 Fri 10/10/2025 09:49:33 PM : [LINK-INFO       ] Link for responder 22 8B F1 2 not found
23305 Fri 10/10/2025 09:49:33 PM : [LINK-INFO       ] Link for responder 23 B3 D4 1 not found
23307 Fri 10/10/2025 09:49:33 PM : [LINK-INFO       ] Link for responder 23 BB 88 1 not found
23309 Fri 10/10/2025 09:49:33 PM : [LINK-INFO       ] Link for responder 23 B3 A2 1 not found
23311 Fri 10/10/2025 09:49:33 PM : [LINK-INFO       ] Link for responder 24 A3 6A 1 not found
23313 Fri 10/10/2025 09:49:33 PM : [INST-ACK    ] 02 62 00.00.1B 00 11 00 06          LTONRR (00)

32277 Sat 10/11/2025 05:27:05 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
32279 Sat 10/11/2025 05:27:05 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
32281 Sat 10/11/2025 05:27:05 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
32283 Sat 10/11/2025 05:27:05 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
32285 Sat 10/11/2025 05:27:05 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
32287 Sat 10/11/2025 05:27:06 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
32289 Sat 10/11/2025 05:27:06 PM : [INST-ACK    ] 02 62 20.CF.13 00 13 00 06          LTOFFRR(00)

32753 Sat 10/11/2025 05:35:23 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
32755 Sat 10/11/2025 05:35:23 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
32757 Sat 10/11/2025 05:35:23 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
32759 Sat 10/11/2025 05:35:23 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
32761 Sat 10/11/2025 05:35:23 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
32763 Sat 10/11/2025 05:35:23 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
32765 Sat 10/11/2025 05:35:23 PM : [INST-ACK    ] 02 62 00.CF.13 00 13 00 06          LTOFFRR(00)

65617 Mon 10/13/2025 11:20:29 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
65619 Mon 10/13/2025 11:20:29 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
65621 Mon 10/13/2025 11:20:29 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
65623 Mon 10/13/2025 11:20:29 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
65625 Mon 10/13/2025 11:20:29 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
65627 Mon 10/13/2025 11:20:29 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
65629 Mon 10/13/2025 11:20:29 PM : [INST-ACK    ] 02 62 20.CF.13 00 13 00 06          LTOFFRR(00)

70855 Tue 10/14/2025 06:52:57 AM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
70857 Tue 10/14/2025 06:52:57 AM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
70859 Tue 10/14/2025 06:52:57 AM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
70861 Tue 10/14/2025 06:52:57 AM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
70863 Tue 10/14/2025 06:52:57 AM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
70865 Tue 10/14/2025 06:52:57 AM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
70867 Tue 10/14/2025 06:52:57 AM : [INST-ACK    ] 02 62 00.CF.13 00 13 00 06          LTOFFRR(00)

72313 Tue 10/14/2025 03:21:45 PM : [INST-TX-I1  ] 02 62 00 00 20 CF 13 00
72315 Tue 10/14/2025 03:21:45 PM : [LINK-INFO       ] Link for responder 20 77 13 1 not found
72317 Tue 10/14/2025 03:21:45 PM : [LINK-INFO       ] Link for responder 20 85 C3 1 not found
72319 Tue 10/14/2025 03:21:45 PM : [LINK-INFO       ] Link for responder 22 AD 9A 1 not found
72321 Tue 10/14/2025 03:21:45 PM : [LINK-INFO       ] Link for responder 4D D3 B1 1 not found
72323 Tue 10/14/2025 03:21:45 PM : [LINK-INFO       ] Link for responder 4F 84 D8 1 not found
72325 Tue 10/14/2025 03:21:45 PM : [INST-ACK    ] 02 62 00.00.20 00 13 00 06          LTOFFRR(00)

74689 Tue 10/14/2025 06:05:15 PM : [INST-TX-I1  ] 02 62 00 00 2A CF 13 00
74691 Tue 10/14/2025 06:05:15 PM : [INST-ACK    ] 02 62 00.CF.13 00 11 00 06          LTONRR (00)

76515 Tue 10/14/2025 08:43:16 PM : [INST-TX-I1  ] 02 62 00 00 1B CF 11 00
76517 Tue 10/14/2025 08:43:16 PM : [LINK-INFO       ] Link for responder 22 8B F1 2 not found
76519 Tue 10/14/2025 08:43:16 PM : [LINK-INFO       ] Link for responder 23 B3 D4 1 not found
76521 Tue 10/14/2025 08:43:16 PM : [LINK-INFO       ] Link for responder 23 BB 88 1 not found
76523 Tue 10/14/2025 08:43:16 PM : [LINK-INFO       ] Link for responder 23 B3 A2 1 not found
76525 Tue 10/14/2025 08:43:16 PM : [LINK-INFO       ] Link for responder 24 A3 6A 1 not found
76527 Tue 10/14/2025 08:43:16 PM : [INST-ACK    ] 02 62 00.CF.11 00 11 00 06          LTONRR (00)

76609 Tue 10/14/2025 10:19:39 PM : [INST-TX-I1  ] 02 62 00 00 29 CF 11 00
76611 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 22 8B F1 2 not found
76613 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 23 B3 D4 1 not found
76615 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 23 BB 88 1 not found
76617 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 23 AF 3D 1 not found
76619 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 23 B3 A2 1 not found
76621 Tue 10/14/2025 10:19:39 PM : [LINK-INFO       ] Link for responder 24 A3 6A 1 not found
76623 Tue 10/14/2025 10:19:39 PM : [VAR  2   25     ]       0
76625 Tue 10/14/2025 10:19:39 PM : [VAR  2   25     ]       302
76627 Tue 10/14/2025 10:19:39 PM : [INST-ACK    ] 02 62 00.11.00 CF 13 00 06          LTOFFRR(00)


Total Mismatches: 13  No Acks: 7  Matches: 429

The cable from my eISY to PLM is about four feet long. I've also scanned logs from when I was using an ISY, and while the mismatches are less frequent, they still appear. The cable between my ISY and PLM (different than the eISY PLM) was the one that came with the ISY.

ISY-Events-Log.v5.9.1__Wed 2025.10.15 12.32.50 AM.txt

Edited Monday at 05:51 PM2 days by kclenden
Answer cable length question

@kclenden , extremely interesting log. Thank you for posting. Very nice presentation with the line numbers to correlate things.

I don't want to take this thread sideways, so I'll try to be brief.

Observations:

1) I have never seen mismatches like this using my ISY994. You are, however, looking far harder than I have. I have been running the event viewer since your 1st post in an attempt to find mismatches.

2) I have never experienced the "LINK INFO" message using the ISY994. This may be a EISY only message. You seem to be highlighting these occurrences. Curious if you believe it's related.

3) I do see where the PLM incorrectly acknowledged a Group Broadcast OFF command to Group 00 (line76627). If you actually witnessed an All-Off that's kind of a smoking gun.

I am not sure if this is the infamous All-on/All-off from the past, or something new.

Edited yesterday at 12:35 AM1 day by IndyMike

Thank you for sharing your work kclenden,

This is very interesting. I have yet to upgrade to an eISY and have never seen such a thing with my ISY994.

The "link Info" messages are new to me, should they be of concern ?

Does not appear like any of the older All/ON , ALL/OFF issues from my experience.

It might be interesting to send the invalid message "02 62 00.11.00 CF 13 00" (A group broadcast to group zero to turn off) directly to the PLM to see how it responds.

If you were to open a ticket with UDI ... I would be curious what they think?

Edited Tuesday at 03:54 PM2 days by ELA

4 hours ago, IndyMike said:

I have never seen mismatches like this using my ISY994. You are, however, looking far harder than I have.

I had never noticed them while using my ISY either, but after creating a log scanner and running it against Event Viewer Logs from my ISY days, they are present, just at a lower frequency than with the eISY. In limited testing, the mismatches appear to have occurred roughly 1 out every 642 times on my ISY, so it's not too surprising that you'd miss them.

4 hours ago, IndyMike said:

I have never experienced the "LINK INFO" message using the ISY994. This may be a EISY only message. You seem to be highlighting these occurrences.

1 hour ago, ELA said:

The "link Info" messages are new to me, should they be of concern ?

I never saw "LINK INFO" tags when I was using an ISY. They just started with the eISY. They show up when a SCENE command is sent. They don't appear to harm anything as scenes react as expected. I've seen posts from other people on the forum asking about them, but no one ever posts an answer. I migrated from an ISY to an eISY so I don't know if they're an artifact of that, but I did try removing a device and readding it to the eISY and it had no effect on the "LINK INFO" that appears for it.

I'm not highlighting them. My scanner merely shows everything that appears in the log between the opening INST-TX-I1 and closing INST-ACK tags. I use a lot of scenes, so a high percentage of the communication between my eISY and PLM is scene commands. I think that's why they're prevalent in the log above, but I have seen eISY / PLM miscommunication in my logs for direct device commands as well.

4 hours ago, IndyMike said:

I do see where the PLM incorrectly acknowledged a Group Broadcast OFF command to Group 00 (line76627). If you actually witnessed an All-Off that's kind of a smoking gun.

I am not sure if this is the infamous All-on/All-off from the past, or something new.

Yes, I was sitting at my desk when it happened, so I'm sure that was the cause of the ALL-OFF. I have also physically witnessed an ALL-ON and have it captured in an Event Log as well. I'm also not sure if these are the infamous ALL-ON / OFF from the past, but since I do find mismatched communication in my old ISY Event Viewer logs, it seems like it could be a plausible theory.

2 hours ago, ELA said:

It might be interesting to send the invalid message "02 62 00.11.00 CF 13 00" (A group broadcast to group zero to turn off) directly to the PLM to see how it responds.

Eventually, I will get to that kind of experimentation . . .

2 hours ago, ELA said:

If you were to open a ticket with UDI ... I would be curious what they think?

Eventually, I will be opening a ticket with UDI and providing any info I have accumulated. I'm hoping to have log scans from more than just my setup. Hopefully other forum users will create Event Viewer logs and scan them. I'd definitely like to have someone that is using a USB PLM scan one of their logs.

I'm heading off on a two-week trip starting tomorrow, so realistically, I won't finish my analysis and open a ticket with UDI for at least a month.

4 hours ago, IndyMike said:

I have been running the even viewer since your 1st post in an attempt to find mismatches.

Happy to send you my program, with the usual caveat that it's not fully tested yet, and only runs under Windows. Of if you'd rather just send me your log, I can scan it and post the results.

Edited Tuesday at 06:10 PM1 day by kclenden