oberkc

LED christmas lights can sometimes glow, as well. If you get enough strung together, then not. Some have suggested plugging in an incandescent nightlight into the same outlet. Others suggest plugging in an unused power supply or charger. Others appear to go as far as to add a resistor. If you have glowing LED problems, try one of those approaches as your skills and interest dictate.

If you did this, then the outletlinc will turn on and off with the keypad button. Effects from programs will be in addition to this. I am not familiar with the statement "stop program". Does this stop any ongoing execution of a program, or more broadly disable the program? My assumption is the former, in which case, this may not do what you expect. What are you expecting to happen when "keypad linc D" is switched on, if anything?

on mine, top is switched. Agree on the concern about the test load. If it is a low-power LED, it could continue to glow, even when off.

Tedious is the word I would use. If I had multiple programs that required seasonal adjustments, I would probably go ahead, but I have basically two folders that use yearly conditions, and it is not that difficult making the once-per-year adjustment. I think you are making a good decision (for now) to skip the variable approach. Become proficient with some of the basis things: the boolean logic (and, or, parenthesees, if, then, else), understanding what triggers a program, knowing the difference between "status" and "control", avoiding loops, effects and consequences of "wait" statements, etc.... Once there, then relook at the suggested variable program.

I believe apostolakisl is absolutely correct...your program will not perform as you expect. With hope that this will help better understand why... There are program triggers (when will a program perform an evaluation) and program results (what are the results of the evaluation). Triggers and evaluations are both dictated by the program conditions (if statement). Your first program will trigger twice, and only twice: on January 4th 2013, and on December 15th, 2030. This program will do nothing between these two points in time. Once triggered, the evaluation will be "true" on the first date (thus running the "then" statement) and will be "false" on the second date (thus running the "else" statement). Bottom line...this program will turn your outlet on when january 4th 2013 rolls around, and will do nothing (empty else statement) in 2030. It will be, simply, a one-time event. Your second program has a couple of problems. First, it will run (trigger) continuously between the "from" and "to" times, meaning it will run from 2013 until 2030 without stopping each January. Second, it will ALWAYS evaluate as "false", because it can never meet both conditions at the same time. This is because you chose "AND" rather than "OR". "AND" requires both conditions to be true in order for the entire condition to be true. Because of this, the second program will do nothing more than send out "off" commands four times daily between December 2013 and January 2030. I also agree with apostolakisl that, short of writing a bunch of amazing programs such that he has done, I have not found a way for ISY to handle your sort of problem. I have taken a different approach. I have simply decided that I am going to be accessing the ISY several time a year regardless, and that I am too lazy to generate the set of programs necessary. Therefore, I simply create a single-year program for holiday lights, and update it each year.

I use keypad buttons as conditions in programs. These keypad buttons are not part of any scene that I created (besides, apparently, the one described by LeeG as a consequence of adding the keypad to the ISY database). The ISY appears to have no trouble keeping track of status.

I apologize for being unclear. The intent of my question was to as about the consistency in the AMOUNT of time she takes, not the start time. For example, does she ususally take around three hours to accomplish her tasks? If so, how about returning the thermostat to energy-saving mode three hours after she enters her elk code?

How about time? Is the cleaning lady consistent in the amount of time it takes? How about motion? Lack of motion for a set period suggests the cleaning lady has left.

Power your ISY (not the PLM) via UPS?

Do you have a means by which imsteon can communicate between legs (or phases) of your eletrial system? This would generally be two dual-band devies, properly verified on each leg.

I tend to use single switches for individual lights, and keypads for other functions, including irrigation, or program delays, or setting home or away status, or garage doors. I also use tablets as a user interface. But I agree with the assassment that the perfect UI has yet to be invented.

I assume "native" refers to the fact that scenes work bteween devices withou need for intervention by the isy. This can tend to be a little faster reponding.

Yes, they could be responders, but not controllers. I don't think that matters. Whatever meets your needs and is most efficient (I like efficient programming). I expect that the ISY status will be fine.

Purely a gut feel, but I would create a second scene. Of course, the second scene would not be able to have the same controllers but I assume that this is not a problem if the purpose of the scene is limited to a one-time-per-day mood shift.

