oberkc

Your programming was fine. My suggestion is to think out completely how you want your system to behave with regards to the motion and switch. My preferences for your consideration: - manual switch ON turns on lights and halt any ongoing timer / disable new timers and motion? - if lights off, and between certain time, motion triggers lights and timer. New motion restarts timer? - at sunrise + 6, any lights on turn off?

I suspect it will do what you stated, but I wonder if that is what you want. What do you want to happen if you manually turn on the lights while in a countdown timer (would you not want them halt the timer and stay on)? What if motion is sensed during the countdown (would you not want to reset the timer)?

http://www.universal-devices.com/mwiki/ ... =Main_Page

my first inclination would be to recheck connections. Make sure none are loose, and that it is bare conductor under the wire nuts. What are flickering? The fan lights? The switch LEDs? What are the lights? Incandescent?

Ah, yes. My fault. I always forget this problem. Secondary buttons cannot be controlled directly, unfortunately. They have to be put into a scene. If need be, create a scene with a single device: the KPL button. The program would then be: if status KPLD is on then set scene with KPLC on set scene with KPLB on wait 2 minutes set scene with KPLC off set scene with KPLD off else nothing sorry for my forgetfulness.

Rather than a marginal Keypadlinc, I suggest you consider the possibility that communication between the PLM and Keypad is somehow being disrupted...most likely by other electronic devices on the circuit powering the PLM. What other devices are on this circuit? Lots of computer stuff?

So, when someone turns on KPL D, you want it to turn off after two minutes, along with KPL C? OK. You did not state what you want to happen if KPL turns off during the two-minute timer, so I will make no assumptions. If Status KPL D is on then set KPL C on set KPL B on wait 2 minutes set KPL C off set KPL D off else nothing

Credit is due to PurdueGuy (though I would prefer it if it were OSUGuy). To re-enforce one point, in each scene, the secondary responder buttons ON level should be OFF (or zero)! The idea is to create a scene such that when you press the controller button for that scene to turn the scene ON, the responder keypad buttons will actually turn OFF.

I view this whole topic as a matter of degree and confidence. Insteon, and the ISY, can provide SOME level of security. Whether it is enough for any one person is up to them to decide. I don't have a security system (yet), but I believe that I am more secure with an ISY than without. Can it completely replace an ELK or other security system? Not with the same levels of confidence and, in some cases, capabilities. Not in my mind, at least.

Like PurdueGuy said, the syntax is not exact, but when you go into the dropdown box in the programming section, and select condition, it gives you the option to choose "control". Then choose the insteon device, the choose the desired command (ON, OFF, NOT ON, etc). The reference to remotelinc.D is, I am sure, button D on the remotelinc. Exact syntax would be generated by the ISY and would look more like: Control 'button D' is switched Off The only way to set a variable in response to a remotelinc button press is via a program, so I don't see how this solves your problem if you are having trouble initiating a program from that button press. Is is possible that you are not having a programming problem, but rather the ISY is not seeing the button presses?

To be clear and precise, there is no way to disable response to motion or to disable motion sensor activity (short of taking out the batteries). There is, however, a few of ways to disable a program from self-triggering. Thesidewinder has identified one of those ways. Another is to create a program and use the state of that program as a condition for a program folder. As an alternative to disabling programs, there are also ways to generate and incorporate program conditions to accomplish your goal. You can use program status (true or false) as a program condition. There are also variables (integer and state) that may prove useful. The trick is to exploit all these tools with the others in such a way that your combination of scenes and programs are integrated, and accomplish your complete goals, and do so efficiently in order to minimize the unforeseen complications. I suspect you have a bit more complicated scenario than I believe you will find is addressed by Thesidewinders example . You also want to disable the motion sensor if the switch is manually turned on, in addition to to enabling motion sensing if the switch is manually turned off, but only after waiting 5 minutes from the point it is turned off. In an attempt to avoid the added complication of creating a variable (perhaps that would be a good next step some day), one could create a couple of programs: Status program for the sole purpose of using as a program condition: if nothing then nothing else nothing Second program for the sole purpose of executing the status program at the right time: if status light switch is on then run status program (then path) << else wait 5 minutes run status program (else path) << Once these two programs are established, the status program could be used as a condition for a program, such as: if time is from XXXX to YYYY and control motion sensor is turned on and status program it false then turn on lights wait 30 minutes turn off lights else nothing Assuming that your light switch is a controller of your lighting scene, this may be a complete solution to your lighting automation requirements. Given that you were interested only in a way to disable the motion sensor response to 5 minutes, however, I will leave it to you to decide whether and if this approach can be incorporated into your current program construct, or whether Thesidewinders method gives you enough ideas to continue. Let us know how it works out.

