kclenden

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.

Sure it's Daylight Saving time, but after several years they add up to become plural. ? My only excuse is that I wrote my post at 1:45am which was really 2:45 am.

As ISY users eventually discover, any programs that are running timers (e.g. WAIT) stop executing when the time on the ISY either springs forward or falls back because of Daylight Savings TIme. If those programs happen to loop so that they are long running programs serving a specific function like listening for a heartbeat from a device then they likely won't start running again until your ISY reboots or you open the Admin Console and restart them. So I decided to try using a variable to detect a change in time caused by DST and have the ISY alert me when DST occurs and have it automatically restart my long running programs. I wrote my programs several month ago and then sort of forgot about them until 1:05am today when I got an alert from the ISY that a DST change had occurred. That's probably the longest I've waited to see if a program actually works. The idea is to have a variable count the hours from 12am to 3am and detect if the progression is the normal 0...1...2...3. If it goes 0...1...1 then I know that fall back has happened. If it goes 0...1...3 then I know spring forward has happened. Here are the programs: =================================================================================== Day Lights Savings - [ID 00BE][Parent 0001] Folder Conditions for 'Day Lights Savings' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- 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 Wait 5 seconds // Restart programs that would have been killed by DST change Run Program 'Outside Lights - Random Brightness' (If) Run Program 'GarageDoorSensor-Control 2' (Then Path) // Assumes Uptime program was killed by DST change before $iISY_Uptime_Counter was incremented $iISY_Uptime_Counter += 1 $iISY_Uptime_Counter Init To $iISY_Uptime_Counter Run Program 'ISY Uptime' (Else Path) Send Notification to 'Text_KBC' content 'Day Lights Savings Time Alert' $sDST_Alert = $cFalse Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_0 - [ID 00BA][Parent 00BE] If Time is 12:05:00AM Then // Need to initialize $iDST_Hour_Check so that the check at 1:05 knows // whether it's running after the 12:05 check or a second time in a row // because of "Fall Back" $iDST_Hour_Check = 0 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_1 - [ID 00BB][Parent 00BE] If Time is 1:05:00AM And $iDST_Hour_Check is 1 Then // $iDST_Hour_Check should have been set to 0 at 12:05AM. The only way // for it to be 1 now is if 1:05AM happened and then happened again. // This should only occur during "Fall Back" when DST is changed from ON // to OFF and the clock goes from 2:00AM to 1:00AM $sDST_Alert = $cTrue $iDST_Hour_Check = 1 Else $iDST_Hour_Check = 1 ----------------------------------------------------------------------------------- DST_Check_2 - [ID 00BD][Parent 00BE] If Time is 2:05:00AM Then // Need to update $iDST_Hour_Check so that the check at 3:05 knows // whether it's running after the 2:05 check or after the 1:05 check // because of "Spring Forward" $iDST_Hour_Check = 2 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_3 - [ID 00BC][Parent 00BE] If Time is 3:05:00AM And $iDST_Hour_Check is 1 Then // $iDST_Hour_Check should have been set to 2 at 2:05AM. The only way // for it to be 1 now is if 2:05AM never happened. This should only // occur during "Spring Forward" when DST is changed from OFF to ON // and the clock goes from 2:00AM to 3:00AM $sDST_Alert = $cTrue $iDST_Hour_Check = 3 Else $iDST_Hour_Check = 3 ----------------------------------------------------------------------------------- DST_Init_0 - [ID 00BF][Parent 00BE][Not Enabled][Run At Startup] If From 12:05:00AM To 1:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 0 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Init_1 - [ID 00C0][Parent 00BE][Not Enabled][Run At Startup] If From 1:05:00AM To 2:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 1 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Init_2 - [ID 00C2][Parent 00BE][Not Enabled][Run At Startup] If From 2:05:00AM To 3:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 2 Else - No Actions - (To add one, press 'Action')

Unfortunately I don't have any particular source to point at to help understanding events. Most of what I know comes from watching things happening in the Event Viewer and then tracing it back to what was happening at the time. For example the [ Time] tag. There seem to be a lot of things that can cause it to appear in the Event Viewer including: In the AC Saving a program Running a program While the ISY is running A program calls another program Time is ... passes (whether based on exact time, sunset/sunrise, or Last Run of a program)* When the start time of a "From ... To ..." passes * When the end time of a "From ... To ..." passes * * - Even if a program is disabled directly, or via a folder condition, and unable to run, a [ Time] tag will appear in the Event Viewer when the start or end time passes I've seen multiple [ Time] tags appear in a row, but generally they're related to either saving program, in which case I see four in a row, or the start/end time of a FROM statement in a disabled program passing in which case it seems to be somewhat random how many [ Time] tags I see. I've seen as many as 38 appear in a row related to a single disabled program with a FROM statement, but usually it's more like 10-20. Another odd thing about the [ Time] tag is the 0(0) that appears at the end. Sometimes it's not 0(0) but x(0) where the x represents the number of days my ISY has been running, like tonight where I'm seeing 86(0) and indeed my ISY has been running 86 days since it was last rebooted.

