oberkc

My understanding regarding transformers is that some of the old magenetic (?) types can overdrive voltage at low power. I have four power supplies at the four corners of my house (each on an appliancelinc). There is less than 20 watts on each. I was concerned that the high voltage (espcially startup) can cause long-term damage to the life of an LED lamp.

Cost management? What is this? My motivation for switching over is broad-based. My motivation for switching to LED is only marginally related to cost. I don't like the way incandescent tend towards yellows and orange when dimmed. Some of my lighting circuits have lots of fixtures, which can push the capacity of my insteon switches. I don't like changing light bulbs, especially in difficult fixtures. I don't like the way CFL dims. I am willing to pay an upfront cost while earning an income to limit expenses when retirement hits. Incandescents get hot, which can cause secondary issues. I prefet the look of LED can lights/trim rings. My cost management is limited to frequent (near daily) visits to Home Depot, Lowes, Menards, Keim Lumber, Sam's Club, and Walmart, and keeping a sharp eye open for sales and clearance items. Whether this proves to make pure economic sense remains to be seen and depends on how long these things last. I tend to prefer local stores to on-line shopping, so most of my lamps are those available at the stores listed earlier, with most from Lowes and Home Depot. I don't remember all the brands, but phillips, utilitech, sylvania, and ecosmart seem to come to mind as brands that work well for me. I recall one early example of a lamp that messed with my insteon communication, but later experience has pretty much removed this consideration from my mind. Both Lowes and HD have a style that I like in table lamps or globe-based fixtures. http://www.lowes.com/pd_338931-75774-LA19/OM800/LED_4294801193__?productId=3550116&Ns=p_product_qty_sales_dollar|1&pl=1&currentURL=%3FNs%3Dp_product_qty_sales_dollar%7C1&facetInfo= http://www.homedepot.com/EcoSmart/h_d1/N-5yc1vZ4b8/R-202668646/h_d2/ProductDisplay?catalogId=10053&langId=-1&storeId=10051= These are two styles that have worked well for me that provide generally broad coverage and good color. For retrofit into can lights, I was limited by height, so I was compelled to use the lowes version - sylvania (style with trim ring) as opposed to the cree-based units at HD, which did not physically fit. These are working well so far. I tried simple PAR replacement bulbs, but did not like the look. The bulb showed below the trim ring, which I did not like. All landscape lighting is LED based and with all with refit bulbs. This was my exception to local purchase. All came from superbrightLED.com. Paying attention to light color and lumens was my only consideration. This also required the replacement of power supplies to keep the voltage better controlled. After three winters and working on my fourth summer, I have had NO lamp failures. If you want more specifics on landscape bulbs, let me know. On the exterior, I use the same bulbs as above where applicable. I have also used PAR-type lamp replacements where appropriate for the fixture. Besides color, I found it important to pay strict attention to "flood" versus "spot", the the LED versions of the spot to have a very tight beam, not appropriate for general exterior illumination. The two cases where I have yet to find a suitable LED replacement are with the little candelabra-base chandelier bulbs. Most strike me as physically too large for my fixtures. I use thes in fixtures and window candles. I am watching with much interest when these become available. I have probably already written too much and should be accused of hijacking this thread.

Like others have pointed out, the decision to purchase LED bulbs is much more a complicated decision than for incandescent....color, dimming, beam spread, electronic noise, compabibilty with ISY, etc.... Having nearly completely replaced my entire house with LED lights, I have tried several different configurations. Based on my experience, my major concern with this bulb is beam spread. Similar designs that I have tried tend to emit light only from the "upper" hemisphere. If true for this bulb, it makes it (to my eyes) unsuitable for table lamps and other fixtures depending on an even distribution of light across the entire globe. While I really like the concept (insteon-enabled bulb), I suggest starting slow with this one until you are sure you like the results in the particular fixture in which you intend to use it.

When you added these to the ISY, what option (keep links, remove links, add related devices) did you choose? I would follow the advice suggested by Xathros. Having said this, when adding a new device, one has the option to keep existing links and add linked devices. You may find this approach more appealing, but I would be concerned about the 'garbage' about which Xathros speaks. Both approaches require you to first remove the devices from the ISY-99, then re-add them. I am not aware of a way to pull link data from a device, once it has been added to the ISY.

