apostolakisl

As above. I use remote desktop from a tablet. Trying to do it from a phone would be very challenging with the small screen.

Here, just separate out the toggle program from the temp setting. Then you can use your from/to. If On Thu at 12:00:01AM And $Every.Other.Thursday is 0 Then $Every.Other.Thursday = 1 init $Every.Other.Thursday = 1 Else $Every.Other.Thursday = 0 init $Every.Other.Thursday = 0 If On Thu From 8:00:00AM To 4:00:00PM (same day) And $Every.Other.Thursday is 1 Then Set 'Downstairs - Main' 85° (Cool Setpoint) Else Set 'Downstairs - Main' 74° (Cool Setpoint) If On Thu From 11:00:00AM To 11:00:00PM (same day) And $Every.Other.Thursday is 0 Then Set 'Downstairs - Main' 74° (Cool Setpoint) Else Set 'Downstairs - Main' 76° (Cool Setpoint)

No, that won't work. Please go back and read the post where I said it won't work the first time. You can't use the from/to. The "to" will be false every single thursday and run the false which will screw up the 0/1. And your second program for the other Thursday shouldn't set the variable. The first program is toggling the variable. Your two programs will fight each other with variable.

I don't know what your schedule is. Lets say that you have a normal schedule mon-fri. Write a program that covers that normal schedule and check off every day except for Thursday. So now all of your week days are programmed except the Thursday the cleaning lady is not there. Then write a program to do every other Thursday that is the opposite of the one above. In other words, swap all your 0's and 1's so it covers only the Thursdays that the cleaning lady isn't there.

That won't work. Your else clause will run every Thursday at 11pm, not every other Thursday since Thursday 11pm is always a trigger and will always run false. Try this. If On Thu at 11:00:00AM And $Every.Other.Thursday is 0 Then $Every.Other.Thursday = 1 init $Every.Other.Thursday = 1 Set 'Downstairs - Main' 74° (Cool Setpoint) wait 12 hours Set 'Downstairs - Main' 76° (Cool Setpoint) Else $Every.Other.Thursday = 0 init $Every.Other.Thursday = 1 EDIT!!! this should have been 0!!! If you want it to start this thursday, set the variable to 0 on the variable page, if you want it to start next Thursday, set it to 1. It will automatically be set to 0 when you create the variable so if you want to start this Thursday you don't need to do anything in actuality. Once the program is set in motion, it just gets toggled back and forth every Thursday 0/1. I also added the initializing line so that it won't get messed up by a reboot of ISY. I'm a bit confused by why you need the setting to 76 degrees at 11pm as part of the cleaning lady routine. Don't you have it set to 76 every day as your normal bed time routine? If so, it doesn't need to be in this program at all. I assume you have another program that sets it to 76 every day at 11pm regardless of whether it is the cleaning lady day or not.

Two choices. 1) If On Thu Time is 8:55:00AM And $every.other.thursday is 0 Then $every.other.thrusday = 1 Cool house (I don't have Insteon thermostats so I don't know how this terminology goes) Else $every.other.thursday = 0 I haven't tested this but I think it should work. The next solution I have tested. You probably need to use an integer variable as a state variable might re-trigger the program. Not sure on that, but for sure an integer one won't. EDIT: I have now tested it. It works. It also must be an integer variable as a state variable does re-trigger. 2) Download the calendar program I wrote. It has a complete set of functions allowing pretty much any type of date scheduling. http://www.universal-devices.com/mwiki/ ... _Variables This would be the way to do it if you think you will want more programs that happen based on something different than the somewhat limited date functioning built into ISY.

The issue I have with Elk is somewhat similar in that the zone status and output status do not seem to be polled at startup and so my programs that use that data are not executing properly after a startup. With weatherbug it is a better situation because you know it will be polled shortly whereas with Elk it seems that there is never a generalized polling. . . unless you do it manually. Values only get updated when they change so if there is no change they stay blank. For you, I would suggest putting your weatherbug dependent programs in a folder. Write a program that checks weatherbug data for being "0". Until at least one of the values is not 0 (humidity would be a good one since it should never actually be 0), then have the folder set to inactive. This is assuming that you are correct in saying that unpolled weatherbug data shows up as "0".

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.