oberkc

Exactly! One subtle difference when using the ISY-99 to create your links (scenes): all scenes created with the ISY will include the PLM as a controller, in addition to the other insteon devices. This is done in the background, without user intervention. Remember also that devices added as controllers in the ISY are also responders by default.

That is one I have not experienced nor recall seeing on the forums. I can only wonder if plugging in your network cable causes the computer to perform some response that generates a lot of noise on the powerlines. I would be getting me some filters and putting the first one on your computer equipment (not the PLM).

??? This sounds exactly like powerline communication problems, to me.

I would even take this as evidence of communication problems. I found that when I was able to identify my problem devices and filter them, communication speed increased, and more than a little. Hopefully, you will find the same thing.

Such a statement makes me wonder if you have links in some your devices from a manual process (versus created by ISY scenes). I would not expect creating a master off scene is relatively straight-forward using the ISY and should not take that much time. I understand that having links in devices not known by the ISY (which can happen if one uses the manual method) can create problems with a system.

Keep in mind that turning off your computer system may not solve your problems. Printers, routers, power supplies, UPS, etc...all consume power and can create problems, even when off. A quick experiment, if you want to try it, would be to find an outlet on the same circuit as that powering your KPL. Get a long extension cord and take the other end to the computer room. Plug in your PLM to the extension cord. See if this solves your problem.

