oberkc

If you are on ISY software v5, yes. If on v4, no (at least, not simple).

Feel free to try my suggested program, or not. Yes, a variable solution could work, but this will add additional layers of complication and programs that (in my mind) are likely unnecessary. Yes, I understand your problem, and it is my hope that the use of "control" condition would solve this problem. Your description leads me to believe that your program is based upon a "status" condition. Of course, you have not posted your program, so this is all assumption. Another feature you have not mentioned is whether you want the lights to automatically turn off and under what conditions. I did not address this in my suggested program.

You left out some details (are you using an IOLinc sensor for status? Is ON=OPEN? Posting your programs?) Remember, also, that for most Insteon devices, there is a difference between a "control" condition and a "status" condition. These two conditions trigger a program differently. For your situation, a program a simple as: if time is from sunset to sunrise (next day) and control 'garage door' is set on then turn on lights send notification else nothing

Consider the possible causes, then devise experiment to test for each. - Is the ISY seeing on/off of sensor? If not, consider communication problems - if seeing on/off, is program triggering? If so, is it triggering TRUE? Check admin console program listing, and identify when last run and status. - if triggering and executing TRUE (then), are you still not getting notifications? Manually run THEN action from admin console. Still not notifications? Consider possible error in program or notification settings. Have you saved your program?

The only place I know to get the various versions is to go to the “current releases, betas, and bug reports” topic. Scroll back far enough and you will find the announcements for the various versions. i doubt that it is required to get 5.09 as an intermediate step to the latest version. Instead, you can expect a bit of work in making the transition from 4.x to 5.x. Hopefully, others can correct me if I am mistaken.

I did not even recall having to create the scene. I thought you could create such an action for any individual device, whether in a scene or not. I guess I remembered incorrectly.

My understanding from your original post was that you desired to change the response of the light when you manually activate the switch (local response). I am not sure that this would be done by creating a scene. In version 4 of the software, however, programmatically changing the local response rates of a device was done via an action to a scene. IIRC (I am no longer running v4 software so this is all from memory), if you were to create an program to run at a certain hour, choose an "action>>>adjust scene". In the first scene box, choose your specific device (not an actual scene, but the individual device). In the second scene box, choose the same device. In the action, choose the on-level (or ramp rate or whatever) that you want to be in effect at that certain time. If you want to change both ramp rates and on-levels, you would create two actions.

First, this may be different syntax depending on whether you are on software v4.x or v5.x. Second, this is from memory and I think from v4 software. In general, to change the local on level for a switch, you use the scene action that goes something like: in scene (name of switch) set (name of same switch) level to xx% I think the approach is similar in v5 software but the wording is a bit more intuituve.

I have not noticed that as much. I guess I notice more the other side (my perception of overuse of variables). Perhaps I am seeing what I want to see and the other side makes less of an impression? First-world problems.

Paul, the original purpose was to have a separate "close" and "open" statement to be used by alexa. I believe that the point was to tell alexa to close the door and, if the door was already closed, to do nothing. Alternatively, telling alexa to open the door would not cause a door already open to be closed. no problem I don't believe that this is a contributing factor. Should not use latching. Since you tried momentary C without success, I would stick to A or B. This is how I do it, using a keypad button as scene controller and relay as scene responder. I did not think you wanted to do this. I suppose you could create a single-device scene with only the relay as responder. Have your program command the scene. Perhaps this is a good idea. I have always had a recollection that the IOLinc modes were only in effect as scene responder, but others have corrected me when I bring this up. But, I have come to the age where I remember things that did not happen and don't remember things that did happen. In the end, I would stick with your two programs as is, but disabled. Call those programs as needed from Alexa. See if this works.

On the other hand, I generally prefer to use variables only when other practical solutions don't exist and to use as few programs as possible to get the job done. I believe that noremac's problem can be solved with a single program and no variable, so this would be the choice I would make if true. It seems to me that many use variables where none are needed.

My fault. These programs must be disabled. What is likely happening is, when the sensor changes state, it triggers both programs. You only want these programs triggered by a call from your echo alexa, not self-triggered.

Depending on the mode (momentary), the IOLinc can turn itself off and respond only to ON commands, only to OFF commands, to both, or can be configured to "latching" mode.

Well, I thought momentary C would be just what you needed. According to my understanding, the proper command to actuate the door would be based upon sensor input, but you tried it and did not do this. So.... Given this, you could potentially solve this problem programmatically. Create a "close" program and an "open" program. Each program would first evaluate the status of your door and, if already closed, the "closed" program would do nothing. If already open, the "closed" program would close the door (by sending an ON command). The "open" program would work opposite this. Perhaps this approach could solve your problem?

I don't think this needs to be complicated and should not require a variable. How about: if time is from sunset to midnight <<<hopefully, later than latest sunsets and time is from 7:00pm to midnight then turn on light else nothing

