oberkc

For one, simple, reason....if it is part of the program in the folder, there is risk (perhaps small) that the program is in a wait state when the folder condition turns false at sunrise. If so, the program execution ceases and the light will never go off. That is my understanding and experience.

My recollection is that certain "older" models required a power cycle (not full factory reset) in order for certain changes to take effect. Perhaps this is what you are experiencing? Then again, perhaps this only applied to changing of settings from a program (my recollection on this is a bit fuzzy). Still, it is easy enough to quickly check.

There are a couple of things to note about your desired program. 1) I understand insteon sensors will send an on signal each time they sense motion, but that there is a reset time period, within which they will not. 2) If a program conditions are evaluated while the program is running (in a wait, for example), then the program will cease running and start again, based upon the evaluated condition (true or false). Regarding note 2 for example, a program can watch for motion and, if detected, turns a light on, waits five minutes, and turns a light off. If, during that five minute wait, further motion is detected, the five minute wait will be terminated and the program will start again from the beginning. This is also true for time constraints (dusk-to-dawn, for example). If you set up a program to run only from dusk-to-dawn, and the program is executing at dawn, execution will stop. It is for reasons such as this that it is sometimes useful to break out single programs into multiple programs. Ergodic's response is one of several ways to solve your problem. You would, of course, have to incorporate your time constraints. Another option (the one that I use) would be: Create a program folder with conditions: if from sunset to sunrise then run the programs in this folder in the folder create a program: if control "motion1" is set on or control "motion2" is set on then run timer program (then path) else outside the folder, create a "timer" pogram if then turn light on wait five minutes turn light off else The program folder will restrict the fist program from running after sunrise and before sunset. The second program will call the timer program (restarting the timer program if already executing) each and every time either of the two motion sensors sends a signal in response to motion. The timer program will incorporate the wait state and continue to run, even if sunrise occurs during the five-minute wait period.

Yes, it could be a bad KPL. If you are interested in further checks, open the event viewer and press a button on the "bad" KPL. See if the event viewer registers receipt of the signal. It is also possible that the "bad" KPL is in a location that the ISY/PLM has difficult hearing, for whatever reason. You can try plugging the KPL into different outlets (extension cord may be necessary) and see if you get the same results.

I took his description of "pot lights" as the same as a recessed, or can, light. Perhaps I was wrong.

I thought halogens would be considered part of the incandescent family for this purpose. They are a pure resistance load, I believe. I use them in various lights fixtures, including recessed, without problem. In certain circumstances, I like the light color better. Unfortunately, I have no answer for why they would flicker. Do they both flicker simultaneously (would tend to indicate switch or connection problem) or independent of each other? Does it happen only to one (would tend to point to lamp as culprit)?

I only login once, but I use the address: xxx.xx.xx.xxx/admin If one just uses the IP address, you are correct....one must log on twice

I have found no significance in the fact that the first statement contains no "and" or "or". I would treat this as normal and not worry about it.

kaplansa, I have a couple of questions.... do you have your sensor wired in such a way that "off" means "open"? is your relay configured such that sending it an "on" command will close it? while I agree conceptually with ergodic about the possibility of programs causing conditions to change, I don't see it in your example. I also agree with him on the value (or lack thereof) of the trailing wait statements. You stated that you put them there in order that the programs not be immediately re-evaluated, but I see nothing in your program or input conditions that would force an immediate re-evaluation. (I anticipate a re-evaluation only when your sensor changes state.) I may have missed it, but what is this first program doing or not doing that you believe it should be doing or not doing? You also mentioned programs that "talk together". Is it possible that one of the other programs is talking to this one, changing the input conditions, and causing the phenominon mentioned by errodic? One thing to consider is swapping "status" with "control", depending on what problems you are experiencing. As far as second program, you may also try "control" rather than "status".

the program folder would contain your first condition and look something like: if from sunset to sunrise and program driveway is true then run the programs in this folder in this folder, add your program if program front door is true then run program "timer" (then condition) else outside the program folder, create a program named "timer" (or whatever you like) that looks something like:

the program folder would contain your first condition and look something like: if from sunset to sunrise and program driveway is true then run the programs in this folder in this folder, add your program if program front door is true then run program "timer" (then condition) else outside the program folder, create a program named "timer" (or whatever you like) that looks something like:

My first instinct is to create a program "folder", with the conditions that program 1 be true. In that folder, put a program with only the condition that program 2 be true. The folder condition must first be true in order for the program to be enabled.

The only problem that I see is that the motion sensors will trigger their individual lights on at schedules different than the ISY program. Even if you set your motion sensor only to work at night, the motion sensors will each likely have a slightly different sense of "night", which is also slightly different that the ISY "dusk til dawn". This may be the best you can get, however, given your hardware selection.

