oberkc

I even claim to read the manuals and did not catch that one.

I did not know that. Cool.

Sorry. My mind immediately goes to an IOLinc when I think of garage doors. I am sure that I started the confusion with Techman also. This tends to suggest to me that your original program was that, for whatever reason, your ISY was not seeing the status of the open/close sensor. I do not believe it was a program problem. The other's "4-tap" suggestions were intended to further confirm this problems, but I see no indication that you attempted this step. I am not even sure how one does this. The open/close sensor is a battery device, with no wires attached. How did you "wired them in series"?

In addition to my earlier post, make sure these switches are in no scene relationships.

Quite contrary. I can tell you categorically that triggering a switch via program THEN clause CAN cause another program to trigger (and run). For example...a program such as: if time is sunset then turn on light will cause this program to trigger (if light was previously off): if status of light is on then do something I am like many of the others...my gut reaction is that you have a lot of unneeded complications and I am having trouble mustering the ambition to try to follow the threads. Still, from an intellectual (and potentially practical) excercise, assuming you don't mind lights making several transitions to their end state, I see no reason why your objective cannot be accomplished. I am ignoring the complications and possible error handling associated with insteon communication errors and treating this purely as an ISY programming excercise. I am also ignoring any timing issues or wait conditions. (I have never had much need for these, personally, but would address only if needed for a specific application.) To start, I would summarize your goal: Upon each manually-triggered ON command from switch1, you want it to progress through the following states (switch1/switch2): off/off (I will call this state 0) on/off (I will call this state 1) off/on (I will call this state 2) on/on (I will call this state 3, but no program is needed to track. State will be assumed condition if states 0,1, and 2 are all false) back to off/off (back to state 0) Additionally, if switch1 is manually-triggered OFF, you want switch1 and switch2 to turn off, regardless of original state. My initial inclination is to use a version of your state machine to track which state (0, 1, 2, or 3) your two lights are in. One could use variables here if it helps visualize things easier, but I tend to avoid variables except where I can think of no practical alternative. Make three programs, one each for states 0, 1, and 2. No program is needed for state 3, since it can be tracked based upon the other three states being all false. An exampl program for state 0: if status switch1 is off and status switch2 is off then nothing else nothing I would create three such programs, one for each of the first three states, planning to use program=true/false as a later program condition. One advantage to this method is that this will accurately keep track of status regardless of how arrived (for example, what happens when someone presses switch 2, even if accidentally?) I know that I want to trigger a lighting state change only upon ON commands from switch1. I also know that I want both lights to go off when switch1 sends an OFF command. I would deal with this as follows: if control switch1 is turned ON and control switch1 is not turned OFF then run next program (if path) else turn both lights off For the next program(s) I would create a series of programs checking the current state and taking the appropriate reaction. All of these programs should be disabled, so that they do not self trigger. Next program (disabled) if state0 program is true then turn on switch1 (switch2 is already off, by definition) else run nextA program (if path) nextA program if state1 program is true then turn off switch1 turn on switch2 else run nextB program (if path) nextB program: if state2 program is true then turn on switch1 (switch 2 is already on) else turn off switch1 (if I have gotten this far and states 0, 1, and 2 have all been false, then it must have been in state three, thus next step is turn off both lights) turn off switch2 Hopefully, this gives you some ideas to consider and possible things to look for in your own programs to get them to work. Given your line of questions thus far, it may only be necessary to disable some of your programs to get everything to work. As is often the case, I make no attempt to be efficient at programming or minimizing numbers of programs or lines of code. With a little extra thought this could be reduced significantly, I suspect.

Reboot everything?

Larrylix, In the original post, it was stated: "no programs, just two scenes". Assuming this is true, the only explanations that are coming to my mind are very unlikely. Device failure? Sensor wired to relay terminals accidentally? Failure of garage door safety sensors? Were this me, I would be breaking this down in pieces, performing experiments, looking for clues. Does the IOLinc LED light come on with the door opened or closed? Does this remain consistent after a power failure? Does the ISY always show correct status for sensor? If I temporarily disconnect the sensor then simulate a power failure, do I see the same result? If I temporarily disconnect the relay then simulate a power failure do I see the same result? Do any programs activate after a simulated power failure? After power failure, do any programs activate when I close the door? Perhaps there could be something discovered to point in a certain direction.

I might differ from stusviews here. Status condition should trigger else clause. Check status of sensor from admin console to be sure ISY is seeing changed status. Is iokinc plugged into same outlet as opener?

Be sure, also, to configure mini remote to 8 scene version. (It can be configured in 4 scene, which would require different buttons Robin versus off.)

The door automatically opens if you close it, always?! Or just opens after power restored? I wonder if, upon power restoration, there is some form of a query and one of the device status changes, causing some chain-reaction from the scene. I cannot imagine what would cause your doors to open after you trigger them closed. Are your keypad buttons in non-toggle mode?

Our posts crossed in the mail. I suspect that your original program would work if disabled.

I tend to agree with MWareman. One thing that could make it work would be to disable the program, then trigger it externally when you want it to start. Disabling the program will avoid having the program trigger itself upon temperature changes.

