oberkc

First, I would create a scene with the lights you want to come on all included, all as responders, with the ON levels for each at 50%. First, I would create a scene with the lights you want to come on all included, all as responders, with the ON levels for each at 50%. Then I would create a program: if time is from 530am to sunrise (same day) and control motion sensor is set on then set scene on else set scene off So you want these lights to turn on at dusk-30, stay on, and turn off at dawn? Is "on" the same as above (50%)? If it is on until dawn, why do you need the first program?

Wow. The original program has a pretty blatant omission compared to the "actual" program. The question that is now coming to mind is what causes the program "morning walk" to become true or false? What is the purpose for this condition? My suggestion is to delete that condition and see if your original problem (lights continuing to stay on) goes away. If so, then we can try to address the other concerns you raise.

I see nothing in the program that would cause this. Often, when people use STATUS as a condition, wait periods can get interrupted. You, however, are using CONTROL. This will trigger only upon receipt of an ON command, and only execute the THEN path. Given this belief, i would try to look for clues to isolate the problem. - is you ISY seeing the ON commands? Check the program logs to see if the program is being triggered by motion, or watch the event viewer when motion is detected. If you have the motion sensor as scene controller with the lgihts as responder, it would be easy to falsely assume that the program is being triggered because the lights are turning on. - program runs, but the lights dont turn off. Try things such as manually running the THEN path of program. Do lights come on then go off? Does changing wait period affect this behavior? Try turning off the lights manually from the ISY.do they consistently respond?

No, i dont believe this isnormal. My mobilinc shows current status, I believe. Still, there are a couple of things that I have learned to watch.... A. It is pretty easy for mobiline to loose sync with the controller. If you make changes in device or scen settings, I find it necessary to re-sync mobilinc. If not, mobilinc will neither show correct status nor control devices B. It is necesssary to pay close attention to the difference between scenes and devices. I suspect your problem is more likely related to the first possibility.

My understanding is the same as LeeG. A better solution, in my mind, is to use a micromodule to power the load in the fixture box. Doing this would allow two wires to switch boxes to be converted to line and neutral. No return is required.

There is one general problem situation with switches: switch loops, where the supply cable enters at the fixture box and they send only a hot-and-return to the switch box. In this case, there is no neutral and one has to get a little more creative with the wiring and devices. If you can determine where the supply cable enters the circuit, and if it is in one of the switch boxes, your are golden.

Michel, This is a duplicate post. The original poster has not been back.

The basic idea is that each insteon device requires a neutral and a hot. Only one of the insteon devices connects to the actual load. Identifying and configuring the wiring is the trick. One cannot assume white is neutral, or black is hot. A voltmeter is, as far as I am concerned, a mandatory tool for people interested in engaging in these types of activities. Google is your friend for learning of the various wiring configurations for multi-way switches, matching to yours.

This, in my mind, is the most common use of motion sensors. Yes, there are good programs available, but will require adaptation for your own types and numbers of devices. Are you familiar with the udi wiki? There is a good discussion about motion sensors used in a bathroom. The basic concepts are the same and pretty well explained there: http://wiki.universal-devices.com/index ... _Bathrooms The way I do this is to use several programs. The first one is simply to keep track of manual control of lights. If Control light switch is turned on And control light switch is not turned off The Set variable (integer type) = 1 Else Set variable = 0 I then use these variables to decide whether i want to enable the motion program If variable = 0 (lights have not been manually turned on) And ( control MS1 is set on Or control MS2 is set on Or control..... (Add as many motion sensors as you wish) ) Then Set lights on Wait x minutes Set lights off Another key is supplementing this with the right scenes. First, the motion sensor should NOT be controller of any scene. The light switch controlling your outside lights SHOULD be in a scene with the lights if there are multilple devices powering your outside lights. For the variable, make sure you define it as an integer. Understand that there are settings on the motion sensor that can affect performance of this setup. Hopefully, you recognize that my syntax is only vaguely accurate, and can see the ideas behind it and adapt for your actual devices.

if control motion sensor is on << then turn on light wait x minutes turn off light else nothing

Perhaps I am loosing track of what you are trying to accomplish, but I am not sure why you have all those STATUS conditions in there. Specifically: And Status 'Garage Interior / Interior - Garage Lights' is Off I suspect it is this condition that is keeping your motion sensor from retriggering the countdown.

The only reason, besides device malfunction, that I understand would case a switch to come on at certain levels are the local settings for that switch. If you are confident you have the programmed appropriate, I would consider cycling the power to the switches. I recall that, for some settings, older versions of switches require a power cycle for the settings to take hold. Alternatively, check that you don't have any funny green or red symbols next to any of these devices indicating a need to write to these devices.

My assumption is that your program is triggering at sunset. The question, then, is how to set up the program with the same conditions, but does not trigger at the from/to times. This is what I came up with: From Sunset To Sunrise (next day) Then run the programs in this folder In the folder, add a program: If $My_iPhone_home is 1 Then Send Notification to 'Text Message' content 'My Home' Set Scene 'Scenes / Outside Rear Pole Lamp' On Wait 3 minute Set Scene 'Scenes / Outside Rear Pole Lamp' Off TJF1960 version would work as well, I expect. Beware....I expect your program has another hole. What happens if you leave home (or sunrise occurs) during the 3 minute wait? (hint: the light may not turn off.)

