apostolakisl

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.

The one thing the OP asked that has just barely been touched on is how to have them only run when away. Put all of these programs that cause lights to turn on/off at somewhat random intervals into a single folder. With ISY, you can write conditions for the entire folder to run. You will notice in the program details page, if you click on a folder it will give you an if/then option. In the "if" section, put some condition that is only true when you are not home. For example, you could have a kpl button next to the door that you push when you go away. You could also set that same kpl button to turn your alarm on for you provided you have an Elk or some other security system that can respond to Insteon commands.

1) CAI will certainly turn the pump on/off. Variable speed may not be possible depending on how that is controlled. If it is a situation where you close one relay and get low speed and close a different one and you get high speed, then you will be able to do it. (2 outputs used) 2) CAI has 8 outputs, so I think you should be able to do this too (3 outputs used) (on/off, probably not the actual temp) 3) Ditto (4 outputs used) 4) Ditto (5 outputs used) 5) It definitely does that. You can have it send emails at certian intervals or at specific temps. You can also have it monitor air temp. 6) PLC code can send you an email when it is getting cold, or flash the pool light, and certainly you could set it to put the pump no high 7) Buy the iphone app for it and you have a remote. Or set up some programs in your isy to turn a kpl into a remote for it. Or just log into the gui from any computer. So you still have 3 outputs left to do other stuff. Also, pool level could be read by buying a pressure transducer from digikey for about $12 and hooking it into one of the analog inputs. Freescale makes them. You can get the plc code to do a lot of stuff if you can get used to it. Also, using the sync program from io_guy you can write programs in ISY to respond to conditions. Or, you could consider using the x10 feature sending commands to ISY that way. EDIT: I just realized you can use cai to set the temp. If you use one of the 8 variables as the set point, then have the plc code turn on the heater when the temp drops below that value and turn it off when it gets above it. The variable value can be changed by a REST command

One thing that hasn't been mentioned here is the cai webcontrol. It has a one-wire bus on it for temp and waterproof one-wire sensors only cost a few dollars on ebay. The cai board costs $40 with shipping. You will need an internet connection (cat5) whereever you locate the cai board, or you would need a wifi bridge. io_guy wrote a .net program that syncs the cai to the isy and it can be downloaded from this forum. You can also program the cai to turn your pool heater on/off (or anything else) all by itself. In addition to the one-wire bus that can give you 8 temp readings, it has 8 digital inputs, 3 analog inputs, and 8 digital outputs. It also can be used to control x10. It has a built-in PLC language programming interface which is very good at i/o control. The ISY can post variable values (8 of them) to the CAI so there is ability for ISY to alter the CAI's behavior provided you write it into the PLC code. The ISY would also keep track of the status of the CAI using that .net interface application, but the CAI would be capable of keeping the pool running properly if something happened to the link with ISY. Assuming you were going to control the heater, pumps, or whatever using relays, you would also need a relay board that can be controlled with ttl level outputs. These can be had on ebay for about $20. Search for "pic relay". These are the same type of relay board that work with arduino. If you get a relay board, to make your life easier, make sure it is the kind that 5 volt inputs turns the relay "on". Some of them work backwards where 5v is "off" and 0 is "on". You can use these, and cai has a "state-inverted" setting for those situations, but I still find it trips me up.

What is the purpose of checking for both "On" and "not Off"? If the device is a relay and not a dimmer, doesn't "on" = "not off"? (I'm still new to the ISY programming, so I am just reading threads to learn) Thanks Kevin You are correct. The single "status is not off" statement will suffice. I have dozens of programs that are written that way. Every time anyone touches the light switch, the program will evaluate, and if it is anything but "off" it will run the "then" clause. If someone touches the light switch during the execution of the "wait" clause, the program will terminate and start over from scratch. Also, if a command is sent to that switch (like from another switch), that will also terminate the program and start it over, even if it the command is "on" and the light is already "on". So if the light is on, and 5 minutes have passed in a 10 minute wait, then someone hits the up part of the paddle, the program wait will terminate, the program will re-eval from scratch, it will evaluate as "true" and the "then" clause will start all over again at 10 minutes.

As pointed out and already corrected by you, the catch-up program at restart can't be checked for this program series to work well. I might point out a couple things. 1) I re-wrote the programs so they all cascade off of a single program (not sure if it is in the wiki but it is for sure on the thread where originally posted). In my mind this is a cleaner way to do it, and it makes it easier to force a run of the whole sequence if you are in a position where it needs a catch up day. Or, if somehow you accidentally pushed it ahead a day, you can just disable the first program in the series and then the whole series will sit idle until that program is re-enabled. 2) The program series will fall a day behind if the ISY is off from midnight to 12:15am (assuming you have the grace period set to 15 minutes).