apostolakisl

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

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.