IndyMike

@Tmc, sorry for the delay in responding - I was on the road. Answers: I "save" the PLM table as an XML file and then Import to Excel as an XML table. it allows be to sort columns and select individual device addresses for inspection. Unfortunately the values in the XML file are in decimal. You have to convert to Hex (+dec2hex) for them to make sense. Curious - my file save with an .XML extension. Most browsers can open it and it appears as you have shown above. In order to format the data, you can open the file with Excel or use a XML viewer. The link 325 that is shown is a "responder" link. As I indicated earlier, I believe the ISY leaves these. As @Techman indicated, the PLM link read isn't perfect and can be interrupted. I run the process 2 - 3 times in a row to make sure things are consistent.

@walkman9999, Had the chance to look at the files you up loaded. Your _Northgate program has a lot going on. Many Device Direct Fast ON commands in succession, followed by a scene command, and then more Direct commands. The rapid succession of these commands are bombarding the PLM and may be confusing it. In my experience, the PLM is rather good at handling stacked commands (back to back). But then I use the older ISY994. The EISY is far faster, and may be capable of overwhelming the PLM. I've posted a section of your event viewer below the program listing. Your fist Insteon command is a Fast ON to device 29.18.D7 Highlighted yellow). The normal sequence would be: Wed 02/12/2025 16:46:26 : [INST-TX-I1 ] 02 62 29 18 D7 0F 12 00 (Fast on Command to PLM) Wed 02/12/2025 16:46:26 : [INST-ACK ] 02 62 29.18.D7 0F 12 00 06 LTON-F (00) (Acknowledge from the PLM) Wed 02/12/2025 16:46:26 : [INST-SRX ] 02 50 29.18.D7 71.1B.41 2B 12 00 LTON-F (00) (Acknowledge from the device) I've highlighted all 3 in the event viewer listing below. These would normally be in sequence. As you can see, you have many other commands in between, as well as the curious "Link for responder XX.XX.XX not found". I believe this is the PLM informing the ISY that it doesn't contain the link for these devices. The thing is, I looked at your PLM listing and it most certainly does contain the links for these devices. As I said, confused. In general, the communication response activity I see in the event viewer log looks rather good. Two or three hops remaining fall all devices (Including older I1 devices). You may have some communication issues, but they were not apparent in the log. That's good. You may have "isolated" issues on some circuits, rather than wide spread issues due to a problem PLM location. Suggestions: Insert some short waits between some of your Insteon commands. If you suspect a scene issue, insert a longer wait before the scene command. Your programs were attached in an XLM format. Very few forum members can interpret it (and I have trouble). If you would please right click on the program and select "copy to clipboard", you'll be able to paste a "text version of your program. Many far more experienced people than I will be able to assist with suggestions. It looks like the Eisy is still using the deprecated Peek/Poke method of restoring your older devices. Did you try switching the Eisy to the "Device Reported" mode under "Advanced Options"? XLM Program Listing <?xml version="1.0" ?> <triggers> <d2d> <trigger> <id>50</id> <name>_North Gate</name> <parent>53</parent> <if> <and /> <status id="ST" node="55 18 EA 1" op="IS"> <val uom="51" prec="0">100</val> </status> <and /> <status id="ST" node="1A B3 C1 1" op="IS"> <val uom="51" prec="0">0</val> </status> <and /> <schedule> <from> <sunset>-1800</sunset> </from> <to> <sunrise>1800</sunrise> <day>1</day> </to> </schedule> </if> <then> <var id="3" type="1"> <op>EQ</op> <val prec="0">1</val> </var> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="49 B2 50 1"></cmd> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="1A 61 8D 1"></cmd> <cmd id="DFON" node="1A B3 C1 1"></cmd> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="29 1 8A 1"></cmd> <cmd id="DFON" node="2A B 38 1"></cmd> <cmd id="DFON" node="1A B7 F 1"></cmd> <notify content="1">1</notify> <cmd id="DON" node="11711"> <p id=""> <val uom="51" prec="0">100</val> </p> </cmd> <wait> <seconds>30</seconds> </wait> Event Viewer Log (Partial) PLM Table Sorted for Group 19 Scene Members

