oberkc

How confident that the motion sensor becomes "violated" when Bristol goes out? Is it possible that the third program fails to run at times because of this inconsistency? Why set the bristol variable to zero after five minutes (second program)? Why not wait until the door is violated (third program)? If the dog is out more than five minutes, what happens? (lights go off?) In general, I suspect it is going to be difficult to keep the variable synced with reality. Might not this program get triggered by someone other than the dog entering or leaving? What happens when the dog is out before sunset, but comes in after?

Well, for my purposes, I have really needed no variables of any kind. I have tried a few examples, but could have accomplished the same thing without them. Others, however, have made extensive use of them to solve problems that cannot otherwise be accomplished. As a minimum, they offer flexibility and options. Perhaps you will never need variables or that your needs are simple like mine. In your case, it may make no difference whether they trigger or not.

Have you checked out the entire forum on "variables"? Check here: viewforum.php?f=68 As for me, I use a variable as a condition for whether I run a motion program. If I turn on a light manually, this sets a variable that keeps my motion sensor program for running. If it were the type of variable where the variable itself triggered the program, then it would trigger the timer each time manually turned it on. This is NOT what I want.

From the wiki: http://wiki.universal-devices.com/index ... _Variables About state variables, it says: "Identical to an Integer variable except that changes to the value do cause an event to be sent, causing programs to run" This sounds a lot like a "yes" to me, in response to your question. If you change it to a state variable, make sure you check how this might affect any other programs that use this variable as a condition.

To the good points made by Brian H, I opine that I have never been happy with the performance of any dimmable CFL that I have tried.

"Manual Overide" was my generic term for whatever method you choose to manually turn on the fan and check for this condition, whether a program, variable, or other method. it seems to me that if you found a method that you liked with your motion sensor problem (you chose to define a variable for this did you not?), you would duplicate that method here.

That approach will work with a motion sensor. The motion sensor will need to be configured to send an OFF command, and the time-out period set, but otherwise that will work. I cannot say how the temperature condition will react or trigger (don't use the climate capability). This is similar to your vacation/guest problem earlier, with the difference that your fan goes off not after a preset time, but when motion is no longer sensed or the temperature drops below a certain value. I would use the same concepts to define a manual override condition. Then, create a couple of programs (conceptual syntax): if temperature is over 80 and control motion sensor is on <<then turn fan on if ( temperature is below 80 or control motion sensor is turned off ) and manual override is not on then turn fan off

I still believe you can either run additional cables, or opt for a two-device approach...an inlinelinc at the fixture and an insteon switch to replace the existing switch. Pick which option is best for you. If material cost is the primary concern, I suspect the additional wire would be cheaper.

There may be other options, but depends on: a) are these switches in a common box, or all separate boxes? are these switches on the same circuit? One option that is near univerally available is to install an inlinelinc at the fixture and insteon switch at the wall. This option requires re-purposing of conductors to provide hot and neutral at the switch location, so the ability to identify and work with wiring helps a bit. Of course, there is the added cost of the additional device, but that is often a better option than rewiring.

. With this, I agree. I like program folders, especially when one has multiple programs based on identical conditions. I have several such folders, including: home away guest winter summer (I could see uses for others, such as weekends, weekdays, night, day, etc...) In each of these folders I have multiple programs governing interior and exterior lighting and device control. When one has only a single program predicated on this type of condition, the use of folders may not offer a lot of advantage.

I am only superfically aware of how harmony remotes work. I believe that they have an inherent X-10 capability. If you can incorporate an X-10 device into your bluray activity, you have the option to make use of an X-10 IR reciever and use this to trigger a scene via ISY program. Another factor is what version of ISY do you have and where is it located. Is yours a version with IR reciever? Is it near the TV? If yes to both, you could configure it to recognize the specific IR command you wish to use to trigger a lighting scene. If none of the above, you could go with an insteon IRLinc and program the ISY to recognize the specific harmony command (via IRLinc) you wish to use to trigger a scene.

I don't think that variables are inherently easier in this regard. Program status (true/false) can also be a folder condition.

