oberkc

With the ISY, a controller device is, by default, a responder device also. Given this, if something turned off the room scene, I would expect button D to be off, since it is part (controller, you say) of the room scene. Did you use the ISY to create these scenes, or did you do it manually via the devices set buttons?

I think I am loosing track of your scenes. You say something turns off the "room" scene, but "toggleD" scene is still on? I don't see how both can be true. If the "room" scene includes all all three lamp modules, button D, and the main button, would not turning off the room scene, by default, turn off the toggleD scene also?

In my mind, best approach is to use an ISY program to control the timing function and when to reset. It is much more flexible.

I think it might be something a little different. I understand that, in "sense" mode, the motion sensor will send ON commands at each detect, regardless of the timer. I am a little fuzzy about the effect of the timer, but assume that the internal timer would be also reset. If you don't want the ON command sent until after the timeout, then you do NOT want it in "sense" mode.

Sachelis, of course I agree with the concerns expressed about stealing neutrals fro other circuits. It is my hope that, were you to find the cable that was originally connected to the "elsewhere" wire, you would find a white wire bundled together with the black wire connected to "elsewhere".. This is the neutral that you should use. If such a white wire is not there, be careful. Sometimes wires can get connected together and this can be hard to identify.

If I had to guess based upon the diagram, I would say that the B cable is to the fixture, and the "elsewhere" wire is connected to a line supply cable somewhere in the back of the box. Black B is connected to common screw, as is black C. In other words...hot into black A to switch2, red/white are travelers back to switch1 and switch1 common to load. No? Is the white wire from B connected to a white bundle in the box somewhere?

Quick plug for tasker here, also. Between that and widgets and access to the file system, I cannot imagine why I would go iOS. (Now...If I can only figure out what to do with those iPads I own.) Regarding the original request, is it even possible that Alexa (or something similar) can be trained to recognize the alarm sound from an iPhone?

I am glad you have it working. I did not look too hard at Gary's suggested program but, after only a quick glance, I wonder why the second program would not retrigger the first program once the 5min wait is over and the status of 'garage entry' changes from ON to OFF? If all continues to work...Great. if you later find some unexpected, we can look a little harder.

I also don't think it helps that smarthomes' definition of "scenes" has morphed over the years. My impressions are that they are now using "links" and "groups".

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.