IndyMike

@MMAltair , I am starting to believe that your EISY filesystem was corrupted during the power outage. You will not be able to do much with only 10 devices in your PLM. You can try another PLM restore to see if that corrects the issue, but my guess is that the EISY image has been corrupted. BEFORE you perform the restore, open the Event Viewer on Level 3. The EISY will then show you exactly which device records are being written to the PLM as in the example below. If you wind up with a "short list" of devices, the EISY image is corrupt. To restore properly, you will need to find a good backup. Programs can be exported to save them. I have had mixed results with this. The best results were obtained by exporting each subfolder to a separate file (do not try to save "My Programs" itself). You can also export individual programs. I would suggest trying this (export/import) to make sure you understand the functionality prior to restoring the backup. You can import folders/programs as a test and then hit "undo changes". If you believe you have a good restore (all 41 of your devices) then you can start working through any remaining communication issues. PLM Restore Snippet Mon 07/27/2026 08:51:35 AM : [ 53 BC 3A 1] Restoring PLM Mon 07/27/2026 08:51:35 AM : [ 58 B0 78 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 58 B0 78 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 1A 5D C7 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 1A 5D C7 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ C C2 32 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ C C2 32 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 18 93 83 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 18 93 83 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 58 B0 74 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 58 B0 74 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 16 CD 80 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 16 CD 80 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 41 21 1 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 41 21 1 1] Replacing PLM links Successful Mon 07/27/2026 08:51:35 AM : [ 29 53 3C 1] Replacing PLM links (locally and in PLM) Mon 07/27/2026 08:51:35 AM : [ 29 53 3C 1] Replacing PLM links Successful

There's a bit to unpack here... Normally when you delete a device it removes all links/scenes from the ISY. Relinking (if you chose remove existing links) refreshes the device with a responder link to the PLM and a controller link to the PLM. Your device has "old links" from scenes that no longer exist. I've never seen that before (Curious), but it's not necessarily a problem. You might try a factory reset to see if things behave differently. Also curious that you still have a (!) on this device. The ISY was able to program it and read the link table. Obviously it CAN communicate with the device. Not sure why it would flag it as non-responding. Could you perform a link table read on the device with the event viewer on level 3, then post the viewer contents? This would help to assess communications with the device. You should NOT need to remove the device from scenes prior to a delete. The ISY will do this automatically. You likely have some "pending writes" on your devices. When the ISY is asked to update a specific device it will also try to update any other devices that are flagged as needing updates. The ISY994 has a method to turn off automatic write to devices. Not sure if that is available on the EISY. That PLM table is a definite problem. It shows links to 10 of your 41 devices. It is either a partial listing (interrupted by communications) or a corrupt table. If you could try a few more reads to verify the contents, that would help. Otherwise you need to restore (or restore from a difference backup).

@MMAltair , you can disregard the mismatch @0FF0. the the "A" in the "EA" byte is a feature associated with newer device communications. For all intents and purposes, the tables are identical. This devices has controller and responder links to your PLM and nothing else. It is not currently included in any scenes. I'm a little confused by the fact that the device table shows deleted entries on lines 2, 3, and 4. Normally deleting the device/re-adding would eliminate these entries (like what I posted above). How are you deleting/re-adding? Does this device still have the (!) indicator?

