oberkc

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.

"Changes"? Are you making changes to the program and it is not being saved? Or are you running programs and seeing no visible evidence that your system is responding? If you manually activate some of the devices controlled by your program, do they respond as expected?

The program looks to me like it should work. Maybe I am missing something. Alternatively, is it possible that your ISY/PLM is not consistently seeing the changes in status. That is, until you open the admin panel and perform some query. I suggest opening the event viewer and running through some tests on your two sconces and fan light to be sure it shows up when you turn them off and on.

Interesting. I have programs that are quite similar. One runs at 11:00pm, based on the condition: Time is 11:00:00PM. and status override is off. It runs every night, same time. I am having trouble understanding why yours would be any different. Something strange is going on.

What is "it"? The program status? The folder status? And what do you believe is the problem with "it" being true? As I see this program, it will send you a message every day at 7:00, so long that the ISY is working. Is this not what you want? Is it not sending these messages? Tim's suggestion would turn the program status to false at 0701, but would have no effect (in my estimation) on when it sends messages or how often.

The answer to that question appears to have stumped minds far greater than mine. Much has been writen, and discussed, and criticized, and applauded, but I am not sure this is settled. Control, as I think of it, is a momentary condition. Status is more of a continuous condition. Programs and folder are evaluated any time one or more of their conditions are recieved (control) or changed (status). In your example, Garage Light Motion On, it will be evaluated any time the motion sensor is switched on, or any time the status of the primary or secondary lights transition from off-to-on or on-to-off. Regardless of what triggers the evaluation, all conditions must be true at that time in your example, because of your use of "AND" statements. Your status conditions will return true for as the two lights remain off, regardless of whether there has been an immediate change of state. Your control condition will show true, however, only at the moment the motion sensor sends an "on" command. All other times, it will show false. The practical effect in your program is that a change of status will probably not trigger the "then" condition because it would require the unlikely event of a simultaneous reciept of a motion sensor trigger (I suspect this may even be impossible). However the motion sensor could trigger it because the status conditions can remain true for finite periods of time. I am sure this explanation is inadequate. Perhaps you would find it useful to check out some of the other threads on this topic.

I am sorry, but I cannot post exact programming for a similar condition. However, I wanted to be sure that I understood your requirements. 1. You want to disable the dust collector if the shop (garage) lights are off, correct? 2. You want to continue to use the remotelinc to turn the dust collector on (but only if the lights are on), correct? 3. Your current lighting design has a scene with the motion sensor and two icon switchs ("directly" controlling the loads). You believe there is a better way, based on what you have seen in the forums. You are looking for suggestions? Regarding the first two, I would first plug the dust collector system into a relay (appliance) module. In the ISY, create a folder with a condition that garage lights are on: If status of garage light switch A is on or status of garage light swith B is on the run programs in this folder In this folder I would add a program if control remotelinc button is turned on and control remotelinc button is not turned off then set dust collector module on else set dust collector module off Regarding the third, if you are satisfied with the way your motion sensor/light scene is working, there is no reason to change it. Having said this, I (and, I believe, most here) use programs with motion sensors rather than scenes. However, this is to allow motion sensors to be active only during certain times of the days, and to better control when the controlled devices go off. There is a pretty lengthy discussion about this in many forums and the wiki, but the programs are generally a variation on this theme: if control motion sensor is switched on then run light program (then path) else light program: if then set garage lights on wait xx minute set garage lights off else

This sounds like how I expect momentary "B" to operate. Of course, if your sensor status never changes, then the IO linc may think that your door is always closed, and respond only to on (open) commands in momentary C. I experienced a little confusion about wire colors from the sensor. Which two color wires are you using to connect to the IOLinc? I think I am using the red and black, which gives me an "on" when the door is open. I recall the instructions showing green and red wires from the sensor connected to the IOLinc, which did not work for me (experienced similar problems to you). Try green and black, or red and black, depending on whether you want on to equal open or closed. Given that your IOLinc seems to be seeing sensor status (as evidence of the LED indication), I am with Sub-routine on this. If wiring the sensor differently does not fix your problem,it sounds like a potential faulty IOLinc.

I suspect most people who have an ISY-99 use programs for motion sensors, for the reasons you state. When you state that you have KPL-C linked to the lights, you did this through the ISY-99 by creating a scene. Correct? (If you did this manually, then I suggest re-doing it through the ISY). If so, then you already have a scene that includes the KPL and lights. Your program should simply turn this existing scene on and off in response to the motion sensor program.

