IndyMike

A number of points regarding GFCI's, refrigerators, and Insteon/zwave: Refrigerators absolutely can trip GFCI breakers at both turn on and shut off. This is far more likely with older refrigerators which have higher inductive loading. GFCI's are not required for refrigerators in a Kitchen. They are absolutely required in garages and unfinished basements. I'm assuming your installation is one of these. If your refrigerator is on a dedicated circuit, a 15A GFCI is sufficient. If the circuit has branches (other outlets) a 20A circuit is required (2011 code - your location may differ). Insteon and Zwave devices/communication can CAUSE GFCI trips depending on the type of devices installed on the GFCI. The higher frequencies used by Insteon can activate "sneak paths" in devices that are interpreted as valid GFCI faults. The Zwave fault (Aetec repeater) I don't yet understand - If I plug the repeater in a GFCI and communicate via Zwave it will trip the breaker. To the points above, have a look at the devices on the circuit. If you are above 80% rated load, unplug/ move some items. It you have items that may include EMI filtering (chargers and the like), they may include sneak paths that can be activated by using Insteon communication. The idea of using the Zooz alarm is good for absolute power monitoring. No questions, you will be notified it the power fails. A similar method would be to monitor your refrigerator temperature. I've recently started monitoring my basement refrigerator temperature using a Aqara Zigbee sensor. It's accurate, low power, and is currently giving reliable communication from inside my refrigerator 35' away (still in the testing phase). Unfortunately, incorporating either Zigbee or Zwave will likely force you to upgrade from the ISY994.

@nil13, The log for your BR light shows "classic" communication problems (low hops remaining) and timeouts (repeated requests from the ISY with no response from the BR Light) After 3 timeouts the ISY declares a fault. BR Light Log: Wed 01/17/2024 06:00:30 PM : [ 1D B5 9A 1] Preparing Device 'Bedroom Swag Lights' for Restore Wed 01/17/2024 06:00:30 PM : [ 1D B5 9A 1] Device 'Bedroom Swag Lights' ready for Full Restore Wed 01/17/2024 06:00:39 PM : [INST-TX-I1 ] 02 62 1D B5 9A 0F 0D 00 Wed 01/17/2024 06:00:39 PM : [INST-ACK ] 02 62 1D.B5.9A 0F 0D 00 06 (00) Wed 01/17/2024 06:00:41 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 27 0D 02 (02) Wed 01/17/2024 06:00:41 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Wed 01/17/2024 06:00:41 PM : [1D B5 9A 0 ] Calibrating engine version Wed 01/17/2024 06:00:41 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:41 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Wed 01/17/2024 06:00:41 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 23 0D 02 (02) Wed 01/17/2024 06:00:41 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Wed 01/17/2024 06:00:50 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:50 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:00:59 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/17/2024 06:00:59 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Wed 01/17/2024 06:01:03 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 06:01:03 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB Wed 01/17/2024 06:01:03 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06 (00) Wed 01/17/2024 06:01:03 PM : [INST-SRX ] 02 50 1D.B5.9A 70.8B.4D 27 2E 00 (00) Wed 01/17/2024 06:01:03 PM : [Std-Direct Ack] 1D.B5.9A-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Wed 01/17/2024 06:01:03 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0032 [7F] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 06:01:03 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:03 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:12 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:12 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:21 PM : [INST-TX-I2CS] 02 62 1D B5 9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C Wed 01/17/2024 06:01:21 PM : [INST-ACK ] 02 62 1D.B5.9A 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Timeout – No response from 1D.B5.9A Wed 01/17/2024 06:01:25 PM : [1D B5 9A 1 ] Memory : Write dbAddr=0x0032 [7F] cmd1=0x2E cmd2=0x00 - Failed The Log for your LR light is confusing. The ISY did not attempt to send anything to the PLM. I'm honestly not sure what the issue is here. You might try power cycling the ISY and PLM. LR Light Log Wed 01/17/2024 05:53:50 PM : [ 1B 93 CD 1] Preparing Device 'Living Room Swag Lig' for Restore Wed 01/17/2024 05:53:50 PM : [ 1B 93 CD 1] Device 'Living Room Swag Lig' ready for Full Restore Wed 01/17/2024 05:55:01 PM : [1B 93 CD 1 ] Memory : Write dbAddr=0x0032 [9E] cmd1=0x2E cmd2=0x00 Wed 01/17/2024 05:55:23 PM : [1B 93 CD 1 ] Memory : Write dbAddr=0x0032 [9E] cmd1=0x2E cmd2=0x00 - Failed