@MMAltair, I am struggling to understand how your devices came to be programmed with the incorrect PLM address. The would normally require a PLM change and a corrupted restore, or a restore from a backup from a previous PLM (without the ISY knowing a New PLM was attached). Your description of events is not matching up with the symptoms. As a result, I'm very hesitant to suggest going to a new PLM. I do not see and indication that the old PLM has an issue. You have good communications, and your PLM can see device activations (sign that the PLM records are intact. Could you try restoring an older Eisy backup? Edit - before doing any thing drastic, could you perform/provide the following: Open the event viewer to level 3. Right click on a working device on the tree and select "Diagnostics\Show Device Link table" A window will pop up showing the device Links and the links will begin populating (reading in process). Once complete, click "Compare" on the lower right. Upload both the link table windows and the event viewer contents. Repeat the above for a device that is not working properly (!). Also - please confirm that your current PLM address is 3D.94.80 Example link records and event viewer for one of my devices shown below Example Link Table Read/Compare Example Link Table Communication in Event Viewer Wed 08/05/2026 07:51:58 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Wed 08/05/2026 07:51:58 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Wed 08/05/2026 07:51:58 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Wed 08/05/2026 07:51:58 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Wed 08/05/2026 07:51:59 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F FF 01 A2 00 53 BC 3A FF 1F 01 C2 Wed 08/05/2026 07:51:59 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Wed 08/05/2026 07:51:59 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA Wed 08/05/2026 07:51:59 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00) Wed 08/05/2026 07:51:59 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Wed 08/05/2026 07:51:59 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Wed 08/05/2026 07:52:00 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F F7 01 E2 01 53 BC 3A 01 00 01 CA Wed 08/05/2026 07:52:00 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Wed 08/05/2026 07:52:00 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 Wed 08/05/2026 07:52:00 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 06 (00) Wed 08/05/2026 07:52:00 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Wed 08/05/2026 07:52:00 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Wed 08/05/2026 07:52:01 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F EF 01 00 00 00 00 00 00 00 00 D2 Wed 08/05/2026 07:52:01 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1

@MMAltair thanks for the log. In general, your communications to the devices are good. The NACK's are not. These are programming errors at the device. You have 1 device that is returning a NACK (4D.9B.F0). This is an indication that a I2CS device is not programmed with your current PLM address. This should have nothing to due with a power outage. Try a "restore device" on this device. If it does not correct the problem, then the ISY image is corrupt for this unit. If this is the only device affected, a "delete/re-add" should correct the problem. If you have many devices affected we need to dig a bit deeper. I can't comment on devices that were not responding (!) because there weren't any in the log. You mentioned 15 devices that were having issues. If see the 1 NACK in the log, can't help with the others.

OK the mobile app would make sense for the rest commands. I would not suspect the new PLM programming. That would result in consistent failures for a given device. That is not my understanding of your problem. This really sound like a classic noise/signal absorption problem. You need to use a methodical process to isolate when/where the problem is. If the problem is always/frequently present, you can turn off breakers in an attempt to improve communications. Also inspect the circuit the PLM is on for any new or possibly failing devices. If the problem occurs at certain times of the day, try to alter the timing of events to improve communications (well pumps, heat pumps, photo cells, etc). These are the worst to locate. Noise/absorption related to certain devices turning on can be a horrible pain to isolate. They require a lot of patience and observation to pin down. You can use the event viewer to monitor "hops remaining" in response to a system query to assess communication quality. If you find a problem device, you can use the "show link table" feature to interrogate the device table. This is a rather intensive read procedure that will show problems if communication issues are present. As you acquire data, post it to the forum. As an example - I had a variable speed heat pump/condenser installed a few year ago. For the 1st couple of years I had no issues. Then it got hot and the heat pump started hitting 80%+ speed levels. As soon as it did, my I1 (powerline only) devices near the electrical panel went offline. Took me quite awhile to pin down. It's been pretty hot this year...

