apostolakisl

From the wiki: "Catch up schedules at Restart - When this box is checked (default) the ISY will attempt to run all programs that are time dependent beginning at midnight until the present time.' Does that mean that a program that was set to run at 5am and I reboot my isy at 6pm, then the program will run again? If this is so, rebooting your ISY after a counter program has already done its daily count, will then add an extra count for that day. Correct? Edit: Answered my own question and it is YES. I rebooted my ISY after writing this program. If Time is 6:00:00 am Then Int_1+=1 the reboot was done at 11:10. When it first rebooted I want to the variables page and the value was at the init value (1). About 10 seconds later it upped it to 2. Presumably the ISY just hadn't gotten to running that program when I first loaded the page. This is definitely a new twist to consider if you are writing any kind of counting variable program. Perhaps you should have the count occur at 11:59pm or perhaps you should uncheck that box and use the 15 minute catchup instead. Since I have my ISY on a UPS, typically I only reboot when I do firmware updates and that only takes about 5 minutes. I think I will uncheck the box and use a 5 or 10 minutes catchup.

Back to poor Teken, if you write the last version of what I posted, it will work. Thanks to Andy for pointing out that it can be made one program instead of 2. And, I am stilling wishing there were some way to make the program foolproof in the event of a poorly timed power failure. Thoughts???

Like Tim said. I like to think of a wait or repeat as making the if "available". The same exact rules apply to an if running during a wait as when the program is not running at all. Oh, and Andy, I apologize for very poor arythmatic, 11:10 is more than 3 hours after 8, so indeed your program would run fine, it is just that the 11:10 part of it is just superfluous.

The program you just wrote will behave exactly the same as the wait were not even there at all. The logic follows in this order When a "then" or "else" is executed. All of the line by line stuff is done in order without possiblity for interuption until a "wait" is encountered. The program pauses for the specified time in the wait. During that time, the contents of the if are opened back up for triggering. If any line of the if statement gets triggered, then the wait is killed, the if gets run in full, and the then or else clause executes. Here is an example program that is easy to do. If Control 'switchlinc' is switched on Then set 'device 1' on wait 30 seconds set 'device 2' on Else set 'device 3' on This statement triggers when you push switchlinc "on" so it runs and evaluates to true. It promptly turns on device 1, (and assuming you don't do anything) waits 30 seonds, then turns on device 2. Device 3 never turns on. This is what actually happens. If, as is implied in the wiki, the wait clause looped back and forced a re-evaluation of the if clause, it would now be false (no one pushed the button a second time), and device 3 would turn on, and device 2 would never turn on. This does not happen. But, if during that 30 second wait, you manually turned off device 1, and then pushed the switchlinc "on" button again, device 1 would turn back on, and the wait 30 second timer would start over again followed by device 2 turning on. This is becuase the "if" clause was available for interuption by pushing the "on" button. As this program is written, there is no way for the else clause to run except if a separate program called it since "control on" can't evalute to false all by itself.

Andy, That isn't written properly. An if statement is not actually run, it won't become false when it hits the wait. It will only become false if there is a statement in there that is a trigger (like a state variable that changes value, or a status of a light). I promise you. Try it. I swear.

No, that isn't how it works. A wait clause does not run an if clause, it only makes it available to run. Your program will run the if clause at 11:10 becuase 11:10 is a trigger. This will kill your then clause prematurely and execute your else clause. This came up in another thread earlier in the week. During a wait, the program's if section becomes available again for triggers, but the wait itself is not a trigger. The if section will sit idle unless some part of it is a trigger, just like it does at any other time, "waiting" or not. In my program there is only one thing that will run the if clause, and that is the time becomming 1pm. Try it, I swear.

My bad, or set the program to trigger on 1 instead of 0. I think setting the trigger to 1 is best, it makes it easier to think about every 15 days if you are setting that variable to 15. And Andy, I don't think you need the time interval 8 to 11:10 in your program. 8 am is the trigger and since you are using an integer variable nothing can interupt the wait except the time becomming 8 am again (which won't happen for 24 hours, well after the three hour wait). Edit: Actually I think the 11:10 part will kill the program. At 11:10 the program will trigger again but be false. The then clause (and the wait) will end and the charger won't get shut off, and the else clause will run. If there is a power failure that crosses that 1pm time frame, the program will shift back one day. If there is a power failure during 1 to 4 pm on the charging day, it will charge again the next day and also set the program back one day. I would love to hear any ideas about how to make that stop. Andy's program would get shifted back one week If $Integer_1 is = 1 And Time is 1:00:00pm Then Set 'battery charger' on wait 3 hours Set 'battery charger' off Send Notification to 'me' $Integer_1 = 15 $Integer_1 Init to $Integer_1 Else $Integer_1 -= 1 $Integer_1 Init to $Integer_1

If $Integer_1 is <= 0 And Time is 1:00:00pm Then Set 'battery charger' on wait 3 hours Set 'battery charger' off Send Notification to 'me' $Integer_1 = 15 $Integer_1 Init to $Integer_1 Else $Integer_1 -= 1 $Integer_1 Init to $Integer_1 Taking from Andy, this merges the two programs into one. You must switch to an integer variable now or the program will get caught in an endless loop.

