kclenden

The Device Links table looks totally wrong. Besides the fact that both rows show "Record mismatch", the data looks wrong. Where I would expect to see the address of your PLM, I see the address for the SynchroLinc, and where I would expect to see option data, I see the address of your PLM. The fact that the records seem so totally wrong could lead credence to @larryllix's theory about a possible failing power supply. Doing a restore should have gotten rid of the totally wrong records, but... The ISY Links table for the SynchroLinc doesn't look right to me either. For pretty much every device I've ever added to my ISY, both an E2 and an A2 record (i.e. two rows) have been created. I have no experience with a SynchroLinc, and have no reason to believe that the ISY Links table is wrong (other than my experience with E2 and A2 records). Having said that, if I were having this problem, I would try removing the SynchroLinc from the ISY and then readding it. However, you'd have to fix any programs and scenes it was used in after you readd it.

Listing the links in the PLM table is a looping process where the ISY asks the PLM for the next row in its Links Table over and over until the PLM says there are no more rows. If there is activity on the powerline, it can interrupt the ISY, and if that interruption is long enough, the looping between the ISY and PLM will timeout. So what you know is that your PLM has at least 426 links. You can try running the Show Links again at a time you're pretty sure the powerline should be quiet to see if you get a number higher than 426. Both the Query and the Restore of your IOLinc are showing the same thing - no response from the IOLinc. In each case, the ISY sends a command and waits for an acknowledgement from the IOLinc. When it doesn't get one, it sends the command a second time and waits. When it still doesn't get an acknowledgement it sends the command one more time, and then when it doesn't get a response it quits trying. So the question is why the IOLinc isn't replying. Weak signal? You can try moving the IOLinc closer to the PLM. Corrupted Links Table in the device? You can trying factory resetting it followed by a restore device. If none of those work, I'd try removing it from the ISY; factory resetting it; adding it back to the ISY. If you do remove it from the ISY and try adding it back, I would have the Event VIewer open at Level 3 to see what was going on. If that continues to show no response from the IOLinc when it's close to the PLM then I'd consider the IOLinc as dead.

As @Bumbershoot mentioned, that error often is a result of doing a firmware upgrade (especially from v4 to v5). What happens is that some of the commands in the earlier version don't translate to the new version so you have to open the program and minimally save it, but sometimes you actually have to make a change in the program (even if just in a comment) before you save it. Another thing that sometimes causes this error is a mismatch between the Firmware and UI versions. You can go to Help->About to see version numbers.

The PLM has a 1000 link limit. If I recall correctly, the non-Pro versions of the ISY limit nodes to something like 255, but I don't know if that includes links. You can see how many links are currently being used in the PLM by going to Tools->Diagnostics->Show PLM Links Table, and then clicking the "Start" button. You should run that a couple times as it can be interrupted by powerline activity. Here's a link to a really old forum discussion on how to estimate the number of links a system will use:

Not sure if it applies to your situation, but here's a link to a conversation in 2018 about a noisy Ezio 2x4.

Just looked at my PLM and the light is ON solid green.

I'm sure there are other reasons, but one reason is because the PLM has a limited number of links that it can hold. Every scene that a device is in counts as a link. So if you have enough devices, and use enough scenes, eventually you'll run out of links in the PLM table. Another is because a device can only be a controller for one scene. So let's say you have a motion sensor directly linked to a light. In the daylight you want the light to come on at 100%, but at night it want it to come on at 20%. The only way you can accomplish this, if you leave the motion sensor directly linked to the light, is by using Adjust Scene.

A couple thoughts. Is it possible that you've reached the limit of links for your ISY? While I can't explain why reaching the link limit would affect only the old devices and not new devices, strange things happen when you reach the link limit. In the Admin Console, goto Tools->Diagnostics->Show PLM Links Table, then click "Start". What's the highest numbered row returned? You should try running the "Show PLM Links Table" multiple times to see if you get the same number. You could also try watching what happens when you try to query and/or add one of the old non-responding devices. Goto Tools->Diagnostics->Event Viewer. Then set the Level to 3. Now try querying or controlling one of the non-responding devices. Also try adding one of the non-responding devices that you removed. The results in the Event Viewer might give you some idea what's going on. You can click "Save Log To..." and then post the results here if you want input on what the log shows.

The PLM Link Count consists of a loop whereby the ISY keeps asking for the next link in the PLM Link Table until the PLM says there are no more. Any activity on the powerline whether from the ISY or other devices may interrupt this loop. So assuming there is activity on your powerline while you're doing the count, what you're seeing is normal and I wouldn't be concerned. Try doing a count when you know there aren't any ISY programs that will run and there's a low probability that devices on the powerline might send status updates.

