IndyMike

OK, I understand why the response isn't immediate, but it's surprising that you notice a measurable delay. What specific switches are you using (Zen77, etc) and what type of Z-wave controller (I'm not up on Hubitat). To put things in perspective, I've been moving from Insteon (ISY994) to Z-wave (Home Assistant). I have numerous locations where I have Insteon/Z-wave switches controlling each other. This is a Virtual 3-way from the ISY994 to Home Assistant. I don't notice a delay. Insteon Switch >>>>> ISY994 >>>>> Network >>>> Home Assistant >>>> Zooz Dimmer. Not sure if you have a Hubitat problem or a Slave Switch problem

@TomNow2 , I'm a bit late to the party and I'm confused by the delay that you are seeing with the Zooz switches. Zooz is one of the few manufacturers that allows you to combine their Z-wave switch/dimmer with a conventional mechanical switch. It's one of the reasons I've installed them. In my experience, the Zooz direct wire is far faster (immediate), 100% reliable, and far less expensive than the Insteon "virtual" 3-way. The Zooz direct wire install (below) should be immediate. You mentioned "slave" switches - I assume these are simple mechanical switches. There should not be any interaction with the hub. If actuating the mechanical switch doesn't produce an immediate response in the load, you may have a ramp rate or something else programmed in the Z-wave switch.

@Techman , give it a try (the ISY994 doesn't have the "isy scene" or I would try it). Open the event viewer to level 3 and execute your program containing the "ISY scene off". If you see "02 62 00 00 FF CF 13 00" appear in the viewer you have sent an "all off" to all linked Insteon devices. Be advised that there may be follow on commands turning off Z-wave and other devices. My read is that this is an "ISY world off" command. If you learn differently, please advise.

@Techman - on my ISY994 this is the same as setting "My Lighting" to off programmatically. It generates identical commands in the event viewer.

@Techman , I use a program to monitor (query) a lamplinc that is my dedicated "all-on" detector. If the Lamplinc is detected as "ON" event has occurred and a "my Lighting" off program is called. You could easily construct a similar program and Link it to a KPL button - activate if "All-On" Note: setting "My lighting Off" turns will issue the Group FF off command to all Insteon devices. On my system, it also issues an X10 all lights off to housecode A (see event viewer below). I don't have Z-wave installed but these could also be turned off as well. If you don't want "other technology" devices turned off, you would be better served by creating an "all off" scene as others have indicated. Disclaimer - this is on the ISY994 Query Lamplinc every 5 Min All on Poll - [ID 000A][Parent 0013][Run At Startup] If Time is Last Run Time for 'All on Poll' + 5 minutes Then Set 'All On Detect' Query Else - No Actions - (To add one, press 'Action')Call My Lighting Off if Lamplinc is ON All on response - [ID 0011][Parent 0013] If 'All On Detect' Status > Off Then Set 'My Lighting' Off Else - No Actions - (To add one, press 'Action')Event Viewer for "My Lighting OFF" Sun 01/11/2026 09:07:37 AM : [ Time] 09:07:37 22(0) Sun 01/11/2026 09:07:37 AM : [INST-TX-I1 ] 02 62 00 00 FF CF 13 00 Sun 01/11/2026 09:07:38 AM : [INST-ACK ] 02 62 00.00.FF CF 13 00 06 LTOFFRR(00) Sun 01/11/2026 09:07:38 AM : [ X10] A1 Sun 01/11/2026 09:07:38 AM : [ X10] A1/All Lights Off (1)

Thanks Brian. I should have noticed that the relay in the schematic was 120V. Miss on my part. Based on the date codes, my Icon was made about 3 months after @johnmsch 's togglelinc. Hopefully they're the same layout. Would you happen to have a better schematic of the Relay/dimmer versions in this Vintage? Understand if that is constrained by a NDA.

As @lilyoyo1 indicated, some Z-wave devices have features that (if set incorrectly) can overwhelm the system with excessive communication. I purchased 4 Zooz ZEN04 power monitoring plugs for monitoring/shutting down various TV and appliances. They worked well in most locations after setting the parameters for monitoring power. My Sony TV did NOT play well with the device regardless of the parameter settings. The communication would hit levels that would cause the system to become sluggish. Disabling monitoring instantly returned the system to normal. I communicated the problem to Zooz and they rolled out a firmware update with additional tuning options. The result is shown in the second plot. System performance is night and day different. I am still running this system today. As both @oberkc and @lilyoyo1 have indicated, consult your logs to determine if you have a device that is constantly communicating and using up all the bandwidth in your system.

Thanks, that produced a spontaneous laugh. I needed that today.

Update - the app note I posted above is a bit misleading. It is in fact what the older Insteon supplies were "modeled" after. However the Insteon version regulated at 30V (not 5v as is the App note). The attached schematic was developed by jbauer back in 2006. As noted, the schematic is not complete. I found one of my malfunctioning ICON relay units from 2006 (photo's below). I had noted that the unit "cycled" when I pulled it. Unit powered up OK without a load. I disassembled and verified the supply regulated @30V as jbauer had documented. My unit had an additional MOV (SDS 201KD07) across the power input (201V threshold). The C2 470u cap appeared to be in good condition as did the D1 30V zener diode. C1 is the large brown (Mica?) cap. I would not expect this to degrade.

Your 3 way switches are "virtual", meaning that only one is actually connected to the load. The other switch simply communicates with the load connected switch to turn your lights on. Bottom line, you only "have" to replace the load connected switch. I3, relay, your choice. .... Or you could swap your current dimmers to see if the triac is dying on the current one connected to the load. I have a number of dimmers that have dead triac outputs - just use them for communicating "ON/OFF" commands to other devices.

Now that's an oldie. Not necessarily a goodie. I didn't realize that Smartlabs was making the Togglelinc back in '06. Insteon devices from that time frame had power supplies based on a Microchip App Note 954 located here: https://ww1.microchip.com/downloads/en/appnotes/00954a.pdf They had a habit of burning up the filter cap/zener due to powerline voltages/spikes. Another issue was with the micro switch contacts themselves. Since the device is a relay switch, I'd guess that the 470uF cap (c2??) is breaking down (power supply drop out). You could open and inspect, but to be honest, these devices are probably at the end of their useful life. The relay units are not bad to open up (no Triac soldered to the heat sink). I still have a number in service, but when they die, will retire them. The good news is that you apparently have very well regulated power as well as rather "clean" powerlines. Later devices incorporated dual band as well as additional simulcasting improvements.

@brockp , it appears that Houselinc is still available here: https://support.insteon.com/support-knowledgebase/2016/6/1/houselinc-windows HouseLinc is a PC based interface for Insteon control. It was the forerunner of Smartlabs Hub based system. I still use Houselinc for it's diagnostic/signaling capabilities. I have it setup on a Windows 11 mini PC with a USB to serial adapter to the PLM. The following was a test that I ran after having issues to a new refrigerator install. Houselinc ran 1000 tests on 17 different devices and rolled up the success %. I had "Disable PLM Retry" selected and "Hops" set to 2, so this was similar to a standard ISY scene (no retries, HOPS=3). You could certainly use this to give your questionable PLM's a workout. 1 word of caution - using Houselinc to link to existing devices will alter their link tables (without the ISY's knowledge). Make sure to use the ISY to restore the Link tables after testing.

@someguy , now that I've re-read the post, you are probably correct about "Instagram" being a typo. You might be surprised to learn that there is an Instagram add-on for Home Assistant... There's a lot of conflicting information here. You're symptoms are following the "random on" events that have been attributed to communication collisions or PLM to EISY serial errors (pointed out by @kclenden ). The Event log that you provided earlier did NOT show any PLM to EISY serial errors that I could find. @kclenden is far more experienced at screening for these. I would welcome his input on the issue. Questions and things to try: Your newer devices should not be susceptible to an all-on command from the PLM. Please verify that this is true by executing an ALL-ON from the MY Lighting Admin console and then physically which devices turn on. Devices like the IOLinc were not updated the last I checked. When you find a light on unexpectedly, does the ISY have knowledge of the Light State? If it does it could point to a Rest command telling the ISY to turn devices on (the ISY knows it sent an on command in response to a Rest request). Try disconnecting the ISY from the Lan to interrupt Rest communication. You'll likely need to leave the system disconnected over a couple of nights to verify any improvement. Manually linked devices can activate devices outside of the ISY's knowledge. I've had this happen previously when visitors were in the house and accidently put devices into linking mode. Scan the device link tables and restore if necessary. The link table that you provided earlier showed only a link for your PLM. Only your PLM (or another controller) should be able to activate this device. If nothing above has helped eliminate the problem - disconnect your PLM. That should prevent any device direct communication. Check for "other" controllers. In the past I've had HouseLinc running on a separate PLM. A PLM can control your devices even with NO links in the device table (just verified this AM). Make sure you don't have any other controllers capable of issuing device direct commands to Group 0. If things are still acting up, we are down to X10 communication or local power upsets. You've already factory reset some of your devices - that should eliminate any programmed X10 addresses. If you factory reset a device and leave the link table blank (do not restore) the only device that should be able to activate it would be a PLM using a device direct command. An all-on command should NOT turn the device on. If the PLM is disconnected, there shouldn't be any controllers capable of turning the device on. If it does, there's something very next level going on. Please report back your findings for the all-on test.

@someguy , from what I remember, you did not have any Alexa communication in the event viewer file that you provided. You also had only 1 link in your affected device link table (to the PLM). That really doesn't leave many options. Since you do have a PLM link in the device, the PLM (EISY) can still turn on the device. That includes any REST device (alexa and other). You might try disabling (unplugging) your network connection to eliminate external commands. @oberkc mentioned that he has been having issues with Instagram communications - I have no experience with that but it sounds like it could be a player. The other possibility would be an "all-on" event. Your older devices are susceptible. The newer device (71.C2.58) should not be. Not sure what this device is - please post back and confirm. You can test to determine whether your devices respond to the "all-on" command from the admin console. From the "my lighting" tab in the admin console tree, hit the "all-on" button. After activating you'll need to visually inspect for devices that have responded. Newer devices will not respond (command removed). Older devices will respond. Very curious about your 71.C2.58 device.

@BobM99 , to the best of my knowledge you will not receive a "message" from querying X10 devices. There are not many 2-way x10 devices out there. Most devices will not respond to queries. Even if a X10 module is 2-way compatible, the ISY will not generate an error if it does not respond to a query (ISY994 won't generate an error). If you are seeing a "Request Failed" error from the EISY, it's possible that it is not communicating to the PLM. Check the "Tools\Diagnostics\PLM Status" for connection errors. If the PLM is a recent replacement, it's possible that it does not support X10. I've heard that X10 was removed in some newer modules, not sure about the PLM's themselves.

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