Goose66

A program to track the status of the X10 B4 signal would work. You would want to reset the program at midnight, or you could let the Sundowner reset it if it sends an X10 "Off" at sunrise. The other option is to purchase the X10 add-on module. Then you could track the status of the X10 B4 address in the ISY and put a Status condition in your program. In this scenario, you would have an if statement much like above: If ( X10 'B4/On' is Received And From 6:00:00PM To 11:59:00PM (same day) ) Or ( Time is 6:00:00PM And Status X10 'B4' is On )

What about one program with this If statement: If Time is Sunset + 30 minutes And From 7:00:00PM To 11:59:00PM (same day) Or Time is 7:00:00PM And From Sunset + 30 minutes To 11:59:00PM (same day) Then Set 'Dining Room' On Else - No Actions - (To add one, press 'Action') Haven't tested it, but logically it should work, right?

If you refrech your ISY from these devices, what scenes does it show? If you can set it up manually, there should be a way for the ISY to reflect the setup with the devices and scenes. I would imagine there are two scenes with the LampLinc, one with the SwitchLinc as a controller, and the other with the RemoteLinc and ControlLinc.

"Run Program '' (Then Path)" is what you select for the action in your first program.

I see a number of problems here. First, the "Control 'Garage-Sensor' is switched Off" condition is ORed with the Sunset to Sunrise condition. So, the Kitchen light will turn ON at Sunset - 30, regardless of whether the garage is opened or not. Is this intended? Also, anytime the garage opens during Sunset-30 to Sunrise, the light will turn on full because the conditions are ORed. Second the condition "Control 'Kitchen' is not switched Off" is a control condition, not a status condition. This essentially means that no OFF command was received from the Kitchen switch concurrent with whatever other condition kicked off the program. What you want here is (I think) "Status 'Kitchen' is Off," in other words not On or dimmed. If your intention is to turn the kitchen light ON whenever the garage door is opened between Sunset-30 to Sunrise as long as the Kitchen light is not already On or dimmed, then your program should look like: IF Control 'Garage-Sensor' is switched Off And From Sunset - 30 minutes To Sunrise (next day) And Status 'Kitchen' is Off Then Set 'Kitchen' On Else - No Actions

By the way, here is what the other poster meant by "latching" a second program. In your first program, instead of the THEN branch containing: Set 'LR Table Lamp' On Wait 20 minutes Set 'LR Table Lamp' Off change it to: Run Program 'LampOn20Minutes' (Then Path) The program LampOn20Minutes would contain no ?IF conditions and the following in Then branch : Set 'LR Table Lamp' On Wait 20 minutes Set 'LR Table Lamp' Off The LampOn20Minutes program would be executed by the first program when the conditions were met and run independently of the first program. Therefore, it would not be preempted by subsequent runs of the first program when the conditions change. When I do this, I often put a "Set 'LR Table Lamp' Off" or the like in the Else branch of the second pgoram as well, just to have a cleanup branch of the program to call, if needed.

A running program in a WAIT will be prempted (i.e. old instance stopped in favor of the new instance) if the trigger conditions for the program occur again, thus causing the program to execute again. You are using status conditions for both the garage door sensor and the lamp. Status conditions will trigger the program any time the status changes. So, assuming between sunset and sunrise, the lamp is OFF, and the garage door is opened (garage-house-sensor is turned ON), your program will run the THEN branch. The first thing that your program does is turn the lamp ON then enter a WAIT. But, hold-on a second, the status of the lamp has now changed to ON, which will kick-off a new instance of the program, causing the old instance of the program in the WAIT to end. The new instance of the program will run the ELSE branch (the lamp is ON) and thus nothing will happen. Your program never makes it to the Set Lamp OFF command. Also, the same thing would happen if somebody closed the garage door in the 20 minute interval, because the status of the gargage-house-sensor would change to off, thus re-running the program and killing the WAIT, thus never turning off the lamp. There are all kinds of convoluted solutions to this issue that you will find all over these forums. My recommendation is to remove the Lamp is OFF status condition, and change the garage-house-sensor condition to a control condition, i.e. "If Control 'Garage-House-Sensor' is turned On." This way, if the garage door is opened between sunset and sunrise, the lamp will turn on and then turn off in 20 minutes, even if the garage door is subsequently closed or the lamp is turned off in the mean time. You are still left with the boundary condition of Sunrise. If Sunrise occurs during the 20 minute interval, i.e. while the program is in the WAIT, the program will again be pre-empted by a new instance, and the lamp will not be turned off. Note that I have long advocated seperating trigger conditions for a program from the conditions in an IF statement. This comes up again and again in programming questions. I wish others would take up the cause and we could get this changed.

Good to hear. However, there is still the fact that running the THEN path of the Disarmed program will not cause programs located in a folder with an "If Program 'Disarmed' is True" condition to run, unless the programs also have the status of the Disarmed, Armed Away, or Armed Stay programs in their own If conditions. I think it is important to point that out for future readers of this thread.

