IndyMike

@johnjces , no cause for embarrassment. The ISY does not publish information on programming x10 codes. Unless you have a separate controller that is capable of programming devices, there was no reason to suspect an X10 code being present. I have had this happen on older powerline only units - presumably due to a communication error during programming. I have not experienced it on a V.45 unit that uses dual band communication. Keep an eye on that unit. It may be in a "poor communication" area or it may be having issues.

Perfect. There is just no substitute for good backups. Kudos Try to keep an eye on your PLM link count. Report back if you see a sudden dive. As I said earlier, there have been issues with the PLM being reset due to communication errors.

@johnjces , Insteon switches are very capable of sending X10 commands. Your log seems to indicate that the "Garage Outside Switch" is doing exactly that. How the switch came to be programmed with an X10 code, I can't say. It's actually not that easy to program the code. To remove the code, factory reset the switch. Then restore with the ISY. The ISY will NOT restore the X10 codes.

That does sound low. For reference, I have 62 devices and 408 PLM links. There is the unfortunate possibility that the file corruption occurred some time back. You may need to regress though multiple backups.

The absolute minimum number of links in your PLM should be 2X the number of devices you have. Every device should have 1 responder link (A2) and 1 controller link (E2) in the PLM. KPL's will increase this # drastically - a 6 button KPL requires a minimum of 6 responder links and 1 controller link if you have no scenes. Scenes also add to the PLM link count. If you have fewer than the Minimum link count you have missing links or the PLM read was interrupted by communications (happens frequently).

You do understand correctly. It's great that you have good backups - this should be far easier than deleting/re-adding devices and re-creating scenes and programs. I believe the ISY will restore the backup and the write PLM in one fell swoop. It may also ask if you want to restore devices (you do). Keep an eye on the messages from the ISY. The process should be: Restore ISY (backup file) Restore PLM (ISY should recognize that you have a new PLM) Restore Devices Very odd for the PLM to have 0 links. Had you checked it before? I ask because we had another forum member experience PLM resets due to serial communication errors.

@Bumbershoot , your Switchlink is missing the Link that tells it to be a controller to the PLM. From my SWL table below, the E2 entry @0FC8 tells the unit that it is a controller of the device @53.BC.3A (my PLM). Your device doesn't have this link. Without it, the SWL will not communicate to the PLM when it is activated. Unfortunately, the ISY believes the table is correct. That means the ISY data is also corrupt. You could delete/re-add this device but you seem to have quite a number of scenes that it is involved with - that sound painful. You also mentioned that your PLM seemed to have surprisingly few Links - could you quantify that (number of links vs number of installed devices)? Given the above, I'm leaning toward asking you to install from a previous backup (Restore ISY).

Hey @Bumbershoot , The fact that your device restores didn't work and your PLM record count is low is rather foreboding. This normally (not always) means that the ISY configuration itself is incorrect. Could you perform a "Device Link Table Read/Compare" of one of your switchlincs and post it? Also, please provide your current PLM address. From this we can try to figure out the least painful path forward.

