oberkc

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.

Sorry that I was not clear. I was not questioning the logic of WHY you are trying to do it...I intended to suggest thinking a little deeper about the logic of HOW you want to do it. Specifically, HOW do you want to determine whether a room is occupied versus simply passing through. What are your thoughts on this? Motion sensed every minute? Every two minutes? What constitutes "occupied" in your mind. To me, and assuming that all I have is a motion sensor, I would tend to assume that occupied would be based upon regular motion triggers at some time period (and I will assume at least once per minute in this example). To continue to the next stage, I would also reverse the order of your thought process. Rather than thinking in terms of motion triggering a 5 minute wait, then (if "occupied") turn the fan on, what about first determining whether the room is occupied, then (after five minutes of occupation) turning the fan on. Does that change things? Does this give you any ideas? Were this me, I would probably write a program that runs true when occupied and false when not. Assuming an occupied state would trigger a motion detection every minute or less, an "occupied" program could be something like: if control motion sensor is switched on then wait one minute run this program (else path) else nothing If there are detections before a minute wait period, the program will re-trigger and start the countdown again. After a minute of no motion detections, this program would run the ELSE path (and be false). So long that motion is detected at least once per minute, this program remains true (THEN path running) the room is treated as occupied. Given this first program, create a second program to wait for the 5-minute period to start the fan. How about something like: if status "occupied" program is TRUE then wait 5 minutes turn on fan else turn off fan I have not tried this, so you may have to experiment with the correct program steps and syntax, but I hope the logic is clear. Of course, this all assumes that an "occupied" room will cause regular motion hits, which may not be true if someone is simply taking a nap or otherwise not moving around too much. But given the assumption that all you have is a motion sensor, you may have to live with that limitation.

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.