@sndflea , The Event Viewer output does not appear to match the programs that you posted - was that intentional? The log shows that you attempted to turn off 10 devices using direct commands (device specific - no scenes). Direct commands require that the device respond with it's acknowledgment of the command. 3 of the devices did not respond (Err 1). 2 of the devices appear to be older based on their addresses (2C 36 41, 18 A0 D7) and may be powerline only devices. The third is more recent (47.E2.57) and would likely be dual band (unless it's a IOlinc). Other than the errors, your communications aren't stelar, but they are not horrible either. From the statistics below, 72% of the commands used 1 Hop (good) with the remaining commands using 2 Hops (Fair). It does appear that you are dealing with signal absorption or noise. The troubleshooting links that @Geddy supplied are applicable. I find it interesting that all of the commands being issued are "rest commands" as if they originated external to the EISY. I am not that familiar with the EISY (I use the ISY994). Were these OFF commands generated by another controller or by a EISY program? Sat 08/01/2026 09:14:07 AM : Create REST U7 [/rest/nodes/2C%2036%2041%201/cmd/DON/0/51] Sat 08/01/2026 09:14:07 AM : U7 Rest: submitCmd([2C 36 41 1],[DON],[<NULL>]) Sat 08/01/2026 09:14:07 AM : [INST-TX-I1 ] 02 62 2C 36 41 0F 13 00 Sat 08/01/2026 09:14:07 AM : [INST-ACK ] 02 62 2C.36.41 0F 13 00 06 LTOFFRR(00) Sat 08/01/2026 09:14:11 AM : [D2D EVENT ] Event [2C 36 41 1] [ERR] [1] uom=0 prec=-1 Sat 08/01/2026 09:14:11 AM : [2C 36 41 1 ] ERR 1 Event Viewer Statistics Elapsed Time 0:01:41 Communications TX-I1 10 TX-I2 0 INST-ACK 10 INST-SRX 7 INST-ERX 0 Total Comms 27 Errors Unknown 0 ERR 1 3 Unexpected Response 0 Unexpected, Ignored 0 Failed 0 Hops Max Hops=3, Hops Left=3 0 Max Hops=3, Hops Left=2 5 Max Hops=3, Hops Left=1 2 Max Hops=3, Hops Left=0 0 Max Hops=2, Hops Left=2 0 Max Hops=2, Hops Left=1 0 Max Hops=2, Hops Left=0 0 Max Hops=1, Hops Left=1 0 Max Hops=1, Hops Left=0 0 Hop Efficiency 0 Hops Used 0 0.00% 1 Hop Used 5 71.43% 2 Hops Used 2 28.57% 3 Hops Used 0 0.00%

dual band devices are far better than powerline only, but that can still be affected by signal absorbers/noise. I have a filterlinc on my fancy linear compressor refrigerator because it takes 2 dual band devices offline without it (V.45) Devices can absolutely work in one direction and not the other (send vs receive). The fact that you have several devices affected normally indicates that the issue is near the PLM. The (!) indicates that a device did not respond to the ISY (On/off command, query, or programming command). A scene on/off will NOT cause a "failed to respond" (!) since it does not request status. The fact that it takes 10 minutes to delete a device indicates that ISY/PLM are re-trying communications many times during the process. I previously asked you to post an event viewer output from a query of "My Lighting" (event viewer on level 3). This will show which devices are having issues and the general status of your communications. The following is a small snippet of a "My lighting" query from my system: Hops left = 3: excellent Hops left = 0: poor Multiple communications without a response: timeout (!) My Lighting Query: Thu 07/30/2026 09:49:53 AM : [INST-TX-I1 ] 02 62 0C C2 32 0F 19 00 Thu 07/30/2026 09:49:53 AM : [INST-ACK ] 02 62 0C.C2.32 0F 19 00 06 LTSREQ (LIGHT) Thu 07/30/2026 09:49:53 AM : [INST-SRX ] 02 50 0C.C2.32 53.BC.3A 2F 04 00 (00) Thu 07/30/2026 09:49:53 AM : [Std-Direct Ack] 0C.C2.32-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/30/2026 09:49:54 AM : [INST-TX-I1 ] 02 62 18 93 83 0F 19 00 Thu 07/30/2026 09:49:54 AM : [INST-ACK ] 02 62 18.93.83 0F 19 00 06 LTSREQ (LIGHT) Thu 07/30/2026 09:49:54 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 11 00 LTONRR (00) Thu 07/30/2026 09:49:54 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/30/2026 09:49:54 AM : [INST-TX-I1 ] 02 62 58 B0 74 0F 19 00 Thu 07/30/2026 09:49:55 AM : [INST-ACK ] 02 62 58.B0.74 0F 19 00 06 LTSREQ (LIGHT) Thu 07/30/2026 09:49:55 AM : [INST-SRX ] 02 50 58.B0.74 53.BC.3A 2F 37 00 (00) Thu 07/30/2026 09:49:55 AM : [Std-Direct Ack] 58.B0.74-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 07/30/2026 09:49:55 AM : [INST-TX-I1 ] 02 62 16 CD 80 0F 19 00 Thu 07/30/2026 09:49:56 AM : [INST-ACK ] 02 62 16.CD.80 0F 19 00 06 LTSREQ (LIGHT) Thu 07/30/2026 09:49:56 AM : [INST-SRX ] 02 50 16.CD.80 53.BC.3A 2B 37 00 (00) Thu 07/30/2026 09:49:56 AM : [Std-Direct Ack] 16.CD.80-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

