oberkc

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.

Nothing additional to purchase of which I am aware. Make sure your program uses "next day" if sunset to sunrise (next day) <<< Watch program status after sunset...does it turn true?

Perhaps updating the firmware to a newer version would help. Also, make sure your admin panel is up to date.

I agree that I also find it unlikely that being a virtual three-way has nothing to do with this.

As I understand the way things work, if a device looses link records with regards to the PLM, or vice versa, the ISY may not see commands from that device. Besides, it is simple to accomplish and is unlikely to hurt anything. Sometimes, I understand it can help to restore the PLM, also. I don't know why devices can loose link records. Do you see any other signs of comm issues or slowness?

The program is simple enough that I think we can declare that this is not the problem. I am unsure why a status would work, but not a control. Is the device part of a scene? Does the event viewer not show the receipt of the control command? What happens if you restore the device?

While I don't expect incandescent to be a problem, it is still worth temporarily removing the bulbs to see if this changes anything. The only other thing that comes to mind is proximity to switches. How far away is the lighting sensor to the trouble switches? I was also curious as to the image...is the direction of the perceived cluster of lighting strikes a clue?

What type of bulb do you have in your back porch lights? What happens if you temporarily remove them? Have you tried a different load in the fixtures?

This sure sounds abnormal to me. Have you checked the keypad manual to determine how to manually set the backlight levels? Does it involve button B somehow? I wonder is there is some failure or stuck button on the keypad that is causing this.

I don't find it hard to believe that this can't be recreated. I can't even recreate it on my own machine at this point.

I added a few new units (dual band) also during that sale. It seems to help with speed of response with my system, so I would suggest that your hope is not unfounded.