IndyMike

Hello Michael, I'm going to apologize up front because I will be ignoring many of your questions - let's cut to the chase: [*:20ddw585]You are installing a new irrigation system and new sod - both are sizable investments. New sod is a great way of obtaining an instant lawn. It's also a water PIG. Personally, I would talk to your sod installers about the irrigation requirements and do EXACTLY what they say. They should understand your local restrictions and the sod requirements. I'm guessing that the watering requirements will be far in excess of anything the ET calculations indicate. Get the SOD to establish itself first, then we can worry about efficiency. [*:20ddw585]Talk with your irrigation installers - you want all of your sprinkler heads "tuned" so the provide a constant rate across the zone (xx inches/hour). [*:20ddw585]After the system is installed, measure the application rate and coverage efficiency using the link I posted to Jmed999. Since you have a new system, I would call the installers if the irrigation rate changes significantly across a given zone (poor overlap/incorrect nozzle sizing). [*:20ddw585]Lastly - the ET numbers that you posted (0.8 and 1.7) are way off for Chicago (actually, there way off for most anywhere). If the units are in inches, you should be seeing around 0.14 inches/day. If the units are millimeters, you should be seeing around 3.56 mm/day. Sorry for ignoring your questions on programming. I would much rather see you get the sod established first, and then worry about efficient watering. IM

Hi jmed999, Answers below - That would be my recommendation. As I stated, you may need to adjust depending on whether you have flat/sloped ground. The irrigation rate is your responsibility. If you have a high irrigation rate (inches/hour) and heavy soil/slopes you will need to apply multiple waterings to prevent runoff. To the best of my knowledge, the "allowable depletion" is presented as a guide. It is not used for programming. I've actually requested that UDI eliminate this in favor of the water balance table above. Glad to hear that. I'd be interested in your system type (spray, rotor, rotator) and your results. IM

-When you say you apply 0.2" of water do you mean your irrigation system applies 0.336" which equates to 0.2"? So you apply 0.336 and only 0.2" is absorbed, right? Seems like if you need 0.336" and allowable depletion = absorption factor you would need to apply 0.56" since 0.56*.6=0.336. If you want to replenish the amount that has depleted (0.336") then wont you need to apply 0.56" since only 0.336" will be absorbed? -Also, for loamy sand (your soil) the ISY has an allowable depletion of 83% which is different from your chart of 60%. Why such a difference? Hello jmed999, I'm running with a Soil Absorption setting of 80%. I tell the ISY that I've applied .25" and it deducts 0.2" (80% * .25 inches) from the irrigation required. On the subject of Soil Absorption - I regard this as a misnomer. In order to calculate soil absorption you need to know the Rain/Irrigation rate (inches/hour). That information isn't available to the ISY. As an example: Heavy clay soil is capable of absorbing around 0.1" of water/hour. 1) If you are on a slope, and received 1" of rain in an hour, only 0.1" will be absorbed. The rest would be lost to runoff. 2) Given the same slope, if you received 1" of rain over the entire day (1/24 = 0.042 inches/hour). Most of the 1" of rain would be absorbed (until you saturate the clay). Instead of using the term "Soil Absorption", I treat this as a "watering efficiency" and set it to 80%: 1) The 80% number is generally accepted as a rainfall efficiency in the irrigation industry. It accounts for runoff and evaporation from the plant canopy (water not reaching the soil). 2) The same 80% is applied to irrigation. An 80% efficiency is at the high end for most irrigation systems, particularly rotor systems that are operated during the day (spray evaporation, wind effects, poor overlap). You can compensate for this by simply running your system longer and telling the ISY that you are applying the same amount of water. Summarizing the above: 1) I would suggest that everyone use a baseline of 80% absorption. People on slopes may need to "tailor" the number downward. People in flat areas may need to "tailor" upward. 2) Please do not use the "allowable depletion" from the ISY. Use the water balance table the I presented previously. The allowable depletion item was based on the "soil absorption" entry - as explained above, this can't be determine with the information the ISY has available. 3) There is no substitute for "measuring" your irrigation rate and coverage (overlap). This is particularly important for Rotor or impulse style heads. Most systems are installed with one size nozzle in all of the heads - this disregards the area covered (45, 180, 360 degrees) and leads to huge differences in the application rate. Section 4 (page 19) of the following provides worksheets and describes how to perform a "catch can test" to determine your irrigation efficiency: http://www.irrisoft.net/downloads/manuals/InSite%20Users%20Guide.pdf

