oberkc

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?

The 75watt flood light IS your load. To double-check, these are incadescent (as opposed to CFL or other) correct? One other shot-in -the dark....where is your PLM plugged? Is it near the plug-in for your computer equipment? Do you have UPS, conditioned power, power supplies, etc... all/any plugged in outlets near the PLM? Do you use any filters in your house? If not a defective device, this sure sounds like communication issues, especially in light of the failed scene test.

That is good news. Still, you will serve yourself well to understand scenes, controllers, and responders. In the manuals of the various insteon devices, they speak of things such as linking and cross linking. When one links devices, one is creating scenes. To link a device to another, first puts a device into linking mode. This first device will be the controller. Then, when putting a second device into linking mode, it creates a link to the first. The second device is the responder. This means that the first device will control the second, and the second will respond to the first. At this point, the second device will not control the first, nor will the first device respond to the second. This is a scene containing two devices, with device one being a controller of that scene If one wants both devices to act as controllers for the other, one must cross link. This would be done by repeating the steps, above, except in opposite order of devices....start with device two, then add device one. You now have a scene with both devices being a controller. The ISY can make this job a little less tedious and time consuming. Remember one difference, however. with the ISY, controllers are, by definition, responders to a scene. While not terribly important, note also that the ISY (technically, the PLM) is also a controller and responder to this and all other scenes created by the ISY. If you have an ISY in your system, I recommend creating all scenes/links using the ISY. If you manually created links before, you may be better off long term is you re-create these on the ISY. In your case, your scene should show two devices, both being controllers.

I don't know which garage door "sensor" that you are using, or the device you are using to actually control the door, itself. It sounds, however, as if you have at least added all these devices to your ISY, correct? Scenes are in inherent part of insteon, made easier to create with the ISY. In the admin mode, with your device list on the left, there is a little icon along the top to add a new scene. Choose that icon, give your scene a name ("garage", for example). Click and drag your devices (keypad, sensor) into the scene. When prompted, make both a controller. One thing that is unclear to me...how did you get the door to respond to the keypad? Did you create an ISY program? Did you manually link the sensor and keypad (in which case, you have already created a scene)? You will definitely want to read up on scenes, both here, and at smarthome. "Scenes" are nothing more than a term used to describe two or more insteon devices linked to each other.

In general, this is my understanding. Programs are executed only at the time a condition is evaluated, which is when one or more of the statements transitions. I don't believe that a the if condition has to change state, but only be evaluated, even if the state remains unchanged. Based on the number of posts about this in the past, this is apparently confusing to many. You may benefit from tracking down some of the earlier topics.

I have purchased many lamps from superbrightLED. All of my purchases, however, were for 12V bulbs for use in my landscape fixtures and for my car. As said by apostolakisl, one must be selective. The output claims about some LEDs are overstated. Another factor about LEDs that I have seen it in the beam patterns. Incadescents, by nature, tend to send light in all directions. LEDs are typically designed in such a way as to as to concentrate their output in a more limited direction. Like apostolakisl, I have purchased (from other sources such as sam's club, Lowes, Home Depot) replacement bulbs with medium edison base and candelabra base. I have fount that most of these are not good replacements in all uses. Most of their light is concentrated straight "up" (away from base). This tends to limit the useful applications. In general, I like from superbrightLED those that have the "SMD" high power LEDs, such as: http://www.superbrightleds.com/cgi-bin/ ... tm%23OTHER http://www.superbrightleds.com/cgi-bin/ ... m%23MALIBU http://www.superbrightleds.com/cgi-bin/ ... m%23MALIBU http://www.superbrightleds.com/cgi-bin/ ... x48SMD.htm I like them all in warm white. This is somewhere between incadescent and hologen, by my eye. Besides those for landscape and car, I have not purchased any others. However, the MR-16s I use for landscaping would work anywhere else that requires MR-16 (12 volts). In my estimation, the warm white might be too yellow for your application, and the cool white too blue. The color of halogen (4000K?) would be ideal. For some reason, I could not identify the E27-xW4 from their web page. My only suggestion is to pay attention to color (look for about 4000K +/-500) and beam pattern/spread. If this is an edison medium base, check out sam's club. They had a screw-in spot bulb that I have tried and currently use. It is close to halogen in color and a pretty narrow beam that might work well in highlighting your cabinet.

Most of my fixtures are those commonly available at the normal places. I tend to look for the aluminum or copper ones. Plastic has simply not held up for me. They use either wedge base or bi-pin lamps. Regarding lamps, I have used exclusively: http://www.superbrightleds.com/led_prods.htm. All lamps that I use came from here. Also, my four power supplies came from this outlet. I am a happy customer of this company. Be sure to pay attention to light color. I prefer mostly the "warm" whites. find the lamp with the correct base to fit your fixtures. Try a couple to see how you like them, find your favorites, then do your entire landscape. Based on guidance from this company, I understand that LED lamps work better on a regulated power supply. Many of the standard landscape lighting transformers may send to high a voltage, due to the low power consumption of LEDs. So far, this has worked for me.