IndyMike

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.

To be clear, your device is responding rather well. It's the ISY that is wriwriting incorrect information due to a corrupted file. Nothing wrong with the device itself. In the end the result it the same - delete device/re-add.

It looks like that completed correctly. Unfortunately, the ISY only wrote 1 link again. It looks like the isy image for this unit may be corrupt. You can view by right clicking on the device tree and selecting /advanced/show is table. If this only shows 1-2 links you'll need to delete and re- add the device

You event viewer is a little odd. You have good communication with the device, but you experienced errors communicating with the plm. Could you please try switching communicatio from "automatic" to "device reported" mode. That should force the ISY to use I2 communication

@DIYguy , your event viewer file does not appear to be on "Level 3". It does not show the details of the communication to the device. It also does not show any errors (appears to have completed normally). It wrote ONLY the responder link to the PLM (1 link). You should have at least 2 links responer to the PLM controller to the PLM (so the device can inform the PLM of changes). Have a look at the "ISY link table" for this device (please post). If there is only 1 link the ISY link table is corrupt.

@DIYguy , since you are using a hardwired signal bridge I'm guessing you have an older system. I do as well. It would be helpfull to know what specific modules are not responding (ex: 2476d vs 2477D dual band). If the devices are single band it's possible they have been having communication issues for some time. The act of restoring them (or writing new PLM addresses) may stress your commincations enough to show the problems. It would also be very helpful if you could post a Level 3 Event Viewer log from one of your Restore sessions. It's possible that you may need to delete/re-add these devices but, as others have indicated, it's rather painful re-creating programs and scenes. There may well be some less invasive methods to get you back up and running with these modules.

Hey @aLf , in one of your other posts we noted that you were seeing ".REC" file errors in the event viewer. If that is still occuring it is beginning to sound like the EISY is having filesystem issues for some reason. If you have a recent backup, restoring the EISY should correct the errors and restore your ability to write to the devices. If you do not have a good backup - Fix your devices (delete, re-add to EISY) then make a good backup. In either case, I would suggest opening a ticket with UD. Filesystem errors do not get better with time.

From a communication standpoint, I would agree that "Status" and "Control" triggers should be equivalent. The difference is programmatic, both in the triggering and the ISY knowledge of scene membership. Example below - 2 switches (A and B) in a scene. Switch A is manually activated and the following events occur: PLM receives a Group 1 broadcast On from the switch @0B.B7.F8 ISY Notes the On status for the Switch ISY notes the On Level for the Switch (this is a relay unit) The Status change triggers programs 0023 and 0093 The ISY notes that switch 16.5C.BF is a scene member and sets its' status to on @255. Note that no communication has been received from this unit. The status change in 16.5C.BF triggers program 0093 PLM receives a direct cleanup request from switch A In different words, the Status trigger does rely on the ISY knowledge of scene membership. There is actually a lot that goes on under the hood here. It's also a good reason why the ISY is rather insistent on being THE controller in the system. It can't infer the status of devices that were linked outside it's knowledge. The control trigger will operate only on the device communication itself - no inferring of scenes as related to the trigger. The ISY will still assess scene membership and status of other devices and may trigger other programs. Program A may trigger based on a control event while program B triggers due to a status event with the same device communication. Wed 05/13/2026 08:31:17 AM : [INST-SRX ] 02 50 0B.B7.F8 00.00.01 CF 11 00 LTONRR (00) Group 1 Broadcast ON from Switch 1) Switch A Turned On Wed 05/13/2026 08:31:17 AM : [Std-Group ] 0B.B7.F8-->Group=1, Max Hops=3, Hops Left=3 Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [B B7 F8 1] [DON] [0] uom=0 prec=-1 2) ISY Notes On status Wed 05/13/2026 08:31:18 AM : [ B B7 F8 1] DON 0 Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [B B7 F8 1] [ST] [255] uom=100 prec=0 3) ISY Notes On Level Wed 05/13/2026 08:31:18 AM : [ B B7 F8 1] ST 255 (uom=100 prec=0) Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0023] STS [B B7 F8 1] ST Converted values Event=100 Condition=0 prec=0 4) Program status Triggers Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0023] STS [B B7 F8 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [B B7 F8 1] ST Converted values Event=100 Condition=0 prec=0 Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [B B7 F8 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [D2D EVENT ] Event [16 5C BF 1] [ST] [255] uom=100 prec=0 5) ISY Notes Scene B Switch On Wed 05/13/2026 08:31:18 AM : [ 16 5C BF 1] ST 255 (uom=100 prec=0) Scene Member Switch noted as On Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [16 5C BF 1] ST Converted values Event=100 Condition=0 prec=0 6) Program Status Triggers Wed 05/13/2026 08:31:18 AM : [D2D-CMP 0093] STS [16 5C BF 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Wed 05/13/2026 08:31:18 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 45 11 01 LTONRR (01) 7) Switch A Cleanup to PLM Wed 05/13/2026 08:31:18 AM : [Std-Cleanup ] 0B.B7.F8-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Wed 05/13/2026 08:31:18 AM : [INST-DUP ] Previous message ignored.

