oberkc

It appears that, perhaps, it is not working as well as you thought. Even if devices eventually respond, sometimes the response is slower if the communication is marginal. If too slow, I think there is a chance of signal "collision" and subsequent problems. I would definitely dig out the instructions for these and make sure they are on separate phases. Since this costs nothing but a little time, I suggest starting here. Once you are sure they are on different phases, run the scene test again and see if it passes. If so, problem solved (maybe). Being on separate panels does NOT guarantee being on separage phases. Furthermore, there can be problems if your panels are on seperate feeds from the transformer. Assuming you have a single feed to the house supplying power, I am guessing you are likely able to communicate between panels. You still have to ensure they are on separate phases. Again, the instructions describe how to do this. Based on my experience and from my readings of this forum, I think it likely that you are seeing communication problems resulting from interference and signal degradation from your computer system. If the access points don't solve your problem, then I would start with a filter on your computer electronics. (Keep your plm off the filtered power.) If you would like to do a crude check to see if this is an issue, get an extension cord and plug it into a circuit separate from that which powers your computer system. Plug the PLM into the extension cord. Run your scene test.....see if this helps. If, after confirming access points are properly located and powering plm from different circuit, your problems persist, the next steps are likely finding other offending devices in your house and filtering them.

What starts and controls the "initial run"? How long does the initial run last? To clarify, does this variable not become true until "after" the initial run? Is it possible that the delay in starting your program is due to the fact that the initial run var takes some time (waits for completion of initial run) to become true?

Perhaps. I do not recall reading of any such problems, but now I have. Given this, I understand your hesitancy. Perhaps, as you say, this was an older version of the ISY firmware, since taken care of. I use an X-10 reciever (IR-543) and the ISY see's these signals without problem. If you don't want to use something like the IR linc, and plan to put the ISY-99 in a room other than the one where you use the remotes, then your options may be limited to an ISY-99IR with some type of IR extender to get the remote signal from the remote room to the ISY room. If you happen to have a remote with RF capability, you may also consider an RF extender at the ISY location.

I understand that the scene test is an indication of communication difficulties. I understand that the scene test is simply a check of communication with fewer attempts than normal, so, yes, it can fail a scene test and your programs still work, but I would take this as further evidence of a rough communication environment. This would certainly explain why your system takes so long to write changes. I would not ignore the failed scene test. Do you use access points or dual-band devices? Are you confident that they are set on different legs of your electrical system? Do you have mulitple electric panels? Do you use any filters on any electrical devices in your house (and, specifically, the computer system itself)? Is the PLM on the same circuit as your computer system or home theater system? Answers to these questions may help isolate your problem.

Yes, I thought one of the recent versions allowed holding off writing changes until they were all done. Like Brian H said, I also suspect intermittent communication issues. When communication is good (at least in my house), writing changes is relatively quick.

I would expect that, like any insteon device, it would integrate beautifully. Whether you hook it up amongst a bunch of home theater electronics, or amongst a bunch of computer electronics, I suggest planning to put such things on a filter, so to limit the potential for inteference. Of course, the PLM itself should not be on a filter. When on filters, I would expect little trouble from these devices.

My understanding is that the IR version has a built-in IR sensor that one can send IR signals into. These signals could be a trigger as conditions in an ISY program. I don't believe there is provisions for an external sensor. I don't believe additional hardware is required. One could locate the ISY in an entertainment center and use a TV remote to send commands. Or, one could locate the ISY anywhere and use some type of IR extender to input IR commands from another room. Or, there are insteon IR recievers available that can be programmed to do similar things. For that matter, there are X-10 RF recievers which can be used to transmit X-10 signals over the powerline and used to trigger programs (this is the solution I currently use to trigger lighting control from a TV universal remote). There are several solutions, including the built-in IR reciever. I don't think you have to be limited due to the fact that you don't have the IR version of the ISY-99.

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

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"?

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).