apostolakisl

If a scene command is written to turn the kpl on, and the kpl receives the scene command, the kpl turns on. But if the PLM does not receive that same scene command, it will not know it turned on. Conversely if the scene is turned on, and the PLM receives the message, but the KPL button does not, then the PLM will think it is on, but it is not.

What ISY "thinks" the status of the KPL is the only thing that matters as far as programs are concerned and is all about the com. If the ISY did not receive the insteon message of the most recent change, then ISY will have the status wrong and the program will not execute as you expect. Programs do not query the device when they run, they only check their own register to see what it was last time it received a status update. I am about 99% certain your problem is missed com's, not anything with the ISY program or internal logic. Try using dual band kpl, adding more dual band devices in general, or finding signal sucking/noise problems in your home. You can also try adding a test program to send you an email every time ISY sees the switch status change. Your emails will then create a log of every status change. Compare that to your actual usage.

Yes, the 400v one that replaces the 250v one is the one to which I refer. The others are more or less the same size as the ones they replace.

I ordered and received the parts. I will do the soldering this weekend. I'll take a few photos, but it isn't rocket science. The thread lists which ones go in which spot (the pcb has all the caps numbered c1, c2, c3, etc). Caps do have polarity, so you have to note which way they go before removing them so that you put the new ones in the same way. Also, the one cap is substantially larger than the one it replaces, but I think it will still fit OK.

Safe mode is what happens when there is no PLM. Odds are VERY high that it is your PLM. Is it jut a bit over 2 years old? They are programmed to self destruct just after the warranty. They are made with a number of cheapo capacitors that burn out in just about exactly 26 months. There are a number of threads on the forum, one fairly recent about this. If you are skilled with electornics and soldering, you can fix it yourself per the parts list on that thread. Also, UD is making their own PLM of high quality materials. But that is no yet for sale. EDIT: Here is the thread http://forum.universal-devices.com/topic/13866-repair-of-2413s-plm-when-the-power-supply-fails/

I believe one of the recent firmware upgrades got rid of "on" for all dimmable devices. There was a lot of confusion of what "on" meant (it meant 100%), but lots of people thought of it more as "not off". I agree that a kpl button itself is either on or off, so probably having the percentage thing is bad. Anyway, using 100% or "not off" should be working. You may have a com issue. Can you confirm that the com is good?

You best put a ticket in on that one. No idea.

Like I said, there is no need to lose your programs. Just export them before the reset then re-import them. It takes a few seconds is all. But all of your programs will presumably be referencing Insteon devices which no longer exist. So there is going to be a lot of work when you add all the devices. By network settings, if you just mean IP address, port numbers, and the like, that is very minimal configuration. If you have the network module and a bunch of network resources setup, those can be exported and then re-imported.

Since it seems as though you are starting from scratch, why not just factory reset the ISY? http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Restarting_Your_ISY-99i Although I see you still have a bunch of scenes, I guess they have no members in them? If you want to reuse your programs, you can always export programs before the factory reset and then restore them. Same with network resources. Variables would need to be manually renamed, so save a screen shot of them if you need to restore them. Same with emails and notifications.

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.