Line #1 - The ISY has passed a message to the PLM [02 62]. The message is intended for device 12.A0.4E. The message flags indicate a direct message (i.e. not a group message) that is allowed a maximum of 3 hops [0F]. The message contains an ON command [11] to Level 44% [70]. I calculated the level by hex 70/FF = 112/255. Line #2 - A program has started Line #3 - The PLM acknowledges to the ISY that it received the message and sent it Line #4 - Device 12.A0.4E acknowledges that it has received the command to turn ON at Level 44% Line #5 - The ISY translates the message received on Line #4 into easier to understand text Line # 6 . . . loop repeats My interpretation of the log is that you a have program (or programs) that do two things every second: Turn on 'Hall - foyer / Front Lites' to 44% Call a program Could be a program that: Turns on 'Hall - foyer / Front Lites' to 44% WAITS 0 Seconds (seems wrong but the ISY waits 1 second longer than specified) Calls itself Could be two programs that: Prog_1: Repeats while (some condition that never changes) Calls Prog_2 Waits 0 Seconds Prog_2: Turns on 'Hall - foyer / Front Lites' to 44% Or there are many other ways this could be implemented. The key is that it appears to be a loop whereby a program is called every second to turn on 'Hall - foyer / Front Lites'. I would think your best bet is to do what @MrBill suggested. Look on the "Summary" page for a program that is constantly running: You might also search your programs for instances of "Wait 0 Seconds" or "Repeat Every 0 seconds".

Unless you mistyped the time of the alert, it seems like the alert came too late (2 minutes after "schedule" trips) for that to be the cause. It sounds like your ultimate goal is to be alerted to an "event" that happens within a set time frame. If that's the case, you probably want to monitor CONTROL instead of STATUS as changes in control are one-time events while status is an ongoing state. So your program would look like: If From 11:00:00 PM To 7:00:00 AM (next day) And 'Device Sensor' is switched On Then Send notification Else - No Actions Only one event can happen at a time, or at least that's how the ISY sees it, so now when the program is triggered by 11:00:00PM (an event) you can't also have a "switched On" event*. That takes care of the one exception problem you had with "status". Now the only event that can really trigger your notification will be "'Device Sensor' is switched On" and if that event doesn't fall within 11:00:00PM and 7:00:00am (next day) it won't send. * While the above is true, you could still have a "switched On" event that just happens to be triggered at 11:00:00PM. You still only have one event being triggered, but in this case it's the "switched On" and not 11:00:00PM.

That's only 99.99% true. ? The program is triggered by three things: Time becomes 11:00PM Time becomes 7:00AM (next day) Sensor status changes from OFF to ON When the program is triggered, the entire IF is evaluated. So at 11:00PM if the sensor state is ON then the program will send even though the sensor status hasn't just changed from OFF to ON. Other than that one instance, the program will only send if the status changes from OFF to ON. Given that the OP's message indicates a time of 11:03:00PM, it's not likely that one exception is the cause of the message though. There are only two ways your message was sent. Either it was sent by the program you typed above, or it was sent by another program. So I would use the "Raw Text" option and search for either "Send Notification", or if you use "Send Notification" in a lot of programs you could search for specifically named content (i.e. the "Name" shown in "Configuration->Emails/Notifications->Customizations"). Keep in mind that when you search using "Raw Text", capitalization matters. Here are two screenshots of examples:

No worries. It's only through robust discussion that we really learn anything. No. Yes. No. Yes. As an example, here is the lead paragraph to developer notes released in Feb 2012: We are making improvements in device firmware to help ensure INSTEON commands are sent in a more reliable manner. This includes the adding of checksum (CS) to commands that set a remote device’s properties, bit flags byte and database records. Also, internal protections have been added such as the ability to prevent device from acting on a message from a device not currently in its database, enhanced buffer corruption prevention and preventing invalid hop count messages from being hopped on the network. While the notes are from 2012, in my experience it can take a year, or two, for inventories of old devices to clear so that you know you're getting a new device when you buy, so I would consider devices that are roughly six years, or older, to be "old". One thing that has definitely changed, for the worse, is that Smarthome has pretty much stopped updating developers on changes. So while you can see when a device's firmware has been changed, you don't know what those changes were.

Or, perhaps, you fail to understand. Older Insteon devices do not manage things on their own. The dynamic management of hops was a later addition. Even then, my understanding is that doesn't happen between the PLM and devices (feel free to correct me on that). On that we agree. And I'll say it one more time and leave it at that - a clean system won't require retries or multiple hops.

Do I have a "kick me" sign on my back today.

There is a maximum of three hops allowed. If lessening hops was going to lead to such instability, then Insteon would have allowed one more bit for MAX HOPS and increased the max to 8. Lessening retries will hardly ever improve anything. A device only uses a retry if it doesn't get an acknowledgement. If it consistently doesn't get an acknowledgement then it isn't working. If it isn't working, you'll notice it and fix it. If you don't notice it, then its use of retries apparently isn't causing you to notice a degradation in your home automation. I've read the white papers many times. Typically I refer to them before making responses about how Insteon works. Thanks for not boring me with the details here. Your response both says that Insteon devices are smart and that the Insteon designers aren't. If those designers were smart, why would they include the ability change configuration parameters for devices that you say are smart enough to know when to send more or less? They included the ability because sometimes it helps, either for reliability or speed.

In my opinion, it's actually opposite. If MAX HOPS is set to 3 then all devices must wait for the time it would take for the message to be repeated three times before they can respond, whether they heard the message the first time or not. They must wait so that they don't try replying while another device is possibly repeating the original message which would cause message collisions on the power line. On the other hand, RETRIES are variable. If a device sends a message and immediately receives a reply, the communication is done. It's only if the original message is not acknowledged that the original device will resend the message*. So on a clean powerline devices that use a retry value of 3 will use way less bandwidth on the powerline than devices that use a max hop value of 3. * - Most Insteon devices that use RETRIES will default MAX HOPS to 1 when they originally send their message. If they don't receive an acknowledgement then when they retry sending their message they will increase MAX HOPS by one (up to a max of 3).

I'm pretty sure it has worked this way for as long as I've had my ISY, which admittedly is not as long as you have had yours. I'm not sure this scenario is why we have the difference between "Status" vs "Control". "Control" has always been described to me to mean local control of the device. Which is to say, if a switch is turned on by the ISY, or a linked device, the ISY does not see that as "Control" even though it often would be helpful if it did.