If weatherbug doesn't respond none of the variables are updated - you get the last valid value.

Hello MWareman, We're getting into "irrigation methods" here. This is very dependent on your location, soil structure, (and in your case) watering restrictions. I can offer some suggestions, but you'll really need to test to see what works best in your particular situation. In the example... If Irrigation_Required > 0.5 and Rain_today < 0.5 ..this gets messed up if it effectively rained 0.4" (meaning I'm applying 0.4" too much - and wasting water). If Irrigation_Required > 0.5 and Rain_today < 0.2 ..this gets messed up if it effectively rained 0.3" (meaning I'm getting .2" too little). Because Irrigation_Required is updated only once a day at midnight - what I really need to do is subtract Rain_Today from Irrigation_Required and see if the result of that exceeds my threshold. I cannot seem to do that in an ISY program (in the same way that water applied by irrigation is currently subtracted from the irrigation required when a cycle complete is executed). I also have every-other-day and time-of-day restrictions to my irrigation - so I have to be able to do the math for twice a day irrigation on the days allowed. During the summer months (and factoring the absorption rate) it is very difficult to apply the needed water in only one cycle without busting the time restriction. In the examples that you provided above, I would err on the side of applying too little water (example 2). Grass is pretty tolerant too little water. You can absolutely kill it with too much water (fungus and other diseases). You need to envision your soil as a leaky container (sponge). It you overfill the container you will get runoff and rapid percolation. The soil will rapidly loose water until it achieves it's "Field Capacity". The Field Capacity is determined by the soil type and root dept of your grass. The heavier the soil and deeper the root depth, the more capacity you have. I happen to have loamy sand with a ~8 inch root depth. From the table below: 1) Field capacity = (0.07 inches water/Inch depth) * (8 inch root depth) = 0.56" water 2) Allowable depletion (60%) = (0.6) * (0.56" Field Capacity) = 0.336 When the ISY tells me that the Irrigation Required = 0, it is effectively saying that the soil is at Field Capacity. When it tells me that Irrigation Required = 0.336, I am at the maximum allowable depletion. I apply 0.2" water. Because my soil is light and can't hold much water, I normally need to water daily in the Summer (4:00 AM). I also practice "deficit" irrigation - I allow my water balance to get below 60%. It promotes root growth in the grass. Please perform the calculations for Field Capacity and post back. I have a suspicion that you are trying to apply too much water - don't overfill the container. Under-filling by 0.2 inches isn't a problem. Real time calculation of ET requires a real time measurement of Solar Radiation (Rs). Weather bug does not provide Rs and hence only daily calculations can be performed. Real time updates of Irrigation_Required is left for the user to implement through programs as discussed above. While the ISY could perform this calculation - it would invalidate existing users programs. In other words, this is a question for the UDI team and the forum as a whole. Your watering restrictions do present some unique challenges. I haven't had to deal with them. Please post back the following: 1) Soil type 2) Root Depth 3) Soil Absorption % 4) Current daily ET (estimate) We'll see if there may be an inventive solution. Right now I'm thinking you could use State Variables to guestimate tomorrows ET loss (non-watering day) based on the time of year. IM

