oberkc

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.

A great option if you are trying to avoid an ON delay, but still limiting regarding ability to apply conditions for when a device responds motion lighting. If, for example, you wish to have motion work only on weekdays (or only during certain times of the day) for some reason, such an approach falls short. Programs offer greater flexibility for defining conditions necessary to trigger responder devices. Take wswartz question for example. Let's say you want to trigger a light and countdown timer to 50% from motion, but only if the light is not already on (or at a different level). I believe that will be very difficult using a scene relationship between the sensor and light. On the other hand, this is relatively trivial from a programmed response. This is the one that I like, actually. I don't use scenes for motion, at all (can live with the delay). I want to restart the countdown at each sensing of motion, whether every second, or less frequent. The non-sensing mode, I understood, would trigger a built-in timer that would continue uninterrupted (regardless of subsequent motion) and send an off command at the end of the time period (again, regardless of subsequent motion). But, since I don't use it, I may be mistaken.

Of course it could. Programs often fill in the capability gaps. One downside to programs is a slight, but noticable time delay. Below is a general idea (syntax not perfect) of a program that will illuminate a keypad button whenever another switch is anything but completely off: if: status "dimmer" is not off then set "keypad button" on else set "keypad button" off

Thus, the tradeoff. Use scenes when your needs are simple: motion = on always. Use programs when your needs become more sophisticated: motion+time+devicestatus+temperature+date=on else off. The question here is whether the added control of programs is worth the cost in time delay. More my purposes, the silly "sensing" mode works well. I have motion sensors outside. So long as the sensors continue to detect motion, the lights stay on. When the motion sensors stop seeing motion for my defined time period, they go off. I like it.

I have no Elk module, and don't understand elk rules, or elk-based conditions. One thing I do notice, however, is that I see program to send any notifications regarding Kristen. This may explain why "not Kristen". I assume this all has to do with triggers, and when are elk conditions triggered? Any change in output? Upon queries? It seems to me that what is going on here is that these programs are being triggered at times not anticipated.

ngeren If you wish to further experiment, press and hold (either dim or brighten) the master keypad. Set the state in various states of brightness and note whether the linked keypad button consistently goes on or off at a certain dimming level. Like LeeG says, this will not work controlling the device via ISY.

I can't say that I have ever seen a load switch have its led's ramp up slowly but yet have the actual load come on instantly. Other than a defective switch, I don't know why that would happen. I thought we were talking about the ramp rate of a "virtual switch". I understood "virtual switch" as one which does not directly power the load. If true, it is absolutely possible that a virtual switch could have a 2-second ramp rate when the switch controlling the load has zero ramp rate.

Yes. Sometimes it is nice simply to use devices as intended. There can be a lot of freedom when the ability to tinker with devices is taken away...it gives us more time to spend doing more important stuff.

Of course, KPL button backlights are either ON or OFF. They have no way of showing a DIM setting. My experience is that KPL buttons and other insteon ON/OFF indications can show OFF when a linked dimmable controller device goes below half. Is it possible that you are seeing this type of behaviour?