FWIW, If you have the event viewer open (Level 3) during a "Restore Devices" operation it will show you the actual devices being restored and the PLM records written. This can be helpful if you suspect your backup has issues. The following is a snippet from a restore operation. The 1st section shows the devices being restored. The second section shows the PLM records being written. Now the enterprising person might think they could simply count the number of write entries to the PLM to determine the record count. Unfortunately life is never the simple. Note that one of the entries has a "15" at the end rather than a "06". The "15" indicates a "NAK" (negative acknowledge) and can't be counted. In my case there were 478 PLM writes attempted or which 414 were successful (excel is very helpful here). Sun 03/29/2026 04:45:10 PM : Optimizing Device Databases Sun 03/29/2026 04:45:10 PM : [ 58 B0 78 1] Preparing Device 'BSMT Kitchen Ceiling' for Restore Sun 03/29/2026 04:45:10 PM : [ 58 B0 78 1] Device 'BSMT Kitchen Ceiling' ready for Full Restore Sun 03/29/2026 04:45:10 PM : [ 1A 5D C7 1] Preparing Device 'Bar Cans' for Restore Sun 03/29/2026 04:45:10 PM : [ 1A 5D C7 1] Device 'Bar Cans' ready for Full Restore Sun 03/29/2026 04:45:10 PM : [ C C2 32 1] Preparing Device 'Kitchen Cans' for Restore Sun 03/29/2026 04:45:10 PM : [ C C2 32 1] Device 'Kitchen Cans' ready for Full Restore o o o Sun 03/29/2026 04:45:14 PM : Reset PLM Sun 03/29/2026 04:45:16 PM : [RST-ACK ] 02 67 06 Sun 03/29/2026 04:45:16 PM : [SET-CNF-RSP ] 02 6B 80 06 Sun 03/29/2026 04:45:17 PM : [MNG-LNK-RSP ] 02 6F 40 E2 00 58 B0 78 01 20 45 06 Sun 03/29/2026 04:45:17 PM : [MNG-LNK-RSP ] 02 6F 40 E2 10 58 B0 78 01 20 45 06 Sun 03/29/2026 04:45:18 PM : [MNG-LNK-RSP ] 02 6F 41 A2 01 58 B0 78 01 20 45 06 Sun 03/29/2026 04:45:18 PM : [MNG-LNK-RSP ] 02 6F 40 E2 00 1A 5D C7 01 19 40 06 Sun 03/29/2026 04:45:19 PM : [MNG-LNK-RSP ] 02 6F 40 E2 10 1A 5D C7 01 19 40 06 Sun 03/29/2026 04:45:19 PM : [MNG-LNK-RSP ] 02 6F 40 E2 13 1A 5D C7 01 19 40 06 Sun 03/29/2026 04:45:19 PM : [MNG-LNK-RSP ] 02 6F 40 E2 13 1A 5D C7 01 19 40 15 Sun 03/29/2026 04:45:20 PM : [MNG-LNK-RSP ] 02 6F 40 E2 17 1A 5D C7 01 19 40 06

@MMAltair , If your ISY is seeing manual device activations the PLM link table is intact (for that device at least). I believe that the V.9E firmware is the latest version (has not changed in some time). This is sounding like a communication issue at the devices or the PLM: Are the devices on the same circuit - could mean a problem with that circuit. Any chance that a phase coupler died during the power outage - doesn't apply if you have newer dual band devices. Most likely is a problem near the PLM (or the PLM output stage). You might try unplugging devices on the same circuit as the PLM. If you could open your event viewer on Level 3 and perform a query of "My Lighting", then upload the results, we can get an idea how well your devices are communicating.

@Bumbershoot , my apologies. I was mixing problems. I did not mean to infer that you PLM was having issues. I do not believe that is the case. I do believe that your ISY had a filesystem issue at some point. That issue was present during your backup and your PLM replacement. This was your root cause of the issue. After this point, system, PLM, and device restores were corrupted. Separately, there was 1 previous instance reported on the forum where a PLM was reset due to a communication error. My request regarding PLM counts was one of curiosity since you saw some extremely low PLM record counts. I'm sorry for mentioning this confusing issue.

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