@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 yesterday at 03:34 AM1 day 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 yesterday at 07:47 PM1 day 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?