Do you have filters on your two garage door devices? If not, it's possible that although things have worked for four years, the communication between the IOLincs and the PLM was marginal such that adding devices in other parts of the house eventually upped the noise level so that the marginal communication became no communication. @larryllix has a post somewhere on the forum that talks about his experience with garage door openers and eventual communication loss.

It's likely the ISY had the same IP address even when you weren't able to find it with the AC finder. If you move it to the farther switch, you can try opening a Command Prompt window (assuming you're using Windows) and then issuing a ping command for that IP address. If the ISY responds, then you know that the ISY can communicate on the network, and that the issue is with the network topology. To find the the ISY, the AC finder sends out a certain kind of broadcast message that some switches aren't configured to pass along. Here's a link to a discussion about this topic, though your issue is with a switch and the discussion is about a separate VLAN:

Generally moving the ISY will not cause any network issues. How are all the devices on the network connected? Do you have multiple routers or multiple switches?

Based on my experience, for a particular device, you are correct - if a Control event occurs for a device, it will be handled by the ISY first before the linked Status event. When you think about it, that makes sense. A control event occurs when a signal comes from a device to the ISY telling it about that device. A status event occurs when the ISY changes the status of a device based on information it has received from the device*. So the ISY first learns about a Control event, and then uses that information to create a Status event. * - The ISY will also change the status of a device based other information besides Control events. For example, if the ISY sends a scene command that affects six devices, it will go ahead and change the status of those six devices based on what those devices should do when they receive the scene command. Another example is when the ISY receives status messages directly from devices after they have reacted to a controller other than the ISY. In both of these examples, no Control event would have occurred for the devices because they were not acted upon locally, but instead were acted upon by other controllers.

When a switch is a controller, it only acts as a controller when it is locally controlled (i.e. you physically press the switch). A switch does not act as a controller when you operate the switch remotely (i.e. the ISY tells the switch to turn OFF). So turning the Bath Fan Switch off from the ISY will have no effect on the IOLinc. That is why you should turn OFF the scene. Another thing to note about your original program. You only have 'switched on" in your IF. You should also include 'not switched off'. If you don't then your WAIT will not be interrupted when the Bath-Fan-Switch is physically switched OFF which means your timer will continue to run. The key is that while they seem like the opposite of each other "switched on" and "switched off" are really two separate events and thus if you want to react to both of them (i.e. start timer on 'switched on' and stop time on 'switched off') then you have to include both in the IF.

@jec6613 is probably right. Easier to just skip the percentage and always run the HRV 15 minutes whether it's already accumulated runtime via the bathroom fan. But I've never been known for doing easy. ? So here's a starting point for you to consider: Create two state variables: $sHRV.Minutes.Left.To.Run.In.Hour and $sMinutes.Left.In.Hour The programs below breaks the day up into 24 hour segments. At the top of the hour the two variables tracking minutes left in the hour and minutes left to run the HRV are reset. Then every minute, the minutes left in the hour variable is decremented by one. If the HRV is turned on, then every minute the minutes left for the HRV to run during the hour is decremented by one. If at some point in the hour, the minutes left in the hour are equal to or less than the minutes the HRV still needs to run, then the HRV is turned ON. Finally, at the top of each hour shut OFF the HRV (unless the Bath Fan Switch is ON) since the two tracking variables are designed to both reach 0 at the top of the hour and that means the HRV has run enough and should be shut OFF. I haven't tested the programs and it's early, so consider them just theoretical. ? Program1 to Monitor Bath Fan Switch IF 'BATH-FAN-SWITCH' is switched On AND 'BATH-FAN-SWITCH' is not switched Off THEN Wait 1 hour Set BATHFANCONTROL scene OFF Program2 Monitor HRV Minutes Left To run IF HRV status is ON AND $sHRV.Minutes.Left.To.Run.In.Hour > 0 THEN Repeat every 1 minutes $sHRV.Minutes.Left.To.Run.In.Hour -= 1 Program3 Monitor Time Left in the Hour IF time is 12am or 1am or 2am or 3am ... or 11pm THEN $sMinutes.Left.In.Hour = 60 $sHRV.Minutes.Left.To.Run.In.Hour = 15 (or whatever minimum run time you want) Run Program5 (IF) Repeat every 1 minutes $sMinutes.Left.In.Hour -= 1 Program4 Turn ON HRV to Meet Minimum Hourly Run Time IF $sMinutes.Left.In.Hour <= $HRV.Minutes.Left.To.Run.In.Hour AND $sHRV.Minutes.Left.To.Run.In.Hour > 0 AND HRV status is OFF THEN Turn ON HRV Program5 Turn OFF HRV at Start of New Hour If Bath Fan Switch Is Not ON (right-click and disable this program so it doesn't run on its own) Program will be called from Program2 at the top of each hour, but only after tracking variables have been reset. IF 'BATH-FAN-SWITCH' status is OFF THEN Turn OFF HRV

