oberkc

For this, I would remotelinc buttons C and D to your existing scene "Sceme B", as controllers. Once added, select button C from the scene and define ON levels for the two B buttons as 0%. Then select the D button from the scene and define ON levels for the two B buttons as 100%. For this, I would simply update your existing two programs: If Control 'Remotelincs / Upstairs Remotelinc / Upstairs RemotelincC-D' is switched On or control "KPL button B1" is switched on or control "KPL button B2" is switched on Then Set Scene 'Upstairs On' On Else - No Actions - (To add one, press 'Action') Make the same change to your other program, except for the condition should be "is switched off", rather than on.

And if, after running the quick test suggested by LeeG, you find it the UPS that is causing the problems, yes, a filter should work (and is THE solution I recommend). Moving the PLM to a different circuit may also work, but I would rather eliminate the problem that the UPS represents to my entire insteon system.

I takes a little while to get your head wrapped around a few of these concepts. Triggers, conditions, waits, etc... Neither is it easy to describe it in words, even if you think you understand it.

I think there is a misconception here. Folder conditions do not DICTATE when a program will run. Folder conditions do not force, or cause, programs to RUN (even with folder conditions enabled, a program still requires a trigger to run). Folder conditions do not prevent programs from running (can still be triggered by conditions external to the folder, such as by another program). Folder conditions simply ALLOW or PREVENT program's IF conditions to trigger itself. In effect, program conditions ENABLE or DISABLE programs. Your current folder condition (pump is off) allows included programs to run ONLY if the pump is off. If the pump is on, NONE of the included programs will trigger, including the program to turn off the pump.

Something needs to tell your program (then/else) sections to execute. This is either a program condition (if), or being called by another program. If you have an empty IF section, and this program is not being called from another, it will never run. I suspect you are making this harder than it needs to be. Why not try: if time is from 8:00AM to 1100AM or time is from 3:00PM to 6:00PM or time is from 9:00PM to 11:00PM. then turn pump on else turn pump off No folders. Simple (hopefully it works)

Yeah, we went all over the map on that one. In everyone's defense, however, a lot of this discussion was arguable initiated by, and addresses, your initial "side note" about continued use of insteon. As the ISY becomes multi-lingual (adding zigbee, z-wave, etc...) this gives one options to introduce other types of devices in the hope that they are more reliable (as you hoped). OK. that was a stretch.

if you don't want a control, on what basis do you want the system to begin and end the 15-minute cycle? Temperature? Time of year? Or...do you want it simply to run a continuous duty cycle, 24/7, 365 days per year?

Woa!! That response sure caught me by surprise. In addition to the other responses, I also recall that nikki specifically asked about our thoughts on the subject of whether or not to continue with insteon. I thought we were all simply offering honest response to that question. I actually think it nice that we can be open about such a topic. The openness adds weight and confidence to the responses that are more positive.

I have experienced few insteon device failures, but I would be lying if I did not admit to being a little nervous about the prospects of this in my future. I can also tell you that one of my older keypads is behaving as you describe...it appears to go completely dead (no LED indicators, no function). I pull the little tab out for a short period (a few minutes), press back in, and the keypad works again. It has been working for a while since last incident, but I wonder if this is early indication of pending failure. That type of behaviour makes me intially think communication problems. Have you performed any diagnostics (formal or otherwise) to check for this? Do you ever get an indication when first logging on that the ISY cannot communicate with one or more devices? Have you ever performed a scene test? How many insteon devices do you have? How many are "dual-band". Do you have access points? Are these confirmed on opposite legs of your electrical system? Do they still appear to be working? Have you added any new electronic devices to your house? Where is the PLM plugged in? Next to (same circuit) computers, UPS, other peripherals? Sorry to throw a bunch of questions, but these are the kinds of things I would be asking myself if I were experiencing the problems you describe. I can't help with your decision about whether to continue or to abandon insteon. I suppose it would depend on how many devices I had, how many had failed, how much discretionary funds I had, and the value I placed on automation. I can tell you that I have had no problems with smarthome covering warranted items, and most of the time the sales and service reps are quite easy to deal with. Every once-in-a-while, (once in person) I run across a rep that has a bit of an attitude that I find offensive, but I am not sure that this is unique to smarthome. One consideration is the newly-introduced (actually not quite available for general release, I understand) Z-wave support in the ISY-994. If this becomes broadly available to folks like you and me, then this may offer a graceful exit from insteon over to Z-wave. If one is unhappy with insteon, and as insteon devices fail, one could try out a z-wave replacement.

I agree. This program cannot, in my mind, produce a notification at 3pm, as written, regardless of which day it is. Another program notification? Another program calling this one then path at 2:45?

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