apostolakisl

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

You will need to install appropriately rated relays for your lights separate from your circuit breakers (effectively becoming a light switch), then use ISY to control the relays. Insteon has this unit http://www.smarthome.com/31283/EZIO40-I ... ler/p.aspx If the high voltage relays have 12vdc coils, then hook a 12 vdc transformer positive to the NO on the Insteon device, hook the 12vdc transformer negative the relay negative, and hook the Common up the positive on the relay. When you send an insteon command to the insteon relay, it will pass power through to the high voltage/high current relay, closing it and turning the lights on. If the HID lights are single phase, you only need to put the relay on the hot. I know nothing about HID lights, so if they are 3 phase (which seems unlikely to me), then you will need a relay on each phase. This relay may be sufficient for your needs. You would need to check the specs on the lights to be certain. http://cgi.ebay.com/Solid-State-Relays- ... 1c1bcced62

Do the programs still work? When a program says "not specified" that means the program has no device to control. This is what happens if you remove a device, not rename it. As Michel said, programs internally reference the device's address. For the ease of viewing, the GUI shows the name you gave to that address, so if you change the name, it will show the new name. So, in short, something is odd. You should be able to change the name of a device and everywhere the device with that address exists, will display the new name. I have had one occurance where I replaced a whole bunch of insteon devices with new ones, and a couple came up with "not specified" in programs after I did that. But that was not a rename it was a "replace with" command. And it only happened on a couple devices after I had replaced about 25.

It is not lack of sophistication that makes ISY not track scene status. It is the fact that, expect for the simplist of situations, it is not clear what it is for a scene to be "on" or "off". To have ISY report scene there would be only two possibilities 1) on exactly as described, or 2) something else. The something else situation would be so common and so uninformative that the entire concept is rendered utterly useless. You can't even define a scene "off" status since it is entirely possible that you have scenes which, when on, have things specifically turned "off". It is precisely for this reason that YOU as the user DEFINE what it means for that scene to be "on", "off", or "whatever" by using the very sophisticated programming interface. If ISY had a scene tracking mechanism, I promise you that there would be never ending complaints about whatever logic was used by ISY. The only valid logic is the logic defined by YOU, the USER, for each scene individualy, not someone at ISY who has no idea what it is that YOU think it means to be on/off/other in various parts of your house. It just isn't that hard to write a few programs to get what YOU want.

Your concept has some validity, but practically speaking it falls apart when you start having switches that are members of multiple scenes. Also, don't forget that a switch can be designated "off" in a scene. I have several scenes which I have included to be shut off becuase they are commonly on and those particularly scenes specifically want them off. So this scenario also puts a monkey wrench into the scene on/off/ambigous logic. Truly this is what programs are for, you get to define exactly what it is you want to know. You can write a dozen programs in less time thant it takes to participate in this debate.

If all of your devices belong to no more than one scene, and each device in that scene is a controller of that scene, you can do what you want. In effect, you will only be creating virtual 3-way, 4-way, 5-way, etc scenarious. In this case, it makes logical sense to track it as a scene since all devices will work together at all times. (it is possible with programs to throw devices out of sync, but lets not go there.) Since ISY will respond to the state of any one device, and in a virtual x-way scene the devices move together, asking ISY to track the status of any one of the devices will tell you the status of the scene. But, the beauty of scenes is that you don't have to do this! You are free to make all kinds of crazy permutations to suit your needs. x-way scenes exist without Insteon, they have been around for 100 years via good old fashioned hardwires.

I understand your thought, but having scene "status" is, practically speaking, untenable. A scene is defined by a set of insteon devices being precisely set a certain way. Even one device being one percent off makes the scene "false", but not exactly off. How would you like ISY to report that? And since one device can be included in a dozens of scenes, this also makes it impractical. The value of knowing the status of a scene is generally in knowing that the lights are off. So if you had a scene tracking method, and one of the devices was not exactly as described by the scene, it would be false or "off" (sort of), but that information is really not helpful. What is helpful is perhaps knowing that a group of lights is actually off. And to this end you write a program that checks the status of whatever bunch of lights you are interested in and reports it. Here ISY has great value as the programs aren't hard to create and are quite versatile. For example, I have a kpl next to my bed that tracks every load bearing switch in the house except for a couple I keep on at night. If anyone of them is not completely off, the kpl lights up. I have all of those lights in a scene for which that kpl is the controller, so pushing the kpl when lit turns the house off. Conversely, pushing that kpl when it is already off, turns all the lights on, like in an emergency, from the bedside. You might also want to know all of the lights in the basement are off. Even if you only have on scene in the basement, if any one of those lights were locally changed by someone in the basement, the scene would be off, but lights on, and your button upstairs tracking the scene would give you the impression that the lights are off. Again, write a program that says whenever any of those load switches is not off, turn the kpl on. And, no need to tear out walls to add kpl's. You can always replace a paddle switch with a 6 button kpl and use the top/bottom as the on/off and have 4 additional buttons. It is also quite simple to cut a little bit wider hole in the drywall and install a double gang box without any drywall patching necessary. All the scene stuff aside, the ISY, in my opinion, is the ONLY reason that I like my Insteon switches. The ability to troubleshoot, update, repair, and track Insteon is second to none. Furthermore, the program versatility is tremendous, and the constant addition of new features makes it a joy to own. That and it never crashes.

What about putting the old router back in and seeing if it connects? From there you might be able change settings on the isy to accomodate the new router without doing a reset.

I use my Elk to do my sprinklers and I use something they called "custom settings" to set the zone times. I have 17 zones, so not quite as big as yours, but not a small setup. By using custom settings, I can open that screen and see all of my times at once and make adjustments without having to go through the programs one at a time and pick out the line of code that changes the times. ISY does not have a custom settings situation. Custom settings have built into their function the ability to be timers. However, ISY does have variables. So you might consider writing one program that counts down your variables one minute at a time so that they can function like my custom settings do. Now you can open your variables page and have all of your zone times listed out in one easy to read/change collumn. Since all of your programs will be identical except for the details, you can use ISY program copy function and just duplicate the same program 40 times or whatever and then go back and point each program to the proper variables. Most irrigation programs I have seen, and the one I wrote, run the zones sequentially using the event of one zone shutting off as the trigger for the next zone starting. It is easy enough in ISY (or Elk) to have one zone's off triggering two zones turning on, or having any number of combos. All you need are ISY controlled relays. I see you already have your relays, or I would suggest looking at CAI webcontroller. With the CAI unit you could write all your programs in PLC, copy them onto the CAI unit and then just use ISY as the start trigger letting the entire sprinkler subroutine reside on the CAI. EDIT: and I would put the ISY onto a battery backup. My Elk has built in battery backup so a power failure won't result in valves potentially be left on when power returns. ISY can be powered by its own power source instead of via the PLM and that could be plugged into a UPS.

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?