oberkc

I believe the answer is NO. Button A will control the attached load and there is nothing you can do about that. Depending on your needs, you could set the ON level to zero, but it would still be controlling the load.

No. Right-click on the program>>>disable. This will keep the conditions, but the program conditions will only evaluate them when called by the other (.cond) program. First, my thoughts were that the .body program would NOT be enabled (thus my suggestion). I do not want it triggering itself by the conditions. Second, once motion is detected and triggers the .cond program, it would call the .body program. (But now that I re-look, I missed something: make sure you call the "IF" path of the .body program, not the "THEN" path. ) This will trigger the evaluation of the .body conditions, which will be false (because .override is TRUE) and, therefore, not start a countdown. One other consideration...what if the motion has already triggered a countdown, THEN you turn the switch on? Do you want to halt the countdown?

A couple of things. First, I would disable shedmotion.body. You do not want that program self-triggering...only run when called from the .cond program. Second, I would get rid of the second condition of the .body program. Since it will be called by the .cond program, the second condition is redundant. Regarding the "shed lights" ...are they a dimmer? If not, then the commands in the third program to turn the on/off are redundant (would they not already be on/off when the program is triggered?). If they are a dimmer, why not simply make the default action 100%-on and zero ramp rate (effectively a "fast on")?

That would work (send notifications), but certainly not affect any motion sensors

I have same provision, at sunrise.

All my lights triggered by motion sensors are on switches. I have programs that, when the switch is manually toggled ON, the motion program is disabled. When the switch is manually toggled OFF, the program is enabled. This is an example of where using a scene between the motion sensor and switch will not work.

I recall, too, that a scene test could fail if one of the included devices triggering a program. If this is a possibility, temporarily disable the program(s) during the scene test.

How do you normally access the ISY? Have you tried downloading a new version of the desktop app?

Still hoping for answers to these questions. If it is an 8-button keypad, the load is controlled by button A. If the keypad powers the light, then the flashing light will cause a flashing button. Is this acceptable. If it is a six-button, then the ON and OFF buttons will alternate when flashing. Is this acceptable?

My gut feel is to do this with a single ISY scene, including all the devices from scene 1 and scene 2. Buttons A and B would both be controllers in the scene. For button A, define the appropriate ON levels for the scene-1 devices. For scene-2 devices (and button B), define ON levels as ZERO (off, whatever). For button B, define the ON levels for scene-1 devices (and button A) as zero. Define the ON levels for scene-2 devices as you want. This requires a program. There is no scene capability that would cause a light to flash. How do you want to initiate the flashing? Pressing button B? How do you want to terminate the flashing? Toggle button B to off? Press button A? Is your keypad six- or eight-button? Is your light bulb powered by this same keypad?

Indeed. Great idea.

Besides suspecting that this is not the response being sought ("only the connected load turns on"), part of the discussion clarified "without linking the big on button".

That would have to be a program. There is no way to create a scene that only responds to OFF commands. Add everything (not including the "all off button") into a scene, all as responders. Write a program: if all off button is switched off then turn off everything scene. else nothing

I did not check, but I wonder if that is the part of the manual that describes the different ways to configure the IOLinc absent a hub-type device...all manually. Additionally, the connections would matter also. What does an "open relay" even mean...If the N/O connection is made, then the N/C connection would be open, and vice-versa. I believe that most of those configuration settings (I am assuming they are talking about the various momentary modes here) can be done via ISY and don't need to be done manually.

Yes, but I wonder the same thing as BrianH...perhaps the IOLinc settings are such that the IOLinc turns off in response to a scene-ON command. Also, scene commands can be more susceptible to communication problems than direct commands from the amin panel. Everything looks correct to me still. If there is something obvious, we are both missing it. I assume that you have tried temporarily removing the COM and N/O connections and tied them together, just to confirm that the lights work, correct?

I do see from the instructions that there is also the status LED, along with the sensor LED. The status LED should apparently be bright when the relay is closed and dim when the relay is open. Is this happening?

LED is, IIRC, based on the sensor input. Do you have anything connected to the sensor input? If not, it surprises me that the LED is lit under any circumstances. I also see that the relay is rated at 5A and 30V. That seems within what you are trying to accomplish, but not with a lot of extra capacity. It looks to me as if you have it wired correctly. Latching mode sounds correct also. Are you trying to control the relay or the sensor from the admin panel? Be sure to control the relay. Still I am not confident with using NO or NC contacts. I believe the NO contact would be open when OFF, which sounds right. What happens when you turn the relay OFF? Were this me, I would start probing voltages at key locations. 12V into IOLinc? 12V out of IOLinc? I would also measure resistance between NO and comm terminals, when the relay is ON and OFF. One should be near infinite. The other should be near zero.

I understand. There has been an ongoing debate about that around here, and also about the security risks associated with having an automation system having this ability. I assume yours has the safety interlocks built in, so it should not close on a child or pet. Since you seemed concerned mostly with critters (probably my biggest risk as well), it seemed you were well suited to an automatic solution. Thanks for satisfying my curiosity. Hopefully, the interlocks will also come into play here. They certainly work well for my doggies.

That would certainly bother me. Sounds like you have succeeded. In case it is not obvious, it will send you two notifications, regardless of whether you close the door after the first message. Personally, I just have the ISY close the garage door (as I thought you were originally trying to do).

This program will be triggered only once per day. It will be triggered at 10:00. It will be triggered regardless of value of variable. Once triggered, whether it runs true or false will be based upon both conditions. Since it was triggered at 10:00, that part of the condition is, obviously, true. Whether or not the variable condition is true will depend upon whether it is a "1" (true) or anything else (false). Both conditions must be true (logical AND) for your THEN clause to run. Otherwise, your ELSE clause will run. Why do you have two notifications, separated by a minute?

Of course, with the elimination of the variable, this program will trigger every time the door changes state, regardless of time. Each time it is triggered by the sensor changing state, it will run false and send you a notification. Is this what you want? This is one advantage a variable may offer in your case. Integer type variables do not trigger programs (which was the reason a couple of people suggested using them here). I am assuming you want this program only to run once per day, at 10:00, correct?

Kentinada, in my mind your program is pretty simple and should work. At 1000, it will trigger and, depending on value of variable, run THEN or run ELSE. I see no problem with this particular program. The only thing that I might be cocnerned about is if the door was open, and your program closes it at 10:00, the variable state chanes in a few seconds, retriggering the program. For this reason, please ensure your variable is the type “integer”. if you are getting unexpected results, try narrowing down your problem. Right-click on your program and choose to run the else path. Did you get your reminder? The answer to this question could point you in a particular direction. Have you confirmed that an open door results with a variable=1? Have you confirmed that a closed door results in a different value? Do you know how to confirm whether the program ran at 10:00, or whenever it last ran? Do you know how to determine whether it ran TRUE or FALSE? If so, check that out next time the clock strikes 10. is it possible that your program is disabled, or in a folder that is disabled?

Don't forget credit to palaymans "guess" in the second post.

For what it is worth, I expect both programs to honor the time condition ONLY in conjunction with the last OR condition. The first two conditions should without any time constraint. If either of the first two conditions are true, in either of the two programs, your program will run the THEN clause. If you find yours doing anything different than this, I would be extremely surprised. This is standard Boolean logic. Parentheses around the cluster of OR conditions is the solution.

Maybe. In fairness, it is perfectly safe and, until the advent of smart switches, perfectly functional.