oberkc

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.

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