Mitch, I setup a test scenario to test this functionality, and I can confirm Darrell's comments. I established a status program Test Status with no code, a folder Test Folder with the following IF statement: If Program 'Test Status' is True Then Allow the programs in this folder to run. and a program Test Program inside of the folder with the following: If From Sunset To Sunrise (next day) Then Set 'Outdoor / Front Lanterns' 65% Else Set 'Outdoor / Front Lanterns' Off I then set the status of Test Status via the REST interface with the following: http://isy//rest/programs/0011/runThen (or runElse) I can confirm that setting the Test Status program True or False via the REST interface does enable the folder Test Folder and schedules or unschedules a Next Run Time for the program Test Program in the Test Folder. However, the Test Program is not executed. Perhaps if you post your actual code, we can find the reason why your program is executing upon change in status of the parent folder.

I don't think I understand the problem. You say "every time a Run Program is sent, the ISY re-evaluates the Folder that is True and resets all the devices to their programmed settings." What is "the Folder that is True," and are you suggesting that the ISY sets the status of the devices in this folder to some defaults without a specific command or function request to do so, i.e. "every time a Run Program is sent?" If so, sounds like a bug in the REST interface. I would suggest logging a support bug.

So you are saying that the ISY is single threaded and you want a WAIT 0 to allow the ISY to run other programs at the same time your program is running? My understanding is that all the WAIT will give you is the ability for the ISY to preempt your currently running program in favor of a new instance of the same program becuase the trigger conditions have occurred again.

Only that IMO Insteon traffic is better than X!0 traffic, in both reliability and bandwidth usage. I rely on Insteon for home automation traffic. I wouldn't want such traffic on my ethernet network, for example. But as we can see from the start of this thread, I prefer to follow the KISS principle in each aspect of my implementation. If you have an Elk or other security system, perhaps you could use that to monitor your motion sensors out-of-band from the Insteon network and communicate with the ISY over the REST interface (does not require the network module).

The EZx10RF does not put any X10 traffic on your powerlines. It receives X10 RF from the motion sensors and sends Insteon commands over the powerline.

I went through my 8 KeypadLincs and gave all the buttons fancy names for their eventual functions (in my dream world). Now I am implementing some of those functions, but I can't figure out which buttons (B, C, D, E, F, G, H) map to the fancy names I provided. The ISY Admin Console lists them in alphabetical order and shows the Insteon address for each, but not the group number corresponding to the button. Anyway to find this in the Admin Console?

All I can say is: Damn! I can't even tell what you are trying to accomplish, but if it takes all that, then there is definitely something wrong with the ISY programming model!

Sorry, I forgot that no post is good unless there is a solution: I would suggest two programs, one with the condition: (Control 'Mbed ceiling floods' is switched off or X10 'B5/off (11) is recieved) And (Status 'Fam Rm Tbl Lamp' is on or Status 'Curts office" is on) and one with the condition: (Control 'Mbed ceiling floods' is switched off or X10 'B5/off (11) is recieved) And Status 'Fam Rm Tbl Lamp' is not on And Status 'Curts office" is not on) Put the THEN branch of your original program in the THEN branch of the first program, and the ELSE branch of your original program in the THEN branch of the second program. Note that I have advocated for the seperation of trigger conditions from IF conditions in the ISY. The way that it is now is very different from other automation controllers and software. Maybe if enough people are confused, some changes can be made.

