apostolakisl

I think Chris said this, but if xxxx is the actual program (it is using its own state as a condition), it will not work properly. For example: 1) all lights off 2) program is "false" 3) turn one light on 4) program triggers, turns true 5) then runs All is good 6) second light is turned on 7) program is true evaluates to false 9) else clause runs All is still good 10) third light turns on 11) program is false 12) program evaluates to true 13) then clause runs (OOOPs, not good) You need to use a separate flag program or more easily now that we have variables, use a variable. If Status 'light a' is not Off Or Status 'light b' is not Off Or Status 'light c' is not Off Then $sledtracker = 1 Else $sledtracker = 0 If $sledtracker is 1 Then Set 'switchlinc' 100% (Backlight Level) Else Set 'switchlinc' 25% (Backlight Level) The first program will run every time the status of any of the lights change. The second program will only run when the status of the state variable ledtracker changes. ledtracker only changes when the first program goes from true to false or vice-versa. You may be able to skip the variable and use the true/false status of the first program as the if clause for the second program. I forget if a program status in the if cluase triggers a program on status change or if you need a separat trigger. Only if it is a trigger would that work. If you wanted 3 or more state to your backlights, you would definitely need to use a variable.

The program is designed such that pushing the "off" side of the paddle when the light is already off turns it on to 25%. I implemented a bunch of these programs a long time ago and actually copied it from the wiki I believe. It is (had been) a nice way to turn the lights on dimmly during the night. It has worked great until the new firmware installation. Now, about 75% of the time, the program runs when I shut the light off even when it was not initially off. In other words, the light is "on", I click "off", the light turns off, but then the program turns it back on to 25% a half second later. The program was only intended to run when "off" is pushed when the light is already "off". It would seem that the new firmware has changed the order of evaluation. It used to be that clicking the off paddle caused the program to run, then the light turned off (if it was already on). Now, it looks like the light is turning off before the program is running (most of the time). So, in effect, the program is seeing the light as off every time you push the off button, regardless of what state it was in when you hit the off button. Flow chart: (old way) starting from light NOT off 1) light status not off 2) push "off" button 3) program triggers, evaluates to false and doesn't run then clause 4) light turns off (this is good, what I want) Flow chart: (new way) starting from light NOT off 1) light status is not off 2) push "off" button 3) light turns off 4) program triggers and evaluates to true 5) light comes back to 25% (this is bad) Flow chart: (not affected by new firmware) starting from light off 1) light status off 2) push "off" button 3) program triggers and evaluates to true 4) light turns on to 25% (as intended)

I have a bunch of programs written like this. If Status 'Master Bedroom / Master/Bath Cans L' is Off And Control 'Master Bedroom / Master/Bath Cans L' is switched Off Then Set 'Master Bedroom / Master/Bath Cans L' 25% Else - No Actions - (To add one, press 'Action') After the most recent firmware update, then program is running the "then" section nearly every time I do anything to the switch. It is not a communication issue. For example, I turn the light "on". The ISY admin console changes from "off" to "on" on the main page. So, ISY knows it is "on". I click "off" on the switch, it turns off, then a second later it goes to 25%. Why is the program executing the "then" section? It doesn't happen 100% of the time, but it is happening maybe 2 out of 3. Is there a timing issue? For example, I click "off" the ISY changes it's status to "off", then the program tests the status?

Michel, Would it be possible to get an LED backlight level tutorial? When it first showed up as an option on ISY I attemtped to use it and wound up with a switch that needed factory resetting. Some threads at the time basically said "don't use it for now". Where do we stand with it at present? And to the OP. After re-reading your post and question I think I have an idea. It would seem that you want the led backlight to be brighter or dimmer based on the current light in the room. But every time a light changes you don't want the program re-sending the led level if it hasn't changed. Here is a solution. Write one program for each led backlight level you want that includes the conditions (if stuff) for those levels. Perhaps you want 3 different levels: low, medium, and bright. So you have three programs (if you only want 2 levels you can do it with one program using the "else" clause) But don't have the program's "then" section set the led's. Instead, have it set a state variable to 1,2,or3. Then have a second program (three of them for 3 states, 1 for two states, again by using the "else" clause) that looks for the variable to change value and if it does, then send the led brightness change. A program with a single "if" clause testing the status of a state variable will only trigger when that state variable changes value.

oberkc is right to say that programs won't change link tables, so I don't get that part. I can only assume you are using the "if" section here as an example for a group of programs since the above program doesn't do anything except set a true/false status of itself (as mentioned by oberck, no traffic). In short, if you don't want a program to trigger every time the status of a switch in the program changes, don't use "status" in your programs. That is the nature of "status", that it triggers programs with any status change. Use "control" if you only want a program to trigger under more specific circumstances. If you want the status of something checked after some trigger event occurs, then use two programs. The first program has the trigger event and then you put a "run if" in the "then" section which runs a second program containing the "status" situation. The second program needs to be disabled so it doesn't run except when the first program calls it.

