oberkc

I think this is the part of your requirements that need further addressing. It is simple enough to have the keypad buttons reflect the state of the sensor. The method I would use would depend on the state of the IOLinc when the door is closed, and this is dependent on the sensor. If your IOLinc is OFF when the door is closed, I would use a scene. If your IOLinc is ON when the door is closed, I would use a program. The limitation with these approaches, however, is that neither address the problem when somebody manually presses the keypad button by accident. For this, I believe you will need additional programming action. My initial reaction to this requirement is an additional program to watch for those button presses, then run your garage door status program. This could look something like: if control keypad button is set on or control keypad button is set off or control keypad button is dimmed or control keypad button is fast on etc... then run garage door single status (if path) Not that I am aware. I do not believe this to be true. STATUS conditions will trigger upon ANY change in status, either from ON to OFF, or OFF to ON. Once triggered, it will execute TRUE (if now OFF) or FALSE (if now ON).

I am saying that query programs have been known to do such things, depending on other factors that are currently unknown. I am also suggesting that the fact that the query program runs at exactly the same time as the event is, in my mind, more than coincidence. I am also suggesting that having programs without a purpose can lead to unkown results.

OK. Thanks. My recommendation stands...if all you want to do is open the door via phone, I do not believe there is any benefit to querying the relay. Unless you have a specific problem that you are trying to solve with this program, disable "Overhead Garage door relay off". Make sure you do not have trigger reverse set in the IOLinc settings. Double checking...you have no other programs that include the IOLinc? Are you using the status of the sensor for anything?

I can corrupt the insteon signal sufficiently that your system fails to respond.

"Switched" is, arguably, a better way to describe the condition. I doubt that this will be hard to adjust to.

Your edit thought is correct. About the proposed program.... -I want to know when a given device is controlled manually. This suggests using CONTROL sconditions. - CONTROL...ON triggers upon reciept of ON commands only. It is TRUE at that moment ON is recieved, otherwise FALSE at all other times. - COMTROL...OFF triggers upon reciept of an OFF command, it is FALSE at that moment and true at all other times. The two statements combined will trigger upon reciept of either ON or OFF commands and will evaluate TRUE when ON and FALSE when OFF. This tracks the last command from the given device.

slpelts, You said that you have been using it for a while and it is six-button. The question I have is whether it arrived new as a six-button? I understand that 2487 is a six-button keypad, but I am wondering if a mistake was made at shipment and they sent you an eight-button deivce with a six-button frame. I definitely like the suggestion by LeeG to see if you can turn it back into a six-button device.

No. Turning on a responder in a scene does not cause any controller of that responder to react, in any way, unless that controller is a part of that same scene that was just turned on. Furthermore, turning on a a scene that includes a controller device (from another scene) does not cause responder devices from that other scene to react. The only time a device behaves as a controller is when it is acted upon locally. When a scene is activated via the ISY, the only devices that respond are those directly in that scene. I have the same philosophy about variables as I do about programs: use only when one must. For my purposes, I have found very few times when variable were necessary. A variable is not necessary for an override, but it is certainly an option. I simply use a program such as: if control "switchX" is turned on and control "switchX" is not turned off then nothing else nothing This program acts as my status tracker. If this program is TRUE, then the switch was manually turned on when most recently activated manually. If this program is FALSE, then it was manually turned of most recently. The program status (rather than a variable) could then be used as a program or folder condition. Generally, one can disable programs, or put programs in a folder that can be disabled, or use program conditions, to decide whether to react to motion sensors. Use a variable as a condition. Use program status as a condition. Either works and is a personal preference as far as I am concerned. If you use variables, be aware of the difference between STATE and INTEGER variables regarding their behaviour as a program trigger and plan accordingly.

I don't know whether that helps battery life, but it sure seems very possible and I suspect that it would. The trick is to find the right balance here. Do want to reset the 15-30-minute countdown after each motion detection? Are you happy to wait 10 minutes to begin watching for motion again before you reset the countdown? Note, also, that there an option to select whether to detect motion always, or only after the timeout. This will also affect the frequency which the motion sensor will transmit ON commands.

No. The updated parameters are only the response levels to be applied the next time the scene is fired from the specified controller (in this case, the PLM). No. At 9:00, the program is triggered and evaluated, where it will be FALSE. Were this program executing the THEN path when this happens, any wait condition will be halted and the ELSE path will run. Since you have no action in the ELSE path, nothing will happen beyond the program halting.

Also, if you plan to rely on the program, light sensitivity settings become almost moot. If you make the sensitivity settings too extreme, you run the risk that it is technically sunset, but the program wont execute because there is still enough light to prevent the motion sensors from firing.

