oberkc

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.

Like techman, my first reaction to most intermittent problems, including this one, tends to be to look at comm problems. Regarding you specifion question re status vs control, there are a couple of factors come into play here that could favor one approach versus the other. The basic difference is that CONTROL is ON will trigger on receipt of every ON command, regardless of current state of the device. STATUS will not. So...if your motion sensor is currently ON (and past The timeout period) and senses motion again, it will send another ON command. If using CONTROL as a condition, the program would trigger upon receipt of the ON command. If using STATUS as a condition, it will not trigger, since there was no CHANGE in status, since the sensor was alreay ON. Personally, I use an ISY program (not scenes) to control response to motion sensors. I like to reset my countdown timer at each ON command. This tends to suggest CONTROL as preferable to STATUS as a program condition.

My experienc is that slower write times are indicative of marginal communications

I believe the ISY will add the preceding $ to the variable name. I would put initial value as 0. This is the value that will be assigned if the ISY reboots for whatever reason (such as power interruption). I assume you are home more than away, so this seems like the natural starting point. There is a way to go through a power interruption and keep your variable, but I suggest getting this working first without worrying about such things, then we can talk about thenext steps. First program should be outside the folder.

I am away right now, so I cannot confirm on my admin panel. Have you created the variable yet. Is it a state variable? If your intention is to continue using the folder to enable or disable your two programs, I believe all you would do would be create a condition, based on the variable being = 1. The exact syntax will take care of itself, from the selection boxes available. Then you would simply create a whole new program: If Status hall keypad is not off <<<<must use STATUS here Then Wait hh.mm.ss <<<<pick your time Set variable =1 <<<enables folder Else Set variable =0 <<<or anything other than 1 If you are taking the folder approach, there is no need to include the variable in your two programs within the folder.