You can try another brand of CFL. I suspect that the CFL issue is just one of several problems you have. Try a scene test on some of your scenes and see if they pass (I bet some will fail). I suspect you have other devices throughout the house that are contributing to this problem. I would start by putting all your computer stuff (except ISY) on a filter. I would put your home theater on one, as well, including the monster power supply.

I believe the key word was "unswitched" power. I think he suspected that somehow the power to the new device was being interrupted when the other switches were engaged. I find your CFL exterior lights to be the most intresting part so far. As mentioned by others, some of these can cause (or contribute to) communication problems. Since it is so easy to confirm, temporarily replace them with incandescent bulbs and see if your problem goes away. I also agree with BLH on pointing out the TVs, cable boxes, and even your monster power supply could contribute to communication problems. First, however, check on the exterior CFL bulbs. The problem seems to be only associated with these being on.

fitzpatri8, I think he noticed LeeGs advice and even commented that it was a "great idea". I think he was just responding to some alternative suggestions and questions from me.

This is not consistent with my understanding. I thought programs ceased "then" and "else" statements at the point where conditions are evaluated, at which point the program starts over, based upon the condition as evaluated. SLee is pretty good with this stuff. Perhaps I was wrong and it only happens in conjunction with 'wait' statements, as he says. I have read about much confusion about this topic. . In general, any change in status or reciept of contol related to the program conditions. If a change is to a device not part of the conditions, the program will not be affected. That DOES sound like a potential solution to your problem! I second your sentiments....great idea. Another thought that I had....does the ISY give you any options for this inlinelinc setup? If you select the device from the tree, are there anything like device options along the bottom that one could set up to ignore off commands? I know that my triggerlinc has such options.

I am unsure of how you can control the amount of time the lights stay on, other than through the motion sensor settings (1min, 5min, 10min). I think the problem with one light going off after a minute is due to the fact that this is how you have them set. If 5 or 10 minutes is what you want, I suggest: -set the motion sensors to 5 or 10 minutes as you desire. -remove all four devices from your scene -add all four devices back, only as controllers (rather than just responders) -eliminate the program altogether. Setting it up this way will use scenes to turn all on if one or more is triggered. It will also turn them all off when one or more times out. It will also happen nearly instantaneously (no delay between first light and other three). I am having difficulty envisioning how you can use the ISY to turn these off, since the motion sensor does not appear to have the ability to disable the off signal. I think this could require additional hardware.

My understanding is that programs that are disabled will not run, except when called by another program. If I understand your setup correctly, yours will not run on their own. Another thing that strikes me as a little unusual are your two folder conditions for home and away. One is true when off. The other is true when 10%. This leaves a broad range of potential conditions (on, greater than 10%, 1-9%) where neither is true. Is this as you want?

I am also wondering if you have created some type of loop as a result of your "else" condition peforming action that affects your "if" conditions. The following example program is a lot like yours. if status of light is on then turn light on else turn light off When the light status is changed to on, it will run the else condition, which turns the light on, which forces another evaluation, which turns the light on, which forces another evalation, which..... Unfortunately, I am not directly familiar with the motion sensor light device. Are your "light X" devices refering to the motion sensor, the in-line-linc, or the fixture, itself? Did you add the 2494MS device to the ISY? Could you use your motion sensors as your program trigger, rather than the light?

I am wondering if in-line links are among those devices that cannot be used as controllers in a scene. (I understand that these may not send a status message.) If so, I wonder if that limitation also applies to using them in program conditions.

I am unsure what this is.

I originally responded by stating my understanding that KPL buttons could not be reponders to other insteon devices. I forget from where I recall that, but I know that in some cases I have had to create a special scene, just to control the KPL button. After thinking further, however, I know that this is not always the case. I DO have KPL buttons as responders in a scene, and this works well. Perhaps this was an issue only with older versions of the KPL? I don't recall. Perhaps I am thinking where one may not control a KPL button from another KPL button. Having said that, I am now wondering again why your initial scenes don't work. While your programs may be currently working, I would prefer using scenes, if possible. If you are interested in a couple of theories: a. is it possible that some of your scenes had the KPL on level set to zero when activated by the RL button? b. is it possible that creating the mutually exclusive relationship between KPL buttons may cause a conflict with the scene controllers? For example what happens if KPL C and A are both on? Is it possible the scenes requiring both KPL buttons to be on cause a conflict with the mutually exclusive relationship? My money is on theory A.

Unfortunately, my understanding is that one cannot control KPL buttons (other than the primary) via other insteon device, by putting it into a scene with the other insteon device as controller. The solution is as you have done: create a single-device scene (including only the KPL button) and controlling it via program. Hopefully, enabling the program will solve any remaining problems you have.

That is my understanding, as well. Regarding the query, I understand that a this would work, if being a bit inelegant.