Larryllix, Even better. I like it.

May take multiple programs. My quick, brute-force approach, without much thought: If time is sunset -30 minutes then run second program (if path) else nothing second program (disabled) if time is from 5:00 until 11:59 <<<pick time after latest sunset in your area then turn lights on else enable third program third program (disabled) if time is 5:00 then turn lights on disable third program

Not that I remember. Replace, yes. Copy, don't think so. Maybe someone else knows different.

18 separate dimmers!!!??? Wow. Yes, that can take a little time to get all the details properly input.

Only one scene is needed, should you choose to take my earlier advice.

I cannot imagine why not. Sounds like a simple program... If Status can lights not 100% Then Turn off led light Else Turn on led light You would need to take the led our of the scene, also

AnthemAVM, I am not sure whether you ever received feedback regarding your specific questuob about your program. In my mind, I would change it in two ways. First, disable the second program. Second, I would eliminate the second condition of the second program. I also assume your motion sensor is configured to send both ON and OFF commands

Nickp, I really appreciate the fact that you are trying to figure out WHAT you want to do before figuring out HOW to do it. I think this is a critical step often missed, especially critical as things get more complicated. Some alternatives for your consideration: FASTON (double-tap) could turn on lights and disable motion program FASTOFF could turn off lights and enable motion program A program triggered each morning which re-enables the motion program, in case it was forgotten from the prior night's activities Use the beep function to confirm disabled motion programs or Tapping ON when the lights are already on could disable the motion program, or extend the timer perior Tapping OFF when the lights are already off could re-enable motion

I would actually do this with a single scene. How many dimmers do you have? Is each of the 18 lights connected to a dimmer? Assuming I understand what you want to happen.... -first configure buttons A-D as non-toggle-ON. -create a single scene with Main and A-D buttons as controllers and the dimmer(s) as responder. -for each of the five controllers in the scene, set the dimmer ON levels (full, 50%, etc...) you want to associate to that particular controller button. - for each of the five controllers in the scene, set the ON level of the other four buttons at zero. Understand that, for the main button, one (either ON or OFF) will be lit always. WDoes it make sense for the OFF button to be lit when one of your A-D buttons is on, or does it make more sense for the ON button.to be lit? Give it a shot!

My impressions, for what it is worth, is that there are very few controllers that control "everything". Furthermore, the ability to control some of those things will depend greatly on the amount of work you are willing and able to devote to this. It will also depend on access to some cloud services. I am mostly familiar with insteon, though I use some z-wave, some hue, sonos, and some LED strip lights I purchased from home depot (IR controlled). Since you want to control some insteon devices, this already limits your options to the ISY, hub, vera, homeseer, things like that. Smart things will not control insteon, to my knowledge. Smart things MAY talk to the insteon hub, but I seriously doubt that this option would have the conditional logic you appear to seek. Furthermore, your intentions with conditional logic tends to eliminate some of the typical controllers you might find at home depot or lowes or best buy. My best guess, without doing a lot of research, is that the ISY is likely one of the few that can talk to most of those devices, but for many the support is not native, and that there is not a small amount of programming and configuring and experimenting and other hardware gateways that will be needed. Unfortunately, it seems you have already purchased these devices, so the next point is moot (but I will say it anyhow). If I were starting fresh, I would start with the controller. I would pick a controller based upon its power with logical conditions and flexibility and the variety of devices with which it can speak, and with consideration of whether I am willing to rely on cloud services for core functionality. Once picked, I would then limit my specific devices to those that are compatible with my chosen controller. My choice, based on that approach, would be the ISY-994.

I am not sure that variables offer any efficiencies here, and possibly even increasing the number of programs required. It seems to me that it will take multiple programs with, or without, variables. Without thinking too hard, I suspect you are stuck with DxC programs, where D = number of doors, and C = number of codes. One thing that I have not experimented much, however, is with is customized notifications. I understand that you can use variables to customize your notification where it is potentially possible to have a single program for each door, something like: if door is unlocked then send notifications Where the notification would be different, depending on which code is used to unlock the door. You would not have to create separate notifications for each code. Perhaps this gives you an idea where to look? Edit: Looking a little further, check out the wiki "substitution variables": http://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables&redirect=no Look into user variables. I suspect that if you could use a variable value associated for each lock code, then use that variable to customize a notification, rather than create multiple notifications.

I agree. I don't think it is a program problem. For some reason, I expect the ISY is not seeing an accurate status of all your devices. When you find the KPL is not OFF when you expect, I would go into the admin console and see if the ISY thinks one of your trigger devices is ON when, in fact, it is OFF.

I have never seen a problem with that approach. Yes, maybe you are sending out an occasional unnecessary OFF command, but is there really any harm in this? In exchange, you get improved simplicity and reliability. I use this method every day, and it is well worth the trade, in my estimation. Still, I, too, am curious about your original programs. Were this me, I would be watching the kitchen dim program to make sure it is TRUE and FALSE when you expect. I missed where you described the devices that are in scene "kitchen dim", so I can only assume there could be something in there that may be triggering some of your programs unexpectedly.