Momentary C mode is the only mode that I am aware that changes relay responses based upon sensor input. If I recall correctly, there is a little LED that is either on or off based upon the sensor input. Does this LED change state when the gate is open and closed? Is the LED on when the gate is open or when it is closed? (I must admit that I am unsure why it is important to you to establish this relationship.) As you initially tried, create a scene with the sensor as controller and keypad button as responder. That will cause the sensor to trigger the keypad when the sensor changes state. No. The sensor status should be accurately reflected without a query. If not, then I cannot help but wonder if the sensor is actually changing state or, if it is, whether the signal is reaching the ISY. Having responded to these specific questions, I will offer the opinion that you might be taking a less-than-ideal approach to your problem. This is not unlike a garage door to me. It sounds as if you want a single keypad button to perform double duty: to control the gate, and to display current status of the gate. It sounds as if you want the keypad button to be ON when the gate is open and OFF when the gate is closed. I assume that the gate controller closes a circuit when the gate is anything but fully closed (that is, "open" is defined as not fully closed). I am hoping that your IOLinc sensor node is ON when the gate is not fully closed and OFF when the gate is fully closed. If these things are all true, I recommend reading the wiki article on programming for a garage door and treat this the same.

I find scenes easier to manage when it is necessary to swap or add/delete devices for whatever reason. I tend to design my programs, as much as possible, without reference to individual devices. So long as my scenes are up-to-date, I generally don’t have to change programs when a different device s introduced.

First, given your requirements, I don't believe that there can be a scene relationship between the motion sensor and switch. Make sure that there is none. I think lilyoyo1 has found good method. Use the manual toggle of the switch (on) to disable the motion program. Use the manual toggle of the switch (off) to re-enable the program (after five-second wait). if control switch is turned on and control switch is not turned off then disable motion sensor program else wait 5 seconds enable motion sensor program Then, use a program to control response to motion sensor if control motion sensor is switched ON then turn on bathroom light wait some nominal period of time turn off bathroom light (note...this motion program will retrigger every time motion is sensed. So long that the retrigger is within the wait period, it will restart the wait clock. Also note, it may be useful for you end-of-day cleanup program to re-enable the motion program, should someone leave the light on overnight.)

My recommendation is to think through your requirements before programming. Programming is a lot easier when you know what you are trying to accomplish. It sounds as if you have a single motion detector and a single light switch, correct? - what do you want to happen when motion is detected? -what do you want to happen when you manually toggle the switch on? Off? -do you want thelights to turn on and off automaticaly? When and under what conditions do you want the lights to turn off?

Perhaps you could get by with a single program, but it may depend on for how long you want the fan to stay off when manually toggled...until the next temperature cycle to exceed 90?..next day?...indefinitely? Also, why do you care whether the fan is off (or on low) as a decision factor? If it is hot, turn on the fan!

There is no way to use a scene status to trigger anything. The theory is that there is no such thing (or at least a consensus on what constitutes) scene status, on or off. For this, I pick a few key members of a scene and use those as indicators that a scene is on. To be clear, this is true only if there are wait states or repeats in the program. Otherwise, the program continues to completion. i tend to do things much like lilyoy1...if I have an event that I want to supersede the motion sensor, then I disable the motion program. This likely requires all motion events to be program-driven rather than scene-driven...it is not easy to tell a scene responder to stop being so.

No programs running at the time of the opening garage door? Hmmm. I would certainly look at scenes per paulbates suggestion. Click on the IOLinc relay from the admin panel and see if is unexpectedly part of a scene. I suppose you could remove the IOLinc from the ISY and perform a factory reset. Before adding it back, observe if the door stops opening by itself. If door continues self-opening, it sounds as if you have external factors in play. If door ceases the uncommanded opening, add it back to the ISY (not adding it to any scenes or programs) and see if the door start the uncommanded actions. If so, this points to some interaction between the two. If not, add it back to your scenes. Continue this process until the problem appears again or, better yet, this solves the problem. If it happens regularly at a predictable time, open the event viewer and watch for clues at that time. Or, if you know when it happened, check the logs for insteon commands (not just programs) at the times when the door opens. I assume, also, that you are not experiencing everything turning on...just the GDO. Correct? I was wondering aloud whether you are seeing the results of one of those ALL-ON issues.

I do not think anything has change in the new 5.x software here. a "status" condition would trigger upon any CHANGE in status, whether from ON>>>OFF or OFF>>>ON and would trigger both THEN and ELSE actions. I believe this is true in software v4x and v5x. "Control" conditions, however, would require the "not" condition in order to cover both ON and OFF commands. All the confusion I have noticed over the years is in regards to the "control" conditions.

If this program is running true regardless of KPL-B status, I would consider the possibility that the ISY is not seeing the actual status of this keypad. This program should run true only when the motion sensor is switched off and KPL-B is OFF at that time. If something else is happening, I do not see this as a program problem.

Yes, you used parentheses around BOTH. The difference is that the first program has no "or" conditions. Consider the following logical statement: "I will go to bed when I get home and lock the doors or when I get to a hotel". What conditions must be met in order for this to be true (to go to bed)? Either: 1) go home and lock the doors, or 2) get to a hotel. If "go home" is condition A, "locking the doors" is condition B, and "finding a hotel" is condition C, this would be written as: A and B or C. Do you remember math from elementary school? The results of 3x2+4 are different than 3x(2+4), right? The same is true in logic...A and B or C has different results than A and (B or C). This is mostly true. For the second code to be true, either 1) $Int_1 must equal 1 and it must be between sunset and sunrise and side sensor is switched on or 2) patio sensor is switched on or 3) west gate sensor is switched on I have little doubt that Larryllix has found your solution