apostolakisl

I think that the part about <=65 is the measured temp, not the set temp. So effectively this would be setting the thermostat to 65 even though it is set to 68, which is OK I guess but a little un-orthodox. I really think the OP has over-complicated this. The thermostat should have built-in programming that can do all of these things except for the part about the alarm system status.

Yes, it wouldn't turn on the heat if any of those aren't true. But that is not the same thing as turning off the heat if any of those aren't true. As long as you actually want this program to actively turn off the heat when things aren't true (like if someone manually turned it on).

Well I suppose it could be that a voltage that is right on the cusp could trigger two of the programs to run during the split second between triggering of the first program and setting $State_LvlCalc = 2. One thing would be to make $State_LvlCalc = 2 the first line of your then clause, but that would just make the time window smaller, not eliminate it. Another would be to cascade your program where each one calls the next one from its Else clause. So all of your programs (except the first) would be set to "disabled" which means they don't trigger from their own "if" clause (but still they run from another program calling a "run if" on it.) If the value is bouncing back and forth, however, it might be that none of the programs run the "then" clause because it happens to be that the voltage is slightly too low when the one program is called and then slightly too high when the next program is called.

So how is this working? You push f4 to trigger the process of checking the voltage and displaying the result. Is this the only thing that can trigger anything to do with the $WtrGallons variable? $WtrGallons is how much water you have in the tank, correct? $SlopeDiv10 is what? How does this variable get set? It appears that this variable is the starting point for every calculation you do to determine the number of gallons.

If only I had known the fun we would have with the Elk/ISY option, I would have gone with the CAI... But we didn't know and now we have to live with the consequences which is ISY 83 programs Now thanks to the fact that I can export and import ISY programs, writing 80 similar programs isn't hard with a text editor. But the number of programs isn't currently my issue. It is the logic race issue inside the ISY and I don't think this would be solved by the CAI. Anyone have ideas on that? I don't really know what the logic issue is, but just at a glance of the posts it looks like it is somewhere in your ISY programs. Assuming your measuring device is outputting the correct value, then I don't know of any reason CAI would have a logic problem. It would be a pretty short CAI program to do what you want. The measured voltage from your measuring device would plug it's value directly into a couple lines of code on CAI that do the math and store the number of gallons as a CAI variable. From there one more line of CAI code posts the value to ISY variable. Since you probably don't want it to post a value every single time the processor cycles, you would include a little more code that either schedules periodic postings or only posts on a change in value. ISY wouldn't need to do any math or perform any logic functions. You could go this route for about $50 (CAI board plus a 4-20ma to 0-5v converter). You would also need a 12v wall wart

You can't do that. ISY variables can only be compared to other ISY variables or a fixed number of your choice. Why did you choose to go with Elk reading the voltages instead of CAI? CAI could have read the voltage, done the math to convert to gallons, and then posted that value directly to an ISY variable.

Then you used the wrong names of scenes/devices. You have a scene that is controlled by the 2440's and includes the swtichlinc as a responder. The first part is the name of the scene controlled by the 2440's and the second part is the device that carries the load to the light and is a responder to that scene. Adjust Scene ‘put the name of scene that has 2440's as controllers and load switch as responder(or controller/responder)’ ‘Set put the name of the switchlinc that is the responder(or controller/responder) to that scene and carries the load’ 30% (On Level)

The Insteon switches had a defect in the microswitches behind the paddle that caused them to fail (you push on/off and nothing happens or you have to push exceedingly hard). Insteon finally owned up to it and replaced all of those. I am not aware of any reason other than that that you would have so many failures. I have had only one switch out of my 60 or so fail since I replaced them about 4 years ago. And the one that failed failed almost right out of the box. They also had a defect in the lamp module with a bad diode and Insteon ended up replacing those as well. Having said that. I don't think I would consider Insteon to be commercial grade switches. Although, it may be the case that the switches receive very little physical use/abuse in your setting. If you manage to program the lights to be on when people want them on and off when people want them off, they may almost never get touched.

What are you trying to do? Control every light in every classroom or things like common areas and hallways? I would personally not expect an Insteon switch to survive the pounding that grade school kids might give it all day long but would expect a good life out of a switch that mostly is operated manually by adults and/or automatically by commands from ISY. Of course a school is probably on 3 phase and who knows what kind of "noise" exists. 3 phase certainly works fine with Insteon, but it is one more thing to consider. It isn't very hard to have one ISY talk to another using the network module. It would only be a minimal jump in "pay grade". The ISY has the REST interface and the network module can send a REST command to another ISY to run a program, turn a device on or off, set a variable, or various other tasks. If you want a full fledged marriage where device status and whatnot is shared. . . well that really is beyond what is reasonable with an ISY.

It would be best to do this with the power off for reasons aside from accidental shock. If you have an almost connected wire and you start wiggling things, it will arc and pop on/off and the power irregularities can easily fry an insteon switch. Should you ever choose to work with hot wires and Insteon switches, you should at least pull the hard disconnect on the Insteon switch first.

