oberkc

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.

Did you put your kpl in non-toggle mode? There is so much interrelationship between the setup, including location of sensor and which sensor mode (N.O. N.C.) one uses that it may be useful to summarize the approach you took if the non-toggle concern does not solve your problem.

Do you have a sense of the source of the wait? Is it the result of a delay between the initial motion sensing and resultant action, or due to the performance of the motion sensor, itself? My perception is that a good portion of the wait is simply due to the performance of the motion sensor. And this will remain regardless of whether one takes a scene-based approach or programmatic one.

I disagree. I believe using a program is the clean way of doing things here. And, while there is a delay, I am not sure one would notice it, since it is a delay only between the motion sensor and response (will anyone even notice when the motion sensor triggers?), and only around a second-or-so. What you are trying to accomplish is pretty standard stuff, discussed often. I would be willing to bet that most have settled on a programmatic approach.

I don't believe the proposed ISY program cares what mode the sensor is in. It will respond to "on" commands, whenever they are recieved. The sensor mode only affects the frequency at which the sensor will send "on" commands. Each "on" command will trigger an evaluation, at which point this will result in a "true" or "false" condition and associated response (then or else). From the admin panel, the status of a motion sensor device is based on last command recieved. If a motion sensor is configured to send only "on" commands, the admin-displayed status will be "on" continuously. Motion sensors cannot be queried, I don't believe.

Whether it causes grief to you is based solely on whether the program does what you intend. Unfortunately, your stated intentions are limited to: I believe your program will do this, but only if "$VerState is 1". Unfortunately, I cannot see where you describe the conditions which control this variable. Is it possible that ther will be times ($VerState is not 1) when motion does not reset the timer? Is this what you want? Having said all that, consider the possibility that you are in a wait state, and the program triggers and evaluates false, because the variable is not "1". The wait will halt, and the light will remain on indefinitely (until the next program trigger evaluation is true). I will leave it to you decide whether this constitutes grief. There are lots of motion sensor examples in the forum and in the wiki. This can get complicated quickly. Do you want to be able to manually disable the motion sensor? If you turn the light on manually, do you want it to stay on indefinitely? Do you want it to work only during periods of darkness? Time spent thinking about the details of what you want it to do is time well spent, in my mind.

So, the indicator light is not working, but that switch (with failed indicator) still appears to be otherwise functioning correctly? If so, I can only imagine that it has malfunctioned. Still, I would check wiring. Maybe ground or neutral is marginal.

This is more clear to me. It seems to me, however, that the way to approach that set of requirements would be for the motion sensor to trigger the light with a program, rather than a scene. This would allow one to put a condition in the program that if the light was already on (or "not off"), then don't do anything. Or keep light levels the same and run only a timer program.

I was simply responding to a statement he made in the original post. I remain confused as to the intent of the OP.