oberkc

Yes. If a relay can only be a responder, then there is no way for an operator to initiate a control command from that device. Responder will be fine.

Me, too. Bring it up in the mobilinc forum. The company response has always been a little cool towards the idea, either because a percieved lack of demand or out of concerns that someone could accidentally activate something without knowing.

Ah! So the C and D buttons are the ON and OFF buttons of a single scene. I am glad you have it working. I am not sure that I understand the difference between primary and secondary keypadlinc. However, when I hear things like not "that well" or a "couple times", this makes me think intermittent problems, to which I instantly wonder if your ISY is, or is not, seeing the commands from some of your keypads. Programs usually work always, or not at all. Communication problems, on the other hand, can be quite hit-and-miss. To test for this, I would open an event viewer and press the mis-behaving keypad button a few times. Does the event viewer always register the button press?

To my knowledge, this cannot be done with Mobilinc. I believe you will need to observe the sensor for garage status and use the relay for garage control. Perhaps there is someone who has figured this out and can report. If so, I will learn along with you. As an aside, I use the android version and my wish is for widgets that can be configured for one-touch commands, for things like garage doors.

To my knowledge, this cannot be done with Mobilinc. I believe you will need to observe the sensor for garage status and use the relay for garage control. Perhaps there is someone who has figured this out and can report. If so, I will learn along with you. As an aside, I use the android version and my wish is for widgets that can be configured for one-touch commands, for things like garage doors.

If it is working, it is not "wrong", but I believe there are benefits to using a single scene, rather than two programs. Put all buttons, including those two relays powering the lights, into a single scene, all as controllers. I think you will find the response faster, more reliable, and still working in the unlikely event of a failure of the ISY or PLM. Any button in this scene that you prefer not acting as controller of the global scene, set only as a responder, rather than controller.

I believe you have answered your own question. Yes, all three must be defined in the scene as controllers.

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.