@IndyUDIuser , As @Guy Lavoie indicated, changing ramp rates, on levels, backlights and Adjust Scene commands write to devices EEprom. You may choose to use them in a program that gets activated 2x/day. Using them in a Looping program is unwise. Adjusting the backlight on a device is also a rather communication intensive activity. This is likely why you saw the "system busy" notification. The ISY makes this so easy to accomplish that it's not at all obvious what is going on "under the hood". Timing/communication varies depending on the type of device involved. The follow sample timings are for setting the backlight to zero and assume "perfect" communication timing: Old I1 Devices: 2 seconds - 8 I1 send/receive comms I2 Devices: 1 second - 2 I2 send/receive comms I2CS Devices (most newer devices): 2 seconds - mixture of 5 I1/I2 comms For the program shown above (set backlight to 0, wait 1 second, set backlight to 100%) the times shown above would be 2x + 1 second. You can easily see that you are at (or over) the 5 repeat time under perfect conditions. If you encounter external powerline activity, rest activity, or device retries, things will go sideways quickly. A couple of "interesting" observations regarding using these commands in programs: If you disable "automatic writes to devices" (ISY994 Pro), programs will run, but they will NOT write to the device EEprom (no communication in event viewer). If you have devices with pending writes (green 11010 showing), a program that writes to a Different Device EEprom will trigger the ISY to perform the pending write (ISY994 Pro again). Your solution of using the "Beep" command is an excellent one. I often use this when I can't remember where a particular device is located. You can further reduce overhead by placing your device in a scene and "Beeping" the scene. I1 Peek/Poke Backlight Write: 8 comms/2 seconds Thu 07/16/2026 10:33:15 AM : [All ] Writing 2 bytes to devices Thu 07/16/2026 10:33:15 AM : [B B7 F8 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Thu 07/16/2026 10:33:15 AM : [INST-TX-I1 ] 02 62 0B B7 F8 0F 28 02 Thu 07/16/2026 10:33:15 AM : [INST-ACK ] 02 62 0B.B7.F8 0F 28 02 06 SET-MSB(02) Thu 07/16/2026 10:33:15 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 2F 28 02 SET-MSB(02) Thu 07/16/2026 10:33:15 AM : [Std-Direct Ack] 0B.B7.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:33:15 AM : [INST-TX-I1 ] 02 62 0B B7 F8 0F 2B 64 Thu 07/16/2026 10:33:15 AM : [INST-ACK ] 02 62 0B.B7.F8 0F 2B 64 06 PEEK (64) Thu 07/16/2026 10:33:16 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 2F 2B 7F PEEK (7F) Thu 07/16/2026 10:33:16 AM : [Std-Direct Ack] 0B.B7.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:33:16 AM : [INST-TX-I1 ] 02 62 0B B7 F8 0F 29 00 Thu 07/16/2026 10:33:16 AM : [INST-ACK ] 02 62 0B.B7.F8 0F 29 00 06 POKE (00) Thu 07/16/2026 10:33:16 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 2F 29 00 POKE (00) Thu 07/16/2026 10:33:16 AM : [Std-Direct Ack] 0B.B7.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:33:16 AM : [INST-TX-I1 ] 02 62 0B B7 F8 0F 24 00 Thu 07/16/2026 10:33:16 AM : [INST-ACK ] 02 62 0B.B7.F8 0F 24 00 06 (00) Thu 07/16/2026 10:33:17 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 2F 24 00 (00) Thu 07/16/2026 10:33:17 AM : [Std-Direct Ack] 0B.B7.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:33:17 AM : [B B7 F8 1 ] Memory : EPROM Refreshed Thu 07/16/2026 10:33:17 AM : [All ] Writing 0 bytes to devices I2 Backlight Write: 2 comms/1 second Thu 07/16/2026 10:35:23 AM : [All ] Writing 1 bytes to devices Thu 07/16/2026 10:35:23 AM : [1A 4F 19 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Thu 07/16/2026 10:35:23 AM : [INST-TX-I2 ] 02 62 1A 4F 19 1F 2E 00 00 03 00 00 00 00 00 00 00 00 00 00 00 CF Thu 07/16/2026 10:35:23 AM : [INST-ACK ] 02 62 1A.4F.19 1F 2E 00 00 03 00 00 00 00 00 00 00 00 00 00 00 CF 06 (00) Thu 07/16/2026 10:35:24 AM : [INST-SRX ] 02 50 1A.4F.19 53.BC.3A 2F 2E 00 (00) Thu 07/16/2026 10:35:24 AM : [Std-Direct Ack] 1A.4F.19-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:35:24 AM : [All ] Writing 0 bytes to devices I2CS Backlight Write: 5 comms/2 seconds (mixture of I1 and I2) Thu 07/16/2026 10:36:35 AM : [All ] Writing 1 bytes to devices Thu 07/16/2026 10:36:35 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Thu 07/16/2026 10:36:35 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Thu 07/16/2026 10:36:36 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Thu 07/16/2026 10:36:36 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:36:36 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 00 A2 00 53 BC 3A FF 1F 01 B8 Thu 07/16/2026 10:36:36 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 07/16/2026 10:36:36 AM : [41 1E 9 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Thu 07/16/2026 10:36:36 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB Thu 07/16/2026 10:36:36 AM : [INST-ACK ] 02 62 41.1E.09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06 (00) Thu 07/16/2026 10:36:37 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2E 00 (00) Thu 07/16/2026 10:36:37 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/16/2026 10:36:37 AM : [All ] Writing 0 bytes to devices

Didn't know this existed - thank you

@TheRydad , I use the Whitepapers (somewhat outdated) and PLM/Hub developer docs. Hard to come by from Insteon these days, but they can be found on 3rd party sites. https://madreporite.com/insteon/insteon.html

@oskrypuch , it looks like all your data is there. For some reason it's been re-ordered. The following shows the entries for your device @46.7A.2B. The column names correspond to the XML entries - ix - PLM record number (Dec) ad - PLM record number (Hex) fl - Flag (Hex). "E" = controller, "A" = Responder gr - Group # (Hex) id - Device address (Hex) data - Device specific data (on level, ramp rate, varies by device/scene) It looks like your second table was re-written in "group ascending" order. I don't know why this was done. I spot checked a couple of other devices - they were not altered. In any event, it looks like your PLM is managing to hold onto its data

Well sh$t, I had not had you pegged as an optimist. Go figure...

@TheRydad , I apologize, but my thoughts and ideas are coming rather lame. The behaviour you are describing makes sense based on the link tables. I don't really understand why this occurred, and don't have an easy solution. It's possible the power interrupt resulted in a FUBAR event. Regardless, I would suggest you open a ticket to see if UD can offer a recover path that doesn't involve deleting/adding 100's of scenes. I've commented your original table below. What is significant is what is NOT shown. Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has no controller link (Flag E2) to the PLM. It can't communicate any local changes to the PLM. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FF0 and 0FE8) Count Addr Flag Group Addr Data Description 0 0FF8 A2 00 58.22.7E FF1F01 Responder to Group0 PLM 1 0FF0 A2 01 58.41.BB FF1F01 Responder to Group1 58.41.BB 2 0FE8 E2 01 58.41.BB 010001 Controller of Group1 58.42.BB 3 0FE0 AA 00 58.22.7E FF1B01 Duplicate responder to Group 0 PLM 4 0FD8 00 06 58.31.9E 001B01 End of record The Scene delete/add fix a couple of things (highlighted): Your device at 58.41.80 has group 0 responder links to the PLM at 58.22.7E (Addr 0FF8). It has a controller link (Flag E2) to the PLM at Addr 0FF0. Your device is a responder to Group 16 as controller by the PLM (Addr 0FE8). This is the scene link you were missing. Your device can control and respond to the device @58.41.BB - it is a scene member (Addr 0FE0 and 0FD8) Count Addr Flag Group Addr Data Description 0 0FF8 A3 00 58.22.7E FF0101 Responder to Group0 PLM 1 0FF0 E2 01 58.22.7E 010001 Controller of Group1 PLM 2 0FE8 A2 16 58.22.7E FF1A01 Responder of Group 16 PLM 3 0FE0 E2 01 58.41.BB 010001 Controller of Group1 58.42.BB 4 0FD8 A2 01 58.41.BB FF1F01 Responder of Group1 58.42.BB 5 0FD0 00 00 00.00.00 000000 End of record

Can you show us what the link tables look like: Before and after you remove/re-add the devices to a scene. IOX table vs a device that has Not been fixed via the scene delete/re-add procedure.

@oskrypuch , that actually doesn't look normal. I'm hoping that something simply moved around in the PLM. That could happen if you were adding/deleting scenes. Would you mind posting your tables? I normally import to excel so I can see them in Hex.

My second Python project. 1st was interrogating yahoo finance for stock dividends and the like. I am an absolute hack when it comes to software. Background is Fortran IV, C, Pascal, and Cobol. Python was surprisingly easy to pick up. A friend from work set me up with a Spyder 6 package and I've been playing ever since. Is I indicated earlier, it was @kclenden that put me on this path. He was the one that noted the errors in the event viewer.

Yes - The following is a history of errors VS request delay for the restore of a KPL. The restore process requires ~800 I1 commands. I tried increasing and decreasing delays. Also repeated delays multiple times and re-checked the 500 mSec because I couldn't believe what I was seeing. I don't understand why, but 500 mSec was the worst.

That's unfortunate. Thanks for checking

Question for those of you who have a PolISY or Eisy - The ISY994 has a configuration shell that can be accessed through telnet. One of the items in the shell is a "CD" or "configure delay between requests. I interpret this to be a delay between successive requests to the PLM. My ISY994 was originally set to a CD timing of 500mSec. I found this to be a very bad setting for my system. I have been using 1000 mSec for most of this year with good results. My question is - does the PolISY or EISY have something similar to this timing feature? It can be extremely helpful in preventing overrunning the PLM when things don't go as planned.

@oskrypuch , hope it helps. Please do report back. As I said, this is the 1st time I've seen this. Likely will not be the last.

@oskrypuch , I have to give credit to @kclenden . Some time ago he opened my eyes to the fact that ISY to PLM errors are occurring. I have been monitoring them on my system with the ISY994. To date I have seen 1 verified instance of a "All-on" caused by a communication error. Yours was the 1st instance of a communication error causing a PLM reset. I had not previously conceived of that. I would say that cutting down on the fast repetitive communication would definitely help reduce the issue. Bottom line, if you didn't have issues prior to the program modification, that's most likely your answer. As a go forward, I would recommend a full PLM restore followed by individual device restores. The PLM log that you posted only contained 8 devices.

@oskrypuch , not what I expected, but your PLM is definitely being reset due to a communication error with the ISY Observations: You have a mind numbing amount of communication to two devices that I believe are thermostats (11.B2.60 and 0E.67.7F). you appear to be requesting temperature data from each of these every few seconds. That's 12 send/receive communications in 5 seconds and it repeats roughly every 30 seconds. In 2 hours and 4 minutes you had over 5K send/receive comms or roughly 1 every 1.4 seconds. Your communications to the devices are excellent. 96% of your communication with the two devices was received with 3 hops remaining. It doesn't get much better than that. You did have 2 communication errors between the ISY and the PLM. The PLM will normally echo a serial command back to the ISY. Sometimes the echo is incorrect. You had two of these. We've seen rare cases where these can cause the dreaded "All-on". The errors in your log appeared innocuous at first. When I looked closer, a communication to the PLM was interpreted as a "Reset Modem" command. You also had two serial communication timeout errors. This is where the ISY sends a command and the PLM does not echo it back. My scanning routine declares a timeout if nothing is received back within 10 seconds, or if xx commands have been executed. The following snippet from your event viewer log shows 4 normal ISY to PLM exchanges. The ACK is the PLM acknowledging the transmission. The 5th exchange is corrupted. The PLM appears to have byte shifted the ISY command. It believes the ISY is requesting a Modem Reset 10269 Sat 06/20/2026 12:40:04 PM : [INST-TX-I1 ] 02 62 0E 67 7F 0F F0 E8 10271 Sat 06/20/2026 12:40:04 PM : [INST-ACK ] 02 62 0E 67 7F 0F F0 E8 06 (E8) 10277 Sat 06/20/2026 12:40:04 PM : [INST-TX-I1 ] 02 62 0E 67 7F 0F 6A 00 10279 Sat 06/20/2026 12:40:04 PM : [INST-ACK ] 02 62 0E 67 7F 0F 6A 00 06 (00) 10285 Sat 06/20/2026 12:40:04 PM : [INST-TX-I1 ] 02 62 0E 67 7F 0F 6B 02 10287 Sat 06/20/2026 12:40:04 PM : [INST-ACK ] 02 62 0E 67 7F 0F 6B 02 06 (02) 10293 Sat 06/20/2026 12:40:05 PM : [INST-TX-I1 ] 02 62 0E 67 7F 0F F0 49 10295 Sat 06/20/2026 12:40:05 PM : [INST-ACK ] 02 62 0E 67 7F 0F F0 49 06 (49) 10301 Sat 06/20/2026 12:40:05 PM : [INST-TX-I1 ] 02 62 0E 67 7F 0F 6A 20 10303 Sat 06/20/2026 12:40:08 PM : [RST-ACK ] 02 67 06 My 1st suggestion would be to reduce the number of queries to your thermostat by a factor of at least 100. Temperatures simply don't change that fast. Currently thinking through other workarounds.

I am looking at the event viewer. Nothing obvious at the moment. This may take some time....

@Guy Lavoie , not as of yet. I do not see anything in the device link tables that would stop it from responding to the PLM. That leaves the PLM table itself, and @oskrypuch has had isssues with previous PLMs loosing records. That's why I was asking @oskrypuch to perform the "Show PLM Links Table" and save. I am guessing that within 24 hours the table will have changed. This will confirm that it's a PLM table problem. To determine why the PLM table is changing, I asked for a "event viewer capture" over a 24 hour period. This would hopefully show the actual command that is modifying the PLM table. To be clear, I have never seen this before on my ISY994. The PolISY and EISY have many plugins and rest devices that I do not have. It's possible that one of them is causing an issue. I am also not aware of a REST command that can modify the PLM table, but I am open to learning.