apostolakisl

I know you want actual experience, so I am sorry for saying I don't have that with this device, but it looks interesting to me. http://www.ebay.com/itm/170724913886?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649 From me reading, I believe there should be no problem controlling it using ISY's network module. The advantages I see here is that 1) no worries about insteon signaling issues. 2) 16 relays for $145 Not sure about how confirmation of the state of a relay can be relayed back to ISY. This is always a problem with ISY and using Insteon because of Insteon comm failure and then ISY listing the wrong state. It appears the state of a relay is easily confirmed using the apps they provide or writing your own. Perhaps it can be programmed to send a REST command to ISY with relay state changes setting ISY variables. Probably not, but maybe. In my experience using ip comm with the webcontrol board, response time is very fast, "instant" to the naked eye. Insteon comm usually has a lag.

I was able to get an Elk valve for $300 a few years back. If you poke around this forum or maybe cocoontech, I believe there are some threads where the OEM was identified and alternative sources for purchase were found at a better price. I use my Elk security panel to control the valve. It is a very good valve that in my case actuates multiples times every day and is now 5 years old. I have my water turn off every time the alarm arms away. I also have about 25 water sensors scattered about the house. But like I said, you can have leaks anywhere and you can't put the sensors everywhere. I have seen devices that monitor flow for suspicion of leak. They have an algorithm built in which mostly can tell the difference between actual purposeful use and a leak. But just plain turning the water off never fails. This assumes you don't have some appliance that must have water while you are away. Also, my Elk valve is after the split off to the outside hose bibs. They don't shut off. My irrigation is on a well. I don't know if you plan on security, but Elk and ISY integrate very well (requires Elk module for ISY).

You should put in a whole house powered water valve. Elk makes a very good one, it is pricey. You can control with Insteon IO linc. I would just shut the water off when you are not there. If you are going to be away for extended periods of time you can't trust leak detectors because they can't be everywhere. An appliance linc can be used to power cycle your DVR or anything else for that matter. I have never ever had to power cycle my ISY. Unfortunately, if you have an issue with your modem/router you won't be able to talk to your ISY. I suppose you could figure a way to program the ISY to power cycle the modem/router if it fails to communicate with the internet. Just quick thinking it might involve having a REST command sent to your ISY daily via internet that sets a variable at some regular interval. Then a program in ISY looks for that, if it doesn't see it, then it power cycles the modem/router. That is just a thought. For example, it sets a variable to 1 at MN and 0 at noon, then a program on ISY runs a program at 12:01 am that looks for 1 and one at 12:01pm that looks for it to be 0. If not, reset the modem. EDIT: Or I suppose use the web-power switch. Hadn't seen one of those. Don't know what it costs, it might be more cost effective to use appliance lincs, especially if all of your power cords aren't in the same place.

You create a couple of temporary variables just for testing. Then you put a line in your program that says $i.test.variable +=1 Each time that line of code runs, it adds 1 to the variable and then you know how many times it ran.

You might put a counter as the first line to see if the program is getting re-triggered multiple times. A second counter after the wait might be helpful too. I know you already have the other variable getting set to 1 which should prevent the program from running true again, but this variable is affected by the other program which may be doing something funny based on the wattage readings it is getting.

Assuming the status of the fridge wattage is changing before the 5 second wait, causing a re-trigger, and running the blank else, you should also find that the variables are not getting set. So, the question then is: Is the variable getting set to 1? ($i.Refridgerator_Defrost_Status = 1) I assume not. So you might need to do something about that also. Or, maybe the wattage reading is not dropping into false category, but rather bouncing around and re-triggering the program true, but it never gets past the 5 seconds to send the email. Eventually the wattage falls into false range and then the else runs. Either way, if the email isn't getting sent when after the 5 second wait, then the variables won't be getting set either. In this case, you might see multiple emails when you put it before the 5 second wait.

