oberkc

Not necessarily. "ON" generally means 100%. Compare "ON" to "NOT OFF". Compare that still to other options, such as "NOT ON" and "OFF". In general, "NOT OFF" means anything over zero. "NOT ON" means anything under 100 percent. "OFF" means zero. "ON" means full on, or 100%. You understand correctly. A switch (or other insteon device) will trigger a program only when activated directly. When changing in response to a linked device (controller), an insteon device will NOT trigger a program. Despite this, I believe that if you look at the status of the linked (2nd floor switch, in your case), you WILL see an accurate status. Still, I am uncertain if this rule is true only for "control" and may not apply to "status" (as suggested by Xathros). Perhaps a program would trigger if based on "status", even if the affected device changed status based on being a responder in a scene. This should be easily verified by a couple of experiments.

That program looks a little strange to me. Your condition will be both "true" and "false" simultaneously, every time. While, logically, I am not sure that this explains why it does not work, it seems like a real possibility to me. Try: if status shop heat is on then send "on" notification else send "off" notification If the notifications are the same, then use the same notification in both paths. Understand that this program will trigger when the status changes, whether to ON or OFF. The path taken will be based on "ON" (then) or "OFF" (else).

Regarding all insteon device quick start guides and user manuals...these instructions assume NO ISY PRESENT. Once you introduce the ISY device into your insteon system, you should base your programming steps from the ISY user manual and universal devices wiki. The manuals are useful to help undertand how to put individual devices into linking modes, how to factory reset them, etc. However, all scenes should be created via the ISY. By the way, I found the manual for the IOLinc Garage Kit to be confusing and, possibly, incorrect. Regarding the wiki, there is a very nice explanation on how to setup a garage door IOLinc with a keypad button. Go to the wiki, search for garage, and it shows up in the search results. I also suggest searching the forum. The garage door scenerio is oft-discussed. Answers to most of your questions are addressed in some very recent threads. When LeeG speaks of "direct" commands, I believe he is talking about commands from the ISY admin panel, where one can choose the device (relay, in this case) and turn it on or off. Scene commands would be where another insteon device or ISY scene is used to control the relay. Like LeeG states, there is no single correct answer. The mode you want to use depends on the device you intend for control of your door (do you want to use a switch with ON for open and OFF for closed? Single keypad button? Separate keyad buttons for open/close). The correct mode can depend on whether you want to monitor status via the keypad button. The correct mode can depend on where you have your sensor mounted (is the sensor closed when the door is open or vice versa) as well as whether you are using a NO or NC sensor. I like using a single keypad button to actuate the door, either to open or close it. I like to use the same KPL to indicate status. I also place higher importance on knowing the door is FULLY closed, rather than knowing the door is open. I like CLOSED to be indicated by the keypad button being OFF with ON for open. For these reasons, I have chosen: a) mount the sensor such that it is engaged only when the door is fully closed. use the correct sensor wires (I believe this is the normally closed wire) such that when the door is fully closed, the IOLinc sensor is OFF (I like OFF to indicate closed). c) configure the keypad button so that it is in "non-toggle on" mode d) configure the IOLinc relay to be in momentary mode, responding to ON commands (can also respond to both ON/OFF, but not to OFF only). e) create an ISY scene with the keypad as controller and relay as responder f) create an ISY scene with the sensor as controller and keypad button as responder If you have already created links with the device outside the ISY, I suggest starting fresh with a factory reset of the IOLinc. Create all the scenes via the ISY. Configure the keypad and IOLinc via the ISY. This is NOT a trivial excercise. I believe that it is important to understand the concepts behind how and why these things work. Once you understand the concepts, you can mix and match devices to suit your needs and interests.

You can find the wiki by going to a search engine and searching for "universal devices wiki". It is here: http://wiki.universal-devices.com/index ... =Main_Page Within the wiki, if one searches for "garage", a good set of instructions shows up. They are here: http://wiki.universal-devices.com/index ... e_Door_Kit While I suspect hardware and software has been updated and may not be an exact match to these instructions, the concepts are still accurate and clear enough to get you started. Be aware that older garage kits included a version of the sensor having wires for both "normally open" and "normally closed" states. I understand newer kits include a different sensor. Once you have an ISY, it is best to link all devices via the ISY admin console using scenes. Do not manually link devices via quick start guides.

Typically, it is as you suspected. Sometimes folks add waits to give things time to react. My experience is that this is only helpful with X-10 commands. I do not use waits between insteon commands. I would definitely NOT use a wait statement to start. if yours works without wait statements, then I would not worry about it.

In case it is not clear, also be sure that the motion sensor is not also part of the scene being controlled by the program.

The most thorough way would be to remove the Keypadlinc and motion sensor from the ISY, then perform factory resets on both, then add them back to the ISY. From the ISY admin panel, neither are showing up as part of scenes? If not, then it may be enough simply to "restore device". Right-click on each, and choose the option. For the motion sensor, you may have to put it into linking mode.

