IndyMike

@PapaBear , the fact that this is a new sensor is relevant. It's possible that it's mislabeled or just defective. One curious item is the device address - 45.D1.A2. I have 4 of the MSII's that are already several years old. They all start with the address 4A.xx.xx. Insteon device addresses don't normally decrease on newer units. One last thing to try before we declare the unit "broken" - manual link to another Insteon device. This is just in case you have a misprinted address label on the MSII. I just did this with a LampLinc I had laying around - Place your MSII into link mode by holding the set button for xx seconds Place the device you with to link into link mode. Linking should be almost immediate. Assuming this works, you can find the MSII address in the link table of the device you just linked (use show device links + compare). In the example below the mismatched link is the manual link just added. The 4A.6F.7A is the address of my MSII. Remember to restore your test device to eliminate the manual link.

@jlloyd_UD , please report back your progress. I have to believe there are others similarly affected.

@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: Nuke the Alexa/Portal integration Verify (over days) that the problem has been resolved. 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.

@oberkc , You are correct that it doesn't hurt to try... I just ran both methods and they work equally well with my spare MSII's. That said, I am using an ISY994 whereas @PapaBear is running the EIsy. @GlowingHair , I believe you are referring to hitting the "Node limit" in the standard ISY994 (254 nodes). PapaBear is running the EIsy. I don't know the node limit but believe it to be substantially higher than the ISY994. I don't recall anyone hitting the Eisy limit as yet.

@oberkc , simply two different methods to link. Bottom line is the command shown below that is being executed by the ISY is correct (get Insteon Engine Version). If the MSII hears to command it should respond with an I2 engine version. It is not responding which leaves us with the following options: Device address is incorrect. Possible, although I've never encountered a mis-printed label. There are methods where the device can be manually linked to determine it's address. The device can't hear the PLM because of interference in the area (or PLM can't hear the MSII). Move to a different location and re-try. Faulty MSII (it happens)

@PapaBear , the ISY is trying to contact the MSII. It retries 3x and then times out. Did you happen to try monitoring the Event Viewer while re-connecting power to the MSII? I'm assuming you had the sensor connected previously. You also seem to be getting a lot of activity from the device @14.16.B3. I'm guessing it's a thermostat. That's both good and bad. The thermostat is communicating well with the Insteon network (do know the point of access). The bad may be the traffic it's throwing at the system. You might still try re-locating to a separate room - this will force a different RF access point to the system.