You did not specify they type of motion sensor (did you?). If it is intsteon, then you could create the effect you want using either scenes or programs. If you want to do it in a scene (possibly best), then create a scene via ISY with motion sensor, light, and KPL. Sensor and KPL should BOTH be controllers in this scene. Of course, you will be relying on the motion sensor to turn things off after certain time. If you prefer using a program (for timing or other reasons), then I suggest creating a scene with the KPL and light, with KPL as controller. (I suspect you have already done this, correct?) Then, use the motion-detector-initiated program to turn the scene on, rather than turning the light only. Turning the scene on will turn both light and KPL.

I guess this is true, but I saw "3-way" and "KPL", so I thought there may be a possibility that some were hooked up to the switches. Still, if there are indications of power to the various devices, then I continue to suspect they are wired correctly. The fact that the lights come (flash or otherwise) on makes me think they are wired properly. The lights blink, or the insteon devices blink? I assume he refers to the lights, themselves. I have experienced the actual device load (lights in most cases) flash when I have communication issues. (At least I think I have.) This all strikes me as communication issues.

I am not so sure that this is an issue. Can you control each light locally (by at least one switch directly)? If you are able to turn all your lights on by means of at least one switch, and all other switches have power (little LED is lit), then they are probably wired correctly. For now, I would focus on the phase coupling issue brought up by others.

I don't believe this would work. The folder would always be true (no condition to make it false). Additionally, folder conditions don't cause an included program to trigger, only enable the programs within the folder. The included program, while enabled, would never be triggered.

I wonder if breaking this out into two programs will solve your problem. First program something like: if sunset then run yard light program (then condition) else Next program, yard light program: if then wait 20 minutes turn on yard lights else

Using the ISY to cross link them....create a scene that includes both devices as a controller.

is it possible that you have the same X-10 address assigned to the two buttons? Try clearing the X-10 address from one (directions are found in the instruction book). Perhaps this will solve your problem.

you may have to better describe how you have set your system up. Do you use scenes? Programs? Both?

Wow. I suspect your multiple-ISY installation puts you in an exclusive group. I would imagine most of us could only speculate about what may work in your case. Have you tried adding your "ALL OFF" KPL button to all three ISYs? Once added, can you not create a program on each ISY to turn off the applicable devices in response to a KPL off command?

My versions of KPL are relatively old (six button), but my recollection was to simultaneously hold buttons a and d. It is probably better and easier to do with the ISY. I don't have mine currently available to confirm, but I believe there is a keypad backlight brightness option when you have selected a given keypad device from your device list. Regarding your scene, forgive me but I am still a little confused. So you have a program that is working that, when you press the scene D button opens and closes the garage door and the button indicates door status. Great. This looks like the same thing as previous, but now it doesn't work? I think my temptation would be to experiment with some options. Perhaps putting button D into non-toggle on mode and using a program to open or close the door any time an on signal was sent, then use a program to turn the button D off when the door sensor senses closed. Normally, a button is always lit in non-toggle on mode, but I understand they can still be controlled as part of another scene. Sorry about my confusion. I can be a little slow at times. I am getting old.

What is supposed to happen when you press button D? Anything? Nothing? Is it an indicator only or do you want to be able to control scene D? I have not tried this to confirm, but you could put your button into toggle-off mode. I am thinking that one can still turn it on remotely (in your case, from a garage sensor), but manual presses will only send off commands. Would something like this work? Background lighting levels can be adjusted manually (I would have to look at a manual to confirm steps). Newer devices can be controlled by the ISY, I recall. When a device is selected from your list, do you not see an option for this?

I looked quickly, but my suspicion is that you have an issue with your priorities between ands and ors (I forget the term used in math and boolean logic). "And" are executed ahead of "or" I have added a couple of parentheses to illustrate how I suspect your logic is flowing based on standard priority: -( Control 'Mbed ceiling floods' is switched off or ( X10 'B5/off (11) is recieved And Status 'Fam Rm Tbl Lamp' is on ) or Status 'Curts office" is on -) In this case, this condition would be true if either of the three "or" conditions are true. This means that if the Mbed ceiling floods is switched off, then this condition will be true regardless of anything else. If Curts office is on, this statement will be true regardless of anything else. etc... Is this how you want it?

That would be simple and effective. If you WANT to be able to separately control them, you have a couple of options. You could leave the inlinelinc separate and turn them both off and on at the same time using programs. Downside: you have no manual control over the inlinelinc. You could also create a new scene with the inlinelinc and switchlinc as responders and use a program to turn this scene on. Still no manual control. If you want manual control over both SWL and ILL while still maintaining individual control over the first trasformer, I believe you will need another switch somewhere. Perhaps you should replace the SWL with a keypad and control each separately?