Hello MWareman, You are very close on your understanding of the WB module: The ETo, Irrigation Required and, Water deficit numbers are calculated once after Midnight. Rain today is a live number from WB. Water_Deficit = ETo - ((Rain_Today + Irrigation) * Absorption_Factor) Irrigation_Required = Irrigation_Required + Water__Deficit (cannot be less than 0) Note that the Absorption_Factor is applied to both rainfall and irrigation. Add Rain_Today to the qualifiers in your irrigation program: If Irrigation_Required > 0.5 and Rain_today < xx Then Run Irrigation_Program

Hi kaisersoze, Thank you for providing the address for the WB backyard station. This particular station has feeds for both Weatherbug and WeatherUnderground. WeatherUnderground is useful since it provides historical data. The "classic" Penman-Monteith calculation for ETo requires measured Solar Radiation (Rs). Weatherbug does not support Rs data in their API. As a result, the ISY is using an approximation based on elevation, temperature, and location (coastal or inland). The approximation works very well on average. As you've noted, it has a tendency to over estimate on very cloudy days. Fortunately, these are low ETo days and the errors should be on the order of hundreths of an inch. It should perform very well on sunny days - in contrast to your observations. This is my reason for posting. I would have expected your sunny day calculations to perform better than you have indicated. Using the WeatherUnderground interface for your local station, I pulled the historical data for the month of April. The table below shows what I believe the ISY should have calculated on a daily basis. I agree with your cloudy day numbers (4/14 - 4/15) of 0.07 to 0.09 ETo. I do not agree with your sunny day numbers (4/18 - 4/20) of 0.13 to 0.15. Something is wrong here, a Weatherbug sampling error. To assess the calculation accuracy, I pulled CIMIS data for your area. CIMIS provides all the necessary data inputs for the calculation, and maintains historical calculated ETo. The Escondido appeared to be the best match for your location. The following shows the CIMIS data and ISY predicted calculations for the current week. It also shows the ISY calculation error for the week based on the CIMIS "PM ETo" calculation. Remember that CIMIS is using measured Solar Radiation, whereas the ISY is using an approximation. Given Identical input data, it would appear that you should be using a setting of "interior" in your climate settings with a resulting error of 0.058" ETo (4.7% error). Surprisingly, the Hargreaves-Samani equation is performing better still (implementation is in process). I would not expect this to be the case over a longer period of time. So, why are you seeing different values? Possibilities: 1) The ISY P-M calculation relies on averages for Windspeed, Dewpoint, and Temperature. These are averaged over the course of the day. While High/Low temperatures are used, these can be acquired in a single "snapshot" at the end of the day. Communication dropouts will cause errors in the data averages. 2) Weatherbug location changes - If a station is unavailable, weatherbug will automatically switch to a "close" alternative. In some areas, where the terrain changes drastically in short distances, this can be a huge source of error. Disclaimer - I do not know if weatherbug does this for "backyard" locations. 3) Poorly placed/maintained station. Stations used for general weather conditions are often not suitable for ETo calculations. The ETo calculations require proper placement and maintenance of the equipment. Note: this is a general comment - your selected PABLOCO station appears to be reporting data that is consistent with CIMIS. If you have correlated the readings between CIMIS and PABLOCO then this is an excellent choice. My hat's off the the backyard operator. Communication errors are the reason that the UDI team is investigating the Hargreaves-Samani ETh calculation. Since it relies on only the max/min temperatures of the day, the data can be acquired in a single snapshot. Averaging is not required. On the subject of communication errors - when I visited the Wetherbug backyard and WeatherUnderground sites for your local station, I found some interesting differences: 1) Weatherbug was reporting a high temperature of 81.2 degrees recorded at midnight (00:00) 2) WeatherUnderground was reporting a high temperature of 59.4 degrees. This could be a simple website translation error - I don't know what the API is transmitting to the ISY. If the 81.2 degree high is being communicated, there will obviously be some significant errors. Weatherbug has been having issues with the feed from the backyard stations for some time now. Is there another station that you could use? Edit: I was able to connect to your local station using the ISY. It did report a high temperature of 81.2 degrees for the day. Based on the stations reports for the day, and the weather graph presented, 81.2 degrees simply isn't possible. Apparently Weatherbug is still having issues. The Station master for this site provides data to the NWS/NOAA in support of the MESONET. In other words, he/she takes this stuff seriously and probably doesn't realize that the data is being misrepresented on weatherbug. You may want to notify him/her.