Wild guess, but most people don't try to tell a thermometer what temperature it should say. Anyway, I answered his question quite directly and succinctly in the first post, and made it clear that the other posts were to assist him (and any other random user) of the bigger picture.

Appreciate the thought, but Paul has clearly stated he is moving an entire home automation system over. It would benefit him greatly to realize that what he is doing here may apply differently elsewhere. He is free to ignore the extra info if he likes.

No problem. And one point that I think is worthy to make. "control" conditions in programs always are INITIATED AT THE DEVICE ITSELF. In other words, "control device x is switched on" means that the command started at device x. For most devices, that means someone physically pushed the button on it. (other types of devices like motion detectors requires that the device itself experienced motion) Please realize, that if you have a scene where a switch is turned on in RESPONSE to that scene, then a "control is switched on" didn't happen and a "control" condition will not trigger and the program will not run at all. Yes, the light switch did switch on, but it was not a "control", it was a response to some other device being "controlled".. If you want a program to trigger based on the switch changing status by any means (whether by direct action on it or by it responding to some other device's command), then use "status"..

Paul, This is a common ISY new user issue. Understand 2 concepts: 1) Trigger. Something that triggers the "if" clause to be run. If there is no trigger event, then there is no true or false execution at all. 2) Post Trigger Evaluation State: After the program "if" is triggered to evaluate, is it true or false (then or else clause). Always one will run. Often times the "else" is blank so nothing happens, but when the "else" and "then" are used, you always have an action take place. . . sometimes with un-intended executions of an "else" clause. This makes using "else" clauses a little more complex, especially with multiple "if" statements. "Control" statements only trigger on the precise action listed. "control is switched on" is only a trigger when an "on" command is sent through the power lines. Thus "control is switched on" by itself can only be true and only will run when an "on" command is sent through the power lines. "Status" statements trigger on all CHANGES in status. They can be true or false. One trick here is that they do not trigger if the status didn't change. In other words, if a switch is on, and someone pushes the on paddle again, this will not do anything. A "control switched on" however will run the if clause again and start over. "is not" can get your brain tied in knots. Simply think of it as the same thing as "is" but the "else" clause will run instead of the the "then" clause. In my example above, I used the "is not switched off" clause to allow an "off" command to 1) trigger the program and 2) evaluate it to false with that "off" trigger. LeeG did that using 2 separate programs having them both run true and using the "then" clause in both. The end result is identical. You may find it easier to get your brain around using 2 programs, especially at first. You could also use "status" in this situation. With insteon devices that do not have dim levels (they are either on or off), status and control programs tend to behave almost the same. The main difference would be if something is already on/off, and a new on/off command is sent from the device.

If you need the else clause to trigger on a control clause then do the following If control device x is switched on and control device x is not switched off Then do something Else do something else. The reason the "else" clause does not ever run in your program is because there is no trigger for a false event. "control switched on" is triggered when an "on" command is received, of course it is then true. Nothing else triggers the program so thus there is no false state. The "is not" terminology allows you to include "switched off" as a trigger, which will then be false, because it was switched off.

I don't know much about the wake on lan. But I can tell you that 10.10.anything.anything is not a public IP adress. Both addresses you list there are private LAN addresses.

Do you have a BOM you can post for us?

4am itself is a trigger. So if the temp is already below 20 when the clock hits 4am, that will trigger the program and your heater block will start. If the temp stays put (below 20), 3 hours later the program will re-trigger (because of the "run if" in program 2), it will still be true, and the timer will start again for 3 more hours. However, 1 hour later, at 8am, the program will trigger and turn the heater off. If the temp is not below 20 at 4am but later drops below 20, then the change in the state variable will serve as your trigger. Your program will run for 3 hours unless 8am happens first.

Yes. Highly recommend that if it is less than 2 years old you return it quickly before it runs out of warranty. This is classic. It will probably be totally dead within days to maybe a couple months.

Looks good. If you manually set the temp variable pretending it is a cold winter night, you can test it out. Maybe you temporarily change the times to a more convenient hour of the day for the sake of not having to test it at 4am.