@glacier991, This is a bit late, but It may help you in the future: https://wiki.universal-devices.com/ISY-994i_Series_INSTEON:Enhanced_A10/X10 Isy 994I User Guide: https://docs.universal-devices.com/production/ISY User Guide v3.3.10 a2.pdf I still use X10 for my out PR511 outdoor motion floodlights that refuse to die after 20+ years. I also have the optional X10 module installed which allows you to name X10 devices. I doubt that's available on the Eisy. Also have some old program code to query and send "preset dim" commands. Let me know if you're interested and I can dig it out.

You may have different mechanisms at play here - The Admin console calling out the outdoor modules as "Failed" is probably a result of your 3:00 AM system query. The Query uses device direct communication. The PLM will retry communication and the ISY will retry the command up to 3 times. Your indoor devices may be controlled by scenes. Scenes are group commands that do not have any followup (no confirmation) and therefor no retries. The ISY assumes the command was executed correctly. In summary, your outdoor devices may be completely offline with the indoor devices suffering from poor communication. Can you post an Event Viewer query (Level3) on both an outdoor device as well as indoor. That may give us a clue about what is going on. If you have Accesspoints or Signalincs you could run a "3-tap" test between them and the PLM. This will hopefully verify that they are still communicating.

Are you sure that your outdoor devices didn't trip GFCI breakers? Rain events are good for that.

Not dangerous - Insecure Unreliable - As you've already learned, the 2450 is powerline only. It has issues with communication in "problem areas" (no news here). In my experience, is it also susceptible to powerline transients activating the switch contacts. Transients are typically caused by inductive and capacitive loads activating/deactivating (motor loads, florescent, etc ). Many HA devices have problems with powerline spikes activating them. The 2450 seems "more" susceptible. I used on one my sprinkler controller to de-activate the system. The garage florescents would routinely activate the 2450 even though it was behind a filter. No Security - No Insteon device is "secure". You won't find an Insteon deadbolt on the market because the protocol does not support secure communication. Your garage door remote has rolling code encryption to prevent capturing and replaying the open close commands. The 2450 does not and can be easily defeated. Susceptible to All-On commands - Most (if not all) IOLinc modules are susceptible to all-on/all-off communication. This is a command built into the Insteon protocol that activates ALL LINKED UNITs. Unfortunately, the PLM can generate this command erroneously under certain conditions. I've had several occurrences, as have others - Another All ON EVENT. If you're lucky, your lights turn on. No great harm. If you're unlucky, your fireplace, house vent fan, and garage door activate. Edit: Wanted to be sure that the 2450 activated it's contacts due to an all-on. I verified that My 2450 with firmware v.36 responds to both All-on and All-off and activates it's contacts accordingly. This would absolutely open/close a garage door during a "All On Event".