Mike, I looked over your XML files. Hard to tell whether the calculations are correct since the data isn't continuous. I did notice that your April 2 data included a 121' elevation. Elevation is reported directly from Weatherbug. This is either a corrupt transmission, or an example of Weatherbug switching stations automatically (really annoys me). If this was a station switch, it was obviously a rather distant station.

I think they're still down. I have 0 stations showing online in all of Michigan/Indiana

Hello Mike, I'm still struggling with your soil system. Comments below - Normal soil structures have been characterized and assigned "Field Capacity" (FC) numbers base on the soils ability to hold water. You stated that you were using a "loamy sand" soil classification and had 6" - 8" of soil. From the table below: 1) 8" of soil @0.07" per inch of root depth (8 x 0.07) = 0.56" in H20 Field Capacity. This is the maximum water that that classification of soil is assumed to be able to hold. 2) Assuming an 8" root depth, your Maximum Allowable Depletion (MAD%) is 60% (0.6*.56" = .34" water depleted). Problems: 1) The table assumes a normal level of percolation - any irrigation above the Field Capacity of 0.56" is assumed to run-off (heavy soil) or be lost to percolation. 2) While a heavy rain in excess of the FC will saturate a "normal" soil, Evapotranspiration will be increased as will percolation. Normally, the FC will be re-established within 24 hours. In other words - the ISY is correct in re-starting irrigation after 48 hours. It is assuming a "normal system" that has re-established the FC due to run-off/percolation. 3) As I stated previously - your lava cap prevents Percolation. This effectively throws the concept of Field Capacity out the window. You effectively have a closed container that can be filled to saturation and is only subject to drainage due to elevation changes. I have not found a "residential" application that can account for the lack of Percolation. The alternative is active soil moisture measurement. As I said in the lead in, I have not come up with a good solution for this. In the meantime: 1) Adjust your soil type to sand (100% absorption). This will help account for the lack of percolation. 2) Historically, your summer months will be marked by lower rainfall and higher ET. This should lesson the problem of Rain storage above the lava cap. 3) Your normal March ETc was 2.4" vs a rainfall of 2.2". Assuming your soil is retaining the rainfall, that's not enough difference to worry about. You might consider disabling the system from Jan through March. That's a news item for me. I did not realize that you had a means of measuring the soil moisture. Could you post back the make/model of your tester and any measurements that you have performs? I rolled up my data this morning. I'm rather disappointed: 1) I forgot about the time zone difference. I believe the ISY was pulling numbers for your site 3 hours early. 2) I had modem issues (1st time in over a year) on 4/3. I missed some rainfall on that date as a result. 3) Sampled the KAUR site at 5 minute intervals. Had 3 errors over the space of 5 days (seems reliable). Other than the loss of data on 4/3 (Modem down), I don't see anything incorrect in the following. Please let me know how I can get your recorded data. PM me if you need an Email address.

