apostolakisl

If you want to track the last action on a scene, you can commit an 8 button kpl to the task. Make each button a member of a scene. If you never push the buttons on the kpl (or otherwise direct them to be altered), the kpl buttons will turn on when the scene is turned on, and off when the scene is turned off. The status of those kpl's can be querried by programs and therefore the ISY knows the last action of that scene. However, this only tracks the last action on the scene, not the devices. So if a scene were turned on, then each device were turned off some other way, the kpl would still be on. This probably isn't what you want. What I have done is write programs that turn kpl's on when certain devices are on. Essentially, I am using them as status lights for other devices. They are not members of scenes themselves. This is probably what you were saying you don't want to do in the original post. You don't necessarily have to put all the switches in programs like this. If you just include the load switches, life is easier and you still know whether the light is on.

ISY doesn't track scene status. Since individual switches in a scene can be controlled outside of the scene if so desired, it just doesn't make sense. KPL buttons can be set as responders in scenes and will turn on when the scene turn's on and off when the scene turns off. In this way, you can track the scene status in ISY by having ISY check the status of that kpl. However, the kpl button won't turn on if one or more of the switches is turned on via some method other than the scene. If you set the kpl to be a controller in a scene, then the button will turn on when the scene turns on, and the button will control the scene (be able to turn the scene on/off). It really comes down to how comlex your scenes are and for the most part how overlapping your scenes are. If you have a switch as a member of multiple scenes, tracking scene status starts getting all crazy. If two scenes shared one switch, and both scenes were turned on, that is easy both scenes are on. But, if you turn one of those scenes off, technically neither scene is on because the scene that is still on is missing one of its members. It comes down to this, if all of your lights are a member of one scene and are only controlled by turning the scene on/off tracking scene status is simple and logical. But, most people would rather use the complex multi scene member capacities of ISY/Insteon.

