IndyMike

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