oberkc

Intermittent is normal for powerline communication problems. Devices turn on and off. Neigbor activity varies. Who knows what else. The failed master bath fan indicates to me that you continue to have a marginal communication problem (powerline). Yes, your problems will come back.

Mine stays empty until some insteon activity occurs. I assume that this is normal. I also assume that LeeG suggested this to see if there was something going on percieved as insteon activity resulting from the network cable issue. It sounds as if this suggests that there is no abnormal insteon traffic caused by the network made normal when the cable is removed.

I also approach this problem from a perspective independent of bits and bites. I know little about logs and addresses and so on. I offer these thoughts, however: a. Your ISY appears to be communicating with the PLM. You are able to perform queries, scene tests, etc.... In general, your ISY appears to be working normally to me. I would think problems with your network would manifest itself in a balky ISY. I don't see this. b. I can accept that high network traffic in general may cause communication problems with those devices on your network. I don't think, however, that communication between the ISY and PLM are on the network. I assume that high use of network bandwith would only affect the communication between the ISY and your computer/browser. c. Your problem appears to be the inability of the ISY to see contol and status of KPL-C. This is communicated through the powerline. d. I consider it possible that the amount of noise or signal attenuation that a computer puts on a powerline to be directly related to it's activity and process. This could be affected by network activity. I consider it plausible that the network cable issue is not the direct cause of your problem. e. Your problems sound to me exactly like the communication (which are powerline) problems experienced by many on this, and other, forums. That is how my mind works, based on limited knowledge of the design of the system. Regardless of how this particular problem works out, I think a filter on your computer system is worthwhile insurance. Like others on this forum, I have gone a step further...adding a separate circuit just for the PLM. I have found that separating the PLM from the myriad of computer devices to be important for good communication. On top of that, I put all computer equipment on a filter. I am confident you can get your system to work.

I don't know about network lines or filters for them. I am happy to defer to others (including LeeG) as far as the possibility that high network traffic could cause problems. This is not something that I knowing have experienced. In my simplistic mind, however, the failure of the ISY to see the change in status of your KPL button seems unrelated to your computer network. I am aware only of the powerline filters from insteon.

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.