oberkc

Make sure you save the changes. The little green arrow on the program name suggests that there are some unsaved changes out there somewhere. Of what scene is your porch light a member, and what devices are controllers? In addition to the LeeG suggestion: Depending on how you have your motion sensor set up, you may need to change "status" to "control" (in fact, I recommend this step regardless). If you motion sensor is set to return itself to "off" after some period within the 10 minute period, it will cause this program to halt wait execution and execute the blank "else" statement. The effect would be that the light would not turn off after ten minutes. Finally, you will probably want to add a step in the "else" branch to turn the light off. If you happen to sense motion less than ten minutes prior to 530am, the program will halt execution of the wait statement and run the "else" statement. Without an OFF command, the light would remain on until motion is detected next evening.

Did you get the whole garage door kit or just the IOLinc? For you to accomplish your goals, you will also need a sensor to know the status of your garage door. Have you added the IOLinc to the ISY yet? When you add the IOLinc to the ISY, you should get two devices in your "my lighting" tree: the relay and sensor. The sensor tells you the status of the door. The relay cannot tell you status, but controls your opener. The first can be a controller in a scene. The second cannot. Assuming you have a sensor and the relay and sensor are in your ISY "my lighting" device tree listing, I think it would be relatively simple to create a program to close your door at a certain time. I believe something like this would work: if time is 1100p and status garage door sensor is on then set control garage door relay off else Please bear in mind that the relay can be set to respond to ON commands, OFF commands, or both. It can also be set to respond to either, based on sensor status. The sensor can also be wired such that a closed garage door can turn it ON or OFF. Your program will have to properly reflect how you set up your IOLinc. You can find all these settings by selecting the IOLinc at the ISY admin panel, where you will find a button to configure it. I don't believe that this is true. One of the configuration settings is momentary open or closed. This is also available through the ISY admin panel and configuration settings. Check out the wiki at universal devices. Search for Garage Door. Search also for IOLinc. You will find much useful here. http://www.universal-devices.com/mwiki/index.php?title=Main_Page

I think you will find a near unanimous concensus in high praise of the ISY-99.

My knowledge of this is based only upon what I have read at this forum. Beyond a reasonable doubt. Yes. Some have reported such experience.

For each controller in a scene (including the PLM/ISY), you can set different levels and ramp rates. This means that the response to pressing controller A can be set different than the response when pressing controller B. For example one Keypad button or switch can turn all the scene's lights to 100%. Another switch can turn them to 50%. Not necessarily true, if you you set the scene levels and ramp rates for the paddle different than that for the scene, itself. Once a scene is created, one can see the devices in the scene by expanding the scene icon. Controllers and responders are identified by color (red and blue). If you select the scene, you will see the on levels and ramp rates for the parent scene. These represent the levels each device will attain when activiate through the ISY (admin panel or via program). If you highlight a controller device within the scene, you see a set of on levels and ramp rates defined for when the scene is activated by that device. These may be the same as the parent scene, or may be different. Your choice.

That is an outstanding point, and one that I might be willing to take, myself. This certainly would make things much easier. Unfortunately, for those to whom this is important, I wonder if this might be a code violation.

I have mostly given up expectations of a consistent web experience. When I enable web access, it works for a while, then not. My working theory is that power interruptions cause web access to go down. So far, going to the admin console, disabling web access, then enabling it again seems to work when this happens.

My bigger difficulty with replacing switches has less to do with wire nuts and more with trying to cram too much stiff wire into too little space, then dealing with the tangled mess when replacement becomes necessary. Once the devices are pulled from the box and the wires untangled, removing and replacing wire nuts becomes pretty trivial in most cases. While I like the concept of these, I don't think I will adopt them for broad use. Price is one reason. Another is that they appear bulkier than wire nuts, taking even more space within my box. I may try some of these for testing devices, however, and for installations where I expect much turnover.

Is your error message always "unable to communicate with KPL", or is the communication error sometimes related to some other device, such as the motion sensor? I vote for option 3. Have you tried a scene test on this scene or any others? The thoughts going through my head is that is most likely a communication problem between your PLM and keypad. The problem could be interference at your PLM, so make sure your PLM is on a clean circuit. On the other hand, if this problem is isolated only to this device/scene, and all others are showing no signs of slow communication, I would be tempted to identify everything that is on the circuit containing the keypad and removing loads, observing any improvement with the communication.

Perhaps another thing that is not clear is that there are only two buttons (on, off) on the six-button keypad and only one (button A) on the eight-button keypad that can directly control a load (via red wire on device). All buttons on the keypad can be a controller or responder in a scene, however. As LeeG stated, buttons within a mutually-exclusive relationship can be controller of the same scene or of different scenes or of no scenes. This means they can control scenes including the same lights or different lights. I believe OFF OFF is allowed... ON ON is not allowed...in a mutually exclusive relationship. Only one button MAY be on, but that is not to say that one MUST be on.

I believe this is the very definition of a mutually exclusive relationship. I don't believe that such a relationship precludes an "off-off" condition. If button 1 is on, button 2 is off, and you turn off button 1, then both will be off.