LeeG knows far more than most about the details of interdevice communication. My view is much more observational. Individual devices can "work" based on communication between the devices, even with communication with the PLM impaired. When initiating the changes from the ISY, communication between device and PLM becomes critical. This is one reason that I suspected the problem is associated with equipment close to the PLM. Regarding the mismatch between ISY and truth....yes, I understand that the ISY looks for confirmation, but when not recieved, it makes the assumption that the device status is as commanded. Hopefully, the more learned among us will confirm or deny this.

Are the devices that failed the scene test the same two that have incorrect reported status? Are these the same devices that are powering your fluorescent (tube) fixtures? Are those hardwired fixtures or can they be temporarily unplugged? All indications continue, in my mind, pointing towards a communication problem. The communication problem could be associated with the PLM. What other devices do you have plugged into the outlet with the PLM? Computer stuff? UPS? Surge suppressor? Do you have your PLM plugged INTO a UPS or surge suppressor? Given your success with your other devices, the communication problem could also be associated with devices powered by the same circuit as that powering your offending devices. I would be investigating what is on those circuits. And how did you confirm this?

If these are CFL, try temporarily replacing with incandescent. While I am not sure that this is a problem for you, the check is simple enough that one might as well be sure. Regarding the scene test, do you have a lot of programs? Are any of these programs potentially triggered by a change of status by any of the devices in the scene-in-question? (If so, this could skew the results of the scene test.)

My understanding is that the ISY will assume a device reacted to commands, even without confirmation from the device. This suggests, to me, that there is a communication problem in your case. Is it necessary to turn the switch off before turning it on? Would not the light come on if you simply turned it on without first turning it off? There are a couple of questions I have: a) do you have a method for providing a communication path across legs of your electrical system, such as two properly verified dual-band devices or access points or a signalinc? what are the loads you are trying to control? Incandescent? CFL? LV with power supply?

I expect that this can be done via variables. Unfortunately, my understanding of variables is only conceptual, so I can offer only concepts. Perhaps others can refine this thought process or come up with their own. A program such as if light switch is turned on then variable = variable + 1 else I also assume that one would re-initialize the variable to zero when the light is off if status switch is off then variable = 0 else I would then put all your motion programs in a folder that is active only if the variable is less than three

If this is a comment regarding mobilinc, my understanding is that the displayed status may not be accurate. I believe that changes made via switch or keypad or ISY may not be reflected in mobilinc. I suspect this has to do with limiting the power and data consumed by mobilinc. There is a manual refresh option which should update device status.

The first thing that I would do is to create a scene, with the module and KPL button as "controllers". Doing this will cause the module to come on when the KPL is pressed, and the KPL to come on when the module is turned on. Smarthome calls this "cross linking" in their manuals, but be sure to do this via ISY. Assuming you have X-10 equipment set up to where the remote is ultimately sending signals via the powerline, and you have good communication across all circuits and legs of your electrical system, I think I would go with a couple of simple ISY programs, such as: if X10 "A1/on" is recieved then turn "newly created scene" on else if x-10 "A1/off' is recieved then turn "newly created scene" off else My experience with mobilinc is that you simply choose the newly created scene and turn it on or off. I don't know whether it uses REST interface and have never cared.

I think of it less as old switches becoming obsolete. Instead, new switches becoming more capable.

http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit This is the basis on which I set mine up.

No. This is part of that "interrelationship" thing I was talking about. To answer your specific question, to avoid having to create a separate "open" and "close" button, one must also configure your relay properly. This means you set your relay to respond only to either "on" or "off", depending on which mode you set your keypad. This can be done through the ISY-99. There are three momentary modes, and one latching mode. A description is here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_an_I/O_Linc The mode you choose for your switch is, in my estimation, based on several things. First is the location of your sensor (is the sensor located low on the door, where it is in "contact" when the door is fully closed, or up high, where it is in contact when fully opened?). Second is your sensor type and hookup (does your LED indication come on when the door is open or closed?). Third, your primary interest in door status is a factor. Do you prefer a higher confidence level in knowing that your door is fully opened, or fully closed. Finally, how do you want to define the meaning of the KPL button (do you want an illuminated KPL to indicate "open" or "closed"?).

Part of the process that I use (based on the wiki) is to put the switch in NON toggle mode.