What time are you heading "for the door"? When you "hit the switch", are you turning it off, or on? It sounds to me that the program is doing exactly what it is programmed to do. If it is after 630pm, and before sunrise, and you turn the switch off, and the motion sensor is already on, then I would expect the first program to turn on the lights. Alternatively, if you are heading out, and you turn off the switch, and the motion sensor was off, but subsequently senses motion as you leave, then I would expect the first program to turn on the lights. I am curious what provisions you believe exist in this program that would allow the ISY to know that you are leaving and to hold off responding until you have left and have closed the door. I don't consider what I think you are attempting to be a trivial problem. Now that you have had some experience with this, and have time to better understand your needs, perhaps it is time to describe your requirements in total. For example, I assume your set of requirements is something like: -between 630 and sunrise, motion detected turns on the lights -30 minutes after last motion is sensed, turn off the lights -at sunrise, turn off the lights regardless of how long they have been on (unless the light switch has been manually turned on) -if the light switch is manually turned on, disable the response to motion and halt any ongoing countdown or automatic shutoff -if we are leaving between 630 and sunrise, and you turn off the switch, re-enable motion response, but only after a short delay to allow occupants time to leave -send text message if motion is sensed and the lights turned on -other? If accurate, this does not sound so trivial, does it? I find that writing your requirements down to be very enlightening and helpful. If you are willing to do this, I will do my best to offer a solution and help understand the reasoning behind it. For now, I believe you are having issues with "status" versus "control" conditions. I believe you will have problems with the current program if sunrise interrupts a countdown period. You may be having problems with the way the motion sensor is configured. I believe the way you have broken your programs down into two is not the best approach.

If you want a level of independence from the ISY, you cannot use programs. Programs only work when the ISY (and PLM) are present and working. Yes, it probably puts a little extra traffic on the insteon network, but I would not describe it as constant...only in reaction to your button presses. Do you have reason to be concerned about this? Scenes, however, can work without the ISY. I don't have a mini remote, so all I know is what I read in the manual. It appears to be capable of operating in 8-button non-toggle mode. When in this mode, it seems to me that you could configure one row of four buttons to control your fan speeds (off/low/med/high) by making these buttons controller of your fan speed scene. The only problem is deciding what to do with the remaining four buttons. Am I missing something here?

Make sure that you have the mini remote buttons in a scene as controllers, with the respective keypad buttons as responders. In the end, I would expect, for each fan speed, a scene with respective keypad button as controller, remotelinc button as controller, and fanlinc speed as responder. All other keypad buttons for other fan speeds should also be included, as responder, with ON levels equal to zero.

I think you programs will mostly work, but will have a problem if sunrise interrupts your 30 minute wait. Instead, try the following approach: If From 630 To sunrise (next day) And Control motion sensor is set on Then Run next program (then path) Else Nothing Next program: If Then Set scene retail lights on Wait 30 minutes Set scene retail lights off Else Nothing Of course, this does not address your need to override the program with the switch.

I am not sure that I am smart enough to figure out your intent by looking at the programs, but a couple of trends interest me. a) you initiate some programs (if path) from others, which is fine. Do you want those same programs to trigger themselves (in addition to being initiated externally)? For example, "kitchen light fade warning" IF PATH is called by "kitchen lights off". Do you want "kitchen light fade warning" to also be triggered conditions initiates this? how many of the individual devices listed in the condition of "iskitchenon" are part of the scene "allkitchenlights"? is it possible that when program "kitchen lights fade warning" turns off the kitchen lights scene, it triggers itself (false), and halts the repeat? What would happen if you disable the program "kitchen light fade warning"? Is it possible that it is already disabled? Are any of these programs in folders?

viewtopic.php?f=26&t=5764

