apostolakisl

I would add a little bit to item "d". A comm issue could have resulted in the one actually not turning on (or off) and then a query later succeeded in updating the correct status on the ISY (one on, one off). Prior to the successful query, I would have expected a failed comm message on the one that didn't update status (assuming the lights had been controlled via that scene).

A controller is any Insteon device that when activated (pushed on/off etc) causes the scene to execute. It is by definition also a responder. A responder is a device that will execute on/off/etc upon receiving a message that the scene was executed. Pushing the device directly will not have any affect on the other members of the scene. What happens when a controller device is pushed on directly is what is listed in the scene as "applied locally". If you click on that device under the scene name in the tree of devices. This same information is also found under the switch settings as a single device in the tree of devices on the ISY home page. What happens when a device responds to a scene is listed when you click on the scene name itself. When you have multiple devices in a scene, you can click the box that applies everything to all devices the same, or you can not check that and set each device to do something different when the scene is activated. When you want to set the applied locally settings, you can click the box to have it copy from the scene, or you can set it to do something different when you directly push the switch as compared to when the switch responds to the scene.

Maybe I am a little slow this morning, but I don't get how this would work. Can you explain? I posted the program for 2.0 volts earlier. At present you are using a 3 step process (program) where a state variable is changed in the "then" clause which is the trigger for the next program. This is an unnecessary step which I am speculating is the reason for your spurious value (you might be getting multiple programs running true at the same time). It is impossible for the program below to trigger more than once per 5am or per pressing of f4. If memory servers me, Elk voltage is not a trigger, it is only checked once the other triggers (5am or f4) causes the "if" to execute. This single program takes the functions you split into three programs and puts them all into one and eliminates the state variable trigger completely. By using parenthesis you can merge all the conditions into one "if" clause. You would need 81 of these (2.0 through 10.0 in .1 intervals). Just use the "copy" function on ISY, and copy this program 80 times. Then use the "find" function looking for "2.0" and each time you hit "find next" replace the value with .1 higher than the time before until you get to "10". Then repeat that for "20" going through and upping that by 1 each time till you get to 100". It should take nor more than 5 minutes. If Elk Zone 'Water Level' 'Voltage' is 2.0 Volts **this of course is different in each of the 81 programs And ( Elk Keypad 'Main Keypad' 'F4' is Pressed Or Time is 5:00:00AM ) Then $WtrGallons = $SlopeDiv10 *** see below $WtrLvl = $WtrGallons *** see below $WtrLvl *= 20 *** and this is also different to match the above voltage $WtrGallons -= $Offset $WtrLvl /= $GallonsPerInch Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel' Else - No Actions - (To add one, press 'Action') ***I don't know what you were doing exactly using these two lines of variables passing values through from one variable to the next. Perhaps these are being altered at other times by other programs, but if not, they aren't serving any purpose getting passed through like that.

Can you turn the scene on? When it can turn on, but not off, that means you just turned on a noise maker. In short, no, an LED light that is off can not make noise. This assumes the LED light was turned off from a switch of some sort rather than having an on/off mechanism built into the bulb itself. One way to isolate noise is to turn off circuit breakers. You obviously can't turn off the one to the PLM/ISY unit. Realize of course that any devices on the turned off breaker will give you comm errors. But you can really isolate things by shutting off breakers. For example, turn off half the breakers and see if the other half of the house works as expected. Then swap which half is on and off. Whichever half gives you trouble, then split that half in half again, and so on, till you find which circuit has the noise. Then track down what is on the circuit that is causing trouble.

Typically an hvac system will have a 24vac transformer bolted inside the electrical hook-up section of the air handler. Radiant floor systems come different ways so I don't know what you have. But if you open the electrical hook-up box on your radiant floor system and find a 24vac transformer in there, you'll just need to splice off of the common wire on the 24vac side of the transformer and run that conductor to your thermostat. If the person who installed your system used thermostat wire, it will have more conductors sitting there unused inside the jacketed section. Your picture shows only 2 conductors and the jacket has been peeled off and then pushed back into the wall, so I have no way of knowing what wires you may or may not have that are unused. The first step would be to touch a multimeter to the white and black wires and see if it is 24vac as is. Radiant floor systems come all kinds of ways, so it wouldn't surprise me if some of them don't follow the normal conventions.

Personally I've fully switched to the Pi. I have 2 webcontrols collecting dust and will never turn them on again. Yes they are cheap with abundant IO, but in reality all their IO is difficult to use, interfacing is a pain (yes the newest firmware makes it a little cleaner) and for me anyway, they have been terribly unreliable. My CAIs 1-wire bus would drop out about once a week requiring a power cycle. The new Pi solution uses a hardware 1-wire controller which has yet to crash on me. It also supports many more devices types and numbers. With the Pi being a full Linux system the possibilities are endless on what could be added to it. I personally run six "Link" programs on mine, a web-based remote control for my TV, NTP server, Samba server and it doesn't miss a beat. I've got 10 of the boards, all with the firmware that can post direct to ISY. I haven't used the one-wire bus as I have no need for it. Mine never need rebooting. I think the latest firmware lets you use the one-wire ad converter, but I had no need for that as the CAI has built-in AD times 3. You can also put them in the can with Elk and power off of the Elk's 12v. If it is in a hot area, you might consider putting a bigger heat sink on it, but mine on the Elk power supply is in conditioned space so I haven't bothered. Just FYI, I am/was using the CAI boards for testing/prototypes of an invention of mine. It was reading analog pressure transducers and reporting them to ISY. In the first version I was using your (ioguys) program to sync ISY with the CAI boards. I have since had a custom designed dedicated hardware device to do that instead which will be the commercial version. But back to the OP. If you got rid of the programs cascading through via state variables triggering down the line and wrote them as a single stage program with all the conditions in a single "if" and all the actions in a single "then", I think you would eliminate your spurious values with no need for any new hardware. EDIT: Come to think of it, I did have one-wire temp hooked up to a couple of the units. I don't recall that ever needed rebooting, but it was a secondary item that I was only roughly paying attention to.

