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 (~1024 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 1024)

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

I have been unable to locate any specifications on the RPC1508-64. I did find the following Enphase filtering document that recommends the use of a RP240-80-10-S for noise issues (https://enphase.com/sites/default/files/2021-06/Power_Line_Filter_Single-Phase_TechBrief.pdf). This device is available @Newark for $233 (https://www.newark.com/astrodyne-tdi/rp240-80-10-s/filter-1-phase-80a-250v-chassis/dp/85AJ1317). Specification lists insertion loss (filtering) @150Khz of 40/60 db for CM/DM signals (https://www.farnell.com/datasheets/3622987.pdf). ...not much of a specification. The Enphase document indicates that it's Microinverters communicate over the powerline @144Khz. The filter is used to clean (or isolate) power to allow the communication. I would not have purchased this filter expecting it to filter/isolate noise in the 130Khz Insteon communication range. While the current range is applicable, the filtering range is spec'd from 150K up to 30M. Too expensive to roll the dice hoping that a device spec'd for 150Khz and above can filter sufficiently in the 130Khz range. Based on the results that @NCSTATE78 is seeing, the filter has sufficient bandpass to cover the Insteon range as well - at lease for the RPC1508-64. Just another data point. NOT proposing that anyone try this. It COULD be something to mention to your installer.

OK, 277 volts would correspond to a 480V 3-phase installation (277V is one leg of the 480V 3-phase). That is truly a commercial install. If you are trying to communicate with devices on all 3-phases you will need RF coupling devices on all 3-phases. That's a different topic, but mandatory for 3-phase (passive coupling will NOT work). The SKU you provided led to the following specification: https://www.ali-corp.com/Upload/File/f184035e-11c7-4c50-92ae-1d016b64d611/Linear Strip-1，.pdf Your lamps can be powered by by voltages ranging from 120V to 277V. Unfortunately, the specification indicates that they must be dimmed by a separate 0 - 10V signal. If this is the correct specification, you should NOT use a Insteon Dimmer with these lamps. The lamps were designed for a dedicated switch (or relay device) to supply power, and a separate 0 - 10V dimmer. Insteon does make a 0-10V dimmer, but it installs at the device and is controlled via RF (https://www.insteon.com/0-10v-ballast-dimmer). I have never used one of these. It is rated for 277V, but I am not certain that it is appropriate for a commercial installation. You would obviously need a separate RF controller for the dimming function.

@NCSTATE78, excellent data point - thanks for sharing. Sounds like Tesla is coming up the learning curve on how to avoid powerline communication problems. Not an easy task. The Enphase filter certainly has to power rating (64A) to handle the Powerwall. There are unfortunately not many specifications on load isolation and filtering. Usage and installation is include in the following (LONG) document: https://enphase.com/download/planning-enphase-energy-system-tech-brief If someone has the technical specification on the device itself, I'd be all ears. IM

It sounds like you are using a Insteon 2334-232 Dimmer as the controller for your garage lights. I'm guessing this because a dimmer will get hot when overloaded whereas a Relay (On/Off) switch will simply erode (or weld) the contacts and stop functioning. The specification for the 2334-232 is 600W incandescent or 150W LED (https://shop.insteon.com/products/dimmer-keypad-6-button). If you truly have 600W of LED load on the circuit, you are way over it's rating. It's not the easiest to find the LED ratings for these devices, but I'm surprised that your electrician didn't look harder. It's incumbent on him to ensure that the installation is safe. The 227V (??) rating is likely the "maximum" voltage the where fixture will operate safely. LED fixtures incorporate internal power converters that will often handle between 120 and 277V. Your 2334-232 is actually specified to operate over 120 to 277V. If you are in the us, you are using plain Jane 120V/60Hz The normal device used for a high wattage installation like this would be an On/Off switch (as @paulbates indicated). I actually have a similar installation in my garage that consumes 432W and I am using a 2477S. The Manual for the 2477S does not have a separate specification for "LED load". It simply specifies "1800 Watts" and I am well within that - ignorance is bliss. The current 6-button KPL On/Off switch is unfortunately nor rated for 600W either (https://shop.insteon.com/products/insteon-remote-control-on-off-keypad-6-button) The webpage shows 450W Led load maximum. Not sure how to interpret that since it likely uses the same relay that is in my 2477S switch (should have the same ratings). If you can provide some additional information on the Make/Model/quantity of fixtures you are using, that would be helpful.

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