Hello Mike, I've been reading Engineering Manuals for the past couple of days. After educating myself a bit more, I am have to retract an earlier statement: The ISY is correct in not allowing a negative water requirement. This is accepted practice in the absence of a detailed site analysis and/or active soil moisture measurements. From the US Dept of Agriculture Engineering Handbook:(FC is Field Capacity) What I view as important in the above is the phase "percolation below the root zone" - You have rock below the root zone. There is no percolation. From your previous description, you have 6 - 8" of topsoil above the Lava cap. Referring to the graphic below, when it rains (or you irrigate) a portion of the water will travel through the soil and hit the lava cap. As you noted above, the slope of your land will cause the water to travel downward until it hits an obstruction (curb, driveway, foundation). The soil near the obstruction will become saturated as a result. As you probably already know, saturated soil is not a healthy environment for grass. Under watering grass will cause it to go dormant. Over watering can kill it (in a much shorter time). I do not have a solution for heavy rainfall. The ISY calculation should accurately calculate the ETo for the upper end of your slopes. If the low end of the slopes are being dammed by an obstruction (saturated), you'll need to apply some "Kentucky Windage". From the looks of your weather history, heavy rainfall should be gone until November. As far as irrigation is concerned, I think you have to correct approach in applying .25" per watering. I would not run the system twice in a day (.5") unless the ISY tells you that you lost over .5" the previous day. Based on your ET#'s, you're not there yet. Most irrigation manuals promote "deep watering" of 0.5" to promote root growth. With only 8" of soil, your grass roots have little room to grow. In other words, daily watering of .25" will cause less drainage to the lower sections of the lawn whereas 0.5" watering every other day may saturate the area. The Rotator heads are nice. I wish they had them when I laid out my system. They are susceptible to wind (which you appear to have a lot of). Be careful watering in the evening when the winds may be high - your uniformity will go to the wind (pun intended). If you are interested, I've used the following site many times over the years as an irrigation reference:http://www.irrigationtutorials.com/reviews/rotor/mprotator.htm I am still interested in the numbers that your ISY is providing. Let's give things a couple more days, then we can compare notes. I have some more suggestions, but want to see the numbers first.

Hello Mike, The station name was a typo. I'm monitoring KAUN. I've updated the charts based on your settings. I have to admit that your soil structure has me a bit mystified. I have no idea what a "lava cap" is. "Highly absorbent" and "runoff" don't normally go together unless you are applying water at a very high rate. From your description, this sounds like soil that is 100% absorbent but quickly hits a saturation limit. I don't know how to model that - yet. Questions: 1) What type sprinkler heads are you using (spray, rotors, etc)? 2) Have you measured the application rate? Observations: 1) If you are able to saturate your soil with the sprinkler system, the same will be happening (probably to a greater extent) when your receiving your 1" of rainfall. 2) The above being the case, retaining the full value of 1" "rain today" is completely incorrect. Most of this would be lost to runoff after the soil becomes saturated. I still do not understand the 7" offset. If I add the total ETo for the month of march (disregarding rain) I get about 3". In other words, your system should never have approached the 7" offset. If this number is correct, something is very wrong. I have my ISY set to monitor your KAUN site using the numbers you posted. If you could collect numbers over the next few days we can compare to see if you are somehow getting corrupted data. The easiest way to pull your data is to use the REST interface via your browser: 192.168.XXX.XXX/rest/climate. Save the XML file and we can compare notes. IM

Mike, I found your station and downloaded the observations for the month of March. I do agree that there should be some method of retaining the rainfall information. Note that your NWS site appears to report at 30 minute intervals. Based on your error log, you are requesting data from weatherbug at a much faster rate (not sure what that is). I believe I remember one of the UDI team posting that over-polling weatherbug sites could be interpreted as a Denial Of Service attack and could result in errors. Regardless, you should be able to back your polling way down - it's not buying you anything. I am currently monitoring the NWS station at 10 minute intervals as a test. I'll let you know if I encounter errors. The 1st chart below shows the ISY calculated ETo and Irrigation required (both as calculated and with retention of rainfall). You've had two rather significant rainfalls (on 3/6 and 3/20) and are in the process of getting more rain today. Sorry for the crappy weather. The second chart predicts Irrigation based on: 1) 100% Soil absorption 2) 0.5" water applied per cycle 3) Both current calculated Irrigation Requirement and Irrigation requirement with Rainfall retention (negative values). As shown, the current ISY calculation (not retaining negative Irrigation) would have resulted in 5 cycles of your irrigation system. If the ISY had retained the negative values, the system would have cycled 3 times (one inch less water applied). With all of the above said, I still do not understand your numbers: 1) You stated that you've applied a 10.5" water offset to keep your system from cycling. I don't understand this - your total calculated Irrigation requirement for March should not have exceeded 1.2". Is it possible that you are using metric values (mm)? 2) I'm having problems understanding why your system would cycle every day or so. Please post back your settings: 1) Irrigation Region 2) Soil absorption (100%, 90%, etc) 3) Water applied/cycle 4) Allowable depletion 5) What you are actually watering (Grass, flower beds, etc). IM

