apostolakisl

Realize that if the light is already on, the program will keep it on.. . until the off time. So if it were a table lamp that someone turned on to ready a book, it would shut off at the end time even if it was already on at the start time. This may or may not be what you want.

I do have situations where I want an automated lighting event to be cancelled if the light is already on. I assume that the light is on for a reason and thus I wouldn't want it to shut off. To do this properly, however, requires 2 programs. If you do it as a single program, then the program will actually shut the light off at the "on" time since the light status would be "on" at the "from" time. . . the "if" would be false. . . and the "else" would execute. As 2 programs it would be like this If time is 12:40 and status light is off Then run program 2 then clause Else blank Program 2 If blank Then set light on wait 5 minutes set light off Else blank EDIT: Another pearl to the newbie: You might think, why not use the "wait" command in the first program? The reason is as follows: Programs in the midst of a "wait" will be cancelled if something in the "if" section is triggered. So, in this case, the "status" statement would trigger if something changed the status of the light (manually or via a program), the "wait" would be terminated and the "else" clause would execute. But having the "wait" execute in a second program prevents the "wait" from terminating since that program has no triggers (the "if" is blank). The "wait" can only be terminated by another program doing a "run then" or "disable" or "stop" or "run else" of program 2 (or you could manually do the same). Whenever you use a "wait" command, you generally will need to break it into 2 programs. The exception to this is when the "if" section contains no statements that might trigger during the "wait". The same holds true when using the "repeat" function.

You need to understand how "from. . .to" and "from . . . for" statements work as well as triggers. These statements act as triggers twice. Triggers cause the program to run and will always result in either the "then" or "else"clause executing. 1) The first trigger is the "from" time. Provided there are no other statements that are false, the program evaluates to true and the "then" clause runs. 2) The second trigger is the "to" time (or the from time plus x minutes/hours. . ). The program runs again and at this time will evaluate to false no matter what else is in the program. When a program runs and evaluates to false, the "else" clause runs. Pearls: 1) The program does not assume that just because you turned it on in the "then" clause, that you want it to turn off in the "else" clause. You must state it. You must tell it what to do when the time expires (like turn the light off). This opens up more options for you since maybe you would want a different scene to execute when the time runs out. 2) Any other statements in the "if" clause may also cause the program to run. If other statements cause it to run in between the two times, provided everything else is true, it will run the "then" clause. If anything in the "if" clause is not true, the "else" clause runs.

let me tell you how I have it in my house. I have a kpl next to my bed and one of the buttons is used in the fashion that you suggest. I have one scene which contains that kpl button and most all of the switches in the house (except lights in the other bedrooms). For the most part, it is set to turn all of the house lights off. A few of the house lights in that scene are set to be on at certain levels for the "house night light mode". I also have a program which turns all of those lights off in the morning automatically. When that kpl is lit, it means that the night time scene is on and all of the lights around the house are as they should be. To keep the kpl's light status consistent with the lights actually being in night time mode, I have a rather unfortunately large program. This program contains most all of the lights in the house and checks to see if each of those lights is as it should be for the night time scene. If it is not, it turns the kpl in the bedroom off so that I know the house is not in night light mode. Pushing the kpl will then activate the scene and put all of the lights into the correct state and light the kpl button. This is essentially exactly what you have asked for except that the kpl is lit when you would rather have it dark. You could do it your way by not having the kpl in the scene but rather have the status of the kpl trip a program which turns the scene on. And then your gigantic program that checks the status of all the lights would set the kpl to off when all the lights are as they should be or on when they are not.

my pleasure

I would suggest setting a variable as a "blocker" Basically like this. If Control '0B-IOL-Basement sensor-Sensor' is switched On and $wateremail is 0 Then Set '01-AL-Pantry flood siren' On Send Notification to 'Tim/Al Aldeman' content 'BASEMENT WATER SENSOR' $wateremail = 1 Run program 2 then clause Else - No Actions - (To add one, press 'Action') PROGRAM 2 If blank Then wait 6 hours $wateremail = 0 Else - No Actions - (To add one, press 'Action') This would send you no more than one email every 6 hours. You can adjust the time to suit your needs.

Also be sure to understand that: The From/To programs only run twice (once at "from" time, once at "to" time) if the "if" clause doesn't have any other trigger statements. So, if you are adding other conditions to the "if" clause, realize that they may also trigger the program to run at other times, which can cause conflicts like you mentioned. For example, if you had: If status of light "a" is off and From 8 am to 9 am Then Set light b on Else Set light b off anytime the status of light a changes the program will run either the "then" or "else" in addition to the 8am and 9am runs.