I have to agree that this is a very elegant solution. I had previously used 2 programs to test for "All OFF" in a scene (device1 and device2 and... OFF) along with a "Any On" program (device1 or device2 or .... > 0 ). I learned something today - that's a good day. My one comment would be that polling devices is not without merit depending on the communication level and criticality of the system. I would not, however, implement the polling based on a state change. The thinking here is that, if you have marginal communications, you may miss the state change from the device. Better to have a free running program that polls the devices in the scene. Case in point, my X10 floodlamps. I have a X10 booster near the PLM. Communications from the PLM to the X10 floodlamps are VERY reliable. Communications from the Flood lamps back to the PLM are less than stellar. Because of this I poll the Floodlamps at regular intervals to determine their status. The same issue can result in Insteon systems (less prevalent) depending on local PLM/Device line loading. I use the following for polling the floodlights during the day. It runs freely during the timeframe note at 15 minute intervals. Make sure "run at startup" is enabled. For Insteon, substitute a "Query scene XX" for the "Send X10 Status Request" Flood Daytime Poll - [ID 0041][Parent 0002][Not Enabled][Run At Startup] If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Flood Daytime Poll' + 15 minutes Then Send X10 'F1/Status Request (10)' Wait 9 seconds Send X10 'F3/Status Request (10)' Wait 9 seconds Send X10 'F5/Status Request (10)'

It's simply difficult to detect with a program. You have to add specific tests (triggers) for Fade Up/Fade Down. I don't happen to use the feature, but many of my family members do. I've been out-voted (even though I've declared our household a Monarchy).

@SMonk , this all depends on how fine you want to slice this onion... If you want to detect state changes then @dbwarner5 advice will perform well. For the ON state this will catch: Standard on (to preset level) Additional button press (to 100% level Fast ON It will not catch fade up (or analogous fade down). While these are rare, I do have guests that regularly tap and hold switches to brighten lights. After many years I have given up on educating family/friends on proper dimmer usage and have incorporated fade up/down in my programming. To be fair, they have acquiesced on a multitude of my failings... Fair is fair

@SMonk , I've used "master" KPL buttons for years to indicate/control the status of different scenes in my home. I typically use things like 1st Floor, 2nd Floor, Basement, and outside. The setup is very similar to what you described. I typically use the KPL buttons in non-toggle-off mode since I only use them to turn things off, but the concept is the same. Your query program is adding a failsafe that I never implemented. My one comment would be that this does become a maintenance item when you add/delete things from your Rec Room scenes. You will need to update your programs the monitor the device(s) status accordingly. This has tripped me up frequently over the years. If you happen to be a Home Assistant user, there is an easier solution to the programming.

Hey @aLf , The on thing that jumps out is the following error from your event viewer - I've seen this error reported on the forum, but have not experienced it myself. Seems to be a missing "REC" file for your device at address 3BDFFC. Ive seen forum posts where this error was associated with writing "Scene level commands" to devices. I haven't seen it associated with writing LED backlight levels, but that is a very similar operation. Solutions that I've seen on the forum involve deleting the device and re-adding to recreate the file structure. If you have a recent EISY backup that should restore the file system. Past that, you may want to consider opening a ticket.

@Smonk, I was referring to the Restore operation for the EISY itself (restore from backup). This is similar to restoring any computer system from backup. The difference in this instance is that your Insteon system is "distributed" with software in the ISY, PLM, and your devices. The ISY does a good job of coordinating things, buy they can get out of synch. Here's the scenario - I backup the ISY to file At this point the backup file contains a copy of all device tables I modify a device by adding (or deleting) it from a scene I restore the ISY from the backup in step 1 (backup now invalid). The ISY now believes the device in step 3 has a "different" link table. Any future operation (restore, add to scene, remove from scene) will cause the scene links to be overwritten. The confusing factor here is that the device will operate normally (it has the correct link table) until you restore/add to a scene/ remove from a scene after which the link table will be overwritten with outdated information. Step 1: Backup ISY Step 2: contents of "test device" vs ISY table (things match") Step 3: Add Device to scene - ISY and Device table match (links added) Step 4: Restore ISY from earlier backup (backup now outdated) Step 5: After restore, ISY device table no longer matches actual device. The device will operate properly, but future operations (add to scene, restore, etc) will overwrite links after the ISY end of record address (x0FD8)