ARRRGH - 3 hours into a post and I just watched it vanish. Lesson (re-)learned: write post local and copy/paste to the forum! Here's the short version: I assisted Michel in checking out the ETo calculation. I believe it's accurate within +/- 7% over a month. It will vary more per day but we're talking about errors on the order of 0.05 inches. The calculation relies on elevation high/low temperature, and averages of current temp, wind speed, and dewpoint. This is a classic example of Garbage in = Garbage out. 1) If you have a unreliable WB connection, your averages will be incorrect. If the "gaps" in data are large enough, the errors can be significant. 2) If you have a very unreliable WB connection, your Min/Max temperatures and rainfall may be incorrect. This will lead to large errors. 3) You need to pick a RELIABLE WB station. Temperatures are typically very reliable. Windspeed and dewpoint are placement/maintenance sensitive. Reliability is more important than proximity. You can compensate for offsets (constant differences) between your local location and the WB station. Nothing can compensate for poor station placement or maintenance issues. 4) NWS stations (airports) are typically well maintained. Unfortunately, they do not normally report rain data and report wind speed at a higher elevation. While not good candidates for WB data, they are a good source for assessing whether your local WB site is giving accurate wind/dewpoint data. 5) WB has a nasty habit of "automatically switching stations" if your selected station is having reporting problems. This isn't a big deal in Indiana where the elevation changes 200' over the course of miles. Out West, where little things like Mountains come into the equation, a station change could move you from a valley to Pikes Peak. I don't have a good solution for this problem - other than selecting a RELIABLE station. I did not address the issue of Irrigation Required or retention of negative values. In hindsight, I can see where this would be required for rain events that far exceed the typical ETo. Unfortunately, I don't believe that it's as simple as retaining a negative irrigation required variable: 1) The soil absorption factor is a linear approximation that is applied over a "normal" range of rainfall. 2) Soils are not linear - after hitting saturation, 100% of the rainfall will result in run-off. Short of running a percolation test (required in my area with septic systems), I do not know how to quantify soil absorption/saturation. Asking users to run a percolation test would seem to be a bit extreme. If anyone has access to data that could be used to characterize regional soil characteristics, please chime in. IM

