@kclenden , thank you again for the information. I am currently writing a Python script to parse through the even viewer data. The differences between your EISY data and my ISY994 are significant. I have many instances where the ISY will issue multiple commands prior to receiving an ACK from the PLM. I am trying to implement logic to "look ahead" for proper ACK's. It's not easy (and I'm a python novice). My ISY instance hung today after roughly 50 hours. I have not seen a PLM ECHO error as yet. I will move the routine to another dedicated PC that will hopefully be able to run longer.

I appreciate the offer of providing your program. Please allow me some time to poke at this from my side. I see advantages in having multiple eyes/approaches to addressing the problem.

I should be able to test the invalid message sequence (02 62 00.11.00 CF 13 00) in the AM. I see no reason that this would not produce an ALL-OFF. I use the old Busyrat PLM tool to write command sequences to the PLM. I retired the old windows PC that had the tool installed. Resurrected the PC from dead storage a little while ago and verified the tool functionality. Will try executing the all off in the early AM so as not to upset family members (and the Boss).

12 minutes ago, IndyMike said:

The differences between your EISY data and my ISY994 are significant.

I've run my scanner against Event Viewer logs from both my eISY and my old ISY994. There were no differences in the layout of the log. So I'm curious what you're seeing that is significantly different.

13 minutes ago, IndyMike said:

I have many instances where the ISY will issue multiple commands prior to receiving an ACK from the PLM.

I have the same thing happen on my eISY. My scanner takes that into account and attempts to match up the proper ACK. As a failsafe, my scanner quits looking for an ACK after ten seconds and retires the INST-TX-I1 and marks it as a NoAck. This means that even if a barrage of communication causes confusion, the scanner will naturally get back into synch with INST-TX-I1 / INST-ACK pairs.

19 minutes ago, IndyMike said:

I see advantages in having multiple eyes/approaches to addressing the problem.

Agreed.

20 minutes ago, IndyMike said:

I should be able to test the invalid message sequence (02 62 00.11.00 CF 13 00) in the AM. I see no reason that this would not produce an ALL-OFF.

I'm actually surprised that it caused an ALL-OFF. My understanding is that devices are supposed to look at the "To Address", in this case 00.11.00, and only act on the message if it's addressed to them. Still, the CF byte indicates a standard group broadcast message so that must be the key.

If you're trying invalid message sequences, you might also try (02 62 0F.19.00 CF 11 00) which was one of my ALL-ON events. Ironically that is a corruption of this command (02 62 21 68 01 0F 19 00) which is a status request sent to my fan controller by the program that I wrote to detect ALL-ON events.

Edited October 29Oct 29 by kclenden

@kclenden , we have confirmation of the invalid sequence

1) 02 62 00 11 00 CF 13 00 was acknowledged by the PLM and turned all lights off (responders to group 00).

2) 02 62 00 11 00 CF 11 00 was acknowledged and turned all linked group 00 lights ON.

3) 02 62 0F 19 00 CF11 00 also acknowledge and turned all linked group 00 lights ON.

I used a spare PLM that had been factory reset. I used Houselinc to link 3 devices to the PLM (group 00). All three devices were older and had been previously identified as responders to the Insteon All-on command. The PLM was an older 2413UH version V1.5 Date Code 1123.

As far as the invalid format is concerned, the "Broadcast Group" command (message flag CF in the above) only considers the lower byte of the address since groups are limited to 00 to 255 (00 to FF). Group 00 is normally reserved for devices linked to the PLM. Group FF is defined as "all linked devices". I am not entirely sure how they differ.

I normally use group FF for my testing. Wasn't entirely sure whether group 00 would work. I was also not sure whether the extraneous data in the upper address bytes would be rejected by the PLM. They were not. I had never considered that the PLM might miss or swap entire bytes in my testing. Your data has been an eye opener.

The following is from page is from the "Insteon Whitepaper: The Details" version 2 - 2013 (page 21). I know you understand this information well. I am not trying to be insulting or pedantic. I am hoping that others may have the same Ah-Ha moment that I had when I saw your log.