Great. It is as I suspected. I agree with teken...simple first. Use scenes where you can, use programs where you must. In this case, however, you want to limit response to certain clock times (sunset to sunrise), which drives to a programmatic solution. By the way, I personally use sunset and sunrise, but have no preference for time versus light levels. I can argue for either, but the differences are trivial, in my mind. If you opt for light levels, then I would skip the program and use scenes. To use a program, first, make sure you eliminate the scene between the motion sensor and lights. Regarding your program, in logic terms, you are wanting two conditions to BOTH be true. In logical construct, this would be if time is X AND (not OR, as in your original program) motion is sensed. Interrupt....I missed your updated program in post 13. You corrected the OR to AND, and added parenthesees bracketing the two motion sensor conditions. Perfect! I expect this program to work exactly as you desire. I would take, however, one additional step...create a single scene with your four lights, all as responders. Adjust your prgroa, to turn on/off the scene, rather than the individual lights.

I SUSPECT you have some logic problems, but it is hard to say for certain without knowing WHAT you want to accomplish with this program. What do you want to happen at sunset? What do you want to happen at sunrise? Do you want the lights to respond to motion at all times, or only at certain times? Your particular program will turn the lights on at sunset (then off 20 minutes later), and will turn the lights on (then off 20 minutes later) when motion is sensed by either sensor. If the lights are on at sunrise, your program will turn them off. Making the changes suggested by teken will restart the 20 minute timer (if running) at each detection.

N8huntsman... Your program, you have a "set scene 'outdoor bar lights' on" statement initially, but fail to include the same statement after each 30 minute interval. This statement is required at each 30 minute to activate the scene at the new levels. I don't see any advantage to using multiple scenes and programs versus your creative approach. I see nothing in your program that turns the lights off. Understand, also, that if 9pm occurs while this programs is executing, it will halt.

Wow. So this is a program to keep mobilinc in line? I guess if it works for you, it is hard to argue. Certainly not a problem I have ever experienced.

While there is no question that the reliability of insteon is not 100%, I believe that this problem is solvable if you want to keep trying. There remains many questions that continue to float through my head (perhaps I missed all this discussion earlier). - what are you trying to accomplish by putting the IOLinc on the door? Is it simply a notification that the door is open or closed (if so, leave the relay disconnected)? - why do you believe you need the status of the relay? Does it serve some purpose in another program? If you have a program who's purpose you don't understand or can't remember, perhaps it is time to rethink the approach. - do you desire to remotely actuate the door, via phone or other device? If so, via what app? Do you simply trigger the IOLinc relay directly or a scene or a program? - do you have a "query all" program (possibly to trigger at 3:00am)? - is the IOLinc part of ANY scene? My temptation would be to temporarily disable that "Overhead Garage door relay off" program. Unless there is a known purpose for it, this program strikes me as suspicious. From there, I would consider taking a fresh look at your objectives. Perhaps it is time to clear out existing programs and scenes with the IOLinc and start over.

Is this what you WANT, what IS, BOTH, or NEITHER.? The decision of scene versus program comes down to what you WANT to happen. If your desire is to limit response to motion to certain TIMES (clock), then a program is your only option. If you want to limit response to motion to periods of lights as detected by the motion sensor, then either a program or scene can accomplish this, all dependent, as stusviews notes, the sensitivity setting of the motion sensor. In fact, the motion sensor, itself, can limit response ONLY based on ambient light. If you want conditions beyond this (time, home or away, manual intervention, override), you will need a program. My perceptions over the years reading posts is that many don't spend enough time deciding what they want to happen. My recommendations are to consider the possibilities. Are you happy with motion sensors that trigger always, or during the dark? Do you want the ability to manually override the motion sensors and leave the lights on until you choose otherwise? Do you want the ability to manually disable the response to motion , should the need arises? Do you want the lights to stay on so long that motion is continuously detected? Would you rather limit response to time?

The other day, I think I saw some bulbs that connected directly to a bluetooth device (presumeably, phone or tablet). I was not that interested so I did not take a lot of mental notes. I bring it up only as an example of a bulb that requires no hub. Range, obviously, would be more limited.

If your lights and sensors are in a scene, then there is no reason to have a program to turn them ON. On the other hand, deleting the scene and using a program can add great flexibility to when the lights turn on and off and at what levels. If you have a program AND a scene, then you have the potential for some unexpected results.

If your program is not causing your lights to turn off when the motion sensor sends the off command, yet the lights still turn off, the only explanation I can think is that your lights and sensors are in a scene together. Is this possible?

Forgive the stupid question...does scene "all on off" include the IOLinc?

I do not believe there is a way to "SYNC" the remotelinc, for the resons stated earlier. A programmatic solution would not sync it either. Instead, I would take a different approach. First, I would take the remotlinc out of the scene. Second, I would consider putting the remotelinc into non toggle mode (not absolutely necessary, but may help simplify programming). Once done, a couple of programs such as: If control remotelinc is switched on (Or off, depending on toggle mode of remotelinc) and status keypad button is on then turn off scene else nothing If Control remotelinc is switched on and status of keypad button is off then turn on scene else nothing

What "phase coupler" do you have installed? When performing factory reset, I am not sure if lamp plugged in matters. When adding to ISY, only hold button until first beep.

I am not sure that the remotelinc, being a battery device, listens for insteon signals (other than when in linking mode). Therefore, I do not believe the remotelink will act as reponder and stay in sync. A programmatic solution may be only option.