Uh oh. My experience has been that filters are required on my computer system to isolate the computer stuff from the PLM (don't put the PLM on the filter). I also have filters on TVs, water heater, and theater stuff. Most of this was discovered by trial and error. Communication problems are a mysterious thing. I would take this as evidence that the PLM is communicating, but that the circuit on which the front lights is electrically quieter than the circuit powering KPL button C. Communication problems, I believe can be cumulative. You may have noise on the computer circuit that, by itself, is not enough to cause problems and noise on the KPL button circuit not a problem by itself. Adding the two together, however, may be a problem. It has been my experience that running scene test can cause your insteon devices to change condition (off or on). It is, however, the "failed" listing in your event viewer that makes me continue to suspect you have some device or devices in your house either causing interference, or attenuating insteon signals. There are lots of little tricks people use to find these little communication gremlins. This forum is full of folks with similar problems. Hopefully, you can find the various threads about this and get your system working well.

LeeG, I thought the circulator pump was controlled via program. I percieve the problem being with the two-device scene (button C and fan). He presses button C, but the ISY does not show it as on.

I may be predispositioned to assume things, but this starts sounding like a communication problem to me. I suggest a couple of steps to further troubleshoot: a. open tools>diagnostics>event viewer b. press your C button c. confirm you see an event on the event viewer corresponding to the button press (three lines of incoherent gobbledygook in my event viewer). If you don't see this event, then I would conclude that you are not getting good insteon signals from your device to your PLM Another test is tools>diagnostics>scene test. From the available scenes, choose one or two that include your devices in question. You may even want to create a temporary dummy scene to include all the devices in question. Run the scene test and see if you have any failures. This would be further indication of comm failure. A quick check of your setup....do you have any access points? Do you use any filters? Do you have a UPS, conditioner, and/or surge protector on your computer? Is the PLM plugged into this, or adjacent to it?

Yes, there is potentially some duplication. With programs, you can do much of the same thing as with scenes. Like those before me said, scenes are part of the basic insteon architecture and can be used with, or without, an ISY. To add to the example of of Brad77, scenes are also device-to-device. If switch A and switch B are part of a scene, then they communicate directly with each other and don't even require the ISY to be there. There are benefits to this. First, it is a little faster than programs. Second, if the ISY fails, your basic lighting will continue to work. My suggesting is to use scenes to link devices to each other and use programs for more complicated relationships between and among devices, and for timing-based events.

I understand it is your intention not to use the dim feature, but I think it possible that one could use it inadvertently, simply by holding the button a little too long. I also do not believe that the dimmer switches are "rated" for motor (inductive) loads. While I have no doubt that many use them for this purpose, I also suspect that it can lead to problems (load non responsive, communication, switch life) in certain cases.

A point of clarification, please. Joe is apparently using a different magnetic sensor. You are using the garage kit sensor, correct? Which wires did you connect from your sensor? Is the LED on the IOLinc responding (on when open, off when closed, or reverse) to the door opening and closing? When you look at the sensor in the ISY admin panel, do you not see a status change when the door is opened or closed?

I like the solution by marksanctuary. I second the concern about this switch being part of other scenes. I assume that the switch is not a dimmer? If so, there may be better (or additional) "if" conditions, such as "not on" or "not off" or "dim" or "bright". The only thing that jumps at me is the possibility that someone could leave the light on, at which point the next person entering the room would have to know to turn it off, then back on, to get the pump working again (assuming that this is important). For that reason, I think I would program the light to go off with the pump.

One could use any insteon switch as a trigger for the programs. Most of mine are the togglelinc variety. You could also use an X-10 switch (if communication allows).

I have no "timer switch". All programming is through the ISY-99

I see no reason why one cannot put KPLs in a scene. However, the secondary KPLs may not respond directly. Create a new scene with your seconday KPL buttons included as responders. I understand that by turning that scene off, you will turn off the KPL buttons. Regarding the second question, it depends on how you currently disable your program. If you use a KPL button to activate the "not home" condition, then would this work?: if ( control KPL button not on and time is 0700p ) control KPL button switched off then set scene on

I recall that you cannot turn off a KPL button by the ISY. However, I think you can put the button into a scene and control the button indirectly, through the scene.

Thanks for the response. It sounds to me that it is potentially your away folder which turns false which causes your program condition to evaulate false. Somehow, adding the from-to condition turns it true again. I still maintain that a program condition of "TRUE" will not keep it from executing. I don't believe a program has to start from a false condition in order for it to be evaluated and executed. When a program is evaluated, and the response to the evaluation, is (as I understand) completely unaffected by the current state (true or false) of a program. Consider the following example: If Time is 7:00:00AM Then Send Notification to 'aLf' Else - No Actions - (To add one, press 'Action') I believe that if you created this program, it would send you a message every day, even though it would show as true, continuously. I believe it is your inclusion of the away folder which creates the complication, which is solved by further adding the from-to condition. It sounds like it is working for you, though. Thanks for the response.

aLF Thanks for the response. I understood that the addition of a from-to condition caused your program to work, and that is great. Still, curiousity (and a desire to better understand how things work) has got me on this one. Because of the several examples of programs in my own setup, I continue to believe it to be unnecessary turn a program false in order for it to run again. I was just hoping you would share your "away" folder conditions for my own edification.

Neat example of a way to make your program false after execution. I like it. However, there are times when one may want to test the last evaluated condition of a program as part of another program's condition. I find that the program list in the admin panel showing active or not is enough for me to know whether a program is executing. Additionally, I don't believe it is necessary for a program status to start out as false in order for it to be evaluated and executed based on the latest evaluation. One of my programs is in a continual true condition, yet it runs every day at the same time. I still find aLf's situation a little puzzling. aLf, under what conditions is your folder "away" true or false? Is it possible that executing this program turns the folder "away" to false? I am curious to see the folder conditions for this folder posted.

It is apparently confusing to many. The "Program" state is the state when last evaluated. If evaluated 20 hours ago and was true at that point, and has not been evaluated since, then the "program" state remains true. However, don't confuse "program" state with the execution of the programs. Just because a program condition is true does not mean that the program is continuously executed. Execution of a program happens only when the "if" condition is evaluated. For controls, evaluation is at the momentary time when the control condition is seen. For status, evaluation is when there is a change of state of that status. In SubRoutine's example, it would be evaluated when there is a change of state of the stairs light, or when a the stairs lights is switched off or when it is switched fast off. At the point of the evaluation, if the "if" condition is true, then the "then" condition will run. If, at the momentary time of evaluation the "if" is determined as true, the program state will remain true indefinitely, or until another evaluation occurs where the "if" condition is evaluated as false. However, the "then" loop will execute only one time per evaluation.

I stand corrected. In fact, I just checked the smarthome web page for the device and it claims insteon also. Either this page has changed recently, or I remember incorrectly. Probably the latter.

This is the first thing that I would be looking at. If these power supplies cause problems for the PLM, then EVERY scene is affected, since the PLM is part of every scene. It sounds as though these devices are such that you could live without them for a few minutes. A scene test with, then a scene test without, might give you a sense of the effect they are having on your network. Yes, I also assume the old X-10 filters are effective to some degree. I continue to find it interesting that Smarthome does not actually sell "insteon filters". I would not expect shielded cable to help. Most of your induced signal would be 60Hz, I assume. I doubt that this would cause a problem for the communication. Interesting, your access points. I would be putting these in places where cleaning services would not disturb them.

I don't know about you, but the recent months and year at my house has seen an explosion of electronic devices added to my house. New TVs, bluray players, internet viewers, mediacenters, electronically-controlled appliances, and home theater equipment have all put a burden on the powerline quality. If your house is like mine in this regard, I am guessing that the relationship between communication and the additional insteon devices is coincidental and more related to other factors. Perhaps there is a few recently-added devices in your house that you can unplug and see if this affects your insteon performance? If so, this would suggest that filters may be helpful. I also think it good practice to put your computer system on a filter, with the ISY/PLM outsie the filtered power.

This is not necessarily conclusive evidence of proximity to each other from an electrical path standpoint. Still, it may be a clue. If we are beginning to suspect communication issues, I suggest trying a scene test on those scenes which may be misbehaving, or include many devices. This may provide a clue as to the robustness of communication. If this is a possibility, you may want to try different conditions in your program. Rather than using "not off", try "not on". I am also thinking that we can use condition such as "less than 10%", but I may be mistaken. The only time that I have found wait statements useful is with X-10 commands. Also, I cannot remember from your earlier threads, but I wanted to confirm that you have access points properly installed, and if you use any filters on your computer system or other electronic devices.