oberkc

I am with LeeG on this one. You are fighting the core design of insteon here. Furthermore, creating a program to perform a scene function will introduce a lot of opportunities to enter these endless programming loops (as you have experienced). In addition to all that, introducing mobilinc into the equation eliminates the use of "control" as a program condition (I believe control conditions work only when a device is physically activated). If you want to control the scene with mobilinc, control the scene rather than individual devices within the scene, even if those individual devices are defined as "controllers". Remember, scene controllers behave as controllers only when directly activated (button press). They behave as responders when commanded externally, such as via the ISY or via moblinc. Everything you describe makes me think your system is operating properly.

This is because such devices are set up as "controllers" of a scene with those other devices. However, when controlled via a program or admin panel, the behaviour better matches that of a "responder" device. Perhaps a good hypothetical analogy would be if switch A is controller of a scene including switch B as responder. Switch B is controller of a scene that includes switch C as responder. Pressing switch A will turn on switch B, but switch B, having responded to switch A, will not turn on switch C. Only if one physically presses switch B will it behave as a controller of switch C. In the same way, if you "remotely" control a switch (via program, control panel, other insteon device), it will behave only as a responder and not propogate commands to other devices of which it is controller.

By definition, controllers are always responders when creating a scene with the ISY. For multi-way "circuits", all switches should be in a single scene, all as controllers.

Perhaps I am missing the question. Are you asking whether you can turn off the mechanical switch on a lamp and somehow have insteon turn it on later? I believe the answer to this is "no". If the lamp switch is off, there is nothing that you can do with insteon to turn the lamp on. Neither do I believe that you can cycle the lamp switch (on>off>on) and have insteon detect this (the insteon module will remain on). My suggestion is to install a switch at the room exits and link it to all your lamps. Use inteon to turn them off when you leave the room.