If I understand your response correctly - 1) You factory reset/restored to PLM (per Lee's request). 2) You plugged a dual band lamplinc in the same circuit as the PLM and received no response to a query. If the above is correct, you are either dealing with a failing PLM, or have severe corruption of the powerline communication. I had asked about moving the PLM to the opposite phase because it's possible that only one of the phases is corrupted. You'll need to figure out which breaker your current PLM location is being supplied from. Once you know this, select a location/breaker that is on the alternate phase per the picture below. Alternating breakers from top to bottom are on the opposite phase. Breakers across the horizontal are on the same phase. Another approach would be to use a Filterlinc on the PLM itself. This will eliminate any powerline corruption and force the PLM to utilize RF exclusively.

... and the six that are responding are different than in your original post. I'd regard that as "non-repeatable" (intermittent communications). Thank you. Would it be possible to move the 2413S to the opposite phase? This would rule out a noise source/absorber near the PLM. The above log is showing a device timeout for a "Insteon Engine query". The ISY attempted to communicate to the device 3 times and did not receive a response. Questions: 1) The device address shown in the event viewer was not in your original list. What type of device is this? 2) Have you tried moving one of your dual band Lamplincs to the same circuit as the PLM (or is that what you are showing above)?

Hello Envirogreen, In addition to the event viewer diagnostics that LeeG has requested... Observations from the screen shot you provided: 1) Your screen shot showed a total of 24 devices. 2) 22 of the devices are dual band - we can hopefully assume that your phases are coupled properly. 3) 8 devices are showing a status (they responded at one point). The remainder are showing that they failed to communicate. Question 1) Are the 8 devices reliable? Do they consistently respond to queries? 4) Of the 24 devices shown: 4 are newer I2CS units, 4 are I2 units, the remaining 16 are unknown (added manually and show version V.00) 5) Of the 8 devices responding: 3 are the newer I2CS units, 5 are unknown. All are dual band. 6) There doesn't appear to be a pattern to the location of the responding devices. Some are on your 1st floor, some on the second. Question 2) Are you using a 2412S (powerline only) or 2413S (dual band) PLM? Question 3) Where is the PLM physically located (1st floor, basement,etc and near service panel, office (away from panel), etc). Suggestions (in addition to Lee's request) - 1) You have a number of dual band Lamp modules. Try moving one to the same outlet/circuit as the PLM. Please post an event trace of a device query. 2) Have you tried a "query Insteon Engine"? Right click on the device, then select diagnostics/query Insteon Engine.

Hello someguy, Sorry to hear that you haven't resolved the issue. I am a bit curious how you are determining that the PLM is losing it's records: Edit: Stupid question follows. Resolved by reading page 1 of this thread. Please disregard. 1) Observation: device responses not registered by the PLM. 2) Link record read: Very difficult to accomplish unless you filter the PLM and disable RF devices. If the link table shows blank (similar to a factory reset), that's conclusive. Otherwise it's very hard to determine whether a particular link record is gone. Not doubting your conclusions - just trying to figure out how the problem is exhibiting itself. That was really a fishing expedition on my part. It should not matter, but I'm not sure that the designers took this into account. Both the PLM and the ISY are isolated from the powerline, but they are not isolated from each other. The question becomes, how good is the power isolation. I don't have an answer for that with the 2413S. It may be a total WAG on my part, but something to think about it you experience problems again. Along a similar line, the "older" modules (SWL, KPL, Etc) could be upset by a line voltage spike making it through the power supply to the uP. Units would require the "air gap" procedure to recover. While I've experienced this with older units, I have not had any problems with units using the "improved" power supply implemented around 2009. The 2413S came out in the same time frame. From what I can see, it uses the same switching power supply configuration. With the above said, if you encounter problems again, please try: 1) Verify the PLM/ISY supplies are on the same phase. 2) Consider moving both to the opposite phase (to preclude line spikes from being an issue). Your passive coupler should not pass (or severely attenuate) a spike between the phases. IM

Hello Someguy, I realize that this is a rather old thread, but I was researching PLM malfunctions and was wondering where you wound up with this. Were you able to recover the PLM, or did you replace it? As a side note, you mentioned that your PLM is installed in a dedicated outlet with a phase coupler. Where is the power supply for the ISY connected? Is it possibly on the opposite phase? IM

Johnnyt, The following is from the GE Zwave manual for a 45609 dimmer: I do not have much recent experience with Zwave. I will say that I am able to communicate with an Intermatic receptacle 68' away through a steel door/12" concrete wall. This is "line of sight" with one rather ominous obstruction, but still rather impressive.

Yeah - I can program my 2876SB Icon Switches (V.39) using I2! These had been a problem previously due to the limited memory. I'm not sure which revision included this change - thank you nonetheless.