Do you want the garage light to turn off five minutes after the door is opened, or after it is closed? Using "status" for your garage door as a trigger, you run the risk that if the door is closed prior to the five-minute time period, the program will halt execution and the light will stay on. While unlikely, if you open the door less than five minutes prior to sunrise, you will have the same problem. Try, instead, control: If From Sunset To Sunrise (same day) And control 'garage door sensor' is turned On <<< try "control" here, instead Then Set Scene 'Garage Lights' On Set Scene 'Kitchen Lights' On Send Notification to 'text' Wait 5 minutes Set Scene 'Garage Lights' Off Else wait 5 minutes <<< I would add these statements to account for the sunrise problem set scene "Garage Lights' off

"Status" will trigger an evaluation (and resultant execution) on ANY status change (on, off, brighten, dim, etc...) for ANY reason (directly controlled, or otherwise). "Control" will trigger an evaluation only upon reciept of the specific command ("control is set to on" will response only to "on" commands), and, I believe, based only upon that specific device initiating the change (not when the device is, itself, responding to another controller).

I have no major logic change suggestions. However, like some of the others, I suspect your problems are related to "status" of some devices, rather than "control", and how this can interrupt execution of your programs. I have not given it great thought, but my first suggested change: Powder room on for 2 If Control 'motion sensor' is On [color=#BF0040]<<< try using a control from the motion sensor[/color] Then Wait 2 minutes Set '01-SLD-Powder Room' Off Else - No Actions - (To add one, press 'Action') I also agree with apostolakisl...something is interrupting your 20-second wait and I suspect it has to do with the "status" condition in your third program. Try, instead: Powder Room Off If Control '01-TL-Powder Room-Opened' is switched On [color=#BF0000]<<< Then Disable Program 'Powder Room Garage-2' <<< am not sure that this serves any useful purpose Wait 20 seconds Set '01-SLD-Powder Room' Off Enable Program 'Powder Room Garage-2' [color=#BF0040]<<<< One time is enough[/color] Else - No Actions - (To add one, press 'Action')

I agree with LeeG. I would not do this due to the amount of insteon traffic needed. However, if you insist, I suggest a program. The logic (if not exact language) would be: if status gate is open then repeat turn keypad on wait a few seconds turn keypad off wait a few seconds else turn keypad off

That is consistent with my understanding, as well. This is why I believe programmatic solutions will be difficult for your situation. Also correct. I am sorry that I failed to recognize that you have not yet come to this realization. This will not solve your original mobilinc problem...you will still need to control the scene from mobilinc. However, the switches will now stay better in sync and should display correctly in mobilinc.

LeeG...correct me if I am wrong, but I don't believe this program will work when "ICON Dimmer 1" is being activated by mobilinc. I thought a "control" status activated only by direct button presses of the device.

I don't believe this is correct. Given a single button switch (as opposed to a keypad), if the LED indicates on, the device is on (assuming no device failure). To be clear, for some insteon switches, the LED being on indicates the switch is off. There is no way to separate the LED status from the load being controlled by the switch.

I am with LeeG on this one. You are fighting the core design of insteon here. Furthermore, creating a program to perform a scene function will introduce a lot of opportunities to enter these endless programming loops (as you have experienced). In addition to all that, introducing mobilinc into the equation eliminates the use of "control" as a program condition (I believe control conditions work only when a device is physically activated). If you want to control the scene with mobilinc, control the scene rather than individual devices within the scene, even if those individual devices are defined as "controllers". Remember, scene controllers behave as controllers only when directly activated (button press). They behave as responders when commanded externally, such as via the ISY or via moblinc. Everything you describe makes me think your system is operating properly.

This is because such devices are set up as "controllers" of a scene with those other devices. However, when controlled via a program or admin panel, the behaviour better matches that of a "responder" device. Perhaps a good hypothetical analogy would be if switch A is controller of a scene including switch B as responder. Switch B is controller of a scene that includes switch C as responder. Pressing switch A will turn on switch B, but switch B, having responded to switch A, will not turn on switch C. Only if one physically presses switch B will it behave as a controller of switch C. In the same way, if you "remotely" control a switch (via program, control panel, other insteon device), it will behave only as a responder and not propogate commands to other devices of which it is controller.

By definition, controllers are always responders when creating a scene with the ISY. For multi-way "circuits", all switches should be in a single scene, all as controllers.

Perhaps I am missing the question. Are you asking whether you can turn off the mechanical switch on a lamp and somehow have insteon turn it on later? I believe the answer to this is "no". If the lamp switch is off, there is nothing that you can do with insteon to turn the lamp on. Neither do I believe that you can cycle the lamp switch (on>off>on) and have insteon detect this (the insteon module will remain on). My suggestion is to install a switch at the room exits and link it to all your lamps. Use inteon to turn them off when you leave the room.

I suspect the problem you are experiencing is due to the insteon feature that enables different ramp rates and levels to be established for the local (switch) setting or when called up as part of a scene. I suspect that if you select the local switch from the admin panel, the "on" level remains 100%, but if you select the scene that includes the switch, the ramp rates and levels for that same switch are different. Your program changes ramp rates and levels for the scene, but leave unchanged the ramp rates and levels for the local device. Unfortunately, when you control the switch manually, the local ramp rates and levels apply, not the scene settings. You could change the local ramp rates and on levels in the program. Unfortunately, I cannot offer the exact language (not at my ISY and don't have it memorized). If another does not offer a suggestion soon, I will get back here when I am near my computer.

No, not normal based on my experience and expectations. My experience is that all buttons operate independent of each other unless specifically configured otherwise. Is it possible that you have inadvertently configured your keypad with some type of button grouping?

I found the manual to be a little confusing in this area. Regarding wire combinations, you should use the ground wire and one of the other two. One will turn the sensor on when closed, the other will turn the sensor on when open (NC, NO). So long that you understand what is happening, you can program the IOLinc and ISY to work properly. Mine is wired in such a way that the IOLinc is "on" (LED lit) when the garage door is open. I include the sensor in a scene with a keypad button which results in the keypad button being on when the door is open. Given this, opening the door transmits an "on" signal, closing the door transmits an "off" signal. If one prefers to set it up such that closing the door sends an "on" command and opening sends an "on", reverse the wires (or change the location of the IOLinc). I found the garage kit to be a relatively complicated insteon setup, with relay wiring and location affecting IOLinc configuration, scenes, programs, etc. There is no single right way to set this up, and all have to work in harmony. This is a case where understanding the how's and why's and what's-going-ons really helps.

Yes. I solved it by replacing the leviton switches with insteon.

To add to LeeG's post, sensors can only be controllers. They cannot be responders. Unlike LeeG, I fail to see the harm in maintaining a scene with the two switches as responders (just remove the sensor). However, since they are already "linked", then there is no need to create a second scene. You did "link" them by creating an ISY scene with both as controllers, correct? The momentary time defines how long the relay is activated, not a delay. To program a delay after the door closes, use an ISY program such as: if Status 'IOLinc-Sensor' is On then set "link scene" on else wait 5 minutes set "link scene" off

LeeG is nearly 100% correct with his responses, so I cannot help but wonder if there is a failure of communication here. Are you sending "on" and "off" commands to the IOLinc, or to a scene that includes the IOLinc?

To elaborate a bit more, please describe which device you wish to use to control the door and which device, if any, you wish to use to display the status, and how you want that status displayed (on = open or closed?). There is a nice explanation in the universal devices wiki. Search on "garage". This is the approach I used.

These kinds of things are usually available with a simple google search. I tried "rogers cell phone email to text" and quickly found: 10-digit cell phone number @ pcs.rogers.com Give it a try. Hopefully this will work for you.

Try: * Sasktel: [10-digit phone number]@sms.sasktel.com

I suspect that when the "then" clause runs, it turns the torchier light on, which changes the program condition to false, halting the "then" cluase and forcing execution of the "else" clause.