If you would rather avoid splitting the program for some reason, perhaps you can take advantage of an command to "disable" itself, then enabling itself after it is finished. There are also integer variables available that, when used as conditions in programs, do not act as triggers for the program. This may offer some options. But I second apostolaksl observation that it is not a CHANGE in status that triggers a re-evaluation. All of your program conditions are also program triggers. When triggered and evaluated, even if no change of state takes place, the program will re-execute whatever path is dictated by the evaluation, from the beginning. So, if the program is 29 minutes into the wait period and the program is retriggered and again found true, the THEN condition will rerun, from the beginning. Perhaps, if you care to share your purpose and goals for this program, more specific ideas would come out.

I have no mini remote, and am unfamiliar with how it works and am getting too lazy to check the manual. I assume you have looked and confirmed that the buttons cannot be put into non-toggle mode? Regardless, I think you will find the ISY can solve this problem. My initial suspicion would be to use a program that looks something like: if control mini remote button it switched on or control mini remote button is switched off then turn off "all lights off" scene else nothing

I have always viewed this as a design decision rather than a bug. It does have its advantages in certain cases, and disadvantages in others. Others, however, have voiced similar viewpoints to your own. I believe that there is a way. It is the one I suggested. Alternatively, you can "disable" a program, which restricts a program from self-initiating (allowing the status to be reevaluated). I think you will find sufficient flexibility in programming the ISY, but it does have some learning curve to fully exploit.

I have always understood a togglelinc to be a switch that is manually turned on or off. How does this indicate whether a door is open or closed? Are you sure that this is the actual name of the device you are using? Regardless, I can offer some conceptual ideas and you can fill in the details based on your setup and devices. Create two programs: if status tooglelinc is ON <<< assuming ON = OPEN and control motion sensor is set ON << then perform action1 else do nothing If status togglelinc is OFF and control motion sensor is set ON then perform action2 else do nothing Keep in mind that this action will be triggered EVERY TIME the motion sensor sends the ON command. The frequency of this is based, in part, on how you have your motion sensor configured. Also, the fact that your togglelinc does not indicate current state is, in my experience, a symptom that something is wrong. This is not normal.

Like LeeG suggests, I and I concur...I believe something in your program is changing and triggering your program, likely changing status to false during the 30 minute wait. Look at your program list and find the current status of this first program? Is it false? When was it last executed? After 7:30 and before 8:00? The purpose of breaking it out into it's own program is to avoid it being interrupted by a change in status. Once running, unless called manually or by another program, it will continue to the end. No wait statements will be interrupted.

Without knowing what are the names of these two programs, or knowing what makes programs "IsShabbatOrYomtov", 'is9Minyan', or 'isRaining' to be true or false, it will be hard to say what is causing your programs to halt execution during the wait statement. Assuming the conditions of these two programs accomplish your goals, my temptation would be not to worry about attempting to isolate your problem. Instead, break out the THEN paths of each program, putting them into separate (disabled, without IF conditions) programs. For example, create a program (disabling it) that looks like this: IF THEN Set 'Dafna's Bathroom' On Wait 30 minutes Set 'Curlers' On Set Scene 'Master Bathroom' On Set Scene 'Closets' On Set 'Upstairs Bathroom' On Set 'Jerry's Bathroom' 50% Wait 2 hours Set 'Curlers' Off Set Scene 'Master Bathroom' Off Set Scene 'Closets' Off Set 'Upstairs Bathroom' Off Set 'Jerry's Bathroom' Off Set 'Dafna's Bathroom' Off ELSE Then modify your first program to look like this: If Program 'IsShabbatOrYomtov' is True And ( ( Time is 7:00:00AM And Program 'is9Minyan' is False ) Or ( Time is 7:30:00AM And Program 'is9Minyan' is True ) ) Then run new program (then path) Else - No Actions - (To add one, press 'Action') Take the same approach to the second program.

I assume LeeG is speaking of my response to your question originally posted on smarthome forum. I paste it here: The answer to this question will partly depend on how you have set up your sensors and IOLinc. Does sending an OPEN command cause the door only to open, and CLOSE only to close? Or...does OPEN or CLOSE cause the door to move, regardless? The simplest might be to create three programs: if status garagedoor1 sensor is open <<< depending on setup, could be ON or OFF. then wait 15 minutes close garagedoor1 << else nothing Do two other programs just like it for the other doors.

One problem you will have with your program (unrelated to your posted concerns) is that if sunset occurs during an on-going wait period, the wait will halt and the fountain will not turn off. I suggest adding a command in the ELSE clause to turn off the fountain scene.