oberkc

Yes, I realize these things. The quoted problem was that the keypad button (on and off only, as you remind us) was not ON. I was relating that to a toggleinc (also, only on and off). Perhaps I miss your point.

Another possibility I recall...at what point is a keypad button "on"? 20%? Anything over 1%? I recall a similar situation at my house where I was using a togglelinc relay as a scene controller. I had come to believe that the togglelinc relay would show ON only as the responding device reached about 50%. Clearly I am speculating at this point, but it may be worthiwhile considering that possibility.

Cqn you not include the kpl in the echo group?

It certainly was a good reminder that we could no longer assume that everything is insteon, and that there are more ways to control a garage door than the iolinc.

To elaborate on Gary Funks's response, one must understand what "events" will drive program evaluation. Your original program would be driven by garage doors changing status (from open to close and vice versa). In addition, it would have driven (or triggered) at sunset and at sunrise, and at change of status of the entry door. At each triggered event, the condition is evaluated and appropriate path (then or else) taken. If it were triggered during a 5min wait, the wait would have been halted and the new path taken. Most likely your program was triggered during a wait, evaluated false, and executed the THEN path (which is nothing). In addition to Gary Funks suggested approach, you might also consider using a CONTROL condition, rather than STATUS. CONTROL ON condition will only trigger upon receipt of an ON command, whereas STATUS condition will trigger upon any change of state. Another feature of CONTROL conditions is that they are only TRUE when triggered. At all other times, they will evaluate false. STATUS conditions evaluate false any time evaluated and the expected condition (ON or OFF) exists. One problem you may run into with status is that your program will also trigger by sunrise and when triggered at that time with the garage door opened, it will trigger the porch light program. I assume you do not want this to happen.

Deuce, Sensing mode MAY help but I consider it unlikely to be the root of your problems. In addition to the parentheses, I recommend use of CONTROL rather than STATUS for your two program conditions. You also have a potential problem at 11:29pm if your program is in the wait state. Make sure your motion sensors are NOT in a scene controlling the lights. Do you want to turn the lights off after wait timeout, or dim?

I can tell you that I have several wall switches that, when toggled from off to on, will go to the defined on level rather than last known state. As I read the manual for the "insteon wall switch", I see that they have different modes, including a "resume dim" feature that can be selected or not. It sounds to me as if your switch is in this mode. I do not recall whether this setting is configurable from the ISY admin panel, but would be surprised if not. Regardless, it appears that you can get the behavior you desire by reconfiguring a switch setting.

To/from conditions will trigger twice (and only twice)...once at from-time and once at to-time. It will evaluate TRUE at all times between those two point in time, and false at all other times. Your specific program will simply turn the lights ON at early evening and OFF later at night. I believe you misunderstand how this program will work. Your program will NOT turn your lights off in the middle of the day, nor will it turn the back on after the initial trigger (should you manually turn them off early). Your program will simply turn them on once and off once.

For this to happen, you must select (click on) each of the controller devices within the Scene "Living Room Main" and check for the same settings as the scene: 8 button dimmer button 1 (LOAD)(Controller) ::Set for on=75% ramp rate=4.5 paddle switch 1 (Controller) ::Set for on=75% ramp rate=4.5 paddle switch 2 (Controller) ::Set for on=75% ramp rate=4.5 8 button dimmer button 2 (Responder) ::Set for on=0% ramp rate=0 Make sure you select the "button 2" of the "movie scene" and ensure the responder settings are consistent with the scene settings. It seems to me that you have the scenes set up correctly. No, I do not think your problems have anything to do with the way the ISY handles scenes, and I believe what you want to happen can, and should, be done with scenes only. No programs needed. The only way that I know of for the ISY to actually change scene responder levels is via a program. Please make sure you don't have unexpected program responses to pressing of any of those buttons or paddles. If you are unsure how to check this, let us know.

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.