Teken "If the time is 1pm" is what triggers the program to count down the variable once per day. You need the variable to go from 15 to 14 to 13 etc till it hits 0 which triggers the battery charger, then it resets back to 15. So, at 1pm, it subtracts 1. You could set it for any time you want. I just arbitrarily picked 1pm. The "init" variable is what the variable sets to at reboot. The line "$state_1 -=1" is what drops the value of the variable by 1 each day, and the line $state_1 Init to $state_1 simply sets the initialized value to the same thing as the current value, so after a reboot it will pick up where it left off (not go back to 0). Edit: Andyf0's program structure won't work for you. The difference is he is on a weekly program, you wanted every 15 days. That makes a big difference. ISY has no built in structure for that.

If $State_1 is <= 0 Then Set 'battery charger' on wait 3 hours Set 'battery charger' off Send Notification to 'me' $State_1 = 15 $State_1 Init to $State_1 If Time is 1:00:00 pm Then $State_1 -= 1 $State_1 Init to $State_1 I added one line to this program to fix things up in the event of a reboot. After a reboot it will maintain the same value as when it shut down. This would only get messed up if the unit was off at 1pm. In that event it would lose one day. I also changed to <=0 on the first if. This avoids the risk of a power failure during the three hours it is waiting, which could restart the countdown from 0, getting into negative numbers where it would never fire again. With the addition of the last line, I now think this is about as robust a program as you are going to get to do what you want. If anyone knows how to fix things so it sets the variable correctly in the event of a power failure that crosses the 1pm mark, I would like to hear it.

I just played around with the "repeat" command. It lets you set it to 360 hours which is 15 days. So you could write a program with a then section of repeat every 360 hours and leave the "if" blank. Once you manually do a "run then" on it, it should keep going until you have an ISY reboot. How you would manage that automatically is a whole other story. I like my first solution. Just be aware that an ISY reboot will reset the schedule to whatever you set your "init" value to. I have my ISY plugged into a UPS so reboots only occur with firmware upgrades and I can manually reset stuff at that time.

And one more thing, set your "init value" to something more than 0. If your isy reboots for some reason the value would go to 0 otherwise and the program would never execute again. (it would go -1, -2, -3 and so on) This page might help explain variables to you a little better. http://forum.universal-devices.com/viewtopic.php?t=6063

