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.