IndyMike

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.

@oskrypuch , I'm going to try the be brief here (not easy for me). I do not think the device tables are your problem. They are a symptom. When you do a device restore, you Also write corresponding records to the PLM. I believe this is what is resetting your devices. Yes, that would mean that your PLM is again loosing links and the restore process is resetting them. Possibilities: PLM memory exceeded. Unlikely given the fact that you seem to have a medium sized system and Many devices go offline at the same time. SDCard failing (not sure if the Polisy still uses SDcards). Check the card and/or the SSD/hdd for errors. EDIT: The PolISY appears to use a SSD for it's filesystem. Unlikely that this is the issue. Communication errors between the ISY and PLM. Check cable Recommendations: Discontinue any programs that adjust backlighting or scene levels. These will cause writes to both the PLM and devices Perform a PLM restore Perform a "Show PLM Links Table". This can be difficult because network traffic will interrupt the process. Once you are satisfied that you have a valid Link Table count (perform this several times to get a consistent #) save the table. If/When your devices stop responding, perform another "Show PLM Links Table". My guess is that it will be very different. My guess is that, for what ever reason, an end of table record is being erroneously written to the PLM. When a device tries to communicate to the PLM, the PLM hits the erroneous End Of Record (does not find the device link address) and ignores the device. Edit: After re-reading your post, I would guess that your "backlight program" is causing writes to the devices and the PLM. For some reason the PLM is being written with an end of record during this operation. This would account for the < 24 hour repetition of the problem. Edit again: yet another swing and a miss. I tested the backlight and adjust scene functions. These DO NOT modify the PLM. They should not be causing what you are seeing. If may be possible for an external device to modify things using the REST interface (polyglot, etc). I'm not sure how to capture this other than looking at the event viewer on level 3. The following snippet shows the ISY writing to the PLM during a device restore. We are looking for the "02 6F" command writing to the PLM. If you could open the event viewer on level 3 and capture events over a 24 hour period we should be able to inspect for writes. Sat 06/20/2026 06:36:13 AM : [MNG-LNK-RSP ] 02 6F 40 E2 00 41 29 3D 01 20 45 15 Sat 06/20/2026 06:36:13 AM : [PLM ] Group 0 : Writing Controller Link matching [41 29 3D 1 ] Link 0 : 0FF8 [A20053BC3AFF1F01] So much for short posts....

Your link table is a bit odd, but I don't see anything that would prevent the device from communicating with the PLM Observations: Lines 1 and 6 (red) are responder link records for group 0 (normally the PLM) device @71.B3.6E. This is the link that allows your PLM to control the device. I've highlighted the links because they are essentially duplicates - this shouldn't happen. Line 5 is a responder link record for group 0 device @58.23.C7. This is another controller in your system that can control your device. Again it is not normal. If this device were to change the state of the device the PLM/ISY would probably Not know about it. Line 4 is the group 1 controller link to your PLM @71.B3.6E. Your device uses this link to communicated local changes back to the PLM/ISY. Line 3 is a group 1 controller link to device 46.7A.2B. When you turn on your local device it will communicate with this device. Line 2 is a group 4 responder link to device 46.7A.2B. Bottom line, I don't see anything that would prevent this device from communicating with the PLM (unless the duplicate records are screwing things up). Please determine what the controller device @58.23.C7 is. This may be a "leftover" from your old PLM. Link tables don't get written to unless you ASK the ISY to write them. Link tables ARE modified when changing device backlighting and adjusting scene settings. If you have programs that modify either, you may with to disable them to troubleshoot. If you find your link tables again being modified, please post back.

@Tv103165 , the flashing you are describing sounds like a device operating in RF Beacon mode (or 4 tap phase detect mode). When activated on a device: 1) devices on the opposite phase leg will flash green 2) devices on the same phase leg will flash red 3) older devices may flash white. Operation is described on pages 6 - 7 here: http://cache.insteon.com/pdf/2992-222-us.pdf I've never seen a device enter this mode by itself. I've used the mode with PLM's and plug in devices (lamplincs dimmers and relays). You typically have to press the set button 4x rather quickly. I just tried it on a Swithlinc and it functions there also (difficult to hit the set button 4x fast). Assuming that one of your devices is confused and entered this mode erroneously, turning off breakers (as suggested by @Guy Lavoie ) may be an easy way to reset. I placed one of my Lamplinc dimmers in Beacon mode and verified that power cycling reset the device. Let us know what you find - I never seen this type of failure before.

Seems like @matapan had similar issues with the "FS" format command.

@IndyUDIuser , the ".REC" files are binary files that the ISY maintains for each Insteon device in your system. The file is a "image" of the configuration for the devices (On levels, ramp rates, scenes - and other things I don't understand). The file is written to each time you change a device parameter, add it to a scene, or change a scene parameter. Forum posts seem to indicate that performing "scene adjustments" or "backlight changes" on a regular basis may increase the likelihood of file corruption. As with all file systems, an interrupt during file access is a sure fire way to corrupt the file. In past years, this was normally due to power interrupts, or SDcard failures. Search 'site:forum.universal-devices.com ".rec" file' for background on the subject. The current EISY "should" be less prone to issues due to the superior storage media. There have been a number of recent posts involving ".REC" file corruption on the EISY. My guess is that the EISY is undergoing reboot's while the ".REC" files are being written (a SWAG to be sure). Recovery is: Delete/RE-add device (recreates .REC file) Restore ISY filesystem from backup On the EISY, you can apparently replace individual device ".REC" files IF you have a valid backup. You will need to search the forum for this - I don't have an EISY - no experience.

@DIYguy , your event viewer shows 2 links being successfully written. If this was your initial link after "deleting/resetting/re-adding", that's appropriate. Hopefully that gets you past the recent speed bumps.