I am not sure if the program works as desired, but if not . . . you can split it into two programs to avoid the problem If on Sat from sunset to 11:15am next day Then Run program 2 then clause Else turn lights off set temp to whatever Program 2 If - - blank Then Wait 4 hours 1 minute turn lights on set temp to 70

I did a preliminary test and hooked light to an inside lamp. No problem with recognition on ISY using LampLinc 2 pin Dim. The light responds instantly with ISY and does dim, but there is a flicker when dimming down. Once light is dimmed there is no flicker. I set it up with motion detector and it works as programmed. So far I am happy with this and will be putting in garage overhead light over the weekend. The LED appears to be the same or brighter than a 60 watt. What about color? Is it like your typical 2700k incandescent or more bluish like a lot of cheaper led's?

I have wondered if there is any long term affect on re-writing the programming on a switchlink 2x/day 365 days per year doing this. Comments?

I have tried quite a few different LED bulbs myself. The CREE CR6 bulbs from HD (or cheaper on ebay if buying lots of them. . . I now have close to 100 between my home and office) are very good. The 2700K temp is very natural and colors represent very well. You really can't tell the difference between them and incandescent. They dim very well and only consume 9.5 watts and have a 5 year warranty and if you read the warranty it is not a bunch of BS like with other brands (mail it in with upc receipt yadayada. . who saves upc's!!! and who is going to pay to mail it in!!!!) So far, I have not had any failures of CREE bulbs which to me, is the best warranty. And I have lots of them. I also have a bunch of CREE ceiling troffers in my office. These are obviously not of much point in discussing here, but they are very nice. The phillips a19 style bulbs are also very natural and project light in all directions. They bulbs work great behind lamp shades. They don't work with clip on lamp shades and you won't want them if you can actually see the bulb. I have yet to see an LED that looks good when the bulb is exposed to direct line of site. I also have some phillips candelabra bulbs (2.5 watt) and they work well behind shades. I would not use them where you can see the bulb, but some people might. I have not been very happy with utilitech bulbs. I have had several fail (2 out of 4) and the warranty is useless. I have some Sylvania par spots that fit in 3 inch fixtures. They so far are fine. The light is a bit contrasty however. They throw harsh shadows in other words. I have not had any trouble with any of LED working with Insteon dimmers.

Based on my own experience, I very much agree with the above.

Assuming it isn't the end of the world if your ISY gets flaky on you, I would try it at 5v. If it starts needing reboots, then you can move up the voltage. But if your 5v supply is nice, you shouldn't have any troubles. I certainly have not.

