Chris Jahn

This is fixed in Release 2.4.13 --------------------------------- For Release 2.4.12 and earlier Please do not use Repeat 0 times as this may hang your ISY. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 0 times Else - No Actions - (To add one, press 'Action')

Rand, You are great at finding bugs, and I am just sorry that one of this scope still remains. I'll try to recreate the problem, and let you know how to get your box working again.

Frank, To some degree, you can use programs as a means of naming your X10 devices (A1, A2 etc.) In this example, program 'Dining Room On-Off' represents X10 A4 On or Off, essentially naming it 'Dining Room On-Off'. 'Program 1' references A4 directly. 'Program 2' is identical, but references 'Dining Room On-Off' instead of 'A4' Program 'Dining Room On-Off': If X10 'A4/On (3)' is Received And X10 'A4/Off (11)' is not Received Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Program 1: If X10 'A4/On (3)' is Received And X10 'A4/Off (11)' is not Received Then Set Scene 'Dining Room' On Else Set Scene 'Dining Room' Off Program 2: If Program 'Dining Room On-Off' is True Then Set Scene 'Dining Room' On Else Set Scene 'Dining Room' Off

I'll see what I can do, but this may have to wait for the next release.

I think it is simplest to use 5 programs to do this. You don't need any new folders for this, although you might want to put them all in one folder just to keep things organized.

Adam, Please post one or two of the triggers that stop working after a few days; we have not heard of this problem before. Have you tried logging the keypresses: http://forum.universal-devices.com/viewtopic.php?t=346 Do you still see these events in the java console, yet the programs do not run? Thanks

Yes, changing either the ramp rate or on level of the local load requires a soft reset.

Doing the soft reset is only required if you are changing the levels of the local load. If you are changing the levels for devices in a scene, no soft reset is required.

When you 'Run' a program explicitly from another program, it does not test the conditions of the program being run, instead, it immediately sets the Program to True and runs the the 'Then' actions (or sets the Program to False and runs the 'Else' actions if you used 'Run Else'). If you explicitly 'Stop' a program, the program 'Then' or 'Else' actions are stopped, but the program True/False state is not changed. Having mulitple programs listen for the same X10 signal (or any other event) is fine; its designed for this. Getting a barrage of commands all at once is fine, again, its designed for this. We put the commands on a queue, and just run the commands one by one until the queue is empty.

There is no problem at all having many of these programs. Adding the wait to the 'Then' should be all you need for the temporary override.

Thats a good idea, I'll add a timestamp to the output.

Thanks Rand, I didn't stay up all night; fortunately when I tried it again this morning I found a way to reproduce the problem. As for the 'And/Or', I could not reproduce the problem, so please let me know if it happens again.

Hi Mike, You can use two programs to accomplish this. Basically by running a separate program, it won't be stopped like the 'Then' would be when the condition changes. Program 1: If X10 'B1/On (3)' is Received And Status 'FoyerControls1A-Driveway' is Off Then Run Program 'Program 2' Else - No Actions - (To add one, press 'Action') Program 2: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set Scene 'Driveway' On Wait 5 minutes Set Scene 'Driveway' Off Else - No Actions - (To add one, press 'Action')

It is a bug, that is why I mentioned the workaround. It will probably be fixed for this release.

Good point Mark, we NULL the device reference when it is deleted, but don't set it back if the device is added back to ISY. The simplest workaround is to just restart your ISY, but if you want to leave it on, you can update all the programs that reference the device instead.

I found a way to reproduce this problem consistently, and have fixed the problem.

Thanks Rand, 1) And/Or The And/Or swapping looks odd, but is working correctly. An And/Or is assigned to each line as you add it. If its the first entry, or the first entry after an open parentheses then it is not shown because it is not used. When you move the line down, it then appears because it is used. In other words, you see: If Control 'Patio' is switched Fast On Or Control 'Patio' is switched On Then But its the same as: If And Control 'Patio' is switched Fast On Or Control 'Patio' is switched On Then Swap the lines: If Or Control 'Patio' is switched On And Control 'Patio' is switched Fast On Then You see: If Control 'Patio' is switched On And Control 'Patio' is switched Fast On Then 2) Fast On changed to On I tried doing this for awhile, and managed one time to get it to do this by some random combination of what you mentioned. I can't reliably reproduce it, but I'll see if I can make a fix for it. It took me so long to reproduce this, I'm surprised you found it in the first place.

This will work fine, although I would suggest using a scene to turn off all the lights in the 'Then'.

Rand, I followed your basic steps (and a few variations) but cannot reproduce this problem. Can you give me an exact sequence of things to do to make this happen?

We forsee a lot of enhancements to triggers in future releases. For now, the best way to implement holidays is to make an individual program for each of the holidays, and then reference the program. You can then update those holiday programs without having to touch the programs that reference them. Program 'New Years Day' If From 12:00:00AM on 2008/01/01 For 24 hours Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Reference the program 'New Years Day' If Program 'New Years Day' is True Then Set 'Holiday Lights' On Else - No Actions - (To add one, press 'Action') We also envisioned doing this for things like office hours: Program Office hours (could also be a folder condition) If On Mon, Tue, Wed, Thu, Fri From 9:00:00AM To 5:30:00PM (same day) Or On Sat From 10:00:00AM To 2:00:00PM (same day) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Turn the Main Lobby on during office hourse, off otherwise If Program 'Office Hours' is True Then Set 'Main Lobby' On Else Set 'Main Lobby' Off

I think Rand answered your question, but just to be complete ... The original program is still running, and if its in the 'wait 20 seconds' step when the 2nd program runs, then the 1st will continue and slowly ramp up the light. To be safe, you can add 'Stop Program 1' to your second program.

Thanks Mark, I went ahead and added it to the example programs.

Use these programs to keep a light on between Sunset and 10:30PM, and off otherwise; even if it is turned on/off manually. Program 1: Keep the light on If From Sunset To 10:30:00PM (same day) And Status 'ApplianceLinc' is not On Then Set 'ApplianceLinc' On Else - No Actions - (To add one, press 'Action') Program 2: Keep the light off If From 10:30:00PM To Sunset (next day) And Status 'ApplianceLinc' is not Off Then Set 'ApplianceLinc' Off Else - No Actions - (To add one, press 'Action')

You can write a program to do what you want, but the standard behaviour is to run the 'Then' when the you enter the range (sunset), and run the 'Else' when you leave the range '10:30PM'. Therefore, your program turns on the 'ApplianceLinc' at sunset, and turns it off at 10:30PM. To do what you want, you need two programs: Program 1: Keep the light on If From Sunset To 10:30:00PM (same day) And Status 'ApplianceLinc' is not On Then Set 'ApplianceLinc' On Else - No Actions - (To add one, press 'Action') Program 2: Keep the light off If From 10:30:00PM To Sunset (next day) And Status 'ApplianceLinc' is not Off Then Set 'ApplianceLinc' Off Else - No Actions - (To add one, press 'Action')