Chris Jahn

Although not needed in this example, here's a couple rules of thumb for ISY programs: 1) If your actions contain a wait or repeat and you don't want them interrupted then split the program into two programs, with the first containing the conditions, and one second containing the actions. Use 'Run Then' in the first program to start the actions in the second program. 2) If you want to have some conditions trigger the program, and others not trigger the program then split the program in into two programs, with the first containing the trigger conditions, and the second containing the non-trigger conditions and actions. Use 'Run (If)' in the first program to start the second program running. The second program should be disabled (ie. not automatically triggered). As for your specific example, these programs will turn the light on/off using the motion sensor unless the light was already on. The reset program stops the off timer if you manually turn the light off/on after the motion sensor turns off. All programs are enabled: KitchenMotion.On If Status 'MotionSensor' is On And Status 'KitchenLight' is Off And From Sunset To Sunrise (next day) Then Set 'KitchenLight' On Run Program 'KitchenMotion.Flag' (Then Path) Else - No Actions - (To add one, press 'Action') KitchenMotion.Off If Status 'MotionSensor' is Off And Program 'KitchenMotion.Flag' is True Then Wait 15 minutes Set 'KitchenLight' Off Run Program 'KitchenMotion.Flag' (Else Path) Else - No Actions - (To add one, press 'Action') KitchenMotion.Reset If Status 'MotionSensor' is Off And Status 'KitchenLight' is Off Then Run Program 'KitchenMotion.Flag' (Else Path) Else - No Actions - (To add one, press 'Action') KitchenMotion.Flag If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') There is another example here showing how to implement a state machine for more complex cases.

Thats very odd, maybe a friend did a manual link as a practical joke. Here's the steps I would take: 1. Restore device on the LampLinc. This would remove any new manual links that someone may have made. 2. If still a problem: - a. Duplicate the phantom link in the ISY by adding the LampLinc to the scene that the SwitchLinc controls. - b. Remove the LampLinc from that scene. -- You may need to repeat this once or twice if somehow multiple links were added to the LampLinc. 3. If you still have a problem, use the Tools to compare the device links to help further debug the problem.

I may have read your post wrong, but it wasn't clear to me if you were using the scene instead of the controller in your programs. The terminology for Scene is a little misleading ... In a practical sense, each controller is itself a scene, containing its own set of levels/rates for the responders. Therefore if you want to adjust the behaviour of an individual controller then you must use the controller, and not the overall scene. e.g. To adjust levels/rates for MotionSensor Scene1 | +--- MotionSensor +--- SwitchLinc1 +--- SwitchLinc2 You would select 'MotionSensor' as the 'Scene' for Adjust scene. Here's another example If you are already doing this and its still not working then there is either a communications problem with the switchLinc's at the time the programs run, or there is a bug. The easiest way to test this is to run the program manually, then go to the main page and see if the levels/rates were changed.

I need to emphasize to anyone following this thread that the you do have this today, it just requires 2 programs. The issue being addressed in this thread is not functionality, but user interface, in that requiring multiple programs seems cumbersome to many.

The last thing we want to do is complicate the existing interface, therefore any changes we consider would have to contain additional function that you just don't have right now. I don't think he is calling for new events at all, just another mechanism for recognizing the existing events. The goal for many of these suggestions is to make it easier to separate conditions that trigger the program vs conditions that do not trigger the program.

This is an interesting thread, and I have gone down many of these design paths myself. When we prioritize a change to the programs interface it will address these issues. You are correct, any change will be compatible with existing programs.

I hope you didn't take offense, certainly none was intended, and we do appreciate your contributions to the Forum. I added my responses simply because some of your posts seemed to imply separating triggers and If couldn't be done at all.

So, is this statement always evaluated as "true" except at the instance when "On" is received. Is the implication also that the trigger for evaluation of this statement is still just an "On" command from the device (off, dim, bright, xx% will NOT necesarily trigger an evaluation)? Yes, that is correct.

Kingwr, I think you are arguing the merits of having this all contained within one program, but just to be clear, you can separate triggers and If conditions with the ISY (see this post), it just requires a separate program.

Its not a bug, but the syntax could be clearer. "Or Control 'Kitchen / Kitchen Intercom/Puck L' is not switched On" Could be rewritten as this: "Or Not (Control 'Kitchen / Kitchen Intercom/Puck L' is switched On)" Thats not how it works, Control statements only trigger the program if the control value (i.e. 'On') matches. You can do this now by using two programs. The first program is enabled and contains the trigger conditions, and whose only action is to 'Run If' the 2nd program. The 2nd program is not enabled, and therefore the If conditions are only used to determine whether the Then or Else path is taken, not whether the program is triggered or not. For more complex Logic, the 2nd program could instead be a set of programs all 'Run If' by the first program. The 1st program could also be a set of programs, each of which 'Run If' all of some of the other programs.