Create a second program, I'll call it "Set_BDRM_BACK_To_12": Set_BDRM_BACK_To_12 - [ID xxxx][Parent xxxx][Not Enabled] If 'BDRM BACK' Status is Off Then Set 'BDRM BACK' On 12% Else - No Actions - (To add one, press 'Action') After creating this program, right-click on it and choose "Disable". This is important because it tells the ISY not to automatically evaluate the IF whenever the status of "BDRM BACK" changes. If you don't do this, then whenever you turn OFF "BDRM BACK" it will automatically come back on at 12%. Now replace the "Set 'BDRM BACK' 12%" line in your program with "Run Program 'Set_BDRM_BACK_To_12' (IF)".

So your current theory is that somehow the notify is being called twice when it's included in the flash program? Certainly the fact that the flash program takes a while to run makes it easier for it to be interrupted before it completes. Here's a way for you to get some more clarity. Create a state variables called sProgramTrack. Then use it to track which programs and statements are being executed, and in what order. In your original trigger program, right before you call the flash program, add the statements sProgramTrack = 1 sProgramTrack = 0 Then in your flash program, right before you execute the notify, add the statements sProgramTrack = 2 sProgramTrack = 0 and then at the very end of the flash program, add these statements sProgramTrack = 3 sProgramTrack = 0 After updating your programs with the tracking statements, start the Event Viewer and then test your programs. In the Event Viewer, changes to state variables are also logged so you will see sProgramTrack being changed as each program runs. This is sort of the equivalent of the using a PRINT statement to debug languages that don't have tracking features. Any way, you'd expect to see sProgramTrack get changed to 1, then 2, then 3. But if you're getting duplicate emails, I think it will probably be 1, 2, 1, 2, 3. By the way, you set sProgramTrack to 0 because only changes to state variables are logged. So if somehow your program logic caused sProgramTrack to be set to 1 twice in a row, you'd only see the first time. By setting it to 0, you'll be able to see unintended looping where the same statement gets called multiple times in a row.

The provided XML files are pretty much useless to anyone but you. They refer to devices and programs that are uniquely defined in your ISY. To share your programs, right-click on the program and choose "Copy to Clipboard". Then simply past the text into your message. If you use the "<>" button above, it will allow you to paste the text and have it appear formatted as code, but even if you don't do that your programs will still be in readable text. Having said all that, looking at the XML files it appears that "Trigger" is merely a program that runs the IF of Program48 whenever the MS is triggered. Program48 appears to only run the THEN if Variable1-7 is 0. The first thing it does is set Variable1-7 to 1, send Notification7, flash a light, run the IF of Program44, and finally set Variable1-7 back to 0. Because Variable1-7 is type "1", I'm assuming it is an INTEGER variable and can't, by itself, cause the program to execute. So first things, first - only one instance of a program can ever run. Your variable is not necessary to prevent two instances of the same program. So let's say you had two MS that both triggered your program. Say the first MS is activated and the program starts running. Now immediately afterward, the second MS is activated and it runs the same program. The program that was running because of the first MS will restart because of the second MS. There won't be two instances of the program. Next, you haven't provided even XML for Program44. What does it do? Third, when you include variables in notifications, their value doesn't get bound to the notification at the time the notification was queued by the ISY to run, but rather at the time the ISY actually gets around to executing the notification. This means that values that appear in the notification may not be what they were when your original program was running. For this reason, people often include a WAIT of 2-5 seconds right after a notification so that they don't end up changing a variable before the notification is actually sent. For anyone to be of much help, you'll need to include the plain text of any program that calls your "flash" program, plain text of your "flash" program and plain text of Program44.

