apostolakisl

How was the light turned on? This would only run if someone physically did a single click "on" to the paddle. If it was turned fast on (double click), or fade up (push and hold), or if it turned on as a responder to a scene or as a command from ISY the program would not run.

That looks fine. It will run the Else path on your second program if the door is opened while the lights are off. In your second program just have the else path turn on the light you want, wait the number of minutes you want, and turn the light off. In the "if" section put any conditions that you would like to have abort the wait. Like If If balcony light is switched on Then - - -blank Else Set balcony light on set pool house light on wait 10 minutes set balcony light off set pool house light off In this case, if someone pushes the "on" paddle of balcony light during the 10 minute wait, it will abort the wait and run the "then" clause. .. which is blank so it just does nothing.

I doubt your program is doing what you think it is. Every time you turn your pool house lights or shed spots on, that program will run and it will be false and the lights will shut off after the wait, even though the door was never opened or if "dark outside" is false. Also, at dusk, the dark outside program will change state and trigger the program to run false and the lights (if they were on) would shut off after the wait. The goal of my program was to check the status of the light when the door was opened. If the light is already on, then the assumption is that it is on for a reason and we don't want it to shut off after the wait. If the light is off to start with, opening the door will turn it on and start the timer. You need two programs to do that. You really need to do this with 2 programs. The reason is that you are going to have lots of un-intended runs of the "else" clause.

I would manually do a "run then" and see if the light turns on. That would clear up any comm issues as the prob or mis-labeled/created scenes. Then I would start with all doors secure, then open a door and leave it open and then check ISY admin console to see if the last run time was at that time and that it ran "true". If a door opens, it should violate which should trigger the program and it should be true and the light should turn on. If the program didn't run true, check the ISY admin console to see what status it thinks the open door is in.

The other option is to create a single scene with all of your devices that you want to turn on at sunset. When they are all in one scene it then is a single Insteon command for the whole group. This is probably a slightly better option since short delays like 1 second don't necessarily prevent Insteon traffic pile ups when several repeats are responses are involved.

This is what I have done. The first program triggers when you open the door and the light is already off. If the light is already on, then nothing happens. This calls the second program "else" path. After 10 minutes it beeps to warn you that the light is going to shut off. If you want it to stay on, you have to hit the "on" paddle and that will re-trigger the second program to run "true" which will abort the timer that shuts off the light. If Program 'Dark Outside' is True And Elk Zone 'Front Door' is Violated And Status 'Foyer / Foyer-Portico Can L' is Off Then Run Program 'front door 2' (Else Path) Else - No Actions - (To add one, press 'Action') If Control 'Foyer / Foyer-Portico Can L' is switched On Then - No Actions - (To add one, press 'Action') Else Set 'Foyer / Foyer-Portico Can L' 100% Wait 10 minutes Set 'Foyer / Foyer-Portico Can L' 250 (Beep Duration) Wait 30 seconds Set 'Foyer / Foyer-Portico Can L' Off

While it is fine to disable the second program, it isn't necessary. A disabled program blocks the "if" section from self triggering. When the "if" is empty, it can't self trigger anyway. But I do agree, it is better to merge the programs into 1 anyway.

If you can turn the scene on/off without trouble from the admin console then it is not a comm issue unless you only have comm issue at sunset. Do you have any other programs that are running at sunset that might have a load that is messing with things? If your program summary page states it is running "true" at sunset, then you can also check your log and see if the Insteon command was actually sent. Also, try doing a "run then" and a "run else" on the program and see if it turns the lights on off.

Switches... Nice! Really creative. Pick a time of the year. Determine when sunrise is at that time of year. Use that sunrise time as the limit of your time condition. I may steal this idea. That is a clever solution. You might run into DST issues depending on the exact dates.

If you are looking for something where the year is a wild card, then ISY doesn't have that built in. The above program by Lee works for this Christmas season only. If you want to add wild cards for all of the different date functions you need to download this set of programs and install as indicated. Otherwise you need to do what Lee did with multiple "if" statements for as many years into the future as you would like to have this program work connected by "or". (If from a to b date, or c to d date, or e to f date, etc) http://wiki.universal-devices.com/index ... _Variables

You can use an IOlinc and 2 relays. One relay has a 120vac coil (I'm assuming your pump runs on 120vac) and is placed in parallel with the pump power, between the pressure switch and the pump itself. When the pressure switch powers the pump, it will also power the relay coil and close the contacts. The output side of the relay is connected to the IOlinc. In this fashion, when the relay coil (and thus pump) are powered, the IOlinc will see the contacts on the relay close and signal ISY. The other relay would be a 12vdc coil and a 120vac contact side (like the Elk relays on SH's website). This relay would be used to interrupt power to the pump. The coil would be powered from the IOlinc and thus ISY can turn the IOlinc output on/off which in turn opens/closes the relay which interrupts/connects power to the pump.

Ube appears to be getting closer to release. They say they will be releasing their API. The switch looks pretty nice in shape and size. It has screw terminals instead of pigtails. I see that is being a little bit more of a challenge with getting the wires tucked in, but we'll see. I am going to assume that being an IP device with a public API we should be able to control them using the network module right off.

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.