Sorry, I completely missed this post. It sounds like your chargers may have large EMI caps installed. These are rather effective at absorbing Insteon signals. It's probably not just the chargers absorbing things. All devices installed on the circuit (and near the PLM) can contribute to noise and absorption. Unplugging one device may re-establish signal levels and look like a smoking gun. In actuality, what normally happens is you have improved signal levels just enough to allow things to operate (barely acceptable signal to noise ratio). Unfortunately good, easy tools for Insteon don't really exist. The best commonly available method I know of to assess communication is by removing and/or filtering loads and then monitoring communication with the Event Viewer. I normally choose the "Show Device Links Table" as this is rather communication intensive. You are looking for transmissions where "Hops Left" is the same as "Max Hops" or possibly one lower. Retries will be signified by multiple transmissions with no response from the device. Your 2450 could be an I1 device (uses Peek/Poke rather than I2 extended comm below) in which case the communication will be FAR more intensive. Good communication (I2 Extended Comms: One read returns 8 bytes of data) Mon 01/15/2024 08:56:09 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 08:56:09 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 08:56:10 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:10 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:10 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F FF 01 A2 00 53 BC 3A FF 1F 01 C2 Mon 01/15/2024 08:56:10 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 01/15/2024 08:56:10 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA Mon 01/15/2024 08:56:10 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00) Mon 01/15/2024 08:56:11 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:11 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:11 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 11 2F 00 01 01 0F F7 01 22 47 53 BC 3A FF 1F 01 CA Mon 01/15/2024 08:56:11 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Mon 01/15/2024 08:56:11 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 Mon 01/15/2024 08:56:11 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 06 (00) Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Communication Re-tries (no INST-SRX 02 50 from device) Mon 01/15/2024 09:02:44 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:44 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:02:53 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:53 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:02 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:03:02 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices I1 Communication ( 2 Operations required for 1 byte of data) Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F8 Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F8 06 PEEK (F8) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B A2 PEEK (A2) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F9 Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F9 06 PEEK (F9) Mon 01/15/2024 09:07:43 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B 00 PEEK (00) Mon 01/15/2024 09:07:43 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

@DwayneA, Both your 2450 and 2443's will flash their LED's on Insteon traffic. If you have Mobilinc you should be able to activate the 2450 remotely and watch for traffic on the LED's. This may help to isolate the problem further. Just noticed that you indicated that the 2450 is also CONTROLLING your garage door. Sorry, but I think that's a very bad idea. The 2450 is not the most reliable module. It's totally devoid of security, and it's susceptible to All-on/All-off communications. I understand to desire to monitor your garage door status, but please re-think controlling it with the 2450.

Sounds more like a communication issue. Garages can be very problematic with all the devices that are plugged into outlets (chargers, etc). Since the 2450 is a plug-in device, try moving it closer to your PLM to check communication. If it works, you need to look for signal absorbers/noise generators on the garage circuit.

@Kentinada, It sounds like you would like to include a "Not switched" for the Ring camera to activate the Else section of a program as shown below for a motion sensor -Correct? Trying to understand the problem and am unclear on the following: 1) Is the option for testing the "not switched off" unavailable for the Ring camera? 2) is the option available but does not trigger when the camera stops sensing motion? Kitchen Motion On Copy - [ID 0012][Parent 0054] If 'Motion/RF / Kitchen Mud.1 Motion' is switched On And 'Motion/RF / Kitchen Mud.1 Motion' is not switched Off Then Wait 2 seconds Set '1st Floor / SC Bar Cans' On Else Set '1st Floor / SC Bar Cans' Off

The secondary buttons do not really have an ON/OFF associated with them. They show up as "keypessed" events in Home Assistant. Think of the events as momentary rather than state events. Youtube of the "keypressed" event in HomeAssistant - Skip to 11:25 Testing scene buttons https://www.youtube.com/watch?v=87jquTZ4B_U

Based on my rather limited testing, your IOlinc (V.41) would be susceptible and your Siren (V.46) would not be. My testing of devices in my home is located here : https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748 You could also try executing a "all-on" command from the Eisy. Not sure if it's still available in the Eisy. It's located at the bottom of the "My-Lighting" screen on the ISY994. Best to try this when family members are not around

