oberkc

Whether you use insteon-enabled bulbs, inlinelincs, micro moducles, or separate insteon switches, you can count on having an intsteon device for each light you wish to control. Whichever option you choose, the cost is somewhere around $50 each, give-or-take a few dollars. If the idea of spending $55 per device for an inlinelinc sounds less than thrilling, what would the price have to be to make you more comfortable?

I came to similar conclusions as others. The garage hawk looked like a nice device for those looking for a descrete system to remotely control a garage door, or for those not having an insteon controller, or not wanting to integrate garage door control with other aspects of automation. For those with an ISY-994 controller, it seems to me that the IOLinc offered a bit more flexibility. But, my decision is made, and I have not kept up with it, or investigated it further since I first noticed it a few years ago.

Adding my opinion to (and in agreement with) LeeG's, I don't consider this an "advancement". If a controller in one scene were also a responder in a second scene, there would be no way to turn on the second scene without the first also coming on. With insteon, and especially remote control, we should be thinking scenes, where possible. No...it is working as it should. Changing is as you suggest would, in my opinion, break the system.

In addition to the response by LeeG, I wanted to make sure you are using the correct "instructions". When using the ISY controller, follow the instructions on the wiki and ISY user manual, all available here: http://wiki.universal-devices.com/index ... =Main_Page Do not manually create scenes using the intructions provided with each insteon device. Always create scenes via the ISY admin panel.

I sure don't see a way. My hope was, perhaps, that the panel/control provided control outputs for the motion sensor, but I don't see any indication of this in the manual. Neither does the control pad appear to be internet enabled.

Yes (HW/SW), to both. My perception is that zigbee support is, and will be, limited to a few items, mostly energy monitors. I believe the zigbee module is available for purchase now. Z-wave is not yet available for purchase, but is under initial user testing. It is addressed by a whole forum: http://forum.universal-devices.com/viewforum.php?f=93

I doubt that it matters, but I would put it into link mode BEFORE adding to ISY. For the purposes of linking, I don't think the jumpers matter. However, I would definitely allow software management of the motion sensor. Of course, the entirety of your problems could be related to version of ISY software, as LeeG suggests. Not being on the forum for a "while".

I think becoming unsynced is inevitable. I wonder if it would be a good idea to have a keypad button or something to indicate Bristol status, so that you could manually correct when needed. Alternatively, why keep track of dog in or out? Why not simplify things, and use a combination of door and motion sensor exclusively, such as: if from sunset to sunrise (next day) and ( elk zone 'back door' is violated or control deck motion sensor is turned on ) then set scene back lights on wait xx minutes set scene back lights off else if you need a way to manually control the lights and override the motion/door program, add a status program such as: if control deck lights is switched on and control deck lights is not switched off then else Add this program status to the first program: if from sunset to sunrise (next day) and status 'status program' is false and ( elk zone 'back door' is violated or control deck motion sensor is turned on ) .... finally, I think you will have to create a third program to turn the lights off at sunrise, for the (hopefully rare) case when you are taking the dog out within xx minutes of sunrise. if time is sunrise then turn off deck scene I am sure I don't have all the syntax correct, but maybe there are some ideas in there you could use.

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.