According to the wiki, choosing a "random" wait will vary the time between zero and the specified time. I am unsure if it is multiples of seconds, minutes, or something else. Try it and see how it works with a longer period.

Whether this is "normal", I would say not. As to why this is happening, it could be several causes. Perhaps the ISY is not seeing the change in physical status for some reason? Perhaps one of your programs that triggers an EMail message has a flaw? Perhaps still there is technical problem with your email system (less likely, in my mind). To troubleshoot, I would first watch the status of whatever device you are using to monitor door condition. Does it consistently and accurately reflect real status? If this is working well, watch the program status. Does it trigger when you expect? Do you see any indication that the programs are not running as you expect? All this is done through the ISY. Any device status can be monitored via the admin panel listing of devices. Select any device that interests you, and the status will be shown. To watch programs, you can select the programs tab and you can see a summary listing of all your programs, their current status, last run time, next run time, etc. Using tools like this, you should be able to further isolate the cause of your inconsistent EMail response.

I see a lot of entries suggesting activity regarding motion sensors. Do you have programs tiggered by motion?

Insteon communicates primarily (in my mind) via powerline. INstallation within light housings should work well. It is no worse than metal electrical boxes. All your devices are on the same circuit. Some floursescent lights can interfere with insteon communication, but my best guess is that you will be fine here. If not, this is nothing that a couple of inexpensive filters cannot fix.

There would be no insteon limitation. The only problem I would be concerned with is ability to safely install modules. Do you have access to the wiring? Do you have box space in which you can install a module for each fixture?

There are a couple of ways that I can think of, but the best way depends on whether you want the response to button presses to vary based on time. That is, if you press one controller during the day, you want 100%, but if you press that same controller at night, you want 40%. If, however, all you want is a program that sets this scene on at different levels at different times, I would simply create a second scene, with the exact same devices, with all being RESPONDERS. Set the second scene "on" levels at 40% (assumes original scene levels set at 100%). First program: if time is sunset then set scene 1 on else Second program if time from 10pm to sunrise (next day) then set scene 2 on else set scene 2 off

I underrstand it is not, due to lack of java

Yes, that is about what I have heard. I am not aware of ANY insteon switch rated by UL or anyone else to use ground as a neutral. While power draw (when not loaded) may be minimal, I still think it a bad idea to hook up insteon other than how shown in the instructions, as designed.

I understand that some devices are, in fact, as you describe...using ground as a neutral for very low-power uses. Speculation on some of the other sites I read suggest that it is because these types of devices were becoming more common that the code was revised to require neutral in each switch location. I cannot say whether this is more "common" than other wiring, but it is certainly one of the standard approaches. Seems to me there are three general wiring methods: power to fixture, power/load to/from same switch, power and load to/from different switches.

That "random" is not working?

Maybe it was a valid point in theory, but refreshing my memory by re-reading the post, we were turning the light OFF (not on). Using scene1 would work just fine.

Xathros, the problem with using the existing scene1 for controlling the keypad is that the "on" levels for scene 1 (with regards to the switch SW1) might be different than for scene 2. Since we are trying to turn on KPL1D in response to scene 2, using scene 1 for this purpose might cause SW1 to be at a different level than desired.

xothros is, of course, correct. This is one of those details that I continue to forget. In case it is not clear in his updated example, "scene1" would be a newly-created scene with a single responder: KPL1D.

Actually, I think it was Brian H who offered that explanation, but I certainly agree with it. The other point I wanted to make was that using ground as a neutral would not just be a violation of the UL certification basis, but a violation of the NEC (and almost certainly of any local building code).

It is not obvious from me, based on your post, that you have confirmed existing wiring matches the instructions. Does it? It is important to note that the instructions are based on one way to wire a three-way. There are other ways, also. It is more important to understand how your house is wired, so be sure to confirm actual wiring rather than instructions.

The answer to this question could dictate a solution. If it does not matter, simply make KPL1D a responder to scene 2 (which would cause KPL1D to come on and off with scene 2, probably my preference). If you would prefer KPL1D to stay off in response to scene 2, but want KPL1D to turn off when scene 2 goes off, this suggests to me that a scene will not work and that you would need a program, such as: As I see it, KPL1D is an indicator showing that the load on switch 1 is on. I would want KPL1D to come on any time switch 1 goes on, including with scene 2

Unfortunately, I don't have an elk (which is why I did not initially respond). I don't know what triggers elk conditions, nor the difference between "toggled" or not. Obviously, something is triggering these programs (in some cases true, in some false). The only thing I can think to do would be to perform experiments, attempting to duplicate the conditions, and watch the event monitor and program status list for clues as to what is triggering them.

Only if you put something in both "then" and "else" clauses. In some cases, a stream of "on" commands may be a limiting factor. I have not noticed any problems in my setup. But, all other things being equal, I would rather limit a stream of commands, as you suggest.