I am assuming that your Siren and GDO are not members of any scenes or programs. You can check scenes by looking at the device in the admin console and looking at the membership tree to the right. You can check program membership by right clicking on any program and selecting "find/replace". Search for your I/O linc and you will be able to cycle through all the programs that it is used in. I'm going to out on a limb and assume that you've already checked this. While it's possible that you encountered an electrical "even" that triggered the 2450, it's highly unlikely that the event would trigger the second floor 2868 at the same time (multiple times). The other possibility would be a "all on event". This purportedly involves a communication collision the generate a "all-on" (or all off) command to all Insteon devices. All affected devices activate. I say affected because Smartlabs has removed the command from more recent modules. It is possible that your 2450 and 2868 were produced prior to Smartlabs removing the command. Please post your device version, firmware and date code

@jhoulihan, not a complete solution, but you could hit save your configuration to a desktop file. You will need to manually enter your address (again) so the IOX finder sees the ISY. The simply press "save" and put the file in a convenient location. You can leave the default name or create something new that you'll remember. The next time the IOX finder "forgets" the address, simply load the file from the desktop. https://forum.universal-devices.com/topic/39489-iox-finder-not-found/?do=findComment&comment=354467

Good idea adding the notification... I'm assuming this is the "new" follow-up program that is talking directly to the devices - correct? Are you still running your scene program and does it still fail to shut off the outdoor lights? Are these lights on GFCI circuits (outside and garage)? I am not familiar with the 'Holiday controller' date control. Assuming the program triggers, the device direct communication should be the same as if you turned the devices off from the Admin console. The PLM will issue device cleanup after each command and will retry communication 5x to devices that do not respond. My only other comment would be to make sure you don't have any other programs running at the same time. The Waits are effective at separating the PLM communication events WITHIN the program. If you have multiple programs executing the ISY could insert communication from other programs within the waits. This normally would be a huge concern, but if your PLM is performing retries to a problem device, it might abandon the cleanup in favor of the new command.

Just noticed that your problem lights were outside - i.e. on GFI outlets. GFI's can sometimes degrade powerline communication. What model Insteon devices are you using outside - are they dual band? Can you temporarily bypass the GFI for testing purposes? To @apostolakisl's point above. Much of this revolves around your programs. Please post them.

There are a few misconceptions regarding the protocol and how the ISY handles scenes - 1) Scenes - ISY scenes do not interrogate members to determine if they have responded correctly. As a result, there are no PLM retries used. The ISY assumes that the scene executed properly. The scenes are a single command and are very fast. Since there is no additional communication between the PLM and responders, scene commands in programs normally do not require delays. 2) Device direct commands (admin console) - Device cleanup commands are used to determine if the device has responded properly. If it does not, the PLM will re-try the command xx times. PLM retries are invisible to the ISY. 3) Device direct commands (programs) - Similar to commands executed from the admin console, cleanup commands are issued. The difference here is that the PLM can be overloaded if commands are "chained" and it will abandon cleanup attempts. This is where you need to insert delay between commands to give the PLM time to issue cleanup messages and retries. 4) Device cleanup retries (advanced menu for the devices) - This is for adjusting the #of retries that devices use to communicate with the PLM (not PLM to device). It will have no effect on scenes initiated by the ISY. It is only available on newer devices. https://wiki.universal-devices.com/index.php?title=ISY994i:INSTEON_Device 5) ISY Retries - ISY retries are used when querying a device. To my surprise, they do not appear to be used for device direct commands (anymore??). Retries default to 2 and can be changed by using Telnet to connect to the ISY Shell. Use "CR" max command retries. I do not advise adjusting beyond 2 as this significantly bogs down the ISY. https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide#CR_-_Max_Device_Command_Retries

My ISY994 does respond to a ping.

That's a classic no-response from a device. The ISY tried to query the device 3 times and received nothing back. Below is and an example of a correct response vs timeout. Your device address (42.D7.A8) indicates that the dimmer is reasonably new (V.45 firmware). It's newer than most of the devices I am using. Unlikely that 3 devices on the same circuit would suddenly all develop problems. If your equipment closet is on the same circuit as the dimmers, you may want to consider filtering devices.