@walkman9999, unfortunately I am traveling through Friday. Can't help with the link tables at the moment. I did look at the restore log. You encountered an error writing to a device 1b.b0.cc. This looks like an older device that may be powerline only. As @oberkc indicated, this device would be a prime candidate for a restore. I'll try to have a look at the rest when I return.

As usual, I could not leave this alone... Anyone who has read my posts knows that they are rarely short, and never very interesting. Read on at your own peril... I ran another test deleting a KPL from my PLM. I compared the PLM link tables before and after the delete. Observations: The ISY deleted the control link (E2) for group 0 at address 14H from the table. This makes sense - leaving the link would allow the PLM to try to interrogate the device even though it didn't exist. Think PLM timeouts, retries, and the whole mess. The ISY DID NOT delete the responder links (A2) for groups 1 though 6 (main button and secondaries). I suppose these are viewed as harmless links. The can't do any damage if the device isn't there to communicate with the PLM. With the "deletion" of the Link @14H, all of the following link addresses shifted up by 1. The PLM now shows 1 fewer total links (497 vs 498). The above makes sense to me except for Item 3. There is no way the ISY had time to delete the link @14H and REWRITE ALL OF THE FOLLOWING links. Anyone who has restored a PLM knows it takes a significant period of time. This operation took seconds. This leads me to the conclusion that the ISY DID mark the record @14H as "available" (22). During the subsequent PLM link table read, the record @14H was IGNORED since it was marked as "available". The PLM Link read operation is very different from the device link read operation. The device read operation is handled by the ISY through read commands for each link location. The ISY displays all Link table information including "available" records. The PLM Link Read operation is handled by the Insteon "Get Next ALL-Link Record". This command apparently skips the records marked as "available". I now yield the soap box... IM

@Tmc, my apologies - I was wrong. I just deleted a device from my system and the PLM responder links are still are still there. I'm scratching my head at the moment... Event Viewer: Mon 02/10/2025 06:22:32 PM : [58 C9 B0 1 ] Start : Removing device from ISY Mon 02/10/2025 06:22:32 PM : [58 C9 B0 1 ] Finish : Removing from ISY was Successful PLM Table:

@Tmc, you are correct that there is a record with your device address still in the PLM. If you look at the flag column you should see a "22". This is the sign that the ISY has marked the record as "Unused". In order to completely remove the information, all of the links following the record would need to be removed. Simply marking the record Unused gets the job done quickly. If you find that you have many "unused" records you can perform a PLM restore to rewrite the entire PLM. The ISY will remove the unused records. The same technique applies to devices. The "22" is used to mark records unused, and a Device Restore will rewrite and remove the unused records.

@walkman9999, your Switchlinc Dimmer appears to be a 2476D that is powerline only. Communication with the device isn't great and that can be a problem when trying to restore a device. It might be possible to install a dual band LampLinc or other RF device electrically near the Dimmer to help with communications. It's also possible that the noise or signal absorption is temporary due to a problem device in the vicinity. Try inspecting for typical problem devices (PC's, chargers, UPS's, etc) in the vicinity. Another thing that is not in your favor is that the ISY is using and old I1 programming mode with this device. The Event Viewer communication below is from your Restore sequence. The Red section is where the ISY attempted a I1 write sequence that timed out after 3 tries. The following green section is a successful write that was performed using I2 (much faster). You could try to "force" the ISY to use I2 communication by going to Link Management/Advanced Options and selecting "Device Reported". The I2 protocol allows the ISY to transfer data in far fewer command sequences than the I1 mode. The communication is still susceptible to noise/absorption issues, but there are far fewer opportunities for failure. Sun 02/09/2025 14:11:28 : [ 1B B0 CC 1] Preparing Device 'Shed Bathroom' for Restore Sun 02/09/2025 14:11:28 : [ 1B B0 CC 1] Device 'Shed Bathroom' ready for Full Restore Sun 02/09/2025 14:11:28 : [All ] Writing 28 bytes to devices Sun 02/09/2025 14:11:28 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 0D 00 Sun 02/09/2025 14:11:28 : [INST-ACK ] 02 62 1B.B0.CC 0F 0D 00 06 (00) Sun 02/09/2025 14:11:30 : [INST-SRX ] 02 50 1B.B0.CC 71.1B.41 27 0D 01 (01) Sun 02/09/2025 14:11:30 : [Std-Direct Ack] 1B.B0.CC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/09/2025 14:11:30 : [1B B0 CC 0 ] Calibrating engine version Sun 02/09/2025 14:11:30 : [1B B0 CC 0 ] May not fully support i2, reverting to i1 Sun 02/09/2025 14:11:30 : [1B B0 CC 1 ] Link 0 : 0FF8 [A200711B41FF1F01] Writing [A200711B41FF1F01] Sun 02/09/2025 14:11:30 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:30 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:39 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:39 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:48 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:48 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:52 : [1B B0 CC 1 ] Link 0 : 0FF8 [A200711B41FF1F01] *Failed Writing [A200711B41FF1F01] Sun 02/09/2025 14:11:52 : [1B B0 CC 1 ] Memory : Write dbAddr=0x0264 [0C] cmd1=0x2E cmd2=0x00 Sun 02/09/2025 14:11:52 : [INST-TX-I2 ] 02 62 1B B0 CC 1F 2E 00 00 03 0C 00 00 00 00 00 00 00 00 00 00 C3 Sun 02/09/2025 14:11:52 : [INST-ACK ] 02 62 1B.B0.CC 1F 2E 00 00 03 0C 00 00 00 00 00 00 00 00 00 00 C3 06 (00) Sun 02/09/2025 14:11:54 : [INST-SRX ] 02 50 1B.B0.CC 71.1B.41 27 2E 00 (00) Sun 02/09/2025 14:11:54 : [Std-Direct Ack] 1B.B0.CC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/09/2025 14:11:54 : [1B B0 CC 1 ] Memory : Write dbAddr=0x0032 [FF] cmd1=0x2E cmd2=0x00