We are now well off the track of the OP's original thread. This may be related to what @someguy is experiencing. I do not believe it is related to @jlloyd_UD 's issue which appears to be purely Alexa base. WE should either start a new thread or ask for his blessing to continue.

2 hours ago, IndyMike said:

We are now well off the track of the OP's original thread. This may be related to what @someguy is experiencing. I do not believe it is related to @jlloyd_UD 's issue which appears to be purely Alexa base. WE should either start a new thread or ask for his blessing to continue.

I am a neophyte when it comes to network concepts and lingo, but I understand at a basic level what is being done to troubleshoot. I have been dabbling with UD and Insteon for about a decade with some degree of achievement. I have enjoyed the back and forth, but if my troubles are Alexa-based, I have not heard anything that would allow me to correct/eliminate the random lights on situation. If someone has provided a suggestion or a solution, I apologize if I have missed it and would appreciate a few ideas on how to proceed. I have been commanding Alexa using "vocals" to turn off the uncommended lights when they (too frequently) happen and disconnecting my eisy from the lan during bedtime. It would be nice to return to normalcy! I would not mind closing this lengthy thread if I could obtain a solution that I can easily apply. My household has become too reliant on Alexa's vocal controls. 🙃

5 hours ago, jlloyd_UD said:

I am a neophyte when it comes to network concepts and lingo, but I understand at a basic level what is being done to troubleshoot. I have been dabbling with UD and Insteon for about a decade with some degree of achievement. I have enjoyed the back and forth, but if my troubles are Alexa-based, I have not heard anything that would allow me to correct/eliminate the random lights on situation. If someone has provided a suggestion or a solution, I apologize if I have missed it and would appreciate a few ideas on how to proceed. I have been commanding Alexa using "vocals" to turn off the uncommended lights when they (too frequently) happen and disconnecting my eisy from the lan during bedtime. It would be nice to return to normalcy! I would not mind closing this lengthy thread if I could obtain a solution that I can easily apply. My household has become too reliant on Alexa's vocal controls. 🙃

My opinion, but I don't think our current discussion in any way helps with your issue. I view this as a Alexa/rest issue and I am not qualified to help in the matter. I do very much hope that you find a quick resolution. If we continue our current discussion we will be diluting possible responses/solutions.

Edited October 29Oct 29 by IndyMike

6 hours ago, jlloyd_UD said:

if my troubles are Alexa-based, I have not heard anything that would allow me to correct/eliminate the random lights on situation.

I've lost track, but if each of your random ON has an associated REST command, then our deep dive into eISY / PLM communication will be of no help. If I recall correctly, your error log did not show a corresponding IP address which would seem to indicate a process internal to your eISY. Do you have any node servers loaded in PG3?

I would like to continue to try to solve (if possible) this problem as I still have devices occasionaly going on for no obvious reason. most of what you kind fellows are saying in this thread goes over my head, unfortunately. is there any way I can contribute to try to solve this problem? is running my "event viewer" on level 3 going to help me (us) any?

@someguy , I would be interested in seen your event viewer logs. I f you could run a couple of days worth we might get some additional insight.

Please also post the Insteon address of your problem devices.

Edited November 15Nov 15 by IndyMike

@someguy

Do you have any Insteon motion sensors installed?

Do the lights all come on at the same time?

If you look at your EISY log do you see any activity just before the light(s) come on

Do you have any older, non dual band insteon devices, in your system?

Do you have any power supplies plugged into your a/c outlets

Did you look at your program summany page to see if any programs ran at the time your light(s) came on?

@IndyMike I started my even viewer. I will only send it if I have an event occur, which happens about 2-3 times per week. my suspicion is that you'd just want the event viewer info surrounding the event.

@Techman questions answered:

yes, I have insteon motion sensors.

no, I haven't had an "all on" event happen in recent years.

my abnormal events are rare enough that it rarely is a witnessed event. I just come home and find something on when no one has been home and no program could have turned that device on.