This would be the same concept as using the cai webcontrol, except you would be running an application on your raspberry pie instead of using a native function of the device. Also you would need the one-wire device instead of the on-board AD converter in the cai.

Create a scene with all of you basement lights. Set all of them as responders. Then manually turn the scene on/off from the ISY admin console. Do all of the light turn on/off? If so, then your communication is fine (at least at the time you did the test). If not, then you have probably found your problem. Especially if the lights turn on, but not off. That means that one of the lights itself is the source of your noise.

This is a very simple control wire, in fact, it is the simplest. It is an open/close circuit. When you close the black/white, the unit turns on, open the circuit, it turns off. If you want to run a thermostat that requires external power, you will need a third wire, and I am pretty sure the 2441th does require external power. Your black wire is probably a hot 24vac and the white wire (when the circuit to the black wire closes) is sending 24vac back to the heater to turn it on. If it is not that, then it is the opposite. Use an multimeter to check it out. What you need is a third wire to be your neutral in order to provide continuous power to the thermostat. Then you use black/3rd wire for power to the thermostat, and black to white to turn on the heater. Pull that wire out of the wall and see if there aren't more conductors running with those in there.

I don't know for sure, but given the "sense" current used by many insteon devices, I consider it a possibility. Furthermore, it is so easy to check by unscrewing the CFL (temporarily replacing with incandescent if needed) that I would not ignore the possibility. Any device that turns on/off via a switch separate from the device is never going to be a problem when off. When off, they have been physically removed from the electrical system of your house. This accounts for about 99.99% of light bulbs (the insteon led bulb being one of the rare exceptions)

Wouldn't changing the $State_LvlCalc value immediately cause the program's IF statement to be re-evaluated and be found to be false. If I understand ergodic's great postings on State Machines and Triigers (viewtopic.php?f=26&t=5731) this is exactly what would happen. Sorry, that would cause the program to abort itself. As I look at your programs, it really is unnecessary to use that state variable at all. The first program and the last program could be eliminated and have the "f4/5am" conditions in every "if" clause and your final program's extra "then" calculations could be added onto each of your voltage programs. Realize that the order of processing can not be predicted in ISY with simultaneous programs. I have done experiments where I ran mathematical formulations on variables using multiple programs that are running "simultaneously" and you do not always see the same order of operation. My experiences on this were confirmed by others a couple years ago when I posted questions specifically addressing that point. I wrote a massive set of programs that serve as a calendar for ISY and the order of operation is critical. I solved the problem by having one program call another after a calculation to be certain that each line of code that alters a variable runs in the proper sequence. In other words, I couldn't just set the "if" to trigger at midnight for all of the programs. It may be that an "if" condition changes but an already running "then" clause still gets a line or two in before it aborts and restarts. Anyway, it is clear by the fact that you are occasionally not getting the right answer that something along these lines is happening. If Elk Zone 'Water Level' 'Voltage' is 2.0 Volts And ( Elk Keypad 'Main Keypad' 'F4' is Pressed Or Time is 5:00:00AM ) Then $WtrLvl = $WtrGallons $WtrLvl *= 20 $WtrLvl /= $GallonsPerInch Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel' Else - No Actions - (To add one, press 'Action') This eliminates all the possible errors that might occur in timing using that state variable flag and gets you 2 less programs. I don't think it would be possible for two of these programs to ever trigger true simultaneous since there are no possible delays related to altering a variable. Edit: Also you can get rid of the voltage variable. .. which I did above. And somewhere in there you are setting the variable gallons/inch. I don't see any reason for that either. Unless you are planning on using this same set of programs on a bunch of different systems and want to just plug in the variable once. But still, the find/replace function on ISY can do that pretty darn well without using a variable.

I have 2 of these. http://www.ebay.com/itm/NetGear-WNCE200 ... 27d1612e37 I have had no problems.

Your idea of low cost seems like a lot of money to me. I have several cai webcontrol boards which run a plc type code and cost $35. Add to that another $30 for an ethernet to wifi converter and maybe $10 more for a housing and I have 3 analog inputs, 8 digital inputs, 8 digital outputs for about $70 that can go anywhere you have 120vac and are in range of a wifi hotspot. And it has the ability to post directly to ISY variables and ISY (with the network module) can set variables or outputs on the CAI board. And it runs on 12vdc so you can mount in your Elk enclosure and use your Elk power supply to run it.

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