I vaguely recall once switching line and load. My recollection is that the switch can appear (leds on) but act very strangely. If you think this is a pssibility, best to confirm independently with a volt meter.

Another option to consider is to look at your program log and see if any fired at the time of the latest log event. If you can identify a program that is causing this, then you should be able to make adjustments to make it behave more as you intend.

Basically, yes. STATUS conditions trigger at any change of state. CONTROL conditions trigger upon receipt of the specified control, but not other controls for the same device. FROM/TO conditions trigger only at the specified times...not anytime between.

based on the reply from apostolakisl, I would also consider the possibility that your first program may suffer similar problems as the second, if one of your elk conditions becomes unviolated. Subsequent sensing of motion would restart the timer, but if the timer is running and an elk condition retriggers the program as FALSE, then your timer will stop and the lights will remain on until another trigger (and TRUE) occurs.

regarding your second program never turning off the lights, I can only assume that some event happens that interrupts the wait statements and forces the program ELSE path to run. Unfortunately, I am unfamiliar with how Elk rules work in this regard to offer any specific advice.

No variable is required. Your program should work as is, unless your motion sensor time-out is set higher than ten minutes. Of course, motion sensors are not 100% reliable and issues such as that can come into play, but I would first check to make sure the time-out period is not set too long. Remember, from the ISY, these settings can be adjusted, but the motion sensor must be put into linking mode for the ISY to write the changes. I believe, too, that jumper 5 must be properly set for the ISY or any other controller to make changes.

Is your variable a state or integer?

I have found some value in have an "all devices" scene. I use this for a couple of reasons, including an ALL-OFF program. Yes. There are a handful of key concepts that are good to understand with insteon and the ISY. One of those concepts is that turning on or off a controller device from the ISY admin panel will not affect any devices that are a responder to that controller....the only time a device acts as a controller is when it is activated locally (press the button).

Only for a few days, up front. I go for months without touching mine. Then, when I do, it is often to experiment or change the way my system works. I encounter nearly NO need for maintenance or babysitting.

That's some great food for thought, I'll try to answer... Yes, technology does intrigue me. Spending an hour or so each night for a few days is fine, but every day, then you can't exactly call it automated. I hate paying someone to do a job just because I'm too lazy. I'll gladly pay somone who actually knows what they are doing. Half of the time when I pay for a job to be done it ends up being no better than if I'd done it myself. I do just want to get it working. I hadn't opened the admin panel in well over a year. But let's be honest- Insteon devices are not built to last, so as they stop working, you do need to deal with them. My house is somewhat static. Maybe once a year I'll think of something I'd like to add to the lighting system. VCR blinking 12:00? No, I did try to keep it set, and I was happy when I bought one that could set its own clock. I rarely programmed it to record. I spend way too many hours a day on the Internet. I use Chrome at work, and Firefox at home. I have no idea why on don't use the same browser in both places. I think the reason might be that there was a version of Firefox that broke flash, and that day I switched to Chrome. I never had that version at home. My smart phone is an iPhone, not because I have a gay crush on Steve Jobs, and not because I love Apple telling me what's best for me, I use an iPhone because it not just can't be tweaked, it doesn't need to be tweaked. Yes there are things I wish it could do better, but I like not having to think abut it. I need it to just work when I use it. I need home automation to be like my iPhone. When I, the household geek pushes a button, I don't want to wonder if it will work. More importantly, when my wife, who quite frankly could live the Amish life style, presses a button, there better be no mystery or trouble shooting involved. It needs to work just like a normal switch that normal people have in their homes. I just feel guilty taking so much from all of you when I have so little to contribute. But if you're willing to hold my hand though this process, then I'd rather just do it myself so I can fix it when it breaks. Thanks, ~Jay I apologize for being unclear, but I intended these as rhetorical questions to help guide your decision. But...I have seen enough. Your attention to detail and willingness to read the responses leads me to the conclusion that you should give this a shot without professional help.

I am having a senior moment with my memory, but this sounds like the common problem where folks can fail to fully account for program triggers versus evaluation results. I can tell you that I avoid programs who's THEN or ELSE path can cause a change of the IF condition. For example, you have a THEN path which turns the "light" off. This would change the STATUS of the light from "not off" to "off". This change of status would trigger (again) the program, which could cause the ELSE path to run. In worse case you may have an infinite do loop. There are a couple of options to avoid this problem. One is to use integer variables as a representation of light status (integer variables, when used in a program IF condition, do not trigger an evaluation when they change). Using this method may require a couple of programs to accomplish, such as: if status light is not off then set integer variable to 1 else set integer variable to 0 if control remote button is set on and integer variable is = 1 then set light off else set light on Another option should you care to avoid the variable approach would be to break your single program into separate programs: if control remote button is set on then run second program (if path) second program (must be disabled): if status light is not off then set light off else turn light on Take your choice. There may be other options, but that should be enough to get you started. Report back if you have any problems. edit: looks like LeeG beat me to it again.

I think you should consider the possibility that there is something about the condition of your power (surges, over-voltages, spikes, noise) that is causing these failures. While I am sure there are plenty around here that will complain about insteon "quality", 5/13 is absurd for the first six months. Something strange is going on somewhere. Is it possible you have a wiring issue that is causing a gross distortion to your AC waveform?