Strong work, a bit odd, but strong none the less. Of course, some of us are capable of doing a lot of damage and getting out in less than 2 min 45 seconds (I don't dilly-dally). I once considered a toilet paper dispenser trigger for the fan. But with the ladies, it would need to trigger twice to avoid the false "pee only" activation. Perhaps an aroma detector? Maybe a detector capable of differentiating the various "splash" noises? Maybe a "grunt" detector? Oh, this is too much fun.

If you look at the program summary page, it will tell you the time the program last ran. What is that saying and is saying the current status is true or false? It is possible that program is running, but that the execution is failing. Also, when you manually do a "run then", does the expected result occur?

I just read the original post and noticed that his toggle lincs are dimmers not relays so you will need to alter your program to account for the dimmed status. If Status 'shower light' is not Off Then Set 'shower fan' On Else Wait 15 minutes Set 'shower fan' Off

Yup, my apologies. My eye flew right past the else. I think that should work with only one program.

Geogecko, This comes up over and over again. I didn't get it at first, I don't think anyone does. When a program is executed, it will go down the "then" statements, in order, without interuption, until it hits a "wait" or a "repeat". At this point, the program opens up the "if" clause for evaluation. In the situation of a "wait", while the program is waiting, anything that causes the "if" to evaluate (a trigger) will kill the program and cause it to start over. For example. When you have a "control switch on" in the if section, anytime someone pushes the "on" button, that is a trigger. It doesn't matter if the light is already on or not. If you have a "status on", anything that changes the status of that light is a trigger (the status must change). Once a trigger occurs, the program will proceed through and head into a false or true state and run the then or else clause accordingly. Also, if you have another program force a "run if" that will also be a trigger and the program will stop what it is doing and proceed through from scratch. In the event of a repeat, the program will check for an active trigger in the if section just for a split section, then do the repeat, then check again, and so forth. So the program will keep repeating until it completes the number of repeats designated, or until a trigger event happens. This is useful, but less useful than it would be if the program continued uninterupted to completion. Your situation is actually one of those nice times where this is useful. To block a program from being interupted, you need to create two programs, one contains the if and the second contains the then. The if program runs the then section of the second program. The second program contains nothing in the if section, so it can't get triggered by anything accidentally.

This wouldn't quite satisfy the original intention because it will shut the fan off 15 minutes after the light is turned on, not 15 minutes after it is turned off. The idea was to remove the humidity and you need to keep the fan running for a specific amount of time after the shower is finished (which I assume corresponds to the light being on).

Your programming logic will serve you well, however, when you get into the opposite situation where you want to block a program from being accidentally killed. This has always been the situation requireing work-arounds.

This issue with wait clauses getting killed is actually a huge topic on the forum. In fact, most people would prefer it the way you had assumed it works. It is very easy to have a wait clause killed by something in your if clause forcing a trigger when you don't want it to. This is one of those less common situations where you actually want the wait to be killed.

It is not true that the wait can't be interupted. You can interupt the wait loop by either retriggering the program (run the if clause provided something in the if cluase is false) or you can use the "stop program" clause. I actaully just edited the program and changed it to stop program because it is a little more obvious what it is doing that way, though both ways work the same. So when the person hits the "on" button, the wait program gets killed.

I think there may be a simpler way to do that. Tell me if this wouldn't work. Fan turns on with light on program. If Control 'Shower Light' is switched On Then Set 'Shower Fan' On Stop Program 'shower fan timer' Else - No Actions - (To add one, press 'Action') shower fan timer If Control 'shower light' is switched Off Then Wait 15 minutes Set 'shower fan' Off Else - No Actions - (To add one, press 'Action')

I'm guessing you are having communication issues. I doubt the querry all is the issue. The "not specified" is what happens when a program is set to control a device or scene and then the device or scene is deleted. A querry all command is not necessary for ISY to run properly. It is just sort of a clean up that ensures ISY has the correct status of everything at least once per day. Are you getting any failure to communicate warnings? You have all dual band stuff, are the switches within rf range of the plm? Also sometimes if you try sending too many Insteon commands all at once I have found that things get missed. I assume that this is from too much traffic on the power lines. I don't know how that relates to the daul band stuff. Anyway, try having the programs run a second or two apart instead of all at once. However, I have only found this to be a problem when sending far far more commands than you are. Since it worked when you manually did the run then command, I suspect you either have an if statement error, or you are getting insteon traffic overload issues. With only a few devices, however, I am leaning more towards an if statement error.

No, these are different. They are connected to the unit via an RS-485 connection I believe. The thermostats can pull up all kinds of info, like static pressures in all of the various air handling stages, freon pressures, outside temp, a history of any fault codes, status of accessories like humidifiers, air filters, hours in operation on all of the different modes (high heat, low heat, high cool, low cool,) hours since installation and on and on it goes.

Your program makes me wish I had thermostats I could control. I have a Carrier Infinity system that uses special thermostats. Oh well.

I have had inconsistent results when I write one program with a boat load of scenes to execute (or shut off). They usually work, but not always. I am sure it has something to do with Insteon signal overload. However, if you have multiple lights in the basement that you want to control independently while in the basement, and you want one kpl button upstairs to shut them all off, you pretty much have to use a program like you are using. If you are willing to use multiple kpl buttons, then you could use one kpl button for each set of lights in the basement and join it to a scene as a controller/responder for each set along with the actual basement switches. This is going to be the most reliable and require no programs, but it will eat up several kpl buttons. If you only care to have all of the lights in the basement turn on and off as a single group, you can create a single scene with each switch plus your upstairs kpl button as controller/responders.

Below is my program for creating an every other, every third, every fourth, and every fifth variable. The value of each of those variables will start at 0, count up to it x-1 where x is every x days. ie, for every fourth, it will go 0,1,2,3,0,1,2,3 etc. If Time is 12:00:00AM Then $iDay.Counter += 1 $iEvery.Other.Day.Counter = $iDay.Counter $iEvery.Thrid.Day.Counter = $iDay.Counter $iEvery.Fourth.Day.Counter = $iDay.Counter $iEvery.Fifth.Day.Counter = $iDay.Counter $iEvery.Other.Day.Counter %= 2 $iEvery.Thrid.Day.Counter %= 3 $iEvery.Fourth.Day.Counter %= 4 $iEvery.Fifth.Day.Counter %= 5 $iDay.Counter Init To $iDay.Counter $iEvery.Other.Day.Counter Init To $iEvery.Other.Day.Counter $iEvery.Thrid.Day.Counter Init To $iEvery.Thrid.Day.Counter $iEvery.Fourth.Day.Counter Init To $iEvery.Fourth.Day.Counter $iEvery.Fifth.Day.Counter Init To $iEvery.Fifth.Day.Counter Else - No Actions - (To add one, press 'Action') Now for your sprinkler program If Time is 6am And ievery.other.day.counter = 0 (or you could use 1 for the other half of every other day) Then Sprinkle The beauty of this is how simple it is to change it to a different schedule, so in the spring and fall you might want every 3 or 4. In the winter you might make an every 15'th or 20th depending on your climate. And you can pull these same variables for any other program you want to happen like this. Edit: I added init to's for reboot protection.

You need to make a counter program. I suggest just haveing a counter that counts days from now to forever ($integervariablecounter). (at 12 am $integervariablecounter += 1) Then in your program, use the %= command to calculate a remainder. $integervariableremainder=$integervariablecounter $integervariableremainder %=2 this will allow an every other day. for example. if the variable is currently 3 and you divide by 2, the remainder will be one. If it is 4, the remainder will be 0. Set your sprinkler to go off on $integervariableremainder either 1, or 0. Either way, it will be every other day. If you change your mind and want every 3rd day, just change to %=3 and so forth. I would write the full out code, but am not at my isy computer.

I have no clue what is Insteon Group Messaging. So far, this lack of understanding has not hindered my use of insteon. I suspect the phrase used in the insteon standard is "scene". In my mind, a scene is analogous to a set of devices all having the same X-10 address, with the ability to define some as transmitters of, others as responders to, or some as both transmitters AND responders to that address. To me, introducing "group" terminology adds an unecessary complication into the picture. I wouldn't think of a scene like sharing an x10 address, it will unfairly constrict your expectations on what you can accomplish with Insteon. With Insteon, the same device can be in multiple scenes each with a completely different assortment of devices. You can even have multiple scenes with the exact same devices, just having them behave differently. It is only like sharing an x10 address if your device was able to simultaneously have a dozens (or more) x10 addresses.

Clever idea. Two questions. 1) What does this mean, " <0>" in the following line of code? "If $Test.State <0> 1000" 2) I can't find any line that sets $test.state to 1

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.