I don't see where this program would cause ANY insteon traffic signals on the powerline. There is no "then" or "else" statements. I don't believe a program can overwrite link tables.

This does not prevent this first button from being a controller in a scene, just like any of the other eight buttons.

Or...you can click-and-drag a button to the scene, from the "my lighting" tree in the admin console. Buttons are no different than any other device in how one adds them to scenes. Which makes me wonder if you are simply not seeing your buttons in your device list? Is there a little "+" besides your keypad device (I cannot recall for sure if this is the case)? If so, you need to click on it to expand your listing to show all buttons.

While I have yet to take advantage of the variables, I would evaluate your condition as: Status 'Thermostats / Remote Stat / Remote Thermostat' IS LESS THAN 84° Given this, your program would set your variable to "1" if the teperature is below 84 degrees. This appears to me to be consistent with every math convention that I learned. Given this, I believe it would be more correct to write your condition: Status 'Thermostats / Remote Stat / Remote Thermostat' > 84°

I wonder if this is a simple timing issue, but I am a little unclear what is "garage door opener button reset" and how it is activated. My quick theory is that, when KeypadB is immediately pressed and the program is triggered, "garage door opener button reset" is false (initially). The program "else" statement runs as expected. At some point after that, "garage door opener button reset" turns true, but it is too late. What if you put a wait statement (a couple of seconds) right at the beginning of the "else" path? If this solves the problem, this could confirm my theory.

I would like to think that I touched upon this a little more than "barely".

This is a quickly generated program where I expect a light to come on and off at variable intervals between the time of 8p and 11p. It uses the "wait" statement. Hopefully, this won't peg your fun meter. If From 8:00:00PM To 11:00:00PM (same day) Then Set 'Family Room / KP FRM A Table Lamp' On Wait 30 minutes (Random) Set 'Family Room / KP FRM A Table Lamp' Off Wait 30 minutes (Random) Repeat 4 times Else Set 'Family Room / KP FRM A Table Lamp' Off The wiki is also worth checking out, if you have not done so. Try here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Action

I am unaware of any article about such a topic, but there have certainly been other threads on this topic. I generally have three categories of programs: - run all the time - run only in "home" mode - run only in "away" mode If programs are to run in home mode, they go in a program folder called "home". Likewise, if only while away, they go into the "away" folder. I use a keypad button as the tool for setting home or away modes. If the button is on, then I am "away", off is "home". The program folders use this button's status as condition. As far as the "lived-in" look, the most likely option is to create a program with a bit of randomness. I believe the best way to do this is through the wait statement, with "random" selected. Hopefully, this gives you some ideas. Have fun.

I understand your position. So long as it is working, I think I would remain unconcerned. Still, my money is on the prediction that this problem will come back for you some day in the future. My experience has been that problems don't completely go away by moving things to a different circuit. They may be marginalized, but they remain....waiting to bite. For now, though, I am guessing you will keep your eye on it. I notice that you have "filters" in your list of worthless X-10 items. My suggestion would be to use one of those. Better yet, keep them in waiting. If (or when) you experience problems in the future, try one to see if it helps. I am glad your system is working.

Perhaps I misunderstand how you "switch it around", but this type of situation is why they make filters. Given my experience, and the perceptions from reading this forum and others, I would put a filter on your media closet devices if you have not already done so. I don't know how much power it draws, so it may take more than one, but I would do this regardless of what circuit you have put this on or how you switched it around to solve your problem. If you have not done the same thing for your computer system and peripherals, I would put a filter here, as well (just make sure your PLM is not on the filtered power). I have followed this thread with interest (not posting for lack of anything meaningful to add) because I have a scene with several LED-based fixtures in my house which experiences a delay (even failure to respond, on occasion). There was no problem when these were incandescent, so I attribute this problem to the fixtures. I know that your own experiments pointed to other causes than the fixtures, but I would not completely rule this out as a possible contributor.

I tested this and get the same thing. I set mine up a while ago, so I had to refer to the wiki. Following the instructions, I expected to be able to add an email address when choose the "recipient" button in the "add/edit/remove recipient" dialog box. I also notice that the dialog box is a little different than in the wiki, lacking the option to "enter your full email address here@domain.com". Like you, I recieved an error message. Is it possible that this is some error in the ISY software?

I think you and I are in complete agreement here. I like the wiki approach. It has worked well for me. I agree that the original poster has bigger problems than a remote possibility of signal crashing. I think it was LeeG that suggested that there is "always a combination where the door did not move and the button shows the wrong status". I simply wanted to respond to this, saying that I have not found this to be the case, but could think of one theoretical possibility (besides powerline communication errors). Unfortunately, I think Jay5 has moved on.

Yes. I know. I use the wiki approach and it works well for me. The concern that I have is whether a flashing keypad (non-toggle on) is able to respond to a OFF command from a controlling device WHILE it is flashing. I have simply not tested this situation to confirm or deny.

I understand that there is also a setting on the IOLinc that sets whether the IOLinc responds only to "on" commands, "off" commands, or both. Perhaps your IOLinc is responding only to one command? (I think there is a setting that also allows a conditional response, based on sensor input, but it does not sound as if you have a sensor.) Perhaps it is here that lies the solution to your setup.