IndyMike

I don't have a good answer to your question on how to determine PLM link record #'s. Earlier posts suggested putting the PLM on a filterlinc to "reduce" insteon communication (https://forum.universal-devices.com/topic/6979-countingestimating-plm-links/#findComment-55359). I've actually had limited success with that - probably due to RF communication. As far as reducing the link count - have a look at your large scenes to see if you have redundancies. Unfortunately, if you can't get a good link count, you won't know how many links to delete. Thanks for the Aeotec info.

Not quite. The ISY knows the address of the dimmer module - it sends that address to the PLM so it can communicate with the device. If you are over the link limit, the PLM will not be able to find the address of the dimmer. If you manually activate the dimmer, the PLM will ignore the communication (just as it is doing with the MS). The Z-wave motion will circumvent the problem for the time being. No telling how many devices/links you have that are beyond the magic #. Which Z-wave motion are you using? I'm always on the lookout for reliable motion sensors.

Sounds like you stepped over the magic line again. I find it is best to run the PLM test in the early AM when the rest of the house is asleep. Two consecutive tests with the same # of links is considered a good test. You could also try performing a "restore modem". In doing this the ISY may be able to recover link records by consolidating memory from deleted devices and scenes. Perform a ISY backup first to be safe. I just performed this on my PLM and was able to recover 150 records (I do a lot of adding/deleting during testing).

#4 - sounds like you ISY (EISY) is being interrupted during the PLM record read. You may want to try in "off" hours. I was asking you to "trigger the motion sensor" (create motion) to see if the PLM registered the communication. Since you did NOT see any communication in the event viewer, you are NOT receiving the signal from the motion sensor. Either your PLM is outside the RF/powerline range of the motion sensor (unlikely since your just re-added the sensor), ...or the PLM does not have the correct link records to receive the communication. Normally, that would imply that you have exceeded the PLM link record capability (~1000 links).

That should work. If it doesn't your PLM isn't hearing the Motion Sensor or has lost the link for it. Open the Event viewer and trigger the motion sensor to see if the PLM is registering the communication. You should also see the program executing your "study cans on" command. Please post the results. Other options: Make sure your program folder isn't disabled. Power cycle the PLM and ISY. Check the number of links in your PLM (max 1000)

I missed the fact that you located an incorrect INIT value... Beyond that, I'll admit that the scene adjust method produces elegant results. I personally don't care for the overhead involved. In terms of the write cycles involved, you probably will not wear out the EEprom before something else dies (power supply, etc). Most EEprom devices are rated at 100,000 cycles. At 2 writes (AM/PM) per memory location per day your device EEprom would last 137 years. Sorry - I should have used my Maths before my previous post. The raw amount of communication required is a concern. Communication errors could result in corrupted device link tables and scene errors. You can check this by performing a link table "compare" from the admin console. You can use a time qualified program to call a scene and produce similar results. Use the scene controllers as the program triggers. My example scene above would look like the following. Note that I inserted a second wait After the Trigger and before calling the Scene - This is because the trigger (BSMT Stair) is part of the Scene (BSMT ENTRY). Best practices call for the wait to prevent potential communication collisions at the PLM which can in turn trigger the dreaded "ALL ON" phenomena. The event viewer communication for the command is shown at the end. Test - [ID 0071][Parent 0003] If From 9:30:00PM To 7:05:00AM (next day) And 'Basement / BSMT Stair' is switched On Then Wait 2 seconds Set 'Basement / SC BSMT Entry' On Else Set 'Basement / SC BSMT Entry' On Scene On communication Mon 03/31/2025 11:56:07 AM : [INST-TX-I1 ] 02 62 00 00 43 CF 11 00 Mon 03/31/2025 11:56:07 AM : [INST-ACK ] 02 62 00.00.43 CF 11 00 06 LTONRR (00)

Wow, that's a lot of updating for day/night on levels. I'll confess that I've never really used the "Adjust Scene" program feature. I prefer to generate specific scenes for different levels and call them through a program. I'll admit that what you are trying to do would result in an "elegant" changeover in device on levels. The price you pay is an extreme amount of communication and many writes to device and PLM EEprom memory. The high communication level opens the door for errors. Excessive EEprom writes can actually wear out the memory devices. You also need to be very careful that you are writing to ALL the scene controllers as well as the Admin Console scene (in case the scene is called by a program). At a minimum, you should insert some wait statements to allow the link table writes to complete. Based on what I'm seeing with PLM write timing, the wait should be around 5 seconds. Try opening the Event Viewer (level 3) and manually running your program. You'll be amazed how much communication results. I tried adjusting 1 scene with 1 controller - the program and Event viewer communication are shown below. You will have MANY times this amount of communication. Answering "Why did I have to Re-create my Scene" - Communication errors during link table writes - or - Worn out EEprom memory (PLM or Devices). Hopefully it's #1. Test - [ID 0071][Parent 0003] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then In 'Basement / SC BSMT Entry' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 2.0 seconds Wait 5 seconds $IOnLevel = 100 In 'Basement / BSMT Stair' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 0.5 seconds Else - No Actions - (To add one, press 'Action') The following is the Event Viewer Communication generated by the above program Mon 03/31/2025 10:28:40 AM : [ Time] 10:29:02 21(0) Mon 03/31/2025 10:28:40 AM : [26898]->[41 1E 9 1] link updated Mon 03/31/2025 10:28:40 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Saving [..........FF....] Mon 03/31/2025 10:28:40 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Saving [............1B..] Mon 03/31/2025 10:28:44 AM : [All ] Writing 2 bytes to devices Mon 03/31/2025 10:28:44 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 Mon 03/31/2025 10:28:44 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) Mon 03/31/2025 10:28:44 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:44 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 Mon 03/31/2025 10:28:44 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 03/31/2025 10:28:44 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Writing [..........FF1B..] Mon 03/31/2025 10:28:44 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90 Mon 03/31/2025 10:28:44 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90 06 (00) Mon 03/31/2025 10:28:44 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:44 AM : [All ] Writing 0 bytes to devices Mon 03/31/2025 10:28:45 AM : [1A 5D 6D 1]->[41 1E 9 1] link updated Mon 03/31/2025 10:28:45 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Saving [..........FF....] Mon 03/31/2025 10:28:45 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Saving [............1C..] Mon 03/31/2025 10:28:45 AM : [All ] Writing 2 bytes to devices Mon 03/31/2025 10:28:45 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 Mon 03/31/2025 10:28:45 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) Mon 03/31/2025 10:28:46 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:46 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:46 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 Mon 03/31/2025 10:28:46 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 03/31/2025 10:28:46 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Writing [..........FF1C..] Mon 03/31/2025 10:28:46 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E Mon 03/31/2025 10:28:46 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E 06 (00) Mon 03/31/2025 10:28:47 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:47 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:47 AM : [All ] Writing 0 bytes to devices

@SirParadox , your device B isn't capable of "pushing back" a link to device A. The only way for device B to write links in device A would be if you Manually linked the device. If that were to happen, the ISY would have no record of the links (it would show up as a mis-match) and you could easilly restore the device. If you believe the link tables in both devices are incorrect, you will need to delete, factory reset, and re-add both devices.

@SirParadox, the device 3D.96.1C appears to be a PLM. It is listed as a controller for group 0 of your family room overhead device. It is possible that this is an OLD PLM (check your current PLM address to verify). In any case, the ISY believes the links to be correct. Restoring this device from the ISY will simply re-write the same links. If you are sure that the links are incorrect, the quickest way to rectify is to proceed as @apostolakisl indicated in his Option #2 above (delete device, factory reset, re-add to the ISY).

@Tmc, I'm in agreement with @paulbates. Since it appears that you have having problems communicating with numerous devices, it's likely you have a noise source or signal absorber near the PLM location. Look for PC's, chargers, printers, UPS's that are common culprits, and remember that electrical devices do go bad. Another option could be your phase coupling. It's interesting that your system was working with the 2412S which is not dual band. The 2413S is dual band and would presumably perform better in a noise environment. How were your phases coupled before? Note that the 4 tap test (beacon test) that Paul suggested is an excellent way to detect phase issues.

@oberkc, I'm thinking you are using the PG3 HUE plugin to communicate with a HUE HUB - correct? It sounds as if @greensha is attempting to connect directly to the HUE bulbs by enrolling them as Zigbee devices.

@pjjameso, your timer program is marked "Run at startup". Can you see it running in the "program summary tab" (you've probably already looked). If not, try a manual start (Run Then) to see if things run and continue. If everything looks good with the timer program, try re-writing and saving the "Airthings AQ Normal" program. I have seen instances where the "text" of a program is correct, but the saved XML is not. A simple Edit/Save will not correct this.

@AD8BC, as you probably already realize, your PLM is only linked to 4 devices. Something is seriously wrong with the restore. If you have a recent backup, try restoring the EISY then follow with a PLM replace procedure (EISY needs a reboot to recognize the New PLM).

@Tmc, sorry for the delay in responding - I was on the road. Answers: I "save" the PLM table as an XML file and then Import to Excel as an XML table. it allows be to sort columns and select individual device addresses for inspection. Unfortunately the values in the XML file are in decimal. You have to convert to Hex (+dec2hex) for them to make sense. Curious - my file save with an .XML extension. Most browsers can open it and it appears as you have shown above. In order to format the data, you can open the file with Excel or use a XML viewer. The link 325 that is shown is a "responder" link. As I indicated earlier, I believe the ISY leaves these. As @Techman indicated, the PLM link read isn't perfect and can be interrupted. I run the process 2 - 3 times in a row to make sure things are consistent.

@walkman9999, Had the chance to look at the files you up loaded. Your _Northgate program has a lot going on. Many Device Direct Fast ON commands in succession, followed by a scene command, and then more Direct commands. The rapid succession of these commands are bombarding the PLM and may be confusing it. In my experience, the PLM is rather good at handling stacked commands (back to back). But then I use the older ISY994. The EISY is far faster, and may be capable of overwhelming the PLM. I've posted a section of your event viewer below the program listing. Your fist Insteon command is a Fast ON to device 29.18.D7 Highlighted yellow). The normal sequence would be: Wed 02/12/2025 16:46:26 : [INST-TX-I1 ] 02 62 29 18 D7 0F 12 00 (Fast on Command to PLM) Wed 02/12/2025 16:46:26 : [INST-ACK ] 02 62 29.18.D7 0F 12 00 06 LTON-F (00) (Acknowledge from the PLM) Wed 02/12/2025 16:46:26 : [INST-SRX ] 02 50 29.18.D7 71.1B.41 2B 12 00 LTON-F (00) (Acknowledge from the device) I've highlighted all 3 in the event viewer listing below. These would normally be in sequence. As you can see, you have many other commands in between, as well as the curious "Link for responder XX.XX.XX not found". I believe this is the PLM informing the ISY that it doesn't contain the link for these devices. The thing is, I looked at your PLM listing and it most certainly does contain the links for these devices. As I said, confused. In general, the communication response activity I see in the event viewer log looks rather good. Two or three hops remaining fall all devices (Including older I1 devices). You may have some communication issues, but they were not apparent in the log. That's good. You may have "isolated" issues on some circuits, rather than wide spread issues due to a problem PLM location. Suggestions: Insert some short waits between some of your Insteon commands. If you suspect a scene issue, insert a longer wait before the scene command. Your programs were attached in an XLM format. Very few forum members can interpret it (and I have trouble). If you would please right click on the program and select "copy to clipboard", you'll be able to paste a "text version of your program. Many far more experienced people than I will be able to assist with suggestions. It looks like the Eisy is still using the deprecated Peek/Poke method of restoring your older devices. Did you try switching the Eisy to the "Device Reported" mode under "Advanced Options"? XLM Program Listing <?xml version="1.0" ?> <triggers> <d2d> <trigger> <id>50</id> <name>_North Gate</name> <parent>53</parent> <if> <and /> <status id="ST" node="55 18 EA 1" op="IS"> <val uom="51" prec="0">100</val> </status> <and /> <status id="ST" node="1A B3 C1 1" op="IS"> <val uom="51" prec="0">0</val> </status> <and /> <schedule> <from> <sunset>-1800</sunset> </from> <to> <sunrise>1800</sunrise> <day>1</day> </to> </schedule> </if> <then> <var id="3" type="1"> <op>EQ</op> <val prec="0">1</val> </var> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="49 B2 50 1"></cmd> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="1A 61 8D 1"></cmd> <cmd id="DFON" node="1A B3 C1 1"></cmd> <cmd id="DFON" node="29 18 D7 1"></cmd> <cmd id="DFON" node="29 1 8A 1"></cmd> <cmd id="DFON" node="2A B 38 1"></cmd> <cmd id="DFON" node="1A B7 F 1"></cmd> <notify content="1">1</notify> <cmd id="DON" node="11711"> <p id=""> <val uom="51" prec="0">100</val> </p> </cmd> <wait> <seconds>30</seconds> </wait> Event Viewer Log (Partial) PLM Table Sorted for Group 19 Scene Members

@walkman9999, unfortunately I am traveling through Friday. Can't help with the link tables at the moment. I did look at the restore log. You encountered an error writing to a device 1b.b0.cc. This looks like an older device that may be powerline only. As @oberkc indicated, this device would be a prime candidate for a restore. I'll try to have a look at the rest when I return.

As usual, I could not leave this alone... Anyone who has read my posts knows that they are rarely short, and never very interesting. Read on at your own peril... I ran another test deleting a KPL from my PLM. I compared the PLM link tables before and after the delete. Observations: The ISY deleted the control link (E2) for group 0 at address 14H from the table. This makes sense - leaving the link would allow the PLM to try to interrogate the device even though it didn't exist. Think PLM timeouts, retries, and the whole mess. The ISY DID NOT delete the responder links (A2) for groups 1 though 6 (main button and secondaries). I suppose these are viewed as harmless links. The can't do any damage if the device isn't there to communicate with the PLM. With the "deletion" of the Link @14H, all of the following link addresses shifted up by 1. The PLM now shows 1 fewer total links (497 vs 498). The above makes sense to me except for Item 3. There is no way the ISY had time to delete the link @14H and REWRITE ALL OF THE FOLLOWING links. Anyone who has restored a PLM knows it takes a significant period of time. This operation took seconds. This leads me to the conclusion that the ISY DID mark the record @14H as "available" (22). During the subsequent PLM link table read, the record @14H was IGNORED since it was marked as "available". The PLM Link read operation is very different from the device link read operation. The device read operation is handled by the ISY through read commands for each link location. The ISY displays all Link table information including "available" records. The PLM Link Read operation is handled by the Insteon "Get Next ALL-Link Record". This command apparently skips the records marked as "available". I now yield the soap box... IM

@Tmc, my apologies - I was wrong. I just deleted a device from my system and the PLM responder links are still are still there. I'm scratching my head at the moment... Event Viewer: Mon 02/10/2025 06:22:32 PM : [58 C9 B0 1 ] Start : Removing device from ISY Mon 02/10/2025 06:22:32 PM : [58 C9 B0 1 ] Finish : Removing from ISY was Successful PLM Table:

@Tmc, you are correct that there is a record with your device address still in the PLM. If you look at the flag column you should see a "22". This is the sign that the ISY has marked the record as "Unused". In order to completely remove the information, all of the links following the record would need to be removed. Simply marking the record Unused gets the job done quickly. If you find that you have many "unused" records you can perform a PLM restore to rewrite the entire PLM. The ISY will remove the unused records. The same technique applies to devices. The "22" is used to mark records unused, and a Device Restore will rewrite and remove the unused records.

@walkman9999, your Switchlinc Dimmer appears to be a 2476D that is powerline only. Communication with the device isn't great and that can be a problem when trying to restore a device. It might be possible to install a dual band LampLinc or other RF device electrically near the Dimmer to help with communications. It's also possible that the noise or signal absorption is temporary due to a problem device in the vicinity. Try inspecting for typical problem devices (PC's, chargers, UPS's, etc) in the vicinity. Another thing that is not in your favor is that the ISY is using and old I1 programming mode with this device. The Event Viewer communication below is from your Restore sequence. The Red section is where the ISY attempted a I1 write sequence that timed out after 3 tries. The following green section is a successful write that was performed using I2 (much faster). You could try to "force" the ISY to use I2 communication by going to Link Management/Advanced Options and selecting "Device Reported". The I2 protocol allows the ISY to transfer data in far fewer command sequences than the I1 mode. The communication is still susceptible to noise/absorption issues, but there are far fewer opportunities for failure. Sun 02/09/2025 14:11:28 : [ 1B B0 CC 1] Preparing Device 'Shed Bathroom' for Restore Sun 02/09/2025 14:11:28 : [ 1B B0 CC 1] Device 'Shed Bathroom' ready for Full Restore Sun 02/09/2025 14:11:28 : [All ] Writing 28 bytes to devices Sun 02/09/2025 14:11:28 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 0D 00 Sun 02/09/2025 14:11:28 : [INST-ACK ] 02 62 1B.B0.CC 0F 0D 00 06 (00) Sun 02/09/2025 14:11:30 : [INST-SRX ] 02 50 1B.B0.CC 71.1B.41 27 0D 01 (01) Sun 02/09/2025 14:11:30 : [Std-Direct Ack] 1B.B0.CC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/09/2025 14:11:30 : [1B B0 CC 0 ] Calibrating engine version Sun 02/09/2025 14:11:30 : [1B B0 CC 0 ] May not fully support i2, reverting to i1 Sun 02/09/2025 14:11:30 : [1B B0 CC 1 ] Link 0 : 0FF8 [A200711B41FF1F01] Writing [A200711B41FF1F01] Sun 02/09/2025 14:11:30 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:30 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:39 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:39 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:48 : [INST-TX-I1 ] 02 62 1B B0 CC 0F 28 0F Sun 02/09/2025 14:11:48 : [INST-ACK ] 02 62 1B.B0.CC 0F 28 0F 06 SET-MSB(0F) Sun 02/09/2025 14:11:52 : [1B B0 CC 1 ] Link 0 : 0FF8 [A200711B41FF1F01] *Failed Writing [A200711B41FF1F01] Sun 02/09/2025 14:11:52 : [1B B0 CC 1 ] Memory : Write dbAddr=0x0264 [0C] cmd1=0x2E cmd2=0x00 Sun 02/09/2025 14:11:52 : [INST-TX-I2 ] 02 62 1B B0 CC 1F 2E 00 00 03 0C 00 00 00 00 00 00 00 00 00 00 C3 Sun 02/09/2025 14:11:52 : [INST-ACK ] 02 62 1B.B0.CC 1F 2E 00 00 03 0C 00 00 00 00 00 00 00 00 00 00 C3 06 (00) Sun 02/09/2025 14:11:54 : [INST-SRX ] 02 50 1B.B0.CC 71.1B.41 27 2E 00 (00) Sun 02/09/2025 14:11:54 : [Std-Direct Ack] 1B.B0.CC-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/09/2025 14:11:54 : [1B B0 CC 1 ] Memory : Write dbAddr=0x0032 [FF] cmd1=0x2E cmd2=0x00

@BRMeeke, 26 KPL's is a lot. That consumes a lot of links in the PLM (1024 max) and nodes in the ISY (1000 max). Keep an eye on both.

@dleduc, I think you may be misinterpreting how the variable is being used in this statement. The Set 'Mister' On '$Timer %' will transfer the value of the variable as the ON LEVEL for the "mister" device. Valid range is 0 to 100%. The Example Program below sets the On Level of one of my dimmers to 4 different levels specified by the Variable 'IOnLevel'. 100 = 100% and 0 = off. The event viewer shows the ISY commanding the dimmer through the 4 different states. Note that this applies to devices only. If you attempt to assign a variable % to a scene you will only be able to command ON/OFF (anything >0 = ON, 0=OFF). Variable On Level - [ID 0070][Parent 0067] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $IOnLevel = 100 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Wait 1 second $IOnLevel = 50 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Wait 1 second $IOnLevel = 10 Set 'Basement / BSMT Video Cans' On '$IOnLevel %' $IOnLevel = 0 Wait 1 second Set 'Basement / BSMT Video Cans' On '$IOnLevel %' Else - No Actions - (To add one, press 'Action') Event Viewer (IOnLevel =100) Sun 02/09/2025 08:19:03 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 FF Sun 02/09/2025 08:19:03 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 FF 06 LTONRR (FF) Sun 02/09/2025 08:19:03 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 FF LTONRR (FF) Sun 02/09/2025 08:19:03 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =50) Sun 02/09/2025 08:19:04 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 80 Sun 02/09/2025 08:19:04 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 80 06 LTONRR (80) Sun 02/09/2025 08:19:04 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 80 LTONRR (80) Sun 02/09/2025 08:19:04 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =10) Sun 02/09/2025 08:19:05 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 11 1A Sun 02/09/2025 08:19:05 AM : [INST-ACK ] 02 62 17.F7.B6 0F 11 1A 06 LTONRR (1A) Sun 02/09/2025 08:19:05 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 11 1A LTONRR (1A) Sun 02/09/2025 08:19:05 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 (IOnLevel =0) Sun 02/09/2025 08:19:06 AM : [INST-TX-I1 ] 02 62 17 F7 B6 0F 13 00 Sun 02/09/2025 08:19:06 AM : [INST-ACK ] 02 62 17.F7.B6 0F 13 00 06 LTOFFRR(00) Sun 02/09/2025 08:19:06 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 2F 13 00 LTOFFRR(00) Sun 02/09/2025 08:19:06 AM : [Std-Direct Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

@walkman9999, your event viewer is showing an error during the PLM record read. The ISY is talking to the PLM but the PLM is returning a negative acknowledge. The ISY retries 2 times and then aborts the operation. 02 69 15 (15 indicates a Negative Acknowledge from the PLM). The proper response would be a 02 69 06 which would then be followed by the PLM link record. You could try power cycling the PLM to see if it recovers. If it does not, your spare will come in handy.

@Illusion, toggling the WAN MAY result in a new WAN IP address being assigned by your ISP. Disabling internet access to IoX should have no effect. Just pointing out the difference. I have no ability to test.

@pwmcmaho, the following table is what you posted 3 hours ago. It shows 21 unique device addresses and 23 total records. 19 of the devices are listed as "responders only" (FL=E2). These devices cannot send messages to the PLM (this is what you are seeing above). You should be able to turn these on/off from the admin console. 2 of the devices have control links for the PLM (FL=A2). I've highlighted these in the table. These 2 devices can communicate back to the PLM when they are manually activated. Again, you either had an aborted PLM restore, or a bad backup.