Thanks Lee, just trying to keep the record straight. Thanks for your input. I'm glad this discussion is getting some visibility. As I noted, I was advised by UDI to list the devices, and avoid putting the multi-way scene itself in the Action list. ... ... In other words, if you want to turn off all the lights in a virtual circuit with 3 lights, you want to have 3 separate Off commands in the list of Actions. You should not take the short-cut of simply setting the scene (that manages the multi-way circuit) to Off. ... I'm not sure who would have said this, or maybe an explanation was misinterpreted somehow; but it is not correct. It is almost always better to use a scene rather than setting devices individually. In fact, the only time I wouldn't use a scene is if I have only a single responder.

I think you are reading too much into this, the simplest way to think of the program cycle is this: 1. When an event is received that causes a program to run, it runs either the Then or the Else 2. A running program can only be interrupted during a Wait or Repeat. 3. If a running program is interrupted (See 2.) by an event that would normally cause the program to run, then the program is stopped, and run again, either the Then or Else path. In other words, at wait/repeat statements, programs can be interrupted and restarted by incoming events.

Overall very nice write up! couple of comments ... This actually describes the side effect of what is going on. When an event occurs that would normally cause the program to run (either the 'Then' or the 'Else') then the program stops if it is currently running, and picks up again at the 'Then' or 'Else'. The reason it appears as if 'Wait' and 'Repeat' evaluate the 'If' is these are the only actions that return control to the "program cycle" which actually tests conditions when new events come in. In other words, the set of actions between a 'Wait' or 'Repeat' is essentially atomic (not the nuclear kind ). This should not cause performance problems because the system only actually re-evaluates conditions that are affected by whatever event has occurred, and therefore uses the previous true/false value for unaffected conditions. This is also one of the reasons we don't short circuit the expression.

No problem, Glad to help.

Some variation of the following would work. You basically have RSTOP trying to stop RSTART before it can call Do Something. You can adjust the wait in each program to change the frequency at which Do Something actually gets called. RSTART Then Wait 10 seconds (Random) Run Program 'Do Something' (If) RSTOP If Program 'RSTART' is True Then Wait 4 seconds Stop program 'RSTART' You could also do something similar in one program: If From Sunset + 30 minutes For 4 seconds Then Wait 10 seconds (Random) Run Program 'Do Something' (If) Else - No Actions - (To add one, press 'Action')

This confirms to me that for some reason when the program was created, it was not given a valid parent folder. If a program does not have a valid parent when loaded into the GUI, it is automatically moved to the My Programs folder (thus the green arrow because it was changed). Yes, let us know if it happens again.

Johhnyt, I've received the export file you sent, and its looks fine. I also loaded it onto an ISY here and tried reproducing the problem but could not. When you actually save the new program when this problem occurs, and then hit "Undo Changes" to see it in the tree, does the new program then appear with a green arrow in the tree icon, or is it just the plain icon? When this happens again, could you try exporting one of your programs, and then importing it into the same or different folder to see if that works. I don't know if this would fix the problem, but I noticed you mentioned you are running Java 1.6.0_20, could you try upgrading to 1.6.0_22. This is no problem, you can freely rename "My Programs" to anything you wish.

I haven't been able to reproduce this problem here, but there seems to be something going on with the folder structure of your programs. Based on your description of the problem, it looks like its somehow trying to add a program to a non-existent folder. The next time this happens, and before doing Undo Changes, please export your programs by right clicking on My Programs and selecting Export. Please send the file to support@universal-devices.com. Also, in the e-mail, please indicate which folder you tried to add the program to.

If you see a program in Program Summary, but not in Program details, then it is likely an issue with one of your folders. If this occurs again: 1. What does the "path" show in the program summary for the new programs that don't show up in details page? 2. In program summary, Right Click and select "Edit" and see where it takes you on the Program Details page. When you create a new program, it creates it inside the Admin Console and does not tell the ISY about it until you actually save it. Therefore, for this particular problem, the ISY itself, and any issues communicating with the ISY should not be a factor. To get around the problem, try pressing "Undo Changes"; this reloads all the programs from the ISY into the Admin Console. You should not have to restart the ISY as this problem is entirely contained within the Admin Console itself.

I suspect you used 'Remove existing links' when adding the device. Currently, if you select 'Remove existing links' it removes all links from the MorningLinc and due to the security measures on the MorningLinc, the PLM can no longer send commands to it. Try adding it this way: 1. (Optional) Factory reset the MorningLinc 2. Link Management -> Start Linking 3. Select 'Add devices found in links and keep existing links'. 4. Link the MorningLinc

We could add a feature like that, but to stay compatible with existing programs it would more than likely be a different action or option and not actually "wait 0". Chris

That's a good question, but I'll need to defer to Chris for the answer . You are correct, it optimizes out the wait 0.

You could also base the program on the status of the light: http://forum.universal-devices.com/view ... highlight=

You're very welcome, hopefully this resolves it.

Hi gfridland, The Catchup Schedules at restart box on the configuration page indicates that when the ISY is restarted, all schedules for the current day are run (starting from just after midnight the night before up until the current time). The Grace period is used during regular operation, and only in the unlikely case where the ISY does not test a time condition at the exact moment specified in the condition. Therefore, as you mentioned in your original post, you should uncheck the Catchup Schedules at restart box to prevent those programs from running when the ISY restarts.