apostolakisl

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

Thanks for the detailed post! And congratulations on becoming my go-to guy when I start messing with this thing next week... Huh, what, I'm confused, what did I say?

variable names can't have any spaces. Try "state.1"

I would like to think that I touched upon this a little more than "barely". Not to get pissy here, but yeah, in your first post you said "I put them in the away folder". There is tremendous detail about creating programs inside that folder, but the fact that you can set folders conditions and how you do it seems to be assumed knowledge. If you are new to ISY, you may have no clue that you can set an entire folder to run on various conditions and how you might do that. You are really quite vague on that point and I am only clarifying something that a person new to ISY can easily have missed.

You might look at a CAI webcontrol unit. They are inexpensive, integrate with ISY via io_guy's application, and can be programmed to operate independently with or without ISY (or other) supervision (so if com goes down they still will operate). They can take 8 1-wire temp sensors and have 8 digital inputs, 8 digital outputs (that you would connect to relay boards), and 3 analog inputs. There are 8 addressable variables that ISY could post values to for temp settings. They have an internal PLC programming language that would be perfectly sufficient to operate an hvac unit without any outside intervention if so desired. They are IP enabled and accessable via a gui or REST interface. A single CAI unit might be all you need to operate all three zones assuming you can get wire from the unit to wherever you want the three temp readings taken and that they aren't too far away. CAI unit is $40 with shipping and a relay board will be about $25 on ebay. You will also need a 9v power supply and a cat5 connection to your internet connection (or you could buy a wireless bridge). I have a couple of these units and am enjoying them. They are fairly simple but with creative thinking, you can actually get them to operate in a very sophisticated way. It mostly comes down to getting a grip on the PLC language. It is a very simple language but putting together the simple commands in with some care and logic produces complex operations.