@PapaBear , I've been taking some swings at this and have not been able to reproduce what you are seeing. I've tried different communication modes (I1 vs I2), linking methods, power methods, and device versions. Things seem to just work. Would you mind posting the contents of your Event Viewer when things fail? The following is what I get when I intentionally enter in the device address. The ISY tries 3x to communicate with the device and then times out with the error message. Another possible check - If your MSII has been linked to the PLM previously, it will still contain the PLM address (even after a factory reset). Assuming the PLM still contains your MSII link (hasn't been restored from backup), you will see the MSII address pop up in the event viewer when you apply power. The communication below is from my MSII @4A.6F.7A telling the PLM that it has turned on when power is applied. Use this to quadruple check your device address (labels do get old and disfigured). The following is the method that I've settled on for linking the MSII's. Using "Auto Discover" is easier that scrolling to the bottom of the device list, and it populates the Sensor Version (v.46 below). If none of this appears to work, it is possible you simply have a defective MSII or RF Interference in the area around your PLM. You could try linking the sensor away from the PLM but close to a different RF repeater. The MSII's are 915 MHz and it's possible that you would have other devices in this range. That's not a problem that I've encountered. It is also possible that you have device(s) spamming the powerline and disrupting things while you're trying to add the device. The event monitor should show evidence if this it the case.

If your program turns of/off a single device, it will request a response from the device. If your program executes a scene, no cleanups are performed. Example program with a Scene ON + a device On. The event viewer output shows that the scene does not request a response from the device. Turning the device itself on will request a response. Test - [ID 0071][Parent 0003][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'SC Basement Bed' On Wait 2 seconds Set 'Basement / Basement Bed' On Else - No Actions - (To add one, press 'Action') EVENT VIEWER OUTPUT ###### following is the program turning on a ascene for my basement light - no verification is performed ### Thu 12/11/2025 08:43:42 PM : [ Time] 20:43:48 7(0) Thu 12/11/2025 08:43:42 PM : [INST-TX-I1 ] 02 62 00 00 59 CF 11 00 Thu 12/11/2025 08:43:42 PM : [INST-ACK ] 02 62 00.00.59 CF 11 00 06 LTONRR (00) ###### program turning on the individual light - Light responds with 2 Hops left ######### Thu 12/11/2025 08:43:44 PM : [INST-TX-I1 ] 02 62 13 0A 51 0F 11 FF Thu 12/11/2025 08:43:44 PM : [INST-ACK ] 02 62 13.0A.51 0F 11 FF 06 LTONRR (FF) Thu 12/11/2025 08:43:44 PM : [INST-SRX ] 02 50 13.0A.51 53.BC.3A 2B 11 FF LTONRR (FF) Thu 12/11/2025 08:43:44 PM : [Std-Direct Ack] 13.0A.51-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Since your scene sounds like it is intermittent, I don't believe you have a link problem. If there were bad links, the devices would never respond. If you wish to look for bad or missing links,: Right click on a device in the admin console tree. Select "diagnostics/show device links table" Once the link table has finished populating, click the "compare" tab at the bottom of the table. A second table will open showing what the ISY believes the table should contain. Any errors will be noted in the original table. ###### Note - If you see an error flagged with a data value of ": EA" this is not an actual error. #####Devices that show errors can be corrected by right clicking the device and using the "restore device" For assessing communication issues - You can query your devices with the Event Viewer open and set to level 3. Inspect the "Hops remaining" response from the device. Normally commands are sent with max Hops = 3. Responses received back with 3 hops remaining is excellent, 0 not so much. You can also perform a scene test from the "Tools Menu". This will turn a scene on and then back off. It will request cleanups from the devices and indicate whether they responded properly. This is actually a rather rigorous test.

@dennisric , the "flashing" sounds like a noise and/or power supply filtering problem (capacitor dying). Are your togglelincs on the same circuit? Have you changed the loads on the switches? Any recent issues with the utility transformer/neutral line to the house? (or other electrical work). I agree that a simple reset/restore is easy and prudent. If that doesn't work you might try swapping one device out to see if that corrects the problem. The togglelincs are ~10 years old or more. Very possible that the power supply's are starting to have issues.

@PapaBear , when you execute a scene from your Insteon switch it will interrogate group members via a group cleanup command to verify that they received/acted on the scene command. If a device did not respond correctly, the switch MAY retry xx times. When you request a scene to be turned on using Alexa, it communicates to the ISY via a Rest command. The ISY in turn executes the scene. The difference is that when the ISY executes a scene it does NOT interrogate the scene members to see if they received/acted on the command. It assumes the command was received properly. You likely have poor communication to some of the scene members. The switch uses retries to try to improve communications. The ISY (and Alexa) do not. You can try to improve communications, or use Individual device On/Off commands (Device on/off vs scene on/off). The ISY will use group cleanups and retries for Device Direct commands.

@UD2)17rrh , to get directly to the point - I was wrong. I was remembering a different situation that involved non-toggle buttons (https://forum.universal-devices.com/topic/42585-kpl-button-on-level-set-to-off-not-working/). I pulled out one of my older rev 1.65 KPL's (2007 vintage) and it worked perfectly. That being the case, your KPL should function as you intended. I'd suggest trying the following in order of increasing pain: 1) Simple device restore from the admin console - you may get lucky and have a simple missing link. or 2) Delete device/ factory reset/ re-add device. Please let us know if either works.

@UD2)17rrh , if your KPL A button is a responder to Controller KPL B it should respond. There may be very old Insteon KPL's where this isn't the case (2008 Vintage) but anything made in the past 13 years should function. Try performing a link table read/compare. If you see errors, restore the KPL.

@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