What lee is referring to is that the wires are often daisy-chained. If the hot/neutral goes from the breaker box to the first gang box, it may then be spliced to one or more wires that go to the next box, and perhaps it may do the same again. If your wire nut is loose or one of the wires slipped a bit and is not making contact under the nut, and this nut happens to be the first in the daisy chain, then all of the rest of the downstream devices would go out. Pick up a volt meter for a couple bucks and pull any one of the "dead" switches and see if the hot is hot testing both against the neutral and ground wire.

No, there is only one Universal Devices device on Harmony Remote software. It brings in 40 IR codes which are the ISY's default 40. They are called IR001, IR002, etc through IR040

I have 2 of the 890's and a 900. All 3 list 40 default codes when I add the ISY to my device list. The codes come from the Harmony server, so it should be exactly the same for everyone. I don't understand why you would only have 16.

They are pretty big, I don't know the exact size but they will not fit in a regular junction box. Yeah, they are kind of bulky. They will fit in a triple wall gang box, but only if it is a deep box and your switches are very thin (pretty sure you aren't going to get an Insteon switch over it). They will fit in a 4 inch j-box like this. http://www.lowes.com/pd_70965-53911-521 ... facetInfo= They are 3.5 inches in longest dimension. http://files.buyitsellit.com/8181/XPF.pdf

I had the exact same problem with a transformer for undercabinet lights. I used one of these http://www.ebay.com/itm/X10-PRO-XPF-20A ... 4176975cf1 and the problem was solved. I hard wired it directly to the transformer so I can still control the light with Insteon switches.

Cutting through all the confusion, you need to understand one thing. When and only when a program triggers will it either run the true (then) or false (else) clause. If you understand triggers then you will get it. For example status: trigger every time there is change in status of specified device control: trigger every time the specific action is taken (control switched on) (never evaluates to false unless you use "not", then is always false) state variable: every time the variable changes integer variable: never a trigger time is: triggers at that time (always true, again unless you use "not") time is from/to: triggers at from and to times (true and false) You may also force trigger a program from another program or manually by doing a "run xxx". These are the most common triggers, others exist, especially if you have modules.

I just looked at the ultimates webpage. It doesn't look like it does much over IP beside update the settings you change on your pc and connect to a smartphone app. So, in short, you would need to do it the same way as with the harmony remotes. The remote or its base station "shines" the ir signal at the isy and the isy executes a program in response. .. like dim the theater lights and turn on the projector, or whatever.

I suspect you would have to determine what it is capable of as far as sending IP commands. ISY wiki gives pretty good explanation of how to use REST commands to set just about anything on the ISY. http://wiki.universal-devices.com/index ... _Interface

If you have ethernet access in the area of where you would put the dry contact input device, a much cheaper way is to use the cai webcontrol. Webcontrol can set variables on ISY and has 8 digital inputs and 3 analog inputs. It also has a bunch of other stuff that you may or may not care to use. The analog inputs can also be used as digital inputs so you can monitor 11 alarm contacts with a single $35 board. You need to write a few lines of code in the cai to get it to set the variables on ISY but it is pretty simple stuff.

The best way is to create one new scene with all of the individual devices as responders and the kpl button as the controller. A program that triggers multiple scenes will be slower and more prone to communication errors since multiple commands will be sent out simultaneously.

No, you wouldn't. The program is always disabled (assuming you set it as disabled). Calling a program via "run if/then/else" does not re-enable it. The "enable" and "disable" only serves to stop the program from SELF triggering (or in other words, by a condition in the "if" clause causing the "if" to trigger). Any other program or a manual action on a user's part can still force run the if/then/else even while disabled.

Yeah, but in a split breaker, both occupy the same even/odd slot. Didn't those Fed Pacific ones get recalled or something? I thought I read about that.

There are panels that don't alternate leg 1/leg 2 every other breaker location. But they are few and far between. The ones that don't do it this way have a crazy breaker design for the 240v breakers where there are 2 breakers where one is nested inside the other. There may be other designs beside that, but it is the only example I know of. So if you have the typical 240v breaker that bridges 2 adjacent "normal" breakers (without hopping over in intervening one), then you almost certainly have the typical alternating legs. It has been my experience that adding more devices doesn't always improve communication. I have added new devices to my home and watched as previously reliable devices became flaky. I can't say that I know how to explain this except that perhaps timing issues or "clashing" of communications occurs.

Your logic is sound. Probably this would be a more easily organized way to do it, especially as you mentioned, if you have lots of toggle programs. You could just disable the whole folder with an if clause that is never true.

This wouldn't work for his program because the "other tests" would need to be: Status 'MASTER - Fan Light' is Off And Control 'MASTER - Fan Light' is switched Off The first line "status master light is off" would be a trigger every time the light changed status which would result in the "else" clause running a whole lot of times you didn't want it. Also, it would require that this program be the only way you turn the noise machine on/off. If you turned the noise machine on or off otherwise, the variable would be out of sync, and you would need another program to track the status of the noise machine. . . which defeats the whole purpose of trying to turn 2 programs into 1. The real answer to this problem has been discussed at length in the past, and that would be for ISY to allow you to select which conditions may act as triggers. Like a check box after each line or something.