oberkc

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?

Yes. Every time motion is sensed, it will initiate something. In your case, however, the morning program first turns on one light at 40%, then turns a scene ON. So, margies closet light will go to 40% each time motion is sensed. Unfortunately, I don't recall whether that closet light is part of the bigger scene, so I don't know if that is a noticable change in ON level for margies closet light.

Yes, indeed. Disable simply deactivates the self trigger. If another program calls the IF condition, the condition will be evaluated and send it down the next path, based on whether true or false. Other than the lack of a self trigger, a disabled program will behave normally.

Sorry. Just responding to one of your comments. I will cease trying to help further.

Our responses crossed in the mail. I agree, the IF condition in the "anytime" program is a potential problem, especially if the program is not disabled.

Yes. When a program is "disabled", it does not mean that it will not run when called from another program...only that it will not self-initiate from its own conditions. I did (and do not) want that program to be triggered by it's own conditions. In your set of programs, the ONLY thing that you want to initiate some sort of action is the motion sensors. Everything else should be initiated exclusively from other programs. So...given your programs, I would disable ALL but the first. Furthermore, I don't think you need a condition in "closet anytime on". What I suspect is happening in yours is that some of the ELSE paths are triggering the parent program, halting any WAIT state.

??? Just because a secondary service circuit is protected by a 40amp breaker does not mean every device installed within must be capable of withstanding 40amps. What is the service breaker for your house...200amps? 400amps? Are all your electrical devices designed to handle this much current? Very few outlets and switches can handle 40 amps. I suspect most of the individual devices connected to your 40amp leg cannot individually handle 40amps. Is that 40amp service further broken into smaller circuits, protected by smaller breakers? Am I missing something.

I am not sure that I follow the trail here, but scene commands don't propogate beyond the original. If button x is controller for button y, which is controller for button z, pressing button x does not cause scene y or z to initiate. If 'keypad main' is controlling a load that you want to come on, then is MUST be in the scene definition, as responder. Being triggered by buttons A or B will not cause the main scene to come on. That is not the way insteon works. BTW, this is the same reason why directly controlling button A or B from mobilinc will not cause their respective scenes to come on. I remain suspicious of a rogue program somewhere. As suggested earlier, I would watch the program listing and see if any program responds to presses of buttons A or B. If so, review that program content to see if that explains the strange behavior.

Further thoughts... controlling all this from a single scene is an efficient approach, in my mind. You mentioned trying to control these scenes via mobilinc, however. If you want to be able to choose any of the responder level options from mobilinc, you may need to keep this in multiple scenes. The only way to control a scene via mobilinc is through the scene level. Controlling a scene controller via mobilinc will not initiate the scene.

Non toggle DOES work with scenes. I use it in a couple of mine. Unfortunately, you can only define a button in non-toggle mode as always turn on, or always turn off. But...the scene WILL respond. Regarding your new problem, the only thing I can think to do would be check your program log to see if there is some other program that is responding for some reason. The scene definition would not do this.

To follow up with Jimbos comments.... You mentioned you have your buttons in NON-TOGGLE mode. Are they in non-toggle ON, or OFF? In the end, what I assume you want is as Jimbo suggests. Both buttons in both scenes. Button A will be responder only to button B, and button B responder only to button A. On levels will be zero. Button A and B should be set to Non-toggle ON mode. Pressing button A would turn on scene A and turn off button B. Pressing button B will turn ON scene B and turn OFF button B. You will need a third scene to turn OFF everything. Depending on whether you want this button lit or not, it would be set to non-toggle ON, or OFF. You may need to include this button as responder in the scenes A and B. You will also need to include buttons A and B as responder in scene C.

let me know how it works.

The fact that both buttons, when turning them off, also turn off the scene makes me conclude that they are, in fact, part of the scene. Given this, if turning the buttons ON do not cause the scene to react, and levels are confirmed good, I would start looking at things such as scene settings did not get written to device. Have you tried restoring any of the devices in the scene? Comm errors? Any reason to suspect? Scene commands are not repeated nor acknowledged, so I assume they can be a little less robust than direct commands. Jimbos thoughts were ones I had earlier. This would be a way to set up such that pressing button A would cause button B to extinguish. Depending on the level of control and options you desire from Mobilinc, you could actually do all this via a single scene.

That is fine. Just add that condition (AND) into the program I called "next program". Those suggestions were just concepts...tweak as you wish. The bigger point of this logic approach was to propose a method to avoid having two programs triggered simultaneously, sending conflicting commands to a device.

A couple of thoughts.... Most controllers will only act as controller when acted upon directly (pressing the button or paddle). Controlled from mobilinc, a device will not act as scene controller. Second, in the scene definition, choose one of the misbehaving controller and check the responder levels for this controller. They can be different cor each controller.

You will have to dig into this a bit. Responder ON levels, with insteon, can be set based on who is the controller. For example, the ON level for your cans can be set to 50% when controlled by the ISY and still be 100% when controlled by your paddle. If you had a third controller, they could be an entirely different level still. When you create the program action, choose "adjust scene", then choose your scene controller device. In this case you want to choose the paddle, rather than the scene itself. Then, responder device would be the office cans, as you already have them. Your action should look something like: in scene keypad paddles set office cans to 50%

Given your programmatic approach, I see a couple of basic concepts: - you are relying on ON commands from the sensor to turn lights ON, and OFF commands from the sensor to turn lights OFF. This is fine, but I choose to use a program WAIT command to turn off the lights, rather than a command from the sensor. My approach tends to favor a CONTROL condition. With your approach, I might choose STATUS, instead. In a practical sense, it may not make a functional difference, but it should avoid some unnecessary insteon traffic over the powerlines. - Your second program is curious to me...What happens if the sensor OFF command comes after dawn? Does the light stay on indefinitely? - are you concerned with denying yourself the ability to manually turn off the light if it were triggered on by the motion sensor. Given the approach you take, I assume you would have to first turn on one of your KPL buttons, then turn it off.

The first program construct strikes me as a little strange. Let's assume that this program is triggered by one of your conditions and is evaluated as TRUE. This triggers execution of the "disable" program. The disable program initially disables the first program, then turns on a light which would, if the first program is not disabled, retrigger the first program. Has this actually been an effective strategy for you? (I would not be certain how quickly these commands become effective and whether the program would be disabled quick enough.) I would have taken a slightly different approach... Morning Closet Entry If On Mon, Tue, Wed, Thu, Fri From 5:30:00AM To 6:30:00AM (same day) And ( Control 'Master Closet MS - Sensor' is switched On <<<<Note removal of closet light condition ) Then Run Program 'Closet MS Disable' (IF Path) <<<note change of path Else - No Actions - (To add one, press 'Action') Closet MS Disable <<<<DISABLE THIS PROGRAM PERMANENTLY If - Status 'Margies Closet Light' is Off Then Set 'Margies Closet Light' 40% Wait 5 seconds Set Scene 'Master Closet Light' On Else - No Actions - (To add one, press 'Action') Of course, none of this addresses the fact that you have two programs, triggered by the motion sensor, telling the closet light to do two things at once. To address this concern, what about something like if control motion sensor is switched on then run next program (if path) else nothing next program if time is from 0530 to 0630 then Run Program 'Closet MS Disable' (IF Path) else run closet on anytime (then path) Modify closet on anytime to remove IF condition and disable. No changes to disable program are necessary.