I am not sure I understand your question. If you are asking what the last line is doing, it is subtracting 1 from the variable. Every day it drops by one. You need to set your variable's value to something more than 0 and after that it will drop by one every day till it hits 0, then it will jump back to 15 and start over. It is all under the variable tab. As I wrote the program, every day at 1pm it will subtract one from the variable, when the variable hits 0, your battery charger turns on for three hours, then the variable resets back to 15. As far as testing the program, I forgot that isy doesn't have a "every second" command like my Elk. It would be a pain to test. You would need to write your if statement to be If time is 1:00:00pm (or pick a time like 10 minutes from now so you don't have to wait till tomorrow!) or time is 1:00:01pm or time is 1:00:02pm or time is 1:00:03pm etc etc. Maybe you just write it like it is and trust me. I am confident it will work. You could check your variables every day and watch the number keep counting down to 0 then it will pop back up to 15. Also, you will get your email confirming it. Or write 45 lines of code as above and follow it through three cycles. And this is about as simple a program as you can get for something to happen every 15 days indefinitely. It really isn't much, just 2 programs and 1 variable. Because you want it every 15 days and ISY has no way to do every 15 days as a built in feature, this is the best I can think of. If you were OK with every 7 days then you could just set it to happen every Sunday at 1pm (or whatever).

If you haven't updated to the 3.1.x series of firmware you won't have variables. So . . . update if you haven't already. I didn't actually write the program and test it. I suggest you do that but instead of having it subtract 1 at 1pm, have it subtract 1 every second and set it to turn a light on for like 3 seconds instead of the charger for three hours. You should see the light turn on for 3 seconds every 15 seconds and get an email every 15 seconds. Once it does that cycle 3 or 4 times I think you can be confident it will work. I have lots of programs on my Elk M1G that are like this. The Elk deosn't have nearly as many time options as ISY, so this is how I do it.

If $State_1 is 0 Then Set 'battery charger' on wait 3 hours Set 'battery charger' off Send Notification to 'me' $State_1 = 15 If Time is 1:00:00 pm Then $State_1 -= 1 Set your initial value of $state_1 to a number which equals the number of days until you want it to trigger for the first time (taking into account whether you are writing the program before after 1pm, or whatever time you are having the program subtract 1).

If Time is Sunset Then Set 'rope lights (Main)' on If control 'lightsOnDemand' is switched On Then Set 'rope lights (Main)' on $State_1 = 1 Wait 20 minutes $State_1 = 0 Set 'lightsOnDemand' Off If From 11:00:00pm To Sunset - 1 second (Next Day) And $State_1 = 0 Then Set 'Rope Lights (main)' Off I have assume the 'rope lights (main)' is the load carrying switch. I also assumed that 'lights on demand' is kpl button or some other switch that is only used to initiate that 20 minute extra. I haven't tested the program series, but think it should work. If 'lights on demand' is a kpl, you will need to turn it off, then back on to reset the timer. If it is a switchlinc, just hitting the up paddle will reset it.

ISY is going to take care of you, don't worry. First off, write one simple program to turn the lights on at sunset. Right a second program to turn the lights off at 11pm. But include a stipulation that a variable should equal something, like 0 for it to happen. Right a third program that says if button x is pushed, turn the light on and set variable to 1, wait 20 minutes set to zero. Right another program that says when variable becomes 0, and time is after 11pm, turn the light off. Now, whenever you push that button, the light will stay on for 20 minutes, or until 11pm, whichever is later. And if you pushed it once, and then 5 minutes later you push it again, it will reset to 20 minutes again. Sorry I didn't write this in full out program language, but I am not at a computer that I can get to my ISY language.

I might have spread my answer out and not been as specific in the first paragraph as I should have been, but the topic was in the presence of "wait" statements and that was what I referred to. If you read paragraph two I was very clear in stating that the then clause is not interuptible until you hit the wait statement, then the program gets killed if a trigger event should happen.

ISY programming is a little different but it is fun and very capable. If you write the program how I demo'd earlier it will do what you want. But you could make it better. For example, say the time is 10:55 and you are walking your guests out. You don't want the light to shut off at 11. You should think about re-writing things so that pushing that button keeps the light on past 11. At present, pushing that button won't stop the 11pm off command from executing. Typically you separate the program that automatically turns the lights on from the one that turns them off at 11. Then in the one that turns them off you can put more if clauses that block it from running in the event that you have pushed your button. Variables are a good way to do that. It can all be great fun! yeah! You have to be a geek! Also, highly suggest using folders to nest these programs otherwise you will have a hard time organizing things. And using the memo section helps to. It all seems so obvious when you write it, then a year later you look at it and go "what the heck was I trying to do here"

I think the best way to think of this is that a "wait" gives the if clause the opportunity to be re-evaluated. If there are no statements in the if clause that behave as triggers, the if clause doesn't re-evaluate and the program keeps on its merry way. If a trigger condition does exist in the if section, the program stops and then runs again according to how the "if" section plays out now. Everything before a "wait" or "repeat" executes regardless. The logic runs all of the lines of the then statement in parrallel (or at least nothing can get in the way of it progressing through all of them) until it hits a wait or repeat. But "wait/repeat" itself, as well as the stuff after a "wait" or "repeat" is subject to the "if" clause not re-evaluating. Any statement in the if section that triggers after the original trigger will restart the program, even if it evaluates to the same thing (true/false). For example If status light x is not off then wait 5 minutes do something status is a trigger whenever the status changes. So, if I turn light x on, the 5 minute timer starts running. If during that 5 minutes, I dim the lights, the timer restarts. Even though the program was always true (on and dimmed both qualify as true in this program). Edit: After reading LeeG's stuff, I think there are some slight differences on what he and I mean to say evaluate. When I say evaluate, I mean that the if clause has been triggered and the program is actively moving towards a "then" or "else" result. I think he means that it is available for testing of the conditions in the event of a trigger. And there is a point in LeeG's statement that implies an incorrect point. The status of the if clause does not need to change from true to false or vice-versa for the program to interupt the then statement. Anything that triggers the if section to be reassesed (a trigger) kills the program, period. So any then/else statement that has not already been sent off, will not happen. If the status stays the same, it will rerun (from the beginning) the then (or else) statement.[/i]

Austin, Please read my post, they may have "crossed in the mail". I speculated correctly on your program. "wait" does not trigger an action, "set rope lights main fast on" however does. And becuase of that, the wait gets terminated. If you write you program like I showed it will work.

Post the program, but I bet LeeG nailed it. Your program probably goes somethin like this if control button x is switched on and status light y is off then set light y on wait 20 minutes set light y off. You need to realize that as soon as the first then statement "set light y on" is executed, the program will loop back and re-evaluate the if statement to false, terminating the then part and running the else part (which is blank). Remember anytime you have a "status" in a program, the if statement gets evaluated every time anything happens to the status of that device. When an evaluation occurs, any then/else stuff currently running stops, and starts again according to the true/false status of the if section. You can solve this problem by having a second program, I'll call it "keeping the lights on for 20". Leave the if section blank and in the then section put wait 20 minutes set light y off And the first program then section should read run program 'keep the lights on for 20' (then path) set light y on

You probably need to change your dns. I had the same problem. When you click on the "synchronize now" button does it give you an error about the DNS? It would make sense that this would happen when you switch providers since the DNS from your old provider is probably not accessable unless you are on their connection.

OK, I fixed it by changing my DNS server. Don't know why it stopped working.

So I tried time-nw.nist.gov as well. I get the same error. Must be something with the ISY.