oberkc

Response to questions: 1...the correct setting depends on your goals and intended usage. I use momentary A, because I want my relay only to respond to ON commands from a keypad button. What you choose would depend on how you establish your scenes between the IOLinc and another insteon controller device, but if you want it to respond to both commands always, choose momentary B. 2...momentary A response to only one command, either ON or OFF. (I would have to refresh my memory on how one choses which command.) Momentary B responds to both ON and OFF commands. 3. I was not thinking that this is a communication problem initially. More on this.... My experience (and recollection) is that the IOLinc relay, when operated directly from the admin control, will NOT respond based upon the momentary or latching modes. The latching or momentary modes are respected ONLY when responding to a scene command triggered from another controller. In my case, commanding the IOLinc relay to be ON caused my relay to be open and commanding it to be OFF causes the relay to be closed. Regardless of momentary mode, commanding the relay to be OFF causes NO response to the garage door. In my installation, commanding the IOLinc to be OFF, directly from the admin console, caused no reation by the garage door, regardless of momentary mode chosen, and regardless of whether the door was initially open, closed, or in motion. Given this, I am unsure why yours would be different. Is your IOLinc a responder in any scenes? Were you commanding the scenes, or the IOLinc directly?

I agree with redridge. I will add that one needs to be careful to avoid having the THEN section retrigger the IF section but, otherwise, it should be as simple as described. Are you concerned only about when the garage lights are manually turned on, or are there other automated cases that might cause your lights to be on?

Did you just upgrade to 5.0.15? I recall getting those types of warnings when I went from 4.x to 5.x. I believe it meant that there was some program action there that could not be properly translated to the new software. Hopefully, you can figure out what action is missing.

I assume it works the same as from>to condition. It might be useful if you want something to happen at the FROM time (then clause) and something else to happen at the end of the FOR period (else clause).

If you have a hue hub and bulb, the ISY-994 can be made to control it. Unfortunately, I would consider this a "major programming change". Is this fixture not controlled by a switch?

This surprised me, so I checked my method and found that I remembered incorrectly. In fact, I do set a variable...zero for normal operation and one for when the switch is manually turned on and I want the motion timer to be ignored. I don't recall why I did it that way. Perhaps I learned the same thing you did, but forgot?

yes correct I suppose one could use variables, but this simply adds another layer of complexity. Yes, the override program is a simple state machine. Of course. When your override program runs TRUE, have it halt the body program. If the body program is in a wait state, it will cease waiting. I am not sure I knew that. Interesting. Perhaps having a variable change value for ON or OFF has value, after all.

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.