oberkc

OK. This introduces some issues many have referred to as "boundary conditions". That is, how do you handle the condition where dawn occurs during your "on" time period. Maybe. If your needs are simple, scenes could be best. They are quick and, as I understand, more robust. Responses to scenes tend to happen a bit quicker than programs. There is a measurable time that programs take to respond. My estimate is that this is somewhere in the 1-second range, depending on complexity. I have three motion sensor programs and two seasonal (holiday lights) programs that I want to operate between dusk and dawn. I find it convenient ("best") to use a single program folder to constrain each program, rather than putting the condition INTO each program. I assume from your response that this motion sensor is the only program you have that you want to run from dusk to dawn. Given this, it may be "best" to put this constrain directly in the program. I don't use insteon sensors (mine are X-10) but I understand that insteon sensors have jumpers that allow one to set certain conditions, such as: - operate all day or only during "dark" - whether the motion sensor transmits an off signal - duration of duration of time between sensing of motion There may be others. Bottom line is that how well a program works and what is "best" is contingent on how you want to configure these jumpers. If you have only a single light, then you may be fine turning that light on directly from the program. If you have mlultiple lights, it may be "best" to create a scene with the multiple lights as responders and turn the scene on through the program. My perception from reading these forums is that programming "skills" are one thing. These can be learned if desired. The harder part is specifically defining what it is that you want to do and expressing this desire in sufficient detail such that those with the programming skill can offer meaningful suggestions. Sub-routine's suggestion on the other thread will work beautifully. Unfortunately, it will not do what you want because you want it only to work from dusk to dawn and he did not appear to know this. Try two programs: if from sunset to sunrise (next day) and ( control motionsensor1 is turned on or control motionsensor2 is turned on ) then run "timer" program (then path) else timer program: if then turn light on wait x minutes turn light off else Good luck and have fun!

There are several ways to do this, all perfectly functional. I have found that "best" is often based on other factors, often unrelated to the specific task-at-hand. 1. Do you have time constraints? Dusk to dawn? Seasonal? 2. Do you prefer controlling the timing via the ISY or the motion sensor, itself? Is your motion sensor difficult to reach? 3. Does the slight delay of programs versus scenes bother you? 4. Do you have other programs with similar time constraints that can consolidate into folders? 5. What type of motion sensors are you using? Insteon? X-10? Other? How are your sensors configured? 6. What do you want the response to motion to be? Multiple lights? One light? I think it will be up to you to decide what is "best", based on your own needs and desires. Several have offered suggestions on the other post, based on the posted desires. If your desire is to use the ISY to control the on time of your lights, and you have no other specific issues pointing towards a certain approach, you might try something as simple as: if control "motionsensor1" is switched on or control "motionsensor2" is switched on then turn light on wait x minutes turn light off else

It looks like you found the other recent thread on this topic: http://forum.universal-devices.com/viewtopic.php?t=5286 After having found it, do you have additional questions?

My perception is that this is unrelated to the program. This sounds more like set-up or communication problems. 1. how many access points (or dual-band devices) do you have? Are you certain that you have one on each "leg" of your electrical system? 2. how did you add the kitchen sink device? Manually (typing an address) or automatically (start linking)? 3. can you control the kitchen sink through the ISY admin panel (select device, select "on")? 4. what kind of light (incandescent, LED, flourescent, 12V halogen, etc) are controlling with the kitchen sink switch?

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.