That is what the program "does" or that is what the program "is supposed to do, but doesn't"? This is what I suspected...that you put the last condition as an override, but THEN and ELSE paths both have the timer. So it is not currently working as you hoped. What I am concerned is happening, then, is that something (motion, zone vioation, etc) triggers your program, which causes THEN to run, which turn on the scene that includes the "back CFL floods", which forces a re-evaluation due to the status change of the "back CFL floods", which halts the THEN path and runs the else path, which (after ten minutes) turns off the scene that includes the "back CFL floods", which forces another program evaluation, which again runs the else path, which turns off the scene that is already off. I think you will need to completely abandon this program and start fresh. First thing is to establish how you want to initiate guest status. Is this a keypad button? Switch? Manual activation of the "back CFL floods" (I assumed this was your approach)? You could create a simple program (calling it "guest status") such as: if control "back CFL flood" is switched on and control "back CFL flood" is not switched off then else This program will act as a simple status check and be TRUE when the "back CFL flood" device is switched on locally, and FALSE when switched off locally. ON (program true) will indicate guest mode. OFF (program false) will indicate normal mode. For the timer, try something like: if program "guest status" is false and From Sunset To Sunrise (next day) And ( Elk Zone 'Fishing Shed' is Violated Or Elk Zone 'Fishing Deck Box' is Violated ) Then run program "timer" (then path) else Add a third program (calling it "timer") if then Set Scene 'Fishing Shed Lights' Fast On Wait 10 minutes Set Scene 'Fishing Shed Lights' Fast Off else The benefit from breaking out the timer into a separate program is that it will not be interrupted by change in guest status, change in elk zones, or sunrise. In other words, it will continue to completion unless you get another zone violation. Each new zone violation will restart the timer. If you prefer, you could create a variable (as suggested earlier by Xathros) to indicate home and away, but I am not sure what benefit there would be in this case. Perhaps it might be a little easier to see the program logic and remember how everything works in the future. Functionally, I don't think it would operate any differently. If, in the future, you wanted more than two conditions (guest and normal), then variables may make things a little simpler.

You may not be able to accomplish what you want with your existing program construct. You current program turns the lights off in both THEN and ELSE paths. This program also seems like it might include a loop, where your THEN path forces a change in status, forcing a re-trigger to the ELSE path, forcing another retrigger....etc...You may need to start fresh. You may also want to rethink your desires. Do you really want to disable the timer always when you have company (regadless of whether you are out back), or only when are sitting out back (regardless of whether you have visiting guests)? Perhaps a better way would be to override the timer via a light switch as you head out back? A few questions: a) Please confirm that your scene "fishing shed lights" include the device "back CFL floods"? (I assume that is does, based upon your description.) What is your purpose for the last condition line: And Status 'Back CFL Floods' is Off? c) Under normal operation, do you want your 10min countdown restarted at every violation of your fishing shed?

I agree...I want the button lit when the door is open. There may be another way to achieve your goal, even with the "new-and-improved" sensor. Perhaps there is a way you could re-mount your sensor such that it is in contact when the door is OPEN? This may be a little more complicated, but I would think doable. The only downside to this in my mind is that I prefer confirmation that the door is FULLY closed, rather than FULLY opened. Mounting the sensor that engages when the door is open would result in a CLOSED status when the door is only partially closed, for whatever reasons.

There are other options. I use folders, including: a) programs to run in summer programs to run in winter c) programs to run when home d) programs to run when away Put your programs into one of these folders, and use home/away status to enable/disable folders automatically.

Consider, also, the possibility that you could take advantage of all that power in your ISY in such a way that manually activating your scene via one of the D buttons would halt the motion sensor response. Or, you could use a FASTON from one of your keypads to do the same. I would think that it would be a useful capability to be able to turn the lights on and have them stay on, for those occasions that justify this.

Correct, this would only respond to a program. Not necessarily. Like garyfunk, I have lots of keypads for this purpose. But for you, simply create a program to react to "control off" from your BAS 3way1 switch. The program would simply turn off the BASEMENT LIGHTS scene. Alternatively, you could create the program to respond to FASTOFF. Doing so would give one the option to only turn off section B (OFF) or all three sections (FAST OFF). The downside is that this might not be sufficiently intuitive for those in your house technologically challenged.

Devices can be part of many scenes, but controller only of one. The only reason that I can think that the ISY would complain is that you are trying to add them as a controller. If you have not yet tried, attempt to add them to the new BASEMENT LIGHTS scene as a responder.

First, I would go to the user manual. Then to the various wiki articles. Both are here: http://wiki.universal-devices.com/index ... =Main_Page After that, this forum is very good.

I don't believe it would matter. In most installations, one cannot directly control a fanlinc (it is up in the ceiling, in the fan canopy). To activate a fanlinc from a program, and have the linked button show correct status, choose the scene in mobilinc or in a program.

And if you wanted to test for LeeGs theory, you could temporarily connect directly the load and line wires in the switch box (bypassing the switch). If the lights come on bright, then you have isolated your root cause to the switch (itself, pending voltage test) or LeeG's propose incompatibility.

The universal devices wiki is a good place to start for most things. Try: http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Variable_Details In addition, there is a complete section on variable in this forum under "common ISY topics". Make sure you have a relatively new version of the ISY software. Variable have only been around a couple of years. If your ISY is older than that, and you have not updated your software, you may not have variable capability.

No rules that I am aware of, other than those you impose upon yourself. I suspect, however, that there is a total character limit, and may be some off-limit characters, but such limits will become self-evident should you ever violate them (I don't know what they are, off-hand). I have developed my own naming convention: "RRR DD Description", where RRR is the three-character designation for room, the DD is a two-character designation for device type.

Another thought... Does the fan/light have a built-in dimmer or remote control?