Please put your exact program in here. Right click on it and click "copy to clipboard" then paste it to the forum.

I have 99irpro. The installation went very smoothly. The unit is running perfectly, seems to be communicating with devices faster than before (updated from 3.1.2). Maybe my imagination.

From a technical standpoint, yes it will work. However, because of the state nature of the ISY and some limitations currently in how variables can be used you will run in to a couple of ease-of-use issues. 1) if you have more than a few devices that you want to include you will end up with either quite a number of individual programs, 1 per device or an extremely complicated and hard to read set of IF/THEN clauses. 2) you will have quite a number of additional state variables, again 1 per device 3) If you have to account for devices that are not simply on/off, your set of IF/THEN statements has to account for every possible status. An AC or other temperature control would be a royal pain. 4) You cannot easily see what state the devices are all supposed to be in. Think of looking at a single scene vs having to look in each individual program. 5) Any time you decide you want to include a new device you have to set up a new variable and a new program. If you use a scene, you simply add the device to the scene and you're done. Hope that helps. The OP stated he has a couple of relays that either turn his ac on/off (I assume these are window units with the temp setting on the unit itself). This would be quite simple to implement in that situation. I truly doubt anyone would do this across a 100 device Insteon installation, it simply isn't necessary. This is a great way to make sure that the mission critical stuff gets into the proper state after a power failure. I just don't consider using the programs and variables that we paid for when we bought the isy to be a problem. That's why I bought them!

What if you had the program that turns your appliance link on/off simultaneously set an integer variable on isy to 1 for on and 0 for off and inits that value so it maintains across power failure. Set a program that runs only on start up which queries the variable and turns the appliance link on if the value is 1. I have not used the "run at start up" feature, but per Michel's comments on another thread it always runs the "then" clause upon power up. So perhaps the "then" clause is a "run if" command that runs a second program reading along these lines. Tracker for appliancelink If Whatever conditions normally turn the appliance link on Then $i.appliance.link.tracker init to 1 Else $i.appliance.link.tracker init to 0 Turn on 'run at startup' for this program If No Conditions Then Run Program 'power failure status check' Else No action Power Failure Status Check If $i.appliance.link.tracker is 1 Then set 'ac appliancelink' to on Else set 'ac appliancelink' to off

Correct me if I am wrong here, but I am pretty sure it works like this. If you have the "catch up schedule at restart" box checked, it runs all the programs that had a scheduled time to run earlier that day regardless of whether it already ran or not. If you uncheck the box and leave the 15 minute grace period it checks to see if the program should have run in the last 15 minutes and only runs it in that case. I think of it like this. When you boot the ISY, it sets the clock for 12am of that day and runs the clock at warp speed up to the current time triggering all the same programs along the way that would have triggered at normal speed.

I was asked if there was a way to have the ISY know that it was the third Wed of the month and if it could keep track of how many days away the next third Wed was. The first part was easy using the day/month/year etc programs I had written but the second part stressed my brain a little bit. I came up with a solution and thought you might like to see it (and hopefully not find any errors). I am not sure that many people will have a direct need for this, but the logic may apply to other applications. It consists of three programs, two of which are very simple and the third is a bit more complex. The concept is that it is always going to be either 4 or 5 weeks between 3rd wed of the month depending on how long of a month you are currently in and when in that month the wed falls. I wrote the program to look at what month you were in (and thus how long it is, remembering leap year), and look at what day of the month your 3rd wed is falling on, and then reset the counter to either 34 or 27 on the day after the third wed. 31 30 29 day month days to third wed If ( ( $iMonth is 1 Or $iMonth is 3 Or $iMonth is 5 Or $iMonth is 7 Or $iMonth is 8 Or $iMonth is 10 Or $iMonth is 12 ) And $iDay.of.Month <= 18 ) Or ( ( $iMonth is 4 Or $iMonth is 6 Or $iMonth is 9 Or $iMonth is 11 ) And $iDay.of.Month <= 17 ) Or ( $iMonth is 2 And $iLeap.Year is 0 And $iDay.of.Month <= 16 ) Then $iDays.To.Third.Wed = 34 $iDays.To.Third.Wed Init To 34 Else $iDays.To.Third.Wed = 27 $iDays.To.Third.Wed Init To 27 Days to Third Wed Countdown If Time is 12:00:10AM Then $iDays.To.Third.Wed -= 1 $iDays.To.Third.Wed Init To $iDays.To.Third.Wed Run Program 'Test for -1' (If) Else - No Actions - (To add one, press 'Action') Test for -1 If $iDays.To.Third.Wed is -1 Then Run Program '31 30 29 day month days to 3rd wed' (If) Else - No Actions - (To add one, press 'Action') You'll notice there is no provision for 28 day Feb's since they will always be 28 days apart and will just automatically fall to the "else" clause. Let me know what you think.