@BRMeeke, 26 KPL's is a lot. That consumes a lot of links in the PLM (1024 max) and nodes in the ISY (1000 max). Keep an eye on both.

@dleduc, I think you may be misinterpreting how the variable is being used in this statement. The Set 'Mister' On '$Timer %' will transfer the value of the variable as the ON LEVEL for the "mister" device. Valid range is 0 to 100%. The Example Program below sets the On Level of one of my dimmers to 4 different levels specified by the Variable 'IOnLevel'. 100 = 100% and 0 = off. The event viewer shows the ISY commanding the dimmer through the 4 different states. Note that this applies to devices only. If you attempt to assign a variable % to a scene you will only be able to command ON/OFF (anything >0 = ON, 0=OFF). Variable On Level - [ID 0070][Parent 0067] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $IOnLevel = 100 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Wait 1 second $IOnLevel = 50 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Wait 1 second $IOnLevel = 10 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' $IOnLevel = 0 Wait 1 second Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Else - No Actions - (To add one, press 'Action') Event Viewer (IOnLevel =100) Sun 02/09/2025 08:19:03 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 FF Sun 02/09/2025 08:19:03 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 FF 06 LTONRR (FF) Sun 02/09/2025 08:19:03 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 FF LTONRR (FF) Sun 02/09/2025 08:19:03 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =50) Sun 02/09/2025 08:19:04 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 80 Sun 02/09/2025 08:19:04 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 80 06 LTONRR (80) Sun 02/09/2025 08:19:04 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 80 LTONRR (80) Sun 02/09/2025 08:19:04 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =10) Sun 02/09/2025 08:19:05 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 1A Sun 02/09/2025 08:19:05 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 1A 06 LTONRR (1A) Sun 02/09/2025 08:19:05 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 1A LTONRR (1A) Sun 02/09/2025 08:19:05 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =0) Sun 02/09/2025 08:19:06 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 13 00 Sun 02/09/2025 08:19:06 AM : [INST-ACK ] 02 62 17.F7.B6 0F 13 00 06 LTOFFRR(00) Sun 02/09/2025 08:19:06 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 13 00 LTOFFRR(00) Sun 02/09/2025 08:19:06 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

@walkman9999, your event viewer is showing an error during the PLM record read. The ISY is talking to the PLM but the PLM is returning a negative acknowledge. The ISY retries 2 times and then aborts the operation. 02 69 15 (15 indicates a Negative Acknowledge from the PLM). The proper response would be a 02 69 06 which would then be followed by the PLM link record. You could try power cycling the PLM to see if it recovers. If it does not, your spare will come in handy.

@Illusion, toggling the WAN MAY result in a new WAN IP address being assigned by your ISP. Disabling internet access to IoX should have no effect. Just pointing out the difference. I have no ability to test.

