oberkc

one - I (and many here) have done this. I don't believe harmony has built-in insteon RF signals (unless recently added) so this leave a couple of options....X-10 signals to the ISY, use one of the insteon IR receivers and learn one of the harmony codes, or make sure you get the ISY-99IR. This works well. This will be no problem.

it seems to me that this would work. There are so many examples of how to do motion sensors. I think there is a pretty good explanation also in the wiki. Perhaps you want to consider coming up with a way to avoid having to make the assumptions above. What if you don't always want the light off during the day? What if you don't necessarily want it to turn off at sunset? What if you want to maintain manual control of a light, but motion sensor control when manual activation hasn't occurred? (These are all rhetorical questions unless you want to try to tackle this.) There are so many variations and it can all be done if you want to take the time to program it.

I am concerned that your approach will suffer the same problem with the so-called "boundary conditions". If your sunset/sunrise program disables your motion program (for example, when it turns to dawn) while the lights are on (in the five-minute period), then the lights will not turn off. First, you cannot use the quick reply. In the full reply, select the text that you want listed as code, then select the "code" button in the reply window.

I suggest posting a copy of your program(s). Perhaps someone can spot why this is so.

I suggest that this is a case of understanding what one wants to do. It appears to me that Sub-routine's program would turn the lights off 5 minutes after the motion sensor sends and off command (and the other motion sensor is off). That constitues 5 minutes, plus whatever time is set on each of the motion sensors before an off command is sent. These are variations on the same theme. Both approaches will work. Both probably have merit. The important thing (in my mind) is to understand what it is you are trying to do. Unfortunately, this was in response to a request to make it "work right". We don't know if five minutes is the correct time, or five minutes plus motion sensor time, five minutes after motion sensor sends an off command, or whatever. Both will work. There are subtle differences in performance. Both require a specific configuration set up in your motion sensor.

I appreciate your desire to learn the system. I beleive this approach helps make all of us a better user. The reason I asked this question is that I recall cases where manual input of addresses caused problems in certain cases...perhaps the ISY could not ID the device (what does the ISY show as device type?)....something like that. My suggestion is to add them automatically. First remove one of your devices. Next, choose start linking (remove existing links). Next put device in linking mode. At this point, you should see the device back in your admin panel. Exit linking mode from the ISY. My suspicion is that if you were to now add this device into your program, it will work as expected. This is only a moderately educated guess, however. It is also pretty easy to check. Hopefully, this will solve your problem.

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, for example, 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!

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.