Curt, You are confused regarding the difference between what causes a program to be executed (trigger conditions) and what is evaluated in order to go down the THEN or ELSE branches (IF conditions). Believe me, you are not by far the only one. The way it works is that if you have a status condition in your IF, the program will run everytime the status of that device CHANGES. If you have a control condition in your IF (Control Device Is Switched On), then the program will run everytime that command is received from the device (or any command is received from the device if the condition is (Control Device Is Not Switched On). See this thread: http://forum.universal-devices.com/viewtopic.php?t=4639

Not to be flip, but this is like writing code that properly calculates a leap year. Divisible by 4, but not by 100, except by 400. You could put that calculation all over your code only to later realize that the first time divisble by 4 doesn't work is 2100. Will your program be running then? Just make an If range for July through October of 2010 OR July through October of 2011 or July through October of 2012 OR July through October of 2013, and that should hold you for a while.

Let me first say that I have several times expressed the need to seperate the trigger conditions for a program from the IF statement conditions, i.e. what starts the program running versus what conditions are evaluated to resolve the IF statement. Much of the confusion could be eliminated by making this change in the programming structure. Second, with all due respect, Mark James's example is not quite correct. This example confuses the difference between "Control" conditions and "Status" conditions. If your condition is "IF switch is turned ON" (a "Control" condition), then the program will only be executed if the switch is turned ON. The program will not run if the switch is turned OFF. For example: If Control 'Master Suite / Keypad - G' is switched On Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off This program will turn the "Left Sconce" ON when the G button is turned ON. However, it will never turn the "Left Sconce" OFF (the ELSE branch), nor will the program status ever be FALSE. The IF condition in this program will always be true, because the program is only run if the G button is turned ON. Compare that with: If Control 'Master Suite / Keypad - G' is switched On And Control 'Master Suite / Keypad - G' is not switched Off Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off In this case, the program works more along the lines of what would be expected. This program is run anytime a G button command is sent, be it ON, OFF, DIM, whatever. This is because all commands are needed to evaluate the "IF switch is not switched OFF" condition. Therefore, turning G ON will turn the "Left Sconce" ON and turning G OFF will turn the "Left Sconce" OFF. Contrast all of this with "Status" conditions: If Status 'Master Suite / Keypad - G' is On Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off This program will run anytime the status of G changes. So, if G is OFF and G is switched ON, then the program will run and the "Left Sconce" will turn ON. If G is subsequently turned OFF, the program will run again and the 'Left Sconce" will turn OFF. Note, however, that if G is ON and is switched ON again (such as a keypad button in non-toggle ON mode), the program will not run since the status hasn't changed, where the two programs provided above will run anytime G is switched ON, regardless of the previous status. Hopefully this helps you understand WHEN programs run, and thus what the likely outcome of the IF statement will be (THEN branch or ELSE branch). Mark James's comment regarding a WAIT in a program is correct. If the program is in a WAIT and is executed again, then the WAIT is termintated, and any subsequent statements are not executed, in favor of the newly executing instance of that program. The same holds true for a REPEAT.

I did test this and it works. The lights in the scene that are off remain off.

It sounds like you want it to be more sensitive to motion, not darkness. There is a jumper to adjust the sensitivity range, but this defaults to the most sensitive. If you want to adjust the sensitivity to darkness for the Dusk/Dawn feature, the v2 Motion Sensors have a potentiometer to adjust the sensitivity. The v1 sensors do not. You could always disable dusk/dawn and write a program to turn on the lights within a time range when motion is detected. However, this will insert a brief delay between motion and the light coming on.

Try something like this: Put all your interior lights in a scene call "Interior All Lights" and then add a program such as: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 5 times Set Scene 'Interior All Lights' Dim Else - No Actions - (To add one, press 'Action') Running the THEN branch of the above program will reduce the level of all lights in the scene by about 15%. If the lights are off, they stay off.

Assumptions: you have a program activated by an ON command from the motion sensor (MS) that starts a 5-minute WAIT and then turns off all the lights in your bathroom. Also, your lights are always set to one of a number of scenes activated by Insteon controllers. 1. Create a first set of programs, one program for each scene, with a condition set to OR each of the controllers for the scene (there is no way to build a condition that is the status of a scene, unfortunately). The THEN branch for each of these programs would run the ELSE branch of all the others, thus only one of this set of programs would be true at any given time. The true program would represent your last scene set. 2. Create another set of programs, one program for each of the programs in the first set, with a condition for the motion detector command ON (not status) and the status of a corresponding program in the first set of True. The THEN branch for these programs would turn on the corresponding scene, nothing more. 3. In your original motion sensor program, after the 5 minute WAIT and the lights off, put another 15 second WAIT, and then set run the ELSE branch of all of the first set of programs to ensure they are all false. Now, when a scene is turned on, the corresponding program from the first set of programs will be set to true. Then, during the 15-second wait after the original program turns off the lights, if an ON is received, the scene that was on will be reactivated, and the original program will be re-run with a new 5-minute wait timer. If you have an all lights off button or some other such controller, you will also want to change that program (or add a new program conditioned on that button(s)) that also runs the ELSE branch of the all of the first set of programs to clean everything up. One drawback of this approach is that while there is movement in the bathroom, there will be repeated ON traffic for the currently activate scene. This could be cleaned up with additional conditions for the second set of programs, but would make keeping them in sync with the scenes complicated. If your lights are set to random levels (i.e. not predefined scenes), then this is not currently possible. Depending on the implementation, this may be possible once the variables feature is added, however.

The status of the button is only important if you use Status type conditions to trigger your programs. As stated above, use Command type conditions instead and the status won't matter. Same deal for motion sensors that are programmed to only send ON commands.

Dwayne, One scene would be All Lights. This scene could be linked to one RL button ON would turn all lights on, OFF would turn them off. For chart light only or reading lamp only, you could do with programs or scenes. For a chart light only scene, for example, set the chart light to 100% and the other lights to 0% in the scene. Link the scene to an RL button. Turning the button ON turns the chart light on and the other lights off (0%). Turning the button OFF turns all lights off. To do this with a program, use the condition "Control 'RL button 5' is switched on" instead of "Status 'RL button 5' is on." This way, the program will run everytime you press ON on button 5, regardless of the status of the button.