I have my ISY powered off of a set of terminal blocks hooked up to an ATX power supply. Along with the ISY it is powering about a dozen other items both 12 and 5v. It has been rock solid at the 5v. However, ATX power supplies produce a high quality, stable, clean 5v through a wide range of current draws. Generally speaking (and I can't say for sure with ISY), electronics like this when presented with power above their need, dump the excess to heat via a voltage regulator. I have not opened my ISY to see what is in there, but you will recognize it if it is there as a chip with 3 leads, often mounted vertically with a heat sink attached usually right near where power enters. So, in short, providing more than the minimal voltage will probably result in more heat. Heat is generally bad. However, if your 5v power supply is flaky, it would be better to over volt it a bit and let the ISY clean it up and bring it down to 5v. So, there is my opinion.

I can almost guarantee you that your problem is that during the 20 second wait, something happens that re-triggers the program to false. If Status '01-SLD-Powder Room' is On And Control '01-TL-Powder Room-Opened' is switched On The above 2 statements are triggers for the program. If the status of the light changes during the 20 second wait, then the program re-evaluates to false, and the enable lines below never get run. Then Disable Program 'Powder Room Garage-2' Wait 20 seconds Set '01-SLD-Powder Room' Off Enable Program 'Powder Room Garage-2' Enable Program 'Powder Room Garage-2' The way to avoid this problem is to split the program into 2. If Status '01-SLD-Powder Room' is On And Control '01-TL-Powder Room-Opened' is switched On Then Run program 2 then clause Program 2 If blank Then Disable Program 'Powder Room Garage-2' Wait 20 seconds Set '01-SLD-Powder Room' Off Enable Program 'Powder Room Garage-2' Enable Program 'Powder Room Garage-2'

The appliance linc would turn on if you had in a program setting it on and the program was "true" at startup. Like if it were supposed to be on between two times and the start happened between those two times. If you wanted it to revert to its last state, you would have to have a variable track its state and have the run at startup program set the on/off status according to the state.

The only thing, however, is that if the ISY does not go down with a power outage, it won't know that there was a power outage, and any run on startup programs or catchup programs won't run. Remembering, of course, that all of the stuff ISY is controlling (probably) is going to shut off when the power goes out.

Yes, except you would use "enable" timing and motion programs, not "run". You would also need a program to "disable" them when you want them to not run. For example: If light status is off and it is switched off then disable motion program If light status is on (on means 100%) and it is switched on then enable motion program The trouble with this is that you don't have any indicator of whether the program is enabled or not. If you had a kpl you could use a button on it to enable/disable the motion programs and you would know the status by if the kpl back light is on or off. Also, you might just test the basic program that started this whole thing. I haven't tested a program that uses "fade up/down" to trigger a program that in turn acts on the same switch that did the triggering setting its current level. The question I have is what if you are still holding the "fade up/down" and ISY sends the command to go to some specific percentage. I am not sure if the switch will accept that command or ignore it while someone is physically holding the fade up/down.

I am assuming the switch is connected to the load (directly to the light). If indeed that is the case, then you can not release control of the light from the switch. In other words, if you flip the switch on, the light will turn on. Turning the light on may also trigger a program that subsequently does something else. For example: If light is switched off Then set light to 25% If the light is on and you push "off" paddle (or toggle off), the light will turn off, then a split second later pop up to 25%. You can not elliminate the fact that pushing "off" makes the light turn off (provided the switch is carrying the load)

You can sort of do what you want using programs. For example, I have a bunch of programs that work as follows. If light status is off and light is switched off then set light to 25% While I haven't tried the following, I assume it would work just as my above program does. If light status is >45% and light status is <55% and light is switched fade up then set light to 75% You would need a handful of programs here to cover all the starting levels. You do have to use the "fade up" and "fade down" rather than "on" "off" because using on/off would cause the light to first go directly to on or off, followed by the program kicking in and putting the light back to the set level. This would be rather annoying.

Elk and ISY with the Elk module for ISY almost completely merges the two systems. There are a few things left out of ISY's Elk module but not many. My 2 cents here, ISY guys should add those couple things even though they aren't that big of a deal just so they can say "it is a 100% marrigage". But anyway. The basic jist is as follows. ISY has tremendous home automation programming abilities which far surpass Elk's built in programming. ISY can do a lot more with your Insteon stuff and can do it with less work and more readable and organizable formatting. Elk on the other hand is rock solid stable (not that ISY isn't, but Insteon clearly is not 100%). So you can't use Insteon technology for security or mission critical stuff. But by using the ISY module, you can get the Elk to control those security and mission critical things (like anything that deals with water or motors) and use the ISY programming interface to do it. The ISY Elk module really expands Elk's capabilities a lot and vice-versa. And not just in programming, also in notification such as emails and texts of system events.

This works, but it requires that you put in multiple "if" conditions for each and every year going forward. If this is something you almost never need, then you can just write the program with multiple "if" conditions for each year going forward 10 or 15 years and call that good enough. If you think that you would be writing lots of date programs like every December, or every 3rd wednesday, or every 3rd day, or every Jan 3rd, and so on, then you should consider downloading the date function programs I wrote a while back. http://www.universal-devices.com/mwiki/ ... _Variables

Yes, it would be nice if ISY natively made all of the individual components of date separately addressable programmatically. That of course is exactly what I created with those programs. If you currently do not have any variables on your ISY it is a pretty quick thing to import the programs and name the variables. If you already are using varialbes and have conflicts it gets more time consuming depending on the details. I considered re-writing the programs starting with variable 50 assuming that almost no one will have used that many variables already, but frankly, I have better things to do right now then "fix it if it ain't broke" The programs work very well. I have had it up and running for a long time now, maybe a year without any problems. It also successfully managed the recent leap year.

Here is a series of programs I wrote for ISY. http://www.universal-devices.com/mwiki/ ... _Variables Perhaps it is more complex than you want, but once implemented it opens up the options for virtually any date function. This would include every other,third, fourth, etc. You can also do even/odd days only, things that happen on a weekly schedule or on a specific week of every month. Also annual recurring events like holidays, birthdays, and the sort.

Do you have an ETA for zwave?