apostolakisl

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

This is how I would do it. I do have a lot of experience with CAI boards and 1-wire. CAI boards can push the 1-wire temp readings directly to ISY upon criteria of your choice within the cai programming. The cai can handle 8 1-wire sensors at a time. I just assumed you want the temp readings in ISY, but I don't know what the other thing(s) is/are and thus can't say if CAI would be able to provide that(ose) devices with the values as well . . . at least directly.

You can write a program that checks for "is responding" on Insteon items in the network on some schedule and set a variable if there is a failure, then it could set the variable back when it does respond. At first boot the ISY checks for the PLM and goes into safe mode if none is detected. I'm not sure if it goes into safe mode if the PLM goes off line after a successful boot. Even if it does, there is no programatic action you can take based on that.

You may not want to put the switches into your new house if they are a bit vintage on the firmware/hardware side. But I really believe that these switches on the whole will scare off a buyer and as such drop your house value. My approach would be: 1) hire a freelance electrician to take all the switches out. Probably end up costing $5/switch and pretty much no time lost or headache for me. 2) save the ones that I want to install in new house. 3) sell the rest on ebay. You make money because 1) your house probably sells for higher price/more quickly without the switches 2) you saved at least some of the switches for you new house 3) you sold the ones you didn't want in your new house for more than it cost to remove them 4) you don't get a million phone calls from the new owner of the house wasting your time (time is money) when they can't figure it out. An alternative would be to make it clear when selling the house that the "fancy" switches are optional and will be removed by you if the buyer doesn't want them. I suppose this might give you the best of both worlds where it does not scare off a buyer who is scared of such techie stuff and might get the special tech happy buyer super excited about your house.

If you put it between the surge protector and the wall outlet. The filterlinc isolates anything on its downstream side from the rest of the house. Of course you can't put anything Insteon on the downstream side either since it will now be isolated from the rest of the house.