Alan, This is likely not achievable. Most of the motorized locks that I have seen are sized so that they stall the motor if they encounter an obstruction. In order "pull the door tight" a gear reduction drive would be required to multiply the motor torque. This toque would still require limiting (motor stall or a clutch) to prevent damage for a true interference condition (door partially shut). This same gearset would also drain the battery due to the increased operating time required to throw the bolt. The installation manuals for all of these locks refer to "alignment" and "smooth operation" during installation. The Kwickset deadbolt does advertise a "tapered" bolt to improve engagement. I do not know how effective this is in practice. If you have a Metal door: You could replace your compression seals with magnetic seals (lock side and top). This will pull your door shut for you allow allow for minimal interference on the deadbolt. If you have a Wood door: 1) Adjust your handset to "hold the door tight" and allow the deadbolt to align properly. Your family members may not like having to "push" the door closed. 2) Consider using a Zwave locking handset + the Schlage Zwave non-motorized deadbolt (expensive). This would allow you to remote lock the handset and still use the Schlage deadbolt to pull the door tight against the seals. Question: Do you really need to force the deadbolt to seal the door? Are you sure that your seals aren't worn out?

Hello again johnnyt, More info on ventilation systems: Nice article on using ERV's and HRV's: http://www.greenbuildingadvisor.com/blogs/dept/musings/are-hrvs-cost-effective At the bottom of the article there are #'s for the relative savings for different locations in the US (johnnyt, you would likely use the Burlington Vermont #'s):http://www.greenbuildingadvisor.com/sites/default/files/Semmelhack%20HRV%20cost%20effectiveness%20table%201.jpg From the chart above, I'm roughly in-line with the numbers posted for Chicago. I just re-tested my furnace blower. After subtracting out the "unneeded" loads (zone panel, vent dampers) it pulls 1100W in heat mode and 575W in low speed continuous mode. I think I'm stuck with my "open window" system until it dies. On the brighter side, I'll be in retirement sooner than I care to admit. I'll get another chance at this when we down-size. Article on the "Lunos" through the wall heat recovery ventilators: http://www.greenbuildingadvisor.com/blogs/dept/musings/european-products-building-tight-homes The Lunos fans go for $1200 for a pair and are rated at 17.6 CFM/Pair. My home would require 5 pair to meet ASHRAE standards. There is no current cost/benefit calculation ratio that would support using these in the States. The sad fact is these may make sense in Europe. On average, Europeans pay nearly 2x my local price for natural gas, and 3.5X the price for electricity. Add in the fact that the fans are "easy" retrofits for older homes and these could work for them. IM

EHV: is either an Exothermic Heat Ventilator (haven't invented it yet) or a typo. I corrected my post to indicate a HRV.

Hello johnnyt, Thank you for the clarification on your local code. I cringe whenever I hear the term "lobbyists". While it is possible that there were issues with the 90's vintage HRV's (your defrost heater as an example), I have a hard time believing they had your best interests in mind when they campaigned to change the code. A HRV would seem to be ideally suited to your area. I do have co-workers that have HRV's with defrost heaters. They appear to function well in the milder climate of N. Indiana/S. Michigan. I can see where it could present an issue with your much colder climate. Since you had a HRV installed during construction, I'm guessing that you have dedicated return/supply ducts throughout your home. In other words, your HRV system is separate from your Heating/Cooling air system. I'm jealous. I'm running bath fans with makeup air vents in the basement (walkout). The air vents are similar to your back draft vents but reversed so they supply outside air to prevent negative pressure in the home. I live in an area where Radon gas is a problem (I've tested the house multiple times over the years) and need to prevent a negative pressure condition. As you stated, my system is analogous to turning on the fans and opening a window. I would love to install a dedicated system, but simply don't have access to the walls/ceilings to be able to install one. That leaves the option of tying the HRV into my heating system. Unfortunately, my furnace is an older model with a fixed speed blower. It consumes ~1500W of power when running. That puts a big dent in the payback from the HRV. I've looked at this a number of times over the years and have always walked away in disgust. I really need my furnace to die (can't believe I wrote that) so I can replace it with a variable speed model. At least I've been able to automate the bath fans using ISY so that the air exchanges occur at a regular rate or my choosing. Thanks for sharing the information on your system. Glad to hear that it's working well for you. IM