Can't say. I don't remember if it was already up or if I just opened it up right before I started working. It could have been up for more than 24 hours. I suppose you are suspecting that it was up for a long time and the clocks were running at different speeds, but how does that fit into the "sync every 5 minutes" concept.

I was following the program summary page looking for run times and true/false changes. I was looking at the clock that was running in the upper left corner of the gui. The connection is good I assume, since the program summary did change true/false and did update the run times as I watched.

Michel, I am not sure I understand you. What do you mean by "does it's one incrementing"? Are you saying that the gui runs its own clock and then every 5 minutes synchs with the ISY? Does it seem right to you that the gui would have been almost 2 minutes different? Lou

I have noticed when writing programs and testing them that the time shown clicking away in the corner of the gui is different than ISY's internal clock. For example, this morning, I was testing a program. It was set to trigger at 8:49. By the gui clock 8:49 came and went, then at 8:50:30 (by the gui clock) the program ran. The "last run time" on the gui showed 8:49:00 after that.

Walrus, What you wrote will work. I am not a big fan of "wait" commands because they open up the program to re-evaluation (unless I want re-evaluation), but in this case that won't matter. However, you are right to say my program won't work. I forgot the else. If From 3:00:00AM For 1 hour And $iMonth >= 5 And $iMonth <= 9 Then Set 'Fan' On Else Set 'Fan' Off From/For programs trigger at the "from" time (3am) and then trigger again at the "from plus" time (4am). They also will force a program to true/false if something else triggers them at times other than the "From" and "from plus" times depending on if it is between the two times (true) or outside of the times (false).

Load the day/month/year/etc program I wrote and write the following. If you PM with your email address I can send it to you If $iMonth <= 9 And $iMonth >= 5 And From 3:00:00AM For 1 hour Then Set 'Fan' On Else - No Actions - (To add one, press 'Action')

You could put a wireless bridge onto a cai webcontrol unit. If your wireless router makes it to your doc then that would work. A wireless bridge would add $40 to $50 to your total costs. Of course both that and the cai would need a weather proof enclosure and power.

Well fortunately all of my programs that I have written this way seem to be working despite this fact. But, I really think there should be an option for wait and hold If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Run and pause for finish Program 'x' (Then Path) Else - No Actions - (To add one, press 'Action') And regarding hunting2ride comment, the trouble with "wait" is it opens up the program conditions for re-evaluation. But that is a whole other topic that seemed to go on forever a while ago.

So even two programs running at 12:00:00 and 12:00:01 could end up not fully executing in order if a bunch of other stuff were going on at once slowing down processing? It sure would be nice if there were some way to force a group of programs to execute in order. Even if some other event got injected in there, if you could know for sure that your stipulated group executed in order that would be nice (ie the subroutine concept). If you have two programs that must execute in a certain order, short of separating them using widely spaced time conditions, there is no way to gaurantee order.

Well that's great. So unexplained stuff is going to change the order of operation? So is ISY jumping back and forth? A linear thread from top to bottom would be much preferred. It obviously executes the called program prior to moving on in the example I created, so it is some sort of unpredictable thing?

In my mind, when I execute a program from another program in ISY, I think of it the same as executing a subroutine in more conventional programming styles.

I did an experiment to see how ISY orders its execution of programs. Order of program execution is very important in all of my day, week, month, etc programs. Having them run at 12:00:00, 12:00:01, 12:00:02, etc is kind of sloppy in my mind. So instead I have one program cascade onto the next, having them run in order without risk of something else running in between. For example, if program a runs program b then d, and program b runs program c, would program b cascade to program c, prior to program d running. The answer is yes. I created four programs a, b, c, d Each program sets a variable equal to 1 plus the previous variable starting with 1 for a. So b = a+1, c = b+1, and d = c+1. So if the programs ran in order a,b,c,d then variables a,b,c,d would end up being 1,2,3,4. I had program a run b and d (the then clauses) (in that order) I had program b run program c. (then clause again) What I found is that the order ran a,b,c,d witnessed by the variable equalling 1,2,3,4 respectively. So, when a program's then clause sends off to another program to run, it will completely run the then clause of that other program and not return to the original program''s next line until it has finished executing all of the then clause of the program it was sent to including getting sent off to other programs. THE EXCEPTION: I put a wait clause into program b. The wait cluase did allow program d to run prior to the completion of program b. This was expected, but I just wanted to confirm.

The symbol compares the two things on each side of it. The alligator eats the bigger number For example: 1<2 4>3 So if you wrote if Status 'Thermostats / Remote Stat / Remote Thermostat' < 84° (Temperature) (in plain English you would say, "if the remote thermostat is reading less than 84 degrees") then $sRemote_Stat_temp_alert = 1 else $sRemote_Stat_temp_alert = 0 Your variable would be set to 1 whenever the temp is less than 84 because that is when the if statement is true.

Just remember, the alligator eats the bigger number. (Yes, you are correct).