Sorry I did this from memory and "is not" availability does not exist for times, So instead swapping the logic in the the then else clause does the same thing (put the then clause stuff in the else clause and vice-versa). If time is 4 am to 8am and state variable temp is below -20 Then run program 2 else Else set heater off Program 2 If time is 8am (optional if you want heater to shut off at 8am no matter what) Then set heater off (optional if you want heater to shut off at 8am no matter what) enable program 1 (only needed if you include the optional if line) Else disable program 1 set heater on wait 3 hours enable program 1 run program 1 if So at 8am program 2 will be true and self trigger the then clause, a running else clause will terminate.

If time is 4 am to 8am and state variable temp is below -20 Then run program 2 then Else set heater off Program 2 If time is not 8am (optional if you want heater to shut off at 8am no matter what) Then disable program 1 set heater on wait 3 hours enable program 1 run program 1 if Else set heater off (optional if you want heater to shut off at 8am no matter what) enable program 1 (only needed if you include the optional if line) Not sure if this is exactly what you want. It will turn the heater on anytime between 4 am and 8 am that the temp is below 20. The heater will run for 3 hours no matter what else happens unless you include the optional lines listed.. If after 3 hours, program 1 is still true, it will leave the heater on for 3 more hours, if conditions are not met, it shuts the heater off. If you include the optional lines listed, the heater shuts off at 8am no matter what.

The fact that you are using a state variable means the program will re-trigger every time the temp changes. So your 3 hour timer will keep resetting every time the temp drops or goes up by 1 degree. Also, it will run false at 8am and stop the 3 hour wait, so the heater will never shut off (or at least not until the next day). Similarly, if the temp rises above -20 while the 3 hour wait is running, it will end the wait and the heater will again just stay on.

The program you first wrote will trigger every time the status of the synchrolinc changes. So if you are getting more than one email, then the synchrolinc is flipping on/off somewhere in there when it shouldn't. This could be a result of variations in the pump current draw. You can change the time out period on the synchrolinc and you can change the wattage trigger threshold. These might prevent it from reading on/off changes when none occurred. On the ISY, there is an "options" button at the bottom of the page for your synchrolinc where you can change those.

I would be happy to help test prototypes. Seems like the ones from SH are so consistent at burning up 1 month past warranty that it might be worth plugging it into 240v one month before warranty expires. . . .just to slightly hasten the inevitable. My original 2412s lasted quite a long time and in fact never burned out. I only replaced it because the 2413s had new features. Maybe I should have kept the 2412s, at least it had the feature of not burning up.

The thing with fridges is that you never handle any of the stuff that has power. All of that stuff is buried inside the machine. This means that only a short to the chassis could put the user in contact with a hot. But the chassis is grounded to earth so a regular breaker would pop as soon as that short happened. I suppose you could be changing the light bulb or futsing with the ice machine and in that case you could touch a hot and be grounded elsewhere. But those risks must not be considered worthy since as you said and I knew was the case as of 2009, it is not GFCI required.

Not sure about GFCI for dedicated fridge circuits. Mine are not GFCI and my house electric was built to code 5 years ago. Perhaps this is something some local jurisdictions require, but mime didn't. It doesn't really make sense to have a fridge on GFCI to me. I can't think of a way for a fridge to shock you aside from a short to the body of the fridge, which should cause the regular breaker to pop. I suppose it could happen.

Well this doesn't sound like poor design but rather plain old cheapskate code violating crappy work. For one, your kitchen fridge should be on its own dedicated breaker. However, a GFCI is not designed to pop on amps, it pops on failed balance between hot and neutral. Or in other words, there is a ground fault. So over-amping a circuit should be popping the regular panel breaker, not the gfci. Your problem is either an actual ground fault or possible some motors at start up have capacitance or some electric phenomenon that creates a short lived imbalance.

As Xathros said, but be sure to realize you need a second program that does the query every so often. If every 30 minutes then query garage freezer