You are not communicating with this device. The ISY is retrying the query after a timeout. Note - the PLM also retries XX times between each of these commands (invisible to the ISY). You're having severe communication issues to this location. Any new devices hanging on your powerline (i.e. Christmas decorations)?

I looks like you may have "Factory Reset" your KPL (erased the link table) and then performed a query. If that is the case, the device is responding with errors and NAK's (negative acknowledges) because it is an I2CS device and is not longer linked to your PLM. I factory reset one of my Test KPL's and got a very similar response. One curious difference is that my ISY994 is using the I2CS protocol to talk to the device. Your log does not show the "CS" (using I2 protocol). That may be a simple difference in presentation (not sure what system you are using). Normally this would be rectified by simply "restoring" the device from the admin console.

@Merlin - Thanks for the response. Another device to investigate - oh well. I am curious how you are powering the devices (and hiding wires) in your installation. Would you mind describing or providing a photo of your wired device? Thanks, IM

I agree that the ISY cannot directly address a KPL secondary button. In order to control a secondary button, it needs to be included in a scene. I am curious why the ISY isn't creating a "scene" for Insteon devices and an "association" for Zwave devices. Either way, it should be an easy thing to determine from the event viewer when the scene is activated by the Z-wave controller. Scene Activation - The 00.00.XX device address is indicative of a Scene. The "CF" flags also specifies a scene command but I am to lazy to decode this AM. Fri 12/01/2023 09:15:15 AM : [INST-TX-I1 ] 02 62 00 00 13 CF 11 00 Fri 12/01/2023 09:15:15 AM : [INST-ACK ] 02 62 00.00.13 CF 11 00 06 LTONRR (00) Device Direct Addressing: The 1A.5D.C7 address is an individual device in my system (member of the scene above). The "0F" Flag also specify a "direct command". Other indicators of a direct command are the 3rd line (02 50) which is a response from the target device. Scene commands (above) do not request a response. Fri 12/01/2023 09:16:24 AM : [INST-TX-I1 ] 02 62 1A 5D C7 0F 11 F7 Fri 12/01/2023 09:16:24 AM : [INST-ACK ] 02 62 1A.5D.C7 0F 11 F7 06 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [INST-SRX ] 02 50 1A.5D.C7 53.BC.3A 27 11 F7 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [Std-Direct Ack] 1A.5D.C7-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 I do not know/understand how the ISY is activating Zwave "associated" devices. I do not currently have a Zwave/ISY installation to test. But I am very curious for future installations. One last comment - I do remember a @lilyoyo post from years ago indicating that Zwave controllers should be added to a scene 1st. I had always abided by that when I had my mixed system. Have no idea if it still applies. IM

@djones1415, I apologize if my response implied in any way that you required this type of response. Being an Engineer (and working with Engineers) for 40+ years, pictures and screen captures are my go to. My friends and family would attest that I am uniquely qualified to provide idiotic responses. Glad it helped. In retrospect, Lou's (Apostolakisi) response was exactly correct. Had I seen it, I would not have replied. Geddy's response was "most" correct - pointing to existing Wiki documentation rather than re-inventing the wheel. I need to remember that. IM

Device replacement steps - This only works with similar device types (dimmer to dimmer/switch to switch) 1) Factory reset your new switch. This removes potentially unwanted settings from the new device (X10 addresses, etc). Manual : 2466 Toggleinc 2) Link the new switch and use the "Remove Existing Links" option. There should not be any links after resetting, but... (belt and suspenders). Name the device something similar to your old device - add a "#" or a "new" to discriminate between them. 3) Right click on the "old" device that you want to replace. It should now show the recently added device as an option for replacement. IF IT DOES NOT your old device is in a sub-folder or a different device type. If in a sub folder, move to the root folder. Device in sub folder will not show replace option After moving to the Root folder: replace is now an option 4) After performing the "replace with" you will be prompted to re-boot the ISY. Following the re-boot, the new switch should be in place and all of your programs and scenes should be updated. 5) Re-name the new device if you wish. All the programs and scenes will be updates.