oberkc

The only time this set of conditions will trigger AND evaluate as true would be when the button D changes to ON for any reason except (possibly) when it changes to ON as a result of FASTON action directly from the keypad button, itself.

This is consistent with my understanding. Secondary (non load controlling) buttons are either ON or OFF. They can send dim and bright commands as scene controllers, but, themselves, are either on or off.

I would take a simpler approach. One scene, including only the keypad button. One program: If From 8am to 4pm Or from 11pm to 7am (next day) Then Set keypad button scene on Else Set keypad button scene off I would then use the status of the keypad button as the indicator whether your system is armed. I would use that as a folder condition: If Status keypad button is not off Then allow programs in this folder to run In the folder, I would put any program I want to trigger, but only when the system is armed.

Alsorrell, I suspect the single problem you had was that you did not configure your button as NON-TOGGLE ON. Perhaps a single scene would work, but your scenes looked correct as described. Set up this way, there is only one way for the KPL to be off...that is, for the sensor to turn it off. Given this, there is a high level of confidence that if the sensor is off, the door is closed.

I use two separate scenes, rather than a single scene, but this is an intriguing thought. Is there not concern that the sensor (as controller of the relay) might cause the relay to trigger as it changes state? Perhaps there are built in protections for this that I have not heard of or forgotten.

Your described behavior sounds abnormal from my experience. If a program runs, I expect it to show one of two outcomes: TRUE OR FALSE. I also expect this state to be reflected in the program listing. Next chance I get, I will confirm, but something sounds not quite right with your program status.

To LeeG's response.... Disabling a folder, by itself, does NOT cause the included programs to trigger, nor does it cause them to turn false. Disabling a folder simply disables the trigger inherent in each program condition. The included programs, simply, will not self-initiate. If a program last ran true at 4pm and the parent folder became false at 5pm, the program is still true. Programs in a folder, even if the folder condition is false, can still be triggered externally, such as when called by other programs or through the admin panel. When called in this manner, they will evaluate and execute the same, regardless of folder condition.

Jumper 5 allows control of motion sensor options via external sources. Yes, ISY can set those options if jumper 5 is in place.

To double check, have you written the changes to the motion sensor as you adjust the settings? Watch for little funny symbols down at the lower left of your program and device listing. They can sometimes indicate the need to write changes to the device. Battery devices are especially important to pay attention to that detail. They cannot be written to without putting them into linking mode.

Don't get too hung up on the actual programming words I used. This was conceptual (though it IS easy to miss "next day" in the condition). The ISY will create these for you.

Try something like: If Time is from sunset To sunrise (next day) Then Turn lights on Else Turn lights off If you actually prefer two programs, this is an possible as well

If you can figure out how to enable the motion sensor mode where it sends only ON commands, then, yes. What is jumper 5 set to? Is there a reason you are not setting this configuration through the ISY?

Yes, good point. I missed that. So your program, as is, with the shutoff program at 6:31, will simply leave the lights on for 1/2 hour at most. No big deal.

I believe scenes are more than the "preferred" approach to controlling secondary buttons. I believe secondary buttons respond ONLY to scene commands. If you want to change the status of a keypad through mobilinc, or a program, or the admin panel, I believe you MUST use a scene. Regarding a program to activate only after a combination of buttons is pressed, I am near certain that is within the abilities of an ISY. Consider button combination B-A-C. Consider making the buttons non-toggle off, and adding programs such as: If Control keypad button B is off then wait 3 seconds run this program (else path) else nothing If Control keypad button A is off and first program is true then wait 3 seconds run this program (else path) else nothing if control keypad button C is off and second program is true then arm/disarm This example is a quick idea, but could be made more robust and secure with the addition of other conditions, timers, whatever. This was just a quick idea to get your mind rolling.

What is the configuration of your motion sensor. Is it possible it is not sending ON commands before the 3 minute timer? The program, to me looks fine. Yes you need jumpers set in a specific way. Instructions will describe purpose of each. Check out jumper 5...I believe this allows software control, allowing ISY to set parameters. Once enabled, make sure you sensor is in occupancy mode (triggering ON command at every sensed motion, no time-out periods.) Another possibility...is the light and sensor part of a scene together?

If I can assume you have found a way to reliably define and know phone "status" (are you using a variable?), the logic is pretty much as you have it: If Status keypad A is on <<<are you using status or control? And status keypad B is on And status phone is 0 And status phone2 is 0 Then Do something The obvious things to look for....are you using congrol or status as a program condition? What are you telling it to do in the THEN path? Is the ISY SEEING THE status changes correctly? The logic is near bulletproof. Yes you can control buttons remotely. You may need to create a scene, add the button as the sole device in the scene, then control the scene remotely.

If all you want is to ensure that controllers for kitchen scene come on when you press dinner scene, then including as responder to dinner scene is likely best option. If, in retrospect, your interests are broader and you want the kitchen scene controller button to come on when any individual light within the kitchen scene is on for any reason, I would tend to favor the programmatic approach described by erick. As with many cases, it all depends on what you are trying to achieve.

Yes. I noticed that you did no have any automatic light shutoff when triggered on weekday mornings. Rather than adding a new program, why not simply put a 5 minute timer in the morning ramp up program?

1. Almost a certainty. 2. Yes. To offer more specific advice, you may need to describe what combinations of the four buttons drive which programs. For example -If button A and B are on, and C and D are off, then run program X. -If button C is on, regardless of state of other buttons, run program Y only. At risk of embarrassing myself, I believe that there are 16 combinations that can be made from those four keypad buttons. If one is not careful here, it will be easy to create conditions where more than one program might fire. Is this acceptable?

Are those "other buttons" assigned as responders to "dinner time" (they should be, if you want them to come on in response to dinner time). The fact that one scene turns on lights that are also part of another scene does not automatically cause controllers of the other scene to come on.

I see that there is a universal interface available for the rollertrol blinds. It seems that would interface will with an insteon IOlinc. I see also a usb dongle RF controller available and claims that this can be accessed via a vera controller. Based on my own experience, I assume that this dongle would be available to the ISY through the network module, but may require abilities to communicate via some REST or HTML or other interface with which I have yet to personally use. I don't believe that there is a plug-and-play solution here.

All other things being equal, they violate my KISS principles. Otherwise, nothing.

I am like teken...simple is good. Use scenes when possible. Minimize number of programs. Minimize lines of code. Don't use variables when other options are available. Consolidate programs. Spend some time thinking about what you want to accomplish. Think about unintended consequences. Plan. If your requirement is to turn off the light 2 minutes after motion is detected, dont complain when the light turns off 2 minutes after motion is detected. (..but I turned it on manually!)

In addition to stusviews points... CONTROL conditions also trigger only upon receipt of anticipated command. "Control On" will trigger only upon receipt of an ON command. Thus, when such is the sole condition for a program, it can never run false. On the other hand, status conditions will trigger upon ANY change in status and can run true or false by themselves.

Perhaps the question is whether the programs are ever DISABLED. My guess is not. Your first program will never run FALSE, unfortunately. Perhaps if you change CONTROL to STATUS, you may have better luck. In the end, I think the wait period is happening, but the programs were never disabled, so waiting a period of time to enable a program that is already enabled will appear to have no effect. It is easy enough to check. In the program status, do you see any of these programs being disabled?