yes, I have some older non dual-band insteon devices installed.

yes, I have power supplies plugged into some of my outletlincs (but those outletlincs haven't, to my knowledge, gone on (or off) in one of these events).

because I almost never know, exactly, when these events occur, I haven't been able to find a program that could be causing them.

@someguy , we'll use the event viewer information to try to eliminate external "Rest" commands and PLM serial communication errors that @kclenden posted about.

Since it sounds like this has been going on for some time, it appears to be different than the "Rest" event that you posted about earlier. Would you agree?

Have you tried looking though the ISY log for on/off events on your problem devices? Keep in mind that you are probably looking for communication errors with the problem devices. The ISY may be telling the device to turn off, but the device doesn't hear the command.

Edited November 16Nov 16 by IndyMike

I have just come across this thread. I have had this issue since the V3 Alexa skill upgrade AND re-adding the spokens through the portal. I kept getting the repetitive message from Alexa that after Nov 4th this device wont work unless V3 is put in place. Ive been doing trouble shooting by restoring devices, trying to figure out triggers, etc. This morning I removed the device that came on randomly from the the spokens in the portal. Havent had the issue since. I think it is an Alexa thing. Of course I cant use voice in this state.

I have a program running that checks to see if any of my offenders are on when ISY thinks they are off. I had three of my common offenders on at 8am yesterday. here is the log for the previous four hours.

the offenders are: 15.A6.B2, 71.C2.58, and 15.A2.CC

I don't see anywhere that these devices are being contacted by the system except at around 8am when I query them and then turn them off (with my program that does so).

ISY-Events-Log.v6.0.0__Tue 2025.11.18 17.53.56.txt

Hey Someguy, thanks for posting the data. This will take a little time to go through, but let me give you some feedback.

Positives:

• You have rather good communication with your devices, including the older ones.

• @kclenden and I had discussed communication errors between the PLM and Eisy. I don't see any evidence of that in your file. You had 240 I1 communications with 0 errors and 0 timeouts.

• While I see rest activity (seems to reoccur @5 min intervals) is doesn't seem to be directly associated with your switches. This doesn't seem to be Alexa related.

Your problem devices:

• I see where you query the devices @4 AM (they confirm off) and again @8 AM. Problem is they respond that they are off @8 AM. I would have expected that query to show them ON.

• I will agree that there are no direct commands to devices 15.A6.B2 and 15.A2.CC (Can't tell if they are part of a scene). There are many 2 off and fast off commands and "Beep" commands being sent to device 71.C2.58. The 1st beep command starts @5:01 am and the Off/f-off commands start @5:15:47 AM (Line number 8071).

• There are a number of scenes being turned on throughout. Can't tell if your problem devices are members.

• Your 15.A6.B2 and 15.A2.CC devices are rather old. They will probably respond to an Insteon All-on command.

• Your 71.C2.58 is rather new. It should NOT respond to the Insteon All-on command.

• There are no X10 transmissions in the log - no evidence of X10 noise causing problems.

Suggestions:

• Check to see what is issuing the beep/off/fast off commands to your 71.c2.58 device. This looks like a program.

• If your 3 problem devices are not members of any scenes, perform link table scans/compares on each. Factory reset/Restore if you see mismatches.

• If the device link tables check out, but they still respond during the night, It's possible that the Eisy data table is incorrect. In this case you'll need to delete/factory reset/re-add the devices.

Edited November 20Nov 20 by IndyMike

I don't know if there is any commonality here, but I too have recently started having lights randomly turn on. Started maybe a month ago. Checking programs, there are no programs showing as having run at those times. The involved lights are Insteon. I haven't changed my Insteon network in quite some time and the devices involved have had no changes in many years. It has happened maybe 4 times in the past month or so.

@IndyMike I do very much appreciate your help with this!

One of my three devices had a missing link in the link table but the device shows as "identical".

it is missing the "E2 01 71.17.AC..." link. I've had this problem with other devices in the past. To fix this, I'll remove the device and then re-add it and this should fix this problem.

None of my problematic devices are part of any scenes, by the way.

this doesn't explain why these devices are turning on for no reason. any more thoughts? is it possible that they are just old switches that somehow go on for no reason? seems unlikely to me.

30 minutes ago, someguy said:

@IndyMike I do very much appreciate your help with this!

One of my three devices had a missing link in the link table but the device shows as "identical".

it is missing the "E2 01 71.17.AC..." link. I've had this problem with other devices in the past. To fix this, I'll remove the device and then re-add it and this should fix this problem.

None of my problematic devices are part of any scenes, by the way.

this doesn't explain why these devices are turning on for no reason. any more thoughts? is it possible that they are just old switches that somehow go on for no reason? seems unlikely to me.

@someguy , the "E2 01 71.17.AC" link is the one that allows your device to communicate back to the PLM when it is turned on locally. Without this the PLM will not receive ON/OFF status from the device.

To summarize, we've eliminated the following:

1. Eisy to PLM serial communication errors

2. Rest/Alexa commands to the devices

3. Program direct commands to the devices

4. Scene commands (your devices do not have links to support scene commands)

5. Random All On/All Off events - your 71.C2.58 device should not respond to the All-on/All-off command

In my mind that only leaves two options -

1. Local powerline disturbance that "tricks" the device into turning on. I have seen this on some Leviton devices, but never on Insteon. It's possible, but highly unlikely that it would turn on 3 devices of different vintages (totally different power supply designs). Are these devices all on the same circuit?

2. X10 susceptibility. Essentially the device receives a noise burst that resembles a valid X10 command. There were no X10 commands showing up in the event viewer, but X10 doesn't travel well through your powerlines or across phases. Possible the devices are seeing X10 "noise" that the PLM doesn't see. Older devices were sometimes received with X10 addresses programmed from the factory. It would be odd for your new device to have a X10 address programmed, but worth checking. A FACTORY Reset is required to remove the address.

On 10/28/2025 at 9:19 PM, kclenden said:

I've run my scanner against Event Viewer logs from both my eISY and my old ISY994. There were no differences in the layout of the log. So I'm curious what you're seeing that is significantly different.

I have the same thing happen on my eISY. My scanner takes that into account and attempts to match up the proper ACK. As a failsafe, my scanner quits looking for an ACK after ten seconds and retires the INST-TX-I1 and marks it as a NoAck. This means that even if a barrage of communication causes confusion, the scanner will naturally get back into synch with INST-TX-I1 / INST-ACK pairs.

Agreed.

I'm actually surprised that it caused an ALL-OFF. My understanding is that devices are supposed to look at the "To Address", in this case 00.11.00, and only act on the message if it's addressed to them. Still, the CF byte indicates a standard group broadcast message so that must be the key.

If you're trying invalid message sequences, you might also try (02 62 0F.19.00 CF 11 00) which was one of my ALL-ON events. Ironically that is a corruption of this command (02 62 21 68 01 0F 19 00) which is a status request sent to my fan controller by the program that I wrote to detect ALL-ON events.

I am the originator of this thread and am revisiting the string of comments to determine if anyone has suggested fix for my random lights. I see that at leat one person indicates with some degree of certainty that my reset commands are coming from Alexa. I do use Alexa extensively for vocally commanding my Insteon switches, and I am getting the random lights on on most all of the switches. I have used Instaon switches for a long time, and I have replaced several over the years with the newest versions as recently as several months ago. I have one keypad_linc relay v36 that is wonky and probably needs resetting. I do have a I upgraded to eisy and have the latest integration of Alexa installed. None of these random events happened until after I upgraded to eisy as my Alexa integration (ISY Portal Amazon Echo Integration v3) was running trouble-free until then (with the ISY994). I recently tried to troubleshoot by removing my Amazon hardware until none were powered on. It did not affect the random lighting... it happened as if nothing had changed. My eisy was connected through a switch, and I changed that to be directly connected to the modem. Nothing changed. So, how do I determine the source of the random resets thought to be from Alexa echo devices? I am thinking they are actually emanating from the eisy/PLM pairing but would like to exonerate this belief. Is it time to factory reset the Alexa integration? How? Will I need to rebuild the vocals? If it persists, do I factory reset my eisy? Will that require I rebuild all the links from zero base? I posted my problem on the Alexa forum. I received a response stating that it was beyond their skill and knowledge base to troubleshoot and fix, even after it was escalated to a higher level. It seemed like they did not want to deal with it. I was hoping there might be a version change to my eisy that would be a magic bullet, but so far, nothing. Most comments are beyond my skill level to fully understand. I am at a point where I remove the eisy when I go to bed and sometimes power back up in the morning, and deal with the random events by using my vocal commands to extinguish the lights. It seems like a neanderthal approach to dealing with this problem. . (My wife likes the automation but has resorted to using the manual switches when she wants the lights to be on or off. It negates the benefit of having home automation I would prefer not to have to rebuild my links, but maybe it is the only way forward unless someone has a better idea. I appreciate the forum's thoughts on resolving my problem. It seems several others are also experiencing random commands of the switches. I have filters on my lines. Maybe I need to reposition them? If anyone has a structured approach for tracing down the origins of these random events, I would appreciate the details. I have lost the full benefit of the investment I made in upgrading my controller back in August. Thank you to all who have contributed here. Happy holidays!

I have been commanding Alexa using "vocals" to turn off the uncommended lights when they (too frequently) happen and disconnecting my eisy from the lan during bedtime.

@jlloyd_UD , the last I remember you were able to stop the random on/off activity by unplugging the EISY from the Lan. In my mind that places to problem external to the EISY. Filters, resets, and restores of devices likely will not help.

My suggestion at this point would be to:

1. Nuke the Alexa/Portal integration

2. Verify (over days) that the problem has been resolved.

3. Add devices back to the Alexa integration SLOWLY.

Unfortunately, I do not know how to accomplish the above nor do I know how much work is involved. Hopefully the forum can help here. If not, I would suggest opening a ticket with UD. While not specifically an EISY problem, I'm sure they could assist in eliminating the integration.

Thanks for the direction. I was thinking the same approach, but also do not know how to do it most effectively, i.e., how would I terminate with less than extreme prejudice as I desire not to lose any subscription I paid to renew this past year. I suspect there is a way to do this so I do not risk the subscription; I am likely registered somewhere, and I will investigate that first. As I recall, I paid a premium for renewing this year since, at the time of renewal, I renewed using my ISY994i, and since it was no longer supported, the Alexa integration subscription cost more. I would first access the vocal mapping to create a paper copy so it will be easier to recreate it (or at least recreate my table without missing any vocal commands that I have created over the years). I am being careful to avoid going back to the beginning if I can avoid it! :>) I hope not to have to open a ticket if the process is already documented somewhere.

@jlloyd_UD

Why not just delete the 'ISY Optimized for Smart Home V3' skill.

I also use it extensively with my Polisy. I've had none of the issues you describe here.

I'm a Prime member - deleting that skill will not have any affect on your Prime subscription.

Adding to my comment:

You would delete it to see if that resolves your issue. - then, as @IndyMike suggested, after reactivating the Skill, add the offending devices back one at a time.

(Reactivate the Skill only after you are certain deactivating it solved your issue.)

Sorry, I was not explicit enough. I was not concerned about my Prime subscription; I was referring to the fee paid (to UD?) for using the skill with the eisy. As I recall, it was either $20 or $40 per year this last cycle before I upgraded to the eisy.

If you are talking about the Portal subscription - just delete all of the 'spokens' (devices) you have set up for Alexa in there. That should have no impact on that subscription. Then add them back one at a time (after a few days) if that solves your issue.

Thank you. Yes, I was talking about the portal subscription. I will begin the task of eliminating and adding back the spokens.