oberkc

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

Well, I would have to assume that something triggered your program "garage lights on" (then path) at 8:30. Twenty minutes later, the lights would turn off, as programmed. Given your first program, the only way (from the programs you have shown) that this could happen is that , at 8:30pm, $int_1=1, sunset has already occurred, and someone must have triggered the driveway sensor. The value of $int_1 at 8:50 is irrelevant. You likely have a misplaced parentheses. Why do you bracket the entire condition in parentheses? Given the way it is currently written, "rear motions active" will be true any time that "patio" or "west gate" sensors are triggered, regardless of the state of the variable, sunset or sunrise, or how much daylight there is.

Personally, I don't think the order matters in this case. Your conditions were joined by "and", so all must be true. Order should not matter. I can see some cases, where one is not careful with "or" and parentheses, where order of commands could matter, but not here.

There is no limitation that I am aware that would keep you from doing this. I also believe that this must be done via programs. I am with lilyoyo1 on this. Logically, you want HHPD to be on if either of the other two buttons are on, and you want HHPD off if both of the other two buttons are off. The program would look something like if status HH is on or status PD is on then set HHPD on else set HHPD off

Probably a good rule-of-thumb, but I am not ready to say "never". Still, I don't think that is the problem here. My argument typically is the condition side of things: in most cases, I don't see a strong reason to check that a light is off before turning it on. I see little harm in turning on a light that is already on, but a higher potential of unintended consequences by insisting checking that the light is off before turning it on. In the case of proj964' program, I would simply eliminate the middle condition if I feared that the program is halting execution due to the condition flipping back to false.

I agree with statements 1) and 2). I am not sure about statement 3). My understanding is that the THEN actions would continue to completion UNLESS there was a WAIT or REPEAT action within. Since there is no wait or repeat, I expect that this program would complete the entire THEN clause, even though the condition was retriggered and is now false. I also agree that it is the upper pane that represents your program as it exists, and that I would not be concerned with the lower pane. What I don't understand is why it would, without any apparent user interaction, change a condition from "is off" to "is 100%".

I am out of ideas. I have not seen a program change itself like this.

Unfortunately, I don't use 4.X software any more, and cannot compare it to what I see on my admin panel. I recall ON and OFF program options for relay devices, not percentages, but my memory could be faulty.

Is it a dimmer or relay? I cannot help but wonder what would happen if you remove it again, then add it by putting the ISY into linking mode, then putting the switch into linking mode.

Out of curiosity, how did you initially add this switch to the ISY? What device does the ISY think it is? Is it possible that the ISY thinks is something different that what it actually is? (It is just a hunch, but I wonder if this is a possible cause of the behavior you describe.)

to set the responder levels for the remote, make sure you have selected the controlling remote button in you device list. responder levels can be different for each controller.

The problem is not because the variable remains equal to 1. The problem is more likely because, when the program turns on the light, the condition suddenly becomes false and interrupts the WAIT action. (There are also a couple of other potential problems.) A simple solution is to remove the second line from the condition. The solution I would choose is to break this into two programs. The first program would keep the existing condition, but change the THEN action to do nothing more than call the second program. The second program would have no conditions, but would have the THEN actions from the original program.

Not sure there is a “best” way. You could use a program. Lilyoyo1 points out an advantage of this approach. You could use scenes (may be a little faster and will still work should the ISY fail for some reason). Bringing the echo into the mix creates additional considerations. I expect you would need something like the portal account, or mobilinc cloud account added to your ISY. You could then configure alexa to run a program or turn on a scene.

There is. I recall it available from the right-click on the device>>>show links. This reads the links directly from the device. Once shown, you would have an option to "compare" to the ISY records. They should match.

While this is not necessarily consistent with your clues, I would certainly look at the scene definition a little closer. (I assume you are on v4.X software, so I am having a little trouble remembering the details of the admin page, compared to v5.0 software.) Please confirm: - that the fanlinc button "kit east fan high" is defined as a "controller" in the scene. (I cannot tell for certain from your screen shot.) - that the fanlinc button "kit east fan high" attributes is full on when tapped. Is it possible that this button is commanded to turn to zero when toggled ON? - that there is no program that is triggered by this "kit east fan high" button which might explain this odd behavior I am also curious what happens when you command this scene to turn on from the admin console versus the button. Do you get the same results? Yes, there might be comms issues, but I am having trouble understanding why a comms issue would turn the fan OFF if scene definitions are correct. You could try showing a list of the links in this device and comparing it to the ISY records. If they don't match, try restoring it.

More likely (in my mind, at least) is that the query caused the sensor to report its status. The sensor cannot be a scene responder and cannot be controlled by anY other insteon device. Besides, absent a program or scene somewhere, the sensor, itself, would not cause the door to open. (You dont have the opener connected to the sensor inputs, do you?). I also remain curious about the answer to BrianH question about sensor reverse setting.

For what it is worth, I don't think the "sensor" can be turned on or off by the ISY, or by any other controller. The "relay", however, is a different story. Do you have a program that is triggered by a change of state by the sensor?

I don't know why it would not be possible. It should be the same as your working program, except that you have two actions rather than one, since you have two responders (assumed two nightstand lights) rather than one. If you want to include the mini remote, you would have four actions: two responders to the switch and two responders to the remote. Exact syntax would depend on whether you are on v4.X or v5.X firmware. Like Kclenden says, there are a lot of assumptions here since you provide so few details. Number of devices involved (one switch, one remote. Outlets? Modules?)??? Scene composition? Post of working program? Post of failed program? Are you saving changes to your programs?

I also wonder same thing as Goose66. Using "or" would result in lights off if PS4 is off, yet TV still on. In my mind, all devices should be off to declare basement unoccupied. Were this me, I would skip the parentheses and join each condition with AND

The parentheses option is lower-right of the main admin window, I recall from memory. Once there, move lines up or down as needed to group items within the parentheses.

I am unsure how you know the various games and TVs are on or not, but the logic is just as you have it. Use parentheses before first OR and after last.