IndyMike

@rwsani99, Your log from the "show device links" is showing evidence of communication timeouts (no-response from the target device). If things were working properly, you would see a "[INST-SRX ] 02 50 4E.7D.16 71.17.44 XXXXX" after the [INST-ACK}. In the above, the PLM is re-trying communications up to 5x per request, and the ISY is re-trying 3x (15x total). That's rather bad. Since you indicated that you are having issues with multiple devices, I'm am going to guess that you have a rather strong noise source near the PLM. I say near the PLM because you are having problems with multiple devices. I am guessing that it's a noise source, rather than a signal absorber, because it's rather intermittent. Your second log section showed sections of total failure, followed by rather good communication (hops remaining = 2). Inspect the circuit where the PLM is installed for problem items (Pc's, UPS, Printers, etc). Alternatively, you could try moving the PLM to another circuit. Let us know how things are progressing

@alixer, when you performed the "restore device", was the ISY able to complete write the link table (no errors)? If this is the case, then your device has the correct PLM address and the scene information is incorrect. I say this because newer devices (I2CS units produced after 2012) will not allow the ISY to read/write to them unless the PLM address is in their link table. It may still be helpful is you could post your device link table, ISY device link table, and PLM address. The membership tree on the right is also helpful since it shows how many scenes the device is associated with. If your link table compare looks similar to mine above (no missing or mismatched entries) then the ISY believes the device has the correct link table/scene information. If the device does not respond correctly to a scene command (assuming that it received the command), then the ISY Link Table for the device is incorrect. The ISY maintains link tables for each Insteon device and for some reason, yours may have been corrupted. You can correct this by manipulating the device settings within the scene, causing a re-write to the device (as you are doing) OR your can restore the ISY from backup. Obviously, the backup may also have incorrect information, or be missing information on your more recent devices. If you do choose to restore a ISY backup, please follow with the process that @lilyoyo1 outlined above.

That's unfortunate. It indicates that the ISY does not have the correct scene information. You could try installing an ISY backup (restore ISY, restore modem, restore devices) , but that may be more work than "refreshing" you scene devices.

To be clear, my system failure was two fold: Poor programming on my part that led to a program cycling the system on/off causing water hammer. Poor irrigation design causing excessive main pipe flow (erosion). Pipe erosion occurs when you have large zones (high flow) and a capable supply. It's not that hard to avoid as long and you understand the pressures and flows in your system. I found the following site helpful. It includes spreadsheets for calculation pressure loss (friction) in various types of irrigation plumping. For reference, I was just below 7 ft/sec in my system mainline with certain zones operating. https://www.irrigationtutorials.com/#gsc.tab=0

It sounds like your new PLM address did not get written to your older devices. Not quite sure why. When you adjust the parameters of scene devices you are re-writing the scene AND the PLM address. That's why things work properly after the update. I can understand why you wouldn't want to do this for all of your scenes - you probably have a life. Could you try performing a Link Table Read/compare on one of your problem devices and posting the results? Please also post the new/old PLM address. This will tell us if the ISY contains the correct information. If it does, a simple "restore device" should correct the problem. If it doesn't, things get a bit more complicated...

@rwsani99, could you post a copy of the event viewer for when this occurs? There are a number of possible issues that could cause this (serious noise issues, PLM address change, PLM failure). Need to see the event viewer to determine which path to send you down.

@hart2hart, I'd say you've got the gist of the repeat loop. Please do pay attention to @dbwarner5's cautions on irrigation. They don't only apply to well fed systems. Cycling solenoid valves on irrigation should not be taken lightly. Rapid cycling and water hammer can destroy pipes - ask me how I know... At one time I tried to integrate my Evapotranspiration calculations, current weather conditions, and my irrigation. It didn't go well and I burst a 2" line. Caught my attention. I don't do that anymore.

@hart2hart, I'm not sure where your "zones" are in the program. I do see the "25 minute waits" at numerous places in the program. If this is where the Zones are, your could insert the code at each "25 minute wait". I think your program would resemble the following. That doesn't look crazy unmanagble. If you want to change all of the waits over to programmable delays, that would get rather confusing. At that point multiple zone programs/delay programs would become more "readable". Then $Water_Today_Start_I = 'Flume Water / FlumeWater / Flume Sensor' Today US gallons Set 'Yard / Yard:Front Mulch Beds' Start '$Irrigation_Run_Minutes Minutes' $I.MinuteCount = $Irrigation_Run_Minutes Minutes Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Yard / 2Yard:Front Mulch Beds' Off Wait 1 minute Set 'Yard / 2Yard:Front Left' On $I.MinuteCount = $Irrigation_Run_Minutes Minutes Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Yard / 2Yard:Front Left' Off Wait 1 minute Set 'Yard / 2Yard:Front Right' On $I.MinuteCount = $Irrigation_Run_Minutes Minutes Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Yard / 2Yard:Front Right' Off Wait 1 minute Set 'Yard / 2Yard:Back Fountain Driveway' On $I.MinuteCount = $Irrigation_Run_Minutes Minutes Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Yard / 2Yard:Back Fountain Driveway' Off Wait 1 minute Set 'Yard / 2Yard:Back Front Left' On $I.MinuteCount = $Irrigation_Run_Minutes Minutes Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Yard / 2Yard:Back Front Left' Off Wait 1 minute

Single program version using a Repeat - While Loop The second "Repeat 1 times" is required to end the loop if you wish to have follow on statements. Not required if nothing follows. You can decrease the wait time to gain granularity, but it comes at the expense of overhead. A 1 second wait loop requires roughly 2 seconds to execute and is working the ISY994 rather hard. Variable Minute Wait Test Program - [ID 0060][Parent 0004][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $I.MinuteCount = 2 Repeat While $I.MinuteCount > 0 $I.MinuteCount -= 1 Wait 1 minute Repeat 1 times Set 'Basement / SC BSMT Entry' Off Else - No Actions - (To add one, press 'Action')

@jaysmc, do you see activity in the Event Viewer when this occurs? Can you post?

As luck would have it, I did something very similar to myself some time back. I was playing with ISY Scenes on Home Assistant. I had set up a program to trigger on a ISY scene (my basement) and immediately turn the scene off. Unlike the ISY, Home Assistant views an ISY scene as "ON" if any member of the scene is on. The HA program would turn off my entire basement (13 lights) if any light were activated. For this to function both the ISY and HA had to be operating. After playing with the program, I disabled it on HA. Fast forward a year or two, and I inadvertently re-enabled the program. Took me quite awhile to figure out what was going on. The event viewer would show my basement scene being triggered off. I figured I had a rogue ISY program being triggered. Disabled all programs, deleted all programs, and it refused to go away. Then I remembered Home Assistant - Homer Slap.

@abrayshaw, you mentioned that you've been unsuccessful loading from Lan. Have you tried loading from the cloud?

@abrayshaw, If you know the IP address for your ISY you can enter it directly by clicking the "Add" button. Use the format shown below. If you do not know the IP address, log into your router and locate it. At this point you should also "reserve" the IP address for the ISY (if you haven't already). You don't want the complications of having DHCP move this address around. Assuming you can find the address and "Add" it successfully, "Save" the configuration to a file on your computer. Choose a location that's easy to locate (desktop, etc). The next time you can't "refresh" the configuration, use the "Load" button to load the configuration file. I created my file in 2022 (it's been working awhile now). @Geddy's approach is the correct one. This is merely a workaround.

A word of caution when using the "My Lighting" query. I'll qualify this by saying that my experience is with the ISY994. The PolISY and EISY may be different. For the ISY994, a "My Lighting" query hit everything. Some things that you may not wish to have queried: All Insteon devices, Including MS-II sensors (bug). You can disable MS-II sensors to get around this. Note that the query is also a problem for IOLinc devices with "trigger reversed" set. All X10 devices, including receive only devices (bug) Z-wave devices - from memory, this includes battery devices. I do not know how Zigbee/WiFi/matter devices are handled on the newer systems. On the ISY994, I created a "House Query" scene that had ONLY the devices that I wanted updated and used that for the 3AM program query. This is a maintenance item as you need to keep adding new devices to the scene.

@sbooke, your event viewer shows communication from your motion sensor, but it's from group 13. Motion is from group 1. I can't see enough from the event viewer to tell if you got a group 1 communication like you had previously. Regardless, your program should run as you have it written: Make sure you have saved the program. Look at the program summary to see the "last run" for the program. It should be triggering within the time window. If it has triggered, try performing a "run then" on the program to see if your device responds correctly. If none of the above works, delete the time constraint and check to see if the motion trigger alone works.

When you execute a scene from the ISY (admin console or program) it does not verify that scene members received the communication. It assumes that the scene was executed properly. If you have noise or signal absorption, scene member may not respond. The ISY will still show these devices as having responded. When you re-boot the system, the ISY queries devices and restores the correct status. Queries are performed using retries and are normally very reliable. The ISY will normally Query your system in the off-hours (3 AM?) to re-synch things. This is a system installed program that runs nightly. If you have persistent issues with a few devices you may have noise/absorption issues on the related electrical circuits. Inspect for chargers, PC's, etc. If you have problems with MANY devices, the issue may be near your PLM. Perform the same inspection. By opening the event viewer on level 3 and performing device queries from the admin console you can observe communication with your devices. Communication from the device to the PLM will be summarized in the "[Std-Direct Ack] Entry" and will show Max Hop and Hops Remaining. Hops Remaining of "3" is as good as it gets. Lower is less desirable. Device Query Communication in Event Viewer. Device address 1A.5D.C7 to PLM Address 53.BC.3A.

@sbooke, your motion sense is working. Your event viewer is showing EXACTLY what I posted above. Your last program you posted is incorrect. You are using a time trigger, not a motion trigger. The THEN statement is also incorrect. However, your original program should work. As @Guy Lavoie indicated, this would perform better if you used a "control" vs "status" qualifier. Not sure how, but we seem to have come full circle. Event Viewer Showing MS-II Communication Original Program Motion Program

That worked, and your PLM does have the link records for your device. If your MS II is communicating (you said you were able to trigger scenes with it), your PLM should see group 1 communication from this device. Your event viewer should show the following when triggered (updated with your device address). Make sure that the Event Viewer is set to level 3. If you cannot see the communication in the event viewer either you have communication issues with that device (noise, etc) or the device itself isn't programmed correctly. If you changed PLM's recently, it's possible that the Motion Sensor does not have the correct PLM address in it's link memory. To verify, place the Sensor in programming mode and perform a Link Table Read + compare. It's possible that the MS-II Options are not set correctly. Verify that "Conditioin, Report, and Sensitivity" are set correctly (see below) Event Viewer Showing MS-II on trigger [INST-SRX ] 02 50 4D.EF.5F 00.00.01 CF 11 01 LTONRR (01) [Std-Group ] 4D.EF.5F-->Group=1, Max Hops=3, Hops Left=3 [D2D EVENT ] Event [4D EF 5F 1] [DON] [1] uom=0 prec=-1 [ 4D EF 5F 1] DON 1 Your PLM link record for the Motion Sensor Motion Sensor Link Table Read + Compare MS-II Device Options

Sorry, nothing in the table (82 bytes) <isy.diag> <title>PLM Links Table</title> <insteon.lincs/> </isy.diag>

@sbooke, I'm guessing that something went sideways during your upgrade to the EISY. Your PLM sounds as if it's relatively new. The table below shows the entries in my PLM for my MS-II sensor @4A.6F.65. In order for the PLM to hear the motion sensor, the circled link MUST be present. If it is not, the PLM will ignore motion on/off communication from the sensor. We need to figure out whether your PLM contains this link for your Motion Sensor. If the link is present, you are having communication errors with the device. If the link is not present, you'll need to remove/re-add the device OR restore a backup. Please save your PLM contents to a .XML file (see 2nd graphic) and upload to the forum. Please also provide the Address of your Motion Sensor. I will sort your PLM contents and try to find the links associated with the sensor.

The link limit has been around in various forms since the start of Insteon. The original 2412S PLM had more memory, but had issues utilizing higher addresses - presumed to be due to speed limitations. There is a fair amount of Smartlabs documentation stating that the 2413S PLM supports 2000 links. Per the following, both @Brian H and @ELA verified that actual hardware from 2017 only supported 1000 links (https://forum.universal-devices.com/topic/24278-anyone-have-a-recent-2413s-plm/). Like you, I have a link count in the middle 300's. That's with ~66 Insteon devices. At one time I had roughly 2x that number and I was pushing the limit. It's interesting to note that PLM memory utilization isn't all that efficient. When devices are deleted, the memory isn't necessarily reclaimed. As I mentioned in a previous thread, I recently "recovered" 150 link records by performing a "restore modem". Finally, the Link Table Read function can be rather intermittent for some giving wildly different counts. The actual reading is performed by a PLM function "Get Next All Link Record". Unfortunately, during certain communication events, the PLM can loose track of where it is in the read process. I can normally get good PLM table reads in the early morning, but others have real issues getting consistent results. As I'm writing this my family is moving around tripping the various motion sensors upstairs. My link table counts are - 178, 919, 263, and 473. None of these are correct.

@sbooke, 48 links is VERY few and somewhat doubtful. I single Keypadlinc with a few scenes can consume 20 link records. If you can't see the motion sensor communication in the Event viewer, your program WILL NOT trigger. The PLM either does not have the correct link records (programmed incorrectly) or the link record is outside of the range the PLM can access. The last condition (link record outside the access range) is what @gregkinney encountered. As he indicated, deleting scenes can help reduce things below the 1024 1000 link limit. If you believe that you have nowhere near that # of devices/links (I also don't), please post back. If you have recently upgraded (Polisy to Eisy, etc) it's possible that something went South, and you don't have the correct links in the PLM. It is also possible that your PLM is having issues and is loosing it's links records. Let us know the vintage (date code/rev level).

@sbooke, if your motion sensor CAN trigger a scene but CAN'T trigger a program: Your PLM can't hear the device Your PLM isn't programmed to listen to the device You have too many link records in the PLM Open the Event viewer to @Level3 and activate the motion sensor. You should see communication similar to the following (with your device address). If you do not see any activity, check your PLM link record count and review the following thread: https://forum.universal-devices.com/topic/45014-motion-sensor-only-works-in-scenes-not-programs/ Thu 04/03/2025 07:42:31 : [INST-SRX ] 02 50 4A.6F.65 00.00.01 CF 11 01 LTONRR (01) Thu 04/03/2025 07:42:31 : [Std-Group ] 4A.6F.65-->Group=1, Max Hops=3, Hops Left=3 Thu 04/03/2025 07:42:31 : [D2D EVENT ] Event [4A 6F 65 1] [DON] [1] uom=0 prec=-1 Thu 04/03/2025 07:42:31 : [ 4A 6F 65 1] DON 1

@WFP, I tried your configuration (24 hour clock) with the following test program. It ran correctly at sunset (activated my scene and set the variable), a ran false outside the time constraint. My sunset is at 20:12 today, so I get slightly less than 2 hours of "true" time for the program. I do agree that the AM/PM are the only options even though the 24Hr clock is specified. I should qualify that I'm running a ISY994... I initially ran things and was having problems determining whether the program ran true - that's when I added the variable flag. The variable was set this AM so I know the program ran true last night. I'm thinking that you program is indeed running, but your scene isn't hearing the PLM. You could check your Log file, or leave the Event viewer open during the run time to verify. You can also try force running the then portion to verify the scene devices can hear the PLM.

I don't have an EISY, but I'm guessing the feature relates to the following: https://www.insteon.com/simple/#Manually-change-switch-modes-dimmer-or-on/off-mode