I suspect the problem you are experiencing is due to the insteon feature that enables different ramp rates and levels to be established for the local (switch) setting or when called up as part of a scene. I suspect that if you select the local switch from the admin panel, the "on" level remains 100%, but if you select the scene that includes the switch, the ramp rates and levels for that same switch are different. Your program changes ramp rates and levels for the scene, but leave unchanged the ramp rates and levels for the local device. Unfortunately, when you control the switch manually, the local ramp rates and levels apply, not the scene settings. You could change the local ramp rates and on levels in the program. Unfortunately, I cannot offer the exact language (not at my ISY and don't have it memorized). If another does not offer a suggestion soon, I will get back here when I am near my computer.

No, not normal based on my experience and expectations. My experience is that all buttons operate independent of each other unless specifically configured otherwise. Is it possible that you have inadvertently configured your keypad with some type of button grouping?

I found the manual to be a little confusing in this area. Regarding wire combinations, you should use the ground wire and one of the other two. One will turn the sensor on when closed, the other will turn the sensor on when open (NC, NO). So long that you understand what is happening, you can program the IOLinc and ISY to work properly. Mine is wired in such a way that the IOLinc is "on" (LED lit) when the garage door is open. I include the sensor in a scene with a keypad button which results in the keypad button being on when the door is open. Given this, opening the door transmits an "on" signal, closing the door transmits an "off" signal. If one prefers to set it up such that closing the door sends an "on" command and opening sends an "on", reverse the wires (or change the location of the IOLinc). I found the garage kit to be a relatively complicated insteon setup, with relay wiring and location affecting IOLinc configuration, scenes, programs, etc. There is no single right way to set this up, and all have to work in harmony. This is a case where understanding the how's and why's and what's-going-ons really helps.

Yes. I solved it by replacing the leviton switches with insteon.

To add to LeeG's post, sensors can only be controllers. They cannot be responders. Unlike LeeG, I fail to see the harm in maintaining a scene with the two switches as responders (just remove the sensor). However, since they are already "linked", then there is no need to create a second scene. You did "link" them by creating an ISY scene with both as controllers, correct? The momentary time defines how long the relay is activated, not a delay. To program a delay after the door closes, use an ISY program such as: if Status 'IOLinc-Sensor' is On then set "link scene" on else wait 5 minutes set "link scene" off

LeeG is nearly 100% correct with his responses, so I cannot help but wonder if there is a failure of communication here. Are you sending "on" and "off" commands to the IOLinc, or to a scene that includes the IOLinc?

To elaborate a bit more, please describe which device you wish to use to control the door and which device, if any, you wish to use to display the status, and how you want that status displayed (on = open or closed?). There is a nice explanation in the universal devices wiki. Search on "garage". This is the approach I used.

These kinds of things are usually available with a simple google search. I tried "rogers cell phone email to text" and quickly found: 10-digit cell phone number @ pcs.rogers.com Give it a try. Hopefully this will work for you.

Try: * Sasktel: [10-digit phone number]@sms.sasktel.com

I suspect that when the "then" clause runs, it turns the torchier light on, which changes the program condition to false, halting the "then" cluase and forcing execution of the "else" clause.

Given that your ISY is not in the same room as the TV, and assuming your remote is IR, I would use an IRLinc. You can find these on the smarthome website.

This can be done with a scene. Create a scene with keypad button D as controller and 4 switches as reponder. This requires a program. You will also have to create a second scene with only button D (as responder). The program : if status 'light A' is on or status 'light B' is on or etc.... then set "scene with only button D' on else set "scene with only button D' off This sounds like the same request as the first. The scene, above, will take care of this.

As LeeG states, a single controller cannot control more than one scene. Given your subject "all off switch", I had assumed that you wanted a switch (or multiple switches) that turns ALL your lights off. Create a single "scene" that includes ALL your lights. In that same scene, include the button or switches that you want to use to turn off ALL your lights. The lights would be added to the single scene as responder devices. The buttons and/or switches would be to the same, single scene as controller devices. If you want to use the same button to turn off ALL your lights AND turn on SOME of your lights, that would constitute 2 scenes, one scene has ALL your lights, the second scene has SOME of your lights. Unfortunately, a controller can be a controller only of one scene (by design). Therefore, you cannot use the same button or switch as controller of both scenes. An ISY program may offer a solution, but I think I would get the concept of scenes and controllers and responders straight before I would worry about programs.

All controllers and responders should be in the scene. Controllers would be the devices that you want to touch in order to turn the lights off...a switch...a button. If I understand correctly, this would be the "It would be 3 switches and some other buttons on 2 key pads". Responders would be the devices that you want to respond to controllers....light fixtures, lamp modules, inlinelincs, ...

Found in the user guide: 5 - 30 VDC User guide: http://www.universal-devices.com/docs/isy99_userguide.pdf

Good point. I must admit that this thought did not cross my mind.

I was questioning the second "condition": Status 'alanas bedroom' is not off. I don't see the value in this condition.

While I suspect this is not part of the problem, why not remove the second condition? It seems unecessary, but could be triggering a second evaluation when the then path runs. It also makes the proper execution contingent upon accurate communication of device status. Otherwise the program appears fine to me. Regardless, it is my impressions that programs dont simply stop working. Something else has changed. In what way is you program not working? Is the light not going off? Failure to notify? Keypad button.? All?

I use only conductor, but I like the widgets that are available. If widgets are important to you, make sure that the app you select has them.

I wonder if changing your KPL button mode to non-toggle ON would be one part of the solution. The second part would be to crate the mentioned keypad-controlling scene, then add a program step to the "fan off" and "hi-off" programs to turn the keypad scene off when the fan is off.

It has been my experience that the http://procedureof editing, or the fact that a program was edited, is not a cause of program failure. In other words, I do not believe that it is possible to create an otherwise-functioning program that fails because the wrong editing "procedure" was used. Rather, the failure of a program to behave as one expects is generally the result of the way program conditions and commands work being different that what one believes they do, or should, work. I second LeeGs suggestion to post your program and, perhaps, the fine folks around here could help identify the problem.