@pwmcmaho, the following table is what you posted 3 hours ago. It shows 21 unique device addresses and 23 total records. 19 of the devices are listed as "responders only" (FL=E2). These devices cannot send messages to the PLM (this is what you are seeing above). You should be able to turn these on/off from the admin console. 2 of the devices have control links for the PLM (FL=A2). I've highlighted these in the table. These 2 devices can communicate back to the PLM when they are manually activated. Again, you either had an aborted PLM restore, or a bad backup.

@pwmcmaho, an easier way to look at the device links (and compare them): "right click" on the device in the admin tree. This should bring up a menu that includes "diagnostics" (1st graphic below). Select "Show Device Links Table" and the ISY will read the Link Table and present all of the stored Links (second graphic). At the bottom of the displayed table is a "Compare" button. Select this and the ISY will display a second table of what I believes "Should" be in the device. It will also highlight discrepancies. If you can post tables for a device, we should be able to determine whether they are configured correctly. The above is the process, However, the PLM table that you posted contains only 21 links. That's simply not enough links. Either something went south during the upgrade process, or you had a bad backup. Please re-try the PLM replace using the procedure that @Techman posted. If things still don't work, we'll assume that backup is bad and revert to an earlier backup.

Flashing Red is normally an indication that a controller can't communicate with a scene responder. Depending on the size of a scene, it can take significant time for the controller to send cleanup messages to each scene responder. If retries are required, the time grows longer still. Additional button presses while the controller is attempting to executing cleanup communication will likely result in the controller abandoning the activity. This could also result in the controller "flashing" an error.

@CoolToys, are you saying that you have a Tesla Powerwall and an Inverter? If that is the case, take my suggestion of moving the PLM to the main panel with a grain of salt... As shown in the other threads, the Powerwall generates noise that appears to be close to the Insteon frequency. It MAY also generate noise near the 60Hz zero crossing - that's a double whammy. Given that the Powerwall is likely tied into your main panel (or sub), you want to put some distance between the Powerwall and the PLM. Line length = Inductance = noise attenuation.

I'm going to echo @Brian H's comments. I do not have a workaround. This has been requested in years past, and it's likely on a "to do" list somewhere. Unfortunately, it's a long list... As a test, I did try manually linking a 2456S3 Appliancelinc as a 2457D2 LampLinc. This would have allowed me to replace the existing LampLinc with the ApplianceLinc. In short - I lied to the ISY. The ISY994 correctly identified the ApplianceLinc and linked correctly for the device. In other words, the ISY outsmarted me. When the UDI team first came out with the Replace feature, it was a boon to the community. SmartLabs devices were having some teething issues with power supply and paddle switch failures that mandated early replacements. KPL power supply issues were particularly painful. Replacing an 8 button KPL could easily wind up being an all day affair depending on the number of scenes and programs involved. The ISY (ISY26 or ISY99??) paid for itself the 1st time I used the replace feature. While I'll admit that there have been times where an "unrestricted" replace might have been useful, these were few and far between. The UDI team has done many amazing things given their resources but, in the end, they are a small shop. Since the early Insteon days they have branched out to Z-wave, Zigbee, and now Matter. Focusing on new device definitions for the expanded protocols (likely) has much higher ROI.

@CoolToys, It sounds like you have a lot of equipment that would be capable of absorbing/interfering with Insteon signals. My 1st suggestion would be to relocate the PLM as close as physically possible to the main panel. The panel is the Nexus of your electrical system and is (normally) the most stable/quite point. Even a temporary install can be extremely instructive. Edit: In addition to the PLM at the main panel -make sure you couple the phases at the panel... Place a dual band device (LL, APL, or range extender) on the opposite phase nearby the PLM. I would also be leery of installing the PLM on the same circuit as your A/V rack. Audio equipment incorporates very good powerline input filters. Unfortunately, many manufactures don't isolate the filters from the input - and they absorb powerline communication as a result. In other words, you may need filterlinc's (or something similar) to isolate your A/V equipment from the powerline.

