apostolakisl

I might add, and Lee pointed this out to me, that ISY does not read the actual percent level after a fade up/down command. It estimates it based on the time between the fade start command and the fade end command. If after a fade up/down happens, you query the device, you will almost certainly see the number returned as being different than ISY guessed it to be (usually not by much though).

I would vote for this solution. You could write all kinds of programs that either allow for resistance heat or not based on the type of situation. Morning warm up could start a half hour before you awake and then 5 minutes before it could allow the strips to come on if needed. That sort of thing.

Never had anything not in a scene be red italic. Java issue makes sense. I clicked away like crazy at the devices not in scenes and after a while java started to screw up and I got some italic-like looking stuff. I'm running Java 6

In scenes, the red italic item is a controller. At least that is how it is on my ISY.

I have noticed you using "else" clauses a lot. Generally speaking, "else" clauses end up with unintended consequences. There are times where else clauses work very well but in ISY, they are not that common. As a new programmer, I highly suggest sticking with "if" clauses that when true cause something to happen and when false don't do anything (else clause is empty).

Use the print screen command on you keyboard (hold the blue "fn" key and the "print screen" button). This turns the contents of your screen into a picture and holds it in memory. Then paste (control v) the picture into a photo program and save it. Then you can upload the photo to a web hosting service and put the link into your post.

You shouldn't use the "else" clause to make this work right. The trouble is you have two programs running on thursday and both are going to run false at the "end" time The best way to do this is to separate your two times. Have one program for each time instead of from/to. I would suggest you do that with all of your programs. Each program should just say at x time, set to y temp. You can have the temp change as many times during the day as you want and there will never be a conflict.

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.