oberkc

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.

To LeeGs response, be aware that the primary button WILL come on when the secondary button is pressed. This does not mean that the ALL LIGHTS scene will activate, but it may confuse someone who is relying on the primary button to indicate the status of the ALL LIGHTS scene.

I am not sure that I fully understand what you are trying to accomplish. It looks as if you want to evaluate the kitchen light level and, if other than 60%, find out what it is and set it to that value (that it already is?) I am having trouble making sense of this. Regardless, I offer a few observations... I am not sure that you can always "write" to the motion sensor. I believe the motion sensor is only receptive to updates if you manually put it into link mode, or within some short period after sensing of motion. I believe there is an ISY command like this. New light level of what device? Kitchen light? ISY already knows this status in order to evaluate first line. There is an ISY command that can do this.

Yes

No. If the devices are listed, they are part of the ISY database of devices. So this scene contains no lighting devices? Another "Night Time" Program is as follows: I assume that this is the condition that was intended to allow the motion sensors to operate only during the night. If so, then it is written incorrectly. Which programs are in this folder, if any? Instead, try something like this: if time is from sunset to sunrise (next day) or if time is from 900pm to 1159pm \ These are starting suggestions. It may help to describe each folder and condition...and which programs are in each folder. (If you have done this, I am having trouble following). Please confirm ALL devices in the scene "front stoop motion" (is this only including four motion sensors?).

I believe your perception is correct, but I am unsure how prevalent problems are. My suspicion is that a majority use insteon without trouble, but that the minority having trouble is significant. Regardless, problems, should they arise, can be solved, but it can often take a fair amount of troubleshooting time. My earlier suggestions about being hopeful were not intended to suggest that there was no chance that you could run into difficulties. Rather, they were to suggest that you should be certain to couple the legs of your electrical system. I continue to be surprised at how much confusion this appears to cause and how there continues to be a steady stream of folks that don't, or did not know to do this, or don't know how to do this. I recently checked several web pages and manuals on smartlinc, looking for advice on this. I must admit, the need to couple the legs of your electrical system was, in my estimation, not always obvious from these resources. Perhaps that is part of the problem? Fortunately, you have already recognized the need for this.

"hopeful" suggests a bit of hit-or-miss. Make sure you "verify" by following the instructions for each dual-band device. There are no "commands" with insteon scenes. Make sure you add all insteon devices to the ISY and ALWAYS use the ISY to create scenes. Do not create scenes using the methods that come with each device (the instructions are based on a system without an ISY). If you do this, later adding a remote is as simple as adding applicable buttons to each existing scene. You do not have to "start over". If you are referring to program "commands", then you simply add new conditions (responses to remote buttons) to existing programs. Again...no starting over. BTW...I have a setup similar to the one you propose. Landscape lighting (four transformers) controlled by appliancelincs. All mine are inside, however, with wires exiting through conduit and boxes. Other line-voltage fixtures that comprise the landscape lighting scene are controlled by switchlincs. All are part of a single scene and come on and off automatically, based on sunset (on) and fixed times (off).

All throught the isy, though you may, initially, need to put individual devices into linking mode. Yes, the isy can configure individual buttons on you keypads. Yes, the isy canconfigure remote buttons, but you need to put remotes, and most battery devices, into listening mode (manual describes how). I am not entirely sure, but I do not believe yo can copy programming of one device into another. I am not sure that this even has meaning in the context of insteon scenes and isy programs. Amount of "busy" time is dependent on quality of communications and complexity of scenes. ISY can adjust for sunrise and sunset. Not sure about smartlinc, but I suspect it can, as well. You WILL need a way to "bridge phases". Make sure you have at least one dual-band device on each leg of you electrical system. Alternatively you can install a passive signallinc. Or both. I still like access points for this purpose.

It sounds to me as if you are looking not at sensor status, but at relay status. Given your sensor location, like you, I expect the sensor state to change only when the door is fully opened. Have you observed the iolinc led? Does it come on immediately when opened, or only after the door has reaced the end of its travel?

i have used a Foscam. No tile or pan, but outdoor. Color is not very good, but night capability is superior to some of the others I have tried. For the money, however, I am pretty happy with it.

Putting an 20% less bright bulb in it, and setting local level to 100% would solve the toggling issue. How often do you use fast on and 100% brightness?