oberkc

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.

I don't recall that there is the option for a program to disable a folder, but there IS an option to disable programs. The way I see it, you have, thus, two choices. Create a variable (I will call it "$away"). Then create a program: If Status 'Hall Keypad-Hallway / Hall Keypad-Away' is not off Then wait 10 minutes "$away" = 1 else $away = 0 Modify your folder condition If Status '$away' = 1 Then run programs in this folder The second option would eliminate the variable and folder. So, get rid of the folder and keep the existing two programs out in the open. Then, create this program: If Status 'Hall Keypad-Hallway / Hall Keypad-Away' is not off Then wait 10 minutes disable motion alert program disable other program else enable motion alert program enable other program Pick one of these options that looks good to you.

For what it is worth, my latest router is from netgear. It comes with a complimentary static ip service mynetgear.com. So far, so good.

I took referenced "switch" to be in regards to the device that goes in the bathroom and actually powers the load. Which makes me think...if the actual wiring is as I suspect, with three conductors between the bath and kitchen location, there would be no reason not to put a relay keypad in the kitchen location and use that device to power the load. Then one could put the dimmer switchlinc in the bath and link it to the keypad via scene. The downside may be that the primary button in the kitchen would need be used for the fan.

Others have mentioned the four-button configuration, but relating this to high WAF may have been the slap to my head that this may be a solution to a WAF problem I have been having. Thanks.

Taking advantage of scenes, spare buttons, and an xacto knife, a seven-button keypad is quite possible.

Yes, you could put KPLs in both locations if your wiring is per the illustration. The lack of black tape is NOT conclusive evidence that hits is neutral. Most likely, they simply failed to add the tape. White, in this case, is NOT neutral. Basically, you would connect white from the power source to all whites. Connect black from the power source to the black going to the second switch. Red wire abandoned. At both boxes connect switch white to other white wires. Connect left switch red to black wire connected to load. Connect switch blacks to supply black.

My admin panel gives me the option to choose the following as a program control condition: on, off, fast on, fast off, fade up, fade down, fade stop, bright, dim. Does yours not show these options, or am I missing something?