oberkc

With the ISY, all controllers are also responders, by definition. Make both devices controllers, in your example, and they will respond to each other.

Then I would do the following: 1. create a scene where all the lights you are interested in tracking are responders, and all the KPL buttons that are to display the status (and turn them off) are controllers. 2. put the KPL buttons in non-toggle off mode, so that a button press will send only off commands. 3. If you have multiple KPL buttons you wish to use to display status, create a second scene with all KPL buttons as responders only if status switch A is not off or status switch B is not off . . . or status switch N is not off then set KPL button display status scene on else set KPL button display status scene off of course, device names would be consistent with your actual devices and scenes. The ISY will not allow you to put a single device as controller in more than one scene. There is also no way to do this manually.

If you want to be able to turn on TL1 independent of TL2, and have the KPL buttons illuminate (turn on) when either is on, then I believe a program is your best option. I have such a program. It looks something like: if status switch A is not off or status switch B is not off then set KPL button on else set KPL button off I think there would be some potential inconsistencies if attempting to do this with scenes. If you want TL2 to come on when TL1 is toggled (and vice versa, plus KPL buttons) then set all four as controllers in a single scene.

If I were forced to give a one-word answer, it would be yes. Keep in mind, however, that when done with the ISY, you are including the ISY/PLM as a controller in the scene. If you manually link two insteon devices, the ISY is not included and the scene could not be used in programs, won't show up in your lists, and may show up as a mismatch in link tables between the device and ISY. There is another thing to remember. When manually linking, you start by putting the controller device in linking mode then adding the responder. If you want multiple controllers, you have to be sure to add the other controllers as a responder (where LeeG and insteon manuals refer to this as cross-linking). When done with the ISY, all devices defined as controllers in the scene are also responders by default. No cross-linking necessary. If you create a scene on the ISY as you describe, there is no need to set up any additional scenes. Because controllers in a scene are also responders, TL1, TL2, and KP2 would be responders to KP1. TL1, TLs and KP1 are responders to KP2. Individually turning TL1 or TL2 on or off will have no effect on any of the other devices within the scene.

Is this to say that sometimes your programs work, but sometimes not? And that your "off" program is more intermittent than the others?

I don't know whether your devices are dimmers, but I understand that dimmed is not necessarily "on". I have a similar program to yours, but with a subtle difference: If Status 'Bedroom / SW MBTH Master Bath Vanity Li' is not Off Or Status 'Bedroom / PM MBR Candle' is not Off Or Status 'Bedroom / KP KBA Nightstand Lamp' is not Off Or Status 'Bedroom / OTL MBR Front Wall' is not Off Then Set Scene 'Bedroom Control' On Else Set Scene 'Bedroom Control' Off Perhaps using the condition "not off" would work for you?

I am unsure about the timing of this, but I suspect this never turns true. If at the time the control is recieved the light is off, the status is false and the condition evaluates false. If the light (switch status) was already on from the motion sensor, then turning the switch on manually does nothing. (I don't believe it sends another on signal.) You can confirm this by opening the event viewer. Turn your garage light on. See if you see the command in the event viewer. While the light is still on, try switching it on again. If my understanding is true, you will not see another on event in the event viewer. I am concerned that there is not way to activate a program or event by attempting to turn on a switch that is already on. Hopefully, someone can confirm this. Wait 25 minutes Set 'Garage Light' On Are you sure you want to set garage light "on"? Would this not be "off"?

I use CFL and LED bulbs. I don't use dimmable versions. I have used different brands, without concern. While I suspect that they put out some noise on my system, I must not use enough of them to cause problems. So far, my system seems to work with these types of bulbs. Most of my interior lighting is dimmable, and I continue to use incadescent for all these. One benefit of insteon is the ramp rates. Since incorporating insteon devices and ramp rates, I notice a HUGE increase in bulb life. It is pretty rare that I have to replace a bulb.

This is pretty much limited to programs, using a program to send X-10 commands. If one purchases the X-10 software module for the ISY, you can add X-10 devices in your device tree, giving them names, and using those name in programs.

This sounds like you intend to manually add devices. While I am sure that this can work, there is an easier (and better) way. From the device tree, remove the device (I recall that this is an option when you right-click on the device). Then, using the icon along the top, or from the menu, choose start linking. A dialog box will open up. I believe the default selection is to eliminate existing links from your device. This would be the correct selection. This puts your ISY/PLM into linking mode. Now, go to the device and put it into linking mode (press and hold the main button on). After a few seconds, the button (and load, if any) will flash. At this point, you will have a new device in your tree. Take the ISY out of linking mode. Your new device should be properly identified with all the keys. This whole process will remove the old device from your ISY, including scenes and programs. Once readded, you will have to go back and add the new device back in.

I organize my devices generally by room. I don't organize scenes in folers. The only folders I use in programs are dicated by functional purpose, where folders have conditions (dusk-to-dawn, April-through-September, etc).

In my lighting tree, they show up under the primary button, accessible by clicking on the little + next to the name. I recall that this view has changed over the various iterations of the software. Mine is v2.7.14. You did not happen to manually (typing in the address) add the KPL, did you?

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?