oberkc

Yes

I did not mean to suggest that there are never reasons to check status, but, rather, in this case. The stated goal is simply to turn them on at a certain time, then turn them off at another time. I believe hyounker has the best approach given the stated desires.

I see no practical reason to check light status as a condition. If Time is from 1240 To 1245 Then Turn light on Else Turn light off

I don't believe there is "harm" from disabling the query program. I have always assumed it is there just to provide re-align ISY status with actual device, reducing the risk of a mismatch. I have never understood why running a query would change the status of a device. Perhaps the query triggers a program?

The point I was trying to make was that I see NOTHING that would cause "NIGHT TIME" scene to go off, accidentally or otherwise. I suspect there are things going on in programs or scenes that you have not mentioned or described.

I see nothing here that would cause a scene "night time" to turn off for any reason. I could only speculate on possible explanations.

Do you have access to the wiring feeding the outlet (such as in a basement or attic)? If so, break into this wiring and add an inlinelinc and filter. Replace the outetlinc with a normal outlet, controlling it with the inlinelinc.

I don't see a "night" scene. I see a "night time" and "night time indictor". What am I missing?

What is in scene "night time indicator"? Good night button? Anything else? If you are happy with how the system operates, i don't see any obvious problems.

Are you suggesting that you want this light to be, in general, permanently on, with the exception being the several-minute period immediately following a button press? Or do you want it to stay off until the following day? Do you only want these several lights to go to these levels and leave the rest as they are, or do you also want this to turn off some lights? Probably. I will call that scene "good night". you can either set the device ramp rate to this or create a program to wait some period and turn it off. I will assume the latter. I suspect there are details that are unspoken or unthought, but the logic of your stated desires should be simple enough. In pseudo code (hoping the intent is clear): If control "good night light set button" is set off << then turn scene "good night" on run program "turn button back on" (then path) run program "turn bedroom light off" (then path) else create a second program called "turn button back on" (and disable it) if then wait several minutes set "good nigh light set button" on else Create a third program "turn bedroom light off" (and disable it) if then wait five (TBD) minutes set "bedroom light" off Of course, use device and program naming conventions as you see fit.

I don't believe "keep existing links" makes any difference, either. My experience is that the relationship between the morninglinc and the lock is unaffected by anything insteon.

I am a relatively new user of mobilinc, so much of this is based on limited experience. I am not sure whether it is clear, but when you add a garage kit to your system, two devices (both part of the IOLinc) show up: the relay and sensor. You should not expect the relay to display status of the door. Neither should you expect the sensor to control the door. Mobilinc shows both devices, relay and sensor. Make sure you are looking at the "sensor" device when determining status of the door. Mine appears to work correctly.

I know I learned a few things today! Makes me want to go get some IOLincs and find interesting uses for them. I have always wanted to install a sensor on the front door and turn on lights when I enter. I just have to figure out how to programatically determine when I am entering versus leaving.

If you choose to use my suggested approach, add the delay to the second program: if status 'elevator 1-opened' is off then Set Scene 'Basement Scene 1 - Group' Fade Down else wait 15 seconds Set Scene 'Basement Scene 1 - Group' Fade Up As Xathros suggests, you can modifiy the wiats and delays to suit experience.

OK...let me take a shot at this. The general logic goes something like: I know that I want to do something (either turn them on or off) with the lights every time I the button is pressed (recieve an "off" command). What I want to do is dependent on the time between the "off" and subsequent "on" commands. If I receive an "off" command, wait a couple of seconds to see if it is still off. If so, turn the lights off. If not, turn the lights on. To do this via ISY: if Control 'Elevator 1-Opened' is Off Then wait 2 seconds run next program (if path) else Next program (disabled) if status 'elevator 1-opened' is off then Set Scene 'Basement Scene 1 - Group' Fade Down else Set Scene 'Basement Scene 1 - Group' Fade Up You will need to disable the second (next) program so that it does not trigger itself. Of course, you can use any naming conventions that you like.

I would expect this, given your original program. However, if you are trying to turn your lights off, would they not already be on? If so, then would this behaviour matter? If you still feel the need to avoid this, perhaps further program refinement could work. This is NOT what I expected (otherwise, I am surprised the suggested program works). Is not the "on" command sent as soon as you PRESS the button? Then, as you release the button, is not an "off" command sent. Knowing the answer to these questions is critical here. Your application strikes me as pretty unusual and it may be best to confirm this in your particular usage.

That would be great if it works! To this great suggestion, I add that the condition should be based on "status", as in: if status 'triggerlinc' is on

Agree with LeeG here. It is more important to know the door is fully closed, rather than fully opened (partial open is still open in my mind). Remounting the sensor is the optimum solution here.

I have experienced, in general, delayed text messages (unrelated to ISY-99 use), but don't know if this is your problem or whether it is one of your other list of well-thought-out possibilities. Until you can figure it out, perhaps use and EMail address rather than your text, to see if there are latencies there. Can you use your email accouunt to forward to a text address? Perhaps doing so would give additional clues as to the source of your problems.

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