oberkc

To clarify...are you using the ISY-99, or the -994? I believe many of the newer insteon devices may not be compatble with the -99 since it was replaced by the -994 and is no longer supported.

If your folder is turning enabled and disabled, based upon the variable and condition, I have no explanations. I use folders with conditions, and they work flawlessly. - you have confirmed no external programs triggering those in the folders, ok. - are the motion sensors controllers in a scene that includes the devices commanded by the program? Last thing that I can think of is speculation. I know, for example, that a statement such as: if control "device" is NOT swithed ON <<<triggered only by ON command. Is it possible that your folder condition if variable NOT = 1 <<<could this be triggered only by a variable=1 condition, and not triggered when the variable equals a value other than 1? (I don't know for sure, but it may be worth considering.)

Is it possible that the programs are being called by another program outside the folder?

If you had a three-way switch connected to black/white/red, you should be MORE than 99% confident that white is NOT a neutral.

Extension cord and a couple of wire nuts?

I have no idea about "most" or average. Personally, I have well fewer than 100 programs, but I have no doubt those crazy guys can have orders of magnitudes greater than that. Useing the program folders and comments, it is pretty easy to manage, in my estimation. Which is another reason I prefered my original suggestion (remove the status condition) and do it in a single program. I suspect you will also find means opportunity to combine programs. For example I might have several programs to turn lights on any given day, but only one to turn all off. For the most part, I have not found this sort of thing to be a constraint.

Probably use an approach similar to haroldunger, but you would have to use two programs. The big difference is that the time condition is a single, discrete, time rather than a range. If time is sunset + 30 and status garage exterior is OFF then turn lights on else nothing if time is 1130pm then turn lights off else nothing One of the big things to be aware of is when a program action can cause the program to retrigger (as your original program did) and get in a never-ending loop. A simple and obvious example would be: if status LIGHT is OFF then turn LIGHT ON else turn LIGHT OFF While easy to see in this case, it is often hard to see when this is happening in more complicated programs. I believe it was happening in your case (but only between the time range specified).

This program is a little different than the original-posted program. Yours has a "if time is..." Ajax' program has a "if time is from/to". Your program works fine because there is only a specific moment in time that it can be true. Ajax program can be true over a period of several hours. Obviously, Ajax' program also has a non-empty ELSE path. There are several ways to approach Ajax program. One could use two programs. One could use a single program as he is trying. If the condition "status exterior light is off" turns out to be important, then it might be necessary to break his into two programs. But, the original intention seemed to be check whether the scene was on, instead using a device within the scene as an indicator. In my estimation, if a scene is ON, there is no harm in turning it on again.

It is because scenes have no status in insteon. Only devices have a status. Your program is, in effect, creating an endless loop. The program triggers, it changes the state of the device (as part of the scene), which triggers the program, which changes the state of the device, which triggers the program, which...well...you get the point. Remove the STATUS condition from the program. It really serves no purpose, anyhow.

Is 'Garage Exterior' part of scene ''Exterior Lights"?

I, too, trigger programs based upon status of secondary keypad buttons. Not being satisfied with my experiment results and looking further, I find that some of my keypad buttons report status, and others (at least the one on which I was doing experiments and likely the oldest keypad I own) does not. Possibly a comm issue with that particular keypad? Or do old ones behave different than newer ones? Oh well. It is getting late and I am losing interest. Back on topic, I think stusviews answered the un-voiced question.

Sorry, got pulled away on something else. It appears to me that this program is using a secondary button as a trigger, but commanding the primary button. I understood that one could not issue direct commands to secondary buttons, but thought you could use them as program conditions. Being uncertain, I tried a quick experiment and found that I was remembering wrong. Secondary buttons apparently do not even report status, nor can they be used to trigger programs. Wow. How long have I been doing this?

True for secondary buttons, not so sure for primary. Also, Secondary buttons, I thought, could be used as program conditions, however. No? If keypad light is the primary button (and i expect that it is here) then

OK. Is there a question here?

As far as "why" it could happen, this is considered a feature of insteon. For a given scene, you can have multiple controllers, and for each controller different responder levels. This gives one the ability, for example, to have a group of lights have have movie setting versus intermission, based upon which keypad button you press. As with many things, with features come added complexity. Treat the "scene" responder levels as those when reacting to the PLM as a scene controller. Please note, also, that when you selected the controller switch within the scene, there was revealed an option so set the responder levels as the same as the scene. This strikes me as a convenient feature of the ISY that keeps things nice and consistent for those like yourself that want a scene to respond the same way regardless if which controller triggered the scene.

Very strange. Same thing happens when you choose, from the device list, the fanlinc and mnually select the speed? Perhaps, as yoy probably suspect, there is some device failure or incompatibility here. These things have worked for me without any of these kinds of issues.

OK. Have you tried stusviews suggestion? What is not always clear is that, within a given scene, responder levels can be different for each controller. For example, in the "HIGH" scene, you may have the fanlinc response level set to high at the SCENE level, but with response level set to OFF when responding to button A.

Yes, sunny Springfield. Lots of nice places in VA. Hope you like it. If your intention is to use button B to toggle the fan motor, then why are you setting buttons A-D "to a setting"? Have you given up on the one-button approach? What about button A? I thought you said that this was for the fan light? Is this no longer true? Is button A still a controller for the fan light? Perhaps I am being counter-productive and simply need to back out of this as gracefully as possible.

Perhaps I am confused as to what David_Gilbert is trying to accomplish? Four buttons (High/Med/Low/Off)? One button toggling through the speeds? Both?

Perhaps, but the keypad buttons are a part of none of those scenes. (Unless you are talking about a second keypad.)

This is, in my estimation, likely caused by have the responder levels set incorrectly. What is typically missed here is that the levels must be set in multiple places, for the scene (itself) and for any controller devices within the scene. If you want a responder device to go to zero in response to a controller device, make sure you check the responder levels when the controller device is highlighted by mouse-click.

I think you are trying too many things at once. My understanding about the program originally suggested by stusviews was that its purpose was to control fan speeds from a single button. Is that your intention, or are you trying to control speeds via dedicating four buttons. Secondarily, if you are using scenes to control fan speeds, no program is needed. I suspect your scenes are fighting your programs. When you move the slider to "HIGH", the motor turns off?! That strikes me as very strange. I can think of no reason for this other than device failure. Are you sure there are no other programs triggered by "STATUS" of fanlinc?

David, I dont see anything in the program that would explain this behavior. Assuming you have double checke to confirm your pogram conditions are consistent with th recommendations, also be sure that you don have any scene relationships between the button and fanlinc (did you eliminate your original scenes?).

The WAIT at the end of the THEN or ELSE clauses will accomplish nothing, I suspect. I dont believe it will delay the running of the other clauses. I understand WAIT statements can be interrupted by a program trigger and will not cause any further delay, once a program is triggered during a wait period.

This ISY is the only real controller I have used. (While I once used some crude insteon software with a USB-based PLM, it was only timers that it provided.) My impressions of the Vera has always been that it tends to be more biased towards z-wave and less towards insteon. Still, I find the ISY pretty good for z-wave and unmatched for insteon. I understand that the z-wave support in the ISY is still growing and will only get better.