@CoolToys, sorry to hear you still have some gremlins running around. Your failed scene is rather curious. The 2476D dimmer is likely powerline only. Surprising that it's the one that responded. The KPL's (V.43 and V.45) are dual band. Would have expected those to have responded. The difference between the 2476D that responded, and the KPL's that didn't, is the path that your scene command took from the PLM to the devices. The path to the 2476d is from your PLM, to the panel, and then to the 2476D circuit. The path from to the KPL's is complicated since it uses RF. It should be better due to the dual band capability. Unfortunately, this isn't perfect. I've seen dual band devices Ignore RF communication due to a low level (below noise level) insteon signal on the powerline. My advice would be to investigate the circuit the KPL's are on for signal absorbers/noise. Beyond that, you can use the "scene test" to determine whether "verification" would help here. The scene test uses the Insteon standard method of activating a scene/interrogating the responders. The PLM will poll each device to determine if it responded correctly. If it does not, it will re-try up to 5x. In my experience, the "scene test" shows failures that do not exist with standard ISY scenes. Beyond that, we may need to understand your "house" configuration (plm placement, home sq footage, #' panels, number of devices, other "problem devices") to go forward.

@JJJ, you are correct. While there is a "feature" in the ISY programming to allow you to set a scene to a specific level, it doesn't work. Turning the scene on to any level above 0% will simply execute the scene command at the stored device on levels. Turning the scene on @0% will turn the scene off. Insteon protocol does allow for scenes to be turned on to a level. This feature may have been removed previously when other devices (Z-Wave) started to be included in scenes. https://forum.universal-devices.com/topic/25805-is-set-scene-on-possible/

Device level retries as explained be LeeG: Understanding Retries in ISY

I'm thinking you may have mis-stated things here. You can't activate a scene by turning one a Controller from the Admin Console. That will activate the controller by itself. You have to activate the "Scene" from the admin console tree (or a program). If this was the case, we need to start looking for noise/signal absorbers on the responder circuits.

Are these scenes locally activated (device) or activated from the ISY? Very different scenarios. Device activated scenes will attempt to determine the status of the responders. The ISY will not.

Right click on the program and "Export" to a file, or "Export to Clipboard". You resulting file is a jumbled mess. You can manually insert carriage returns using clipboard, or find a quick XLM viewer on the web.

I'm sorry, I'm not being clear... The following is my guess based on my recent experience with the ISY994 - Your program is not triggering properly because it is not saved properly. Said differently, the program that you posted is not what is saved in XML. It was corrupted some time back and "updating/re-saving" is not changing/fixing the corruption. I saved and copied my program several times to no avail. The XML was still wrong. When you re-save, you are resetting the "last run" status and the state (true/false) of the program. It's possible that is allowing the program to trigger once. Can't tell you why without seeing the XML. I don't understand what I did to screw up my program. It was an isolated case. I had been editing the program frequently throughout the day. The program is very long with numerous embedded waits. Suddenly it began to execute things that I couldn't explain. That's what drove me to look at the XML code.

@dbwarner5, another possibility is that your program became corrupted. I ran into this a week ago and had a difficult time finding/fixing the problem. My program is shown below next to the actual XML that my ISY994 was running. They didn't match. The RED scene control is incorrect in the XML. What I saw in the program editor was correct and no number of saves, copy to a new program and saving, etc would correct it. I corrected the program by deleting the "Set Basement/ SC Basement On" statement, saving the program, and then adding the statement back. My example dealt with a "then" action that was incorrect. I could SEE that the program was turning on the wrong scene. You may have a corrupt "IF statement". That would be much more difficult to determine. You could export the program XML and inspect it for errors (somewhat painful), or simply rewrite the program. Program Program XML If <if><and /> '19.21.5C.1' is switched Off <control id="DOF" node="19 21 5C 1" op="IS"></control></if> Then <then> $FirstDining.On = 1 <var id="11" type="2"><op>EQ</op><val prec="0">1</val></var> Wait 5 seconds <wait><seconds>5</seconds></wait> Set 'Basement / SC Basement' On <cmd id="DON" node="46453"></cmd> Wait 23 seconds <wait><seconds>23</seconds></wait> $FirstDining.On = 2 <var id="11" type="2"><op>EQ</op><val prec="0">2</val></var> Set 'Basement / BSMT Back Room' Off <cmd id="DOF" node="B B7 F8 1"></cmd> Set 'Basement / BSMT Back Room Load' Off <cmd id="DOF" node="16 5C BF 1"></cmd>