Mr.Bill's answer seems to have sufficed for you, but for newbies that might read this in the future, the answer is YES and a little bit complicated. The ISY is an event based system, but despite that, two events can't happen at the same time. Your IF statement has three events that can trigger the IF to be evaluated causing either the THEN or the ELSE to execute. Light is physically switched OFF Fan is physically switched ON Status of Light changes (from ON to OFF or OFF to ON) As Mr.Bill says, if any of those events occurs the WAIT is interrupted and the IF is reevaluated. The 3rd trigger is what confuses most people. They see it as a constant state, not an event. And the status is indeed a constant state that can be evaluated at any time, but when the status changes, and only when it changes, an event occurs that causes the IF to be evaluated. So the "And 'MBR / MBR Toilet Pots' Status is Off" acts as both an event which can trigger the IF to be evaluated and as a state which can be evaluated whenever another event triggers the IF. The other two pieces of the IF act only as events. That is to say they are only TRUE when they caused the IF to be evaluated, and whenever anything else causes the IF to be evaluated they will be FALSE. So what is happening with your program is that when you physically switch the light OFF, event #1 above occurs. The IF of the program is evaluated to be TRUE so the THEN is executed and the WAIT begins. Now the ISY changes the status of the light from ON to OFF which causes event #3 to happen. This interrupts the WAIT and when the IF is reevaluated it is FALSE because event #1 happened in the past (remember only one event can happen at a time), event #2 hasn't happen and couldn't occur when event #3 is happening anyway, and thus the ELSE is executed which means the WAIT and subsequent turning OFF the fan never happen. So far we've accounted for what happens when event #1 and event #3 trigger the IF to be evaluated. What happens when event #2 occurs. The IF is evaluated and if the light is ON the ELSE is executed (so nothing happens), but if the light is OFF the THEN is executed which starts the WAIT and then two minutes later the fan is turned OFF just like you want. So key things to remember: As far as the ISY is concerned only one event can occur at a time Statuses create an event when they change (e.g. ON to OFF, 0 to 1, etc), but only when they change. So if your light switch is OFF, and you turn it OFF again no event will occur, likewise if a state variable is 0 and you set it to 0 again no event happens. WAITS and REPEATS will be interrupted and cause the IF to be reevaluated whenever an event within the IF occurs Hmmmm... Got a little wordy. Oh well, this subject is the thing that gave me the most fits when I first started using the ISY so I'll leave it all there in hopes that it helps a someone in the future.

I'd recommend starting the Admin Console and then start the Event Viewer (Tools->Diagnostics->Event Viewer) and set it to level 3. Let the Admin Console and Event Viewer run until one of the random ON occurs. Then use "Save Log To..." to save the Event Viewer output. This will give you a lot more data than the normal log to help you figure out what may be causing the On/Off module to "randomly" go on.

Not sure if you've tried them, or not, but some common things that have been known to fix "out of memory" problems: Clear Java cache Increase Java memory Fixing mismatch between ISY firmware and IU versions

As it turns out, I should have done it this way. Either that or put a "Wait 5 seconds" directly before the "$sDST_Alert = $cFalse". My "ISY_Uptime" program didn't get restarted and my theory is that there was a race between getting the program "Run" executed and the "IF" reacting to the change in "$sDST_Alert" which caused the program to switch from running the THEN to running the ELSE. So I've now changed the alert program to have a WAIT statement before the variable change and moved the list of programs to restart to a separate program that won't be impacted by the IF reacting to the change in state variable. DST_Alert - [ID 00C1][Parent 00BE] If $sDST_Alert is $cTrue Then // Wait a couple seconds because later we're changing the state // variable that kicks off this program and we want other programs // that react to $sDST_Alert to have a chance to run. Wait 5 seconds // Restart programs that would have been killed by DST change Run Program 'DST_Restart_Stopped_Programs' (Then Path) // Send notification of DST change Send Notification to 'Text_KBC' content 'Day Lights Savings Time Alert' // Wait a couple seconds because when we change $sDST_Alert the "IF" will // flip this program from executing the "THEN" to executing the "ELSE" and // it's possible that will keep some lines in the "THEN" from completing. Wait 5 seconds // Cancel DST alert $sDST_Alert = $cFalse Else - No Actions - (To add one, press 'Action')

As @MrBill says $cFalse and $cTrue are just integer variables that have been set to a constant value of 0 and 1, respectively. They are used to make programs more readable. The "c" at the beginning of the variable name indicates "constant". My other variables have either an "i" or "s" at the beginning of the variable name to indicate "integer" or "state".

I think it's a toss-up. Including the state variable in the body of the IF for each heartbeat program is the easiest thing to do when originally writing a program, or creating new ones. On the other hand, if you already have a bunch of heartbeat programs, including the full list as "run program ____ (then)" is easier than touching all the individual heartbeat programs. Two additional benefits of the latter method is that 1) you can see which programs will be restarted in one place, without having to look at the IF of each program and 2) it's easier if you want to space out the restart of the heartbeat programs.

Yeah, none of the programs run in "DST_Alert" are relevant to DST operation. They're just programs that got killed by the ISY reaction to DST that I need to restart. I could make it clearer, and likely easier to support if I move all the "Run" statements into another program called "Restart Stopped Programs" and then ran it.