oberkc

Like I said earlier, I don't believe momentary mode has any effect when controlling the device directly. Regardless of mode, only an ON command will trigger it. Added: for the momentary modes to be enforced, one must be using scenes. If the use of momentary modes is important (such as limiting response only to OFF commands, or responding based upon sensor status), I believe the relay must be in a scene, and the scene be controlled, whether through mobilinc, a program, or an insteon controller.

The only scene in which is my relay is one where the keypad button is controller and relay is responder. If you have no need to control the relay via other insteon device, I see no need for a scene. Keep in mind that the various momentary modes may not be enforced if controlling directly. As I understand it, when controlling directly, only an ON command will actually trigger the relay. OFF will not actuate the relay. It is best for confirmation of this if this turns out to be important in your case.

Call me stubborn, but I continue to believe that this should not be necessary, and, in fact, is NOT necessary on my phone with mobilinc. I open mobilinc, select the relay, choose proper (on) command. Done. It is not dependent on the status of the relay, percieved, real, or other. Mine is android version. I can only assume you are on iOS and that it must be different in this regard.

For any given scene, there will be "controllers" and "responders". Furthermore, for any given scene, the PLM is ALWAYS, by definition, a "contoller". In your scene, therefore, you have two controllers. One is the motion sensor. The other controller is the PLM. Your scene has one responder device: the switchlinc. Remember also, with insteon, the response (ramp rates, ON levels) can be unique to each controller device. In your case, therefore, you can define a different switch respnse if your switch is responding to the PLM compared to the response to the motion sensor. Whan an insteon program commands a scene to turn on, the responders in that scene will respond at the levels defined for when the PLM is controller. When a defined scene controller (motion sensor, in this case) commands a scene to be on, the responder devices will respond based on the defined level for that specific controller which can be different than the levels for the PLM. So, construct for the given command is: In scene <scene controller> set <scene responder> xx%

I do not believe thay are the same. The "pro" refers to a specif version of an app. "Connect" is in reference to a service.

I dont know if it has been suggested, but I would definitely be checking the logs to determine if there are other programs, beyond the two query programs, that trigger around 0257. Imwould also exploit the find/replace function to be sure that I knew with certainty which programs include the IOLinc.

These are my fears, as well. Hypothesise...if a garage door is open and one commands closure, what happens when the door closes and the sensor (controller) changes state? Would it not issue a new ON (or OFF, depending on sensor) to the relay (responder), potentially causing the door to open again? While it may be possible to avoid this with great care applied to the momentary modes, I am missing the purpose in establishing this scene relationship and it appears to me to be all risk and little reward. I dont think we can discount this as a potential contributory factor. On the other hand, I am a little fuzzy on whether a query would cause the door to open solely based on the scene relationship. The query, I understand, potentially updates the ISY status and would not necessarily be the equivalent of a scene command, so I assume that this would trigger only programs, not scenes. Whether it is scenes or query programs or something else, unless there is good reason for having them and that the unintended consequences are understood and mitigated, simple is better. It may be time for blackbird to start fresh with this IOLinc. There appears to be a lot going on here.

It is getting late, and I may be having a brain cramp, but i dont think one wants the relay and sensor in the same scene. Would not one run the risk that the sensor triggers the relay? At my house, I have two separate scenes for eac button. One scene has button as controller and relay as responder. Then there is a second scene with sensor as controller and button as respnder. I have no scenes than include both relay and sensor.

In the same scene?

Point of clarification...do you want it to wait for one minute before checking again, or to send a notification if motion is sensed a second time, within 60 seconds of the prior motion detection. I am not sure that there is a way to "check again" for motion. The sensors will send out motion when detected and the odds of motion being detected EXACTLY after sixty seconds are next to impossible. The thing one can watch for is whether motion is sensed within certain time ranges or intervals. so...if motion is detected 70 seconds later, you want a notification? If 90 seconds? A half hour? Better, in my mind, is to see if you have multiple detections within a short period (minute sounds good), rather than random detections many minute or hours apart.

I like LarryLix proposal, but suspect there might be one extra step to the proposed "Motion Notify" program necessary: Motion Notify (disabled) If Control 'Motion Driveway - Sensor' is switched On <<<I would add these three lines so that, once enabled, the program will actually trigger Or Control 'Motion Patio - Sensor' is switched On Or Control 'Motion Front - Sensor' is switched On Then Send Notification to 'xxxxxxx@gmail.com' Else ----- I do not, because I don't desire to have notifications. If I did, however, I would take an approach like suggested by LarryLix.

Any reason to believe it won't work? Just beware...secure, non-secure, HTTP, HTTPS, mobilinc connect or not...these are common points of confusion. If you run into problems, don't hesitate to ask. The support from universal devices and mobilinc is the best. They will get it working for you and answer any questions you have if the various instructions and forum support can't get you going.

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.