IndyMike

@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: Eisy to PLM serial communication errors Rest/Alexa commands to the devices Program direct commands to the devices Scene commands (your devices do not have links to support scene commands) 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 - 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? 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.

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.

@gssincla , your event viewer is showing commands being sent TO the PLM. I don't see any evidence the PLM is acknowledging the commands. The following is a section from the end of your event viewer post. There should be PLM acknowledge responses [INST- ACK] after each command sent by the ISY [INST-TX-I1]. Hopefully the PLM has simply locked up. Try a power cycling both the PLM and ISY. If that does not work, it may have given up. Sun 11/16/2025 23:25:22 : Create REST U7 [/rest/nodes/57%2030%20F4%201/cmd/DON/0/51] Sun 11/16/2025 23:25:22 : U7 Rest: submitCmd([57 30 F4 1],[DON],[<NULL>]) Sun 11/16/2025 23:25:22 : [INST-TX-I1 ] 02 62 57 30 F4 0F 13 00 MISSING PLM ACKNOWLEDGE Sun 11/16/2025 23:25:23 : Create REST U7 [/rest/nodes/57%2030%20F4%201/cmd/DON/0/51] Sun 11/16/2025 23:25:23 : U7 Rest: submitCmd([57 30 F4 1],[DON],[<NULL>]) Sun 11/16/2025 23:25:23 : [INST-TX-I1 ] 02 62 57 30 F4 0F 13 00

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

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

@Geddy, thanks for confirming. I should probably know that by now, but some things just don't stick. I'm still thinking the 2477D issue sounds like an intermittent communication problem.

The older isy994 included a program that would query "My Lighting" at 3:00 AM to re-synchronize the system. I am guessing that the EISY has the same program. If a device does not respond during the system query your will get a "Cannot Communicate With XX.XX.XX. Please check connections" when you open the Admin Console. This sounds like what you are seeing on the 2477D. Since you can control it from the Admin Console/UD Mobile it sounds like the device is somewhat intermittent. You may have a noise source/signal absorber that is active at night and is interfering with communications. Open your Event Viewer and set to Level 3. Perform a "Query" from the admin console. It should look something like the following. The "Hops Left=3" in the communication below shows the message is being received on the 1st Hop (very good). If the Hops Left were to be 0 that would be marginal. Thu 11/13/2025 08:56:10 AM : [INST-TX-I1 ] 02 62 54 A1 F5 0F 19 00 Thu 11/13/2025 08:56:10 AM : [INST-ACK ] 02 62 54.A1.F5 0F 19 00 06 LTSREQ (LIGHT) Thu 11/13/2025 08:56:10 AM : [INST-SRX ] 02 50 54.A1.F5 53.BC.3A 2F 00 00 (00) Thu 11/13/2025 08:56:10 AM : [Std-Direct Ack] 54.A1.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 The fact that you cannot control the device from your program MAY be because you are using a scene. Scene control on the ISY does not verify that the device responded. It issues the command and assumes it succeeded. Commands sent from the Admin console are "Device Direct" and do verify the communications. I am not familiar with the error you are getting on the mini remote switch. It's possible that the add process didn't finish completely and the ISY is continuing to retry the addition. Could you post the model of the remote and the exact error message that you're receiving?

@JimTurner , Your Rest command syntax is correct for the ISY994. I don't believe there has been a syntax change in the Eisy (I do not have one). Is it possible that the program ID or IP has changed? As a follow on thought, does the Eisy allow http access (not https)?

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.

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

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

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

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.

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.

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.