IndyMike

Hi Mike, My logs are showing that as well: 1) 10:00 PM 0.5" rain. 2) 11:00 PM 0 rain. 3) 12:01 PM Irrigation required calculated for 0 rainfall. Still not sure whether this is the ISY or Weatherbug.

Hello Mike, Good catch. I just checked my ISY logs and my Rain_today value appears to be setting around 11:00 PM. This appears to have kicked in after the time change on Nov 3. Odd thing is - 1) You didn't change times in AZ. 2) I believe the ISY reports the Rain_today value directly as reported by Weatherbug. This may be a Weatherbug issue. If you are getting rain, and have the opportunity, could you check the actual Weatherbug site to see what it is reporting after 10 PM?

Hello Charles, Both PLM's and ISY's should be able to send and receive X10. There is no specific linking in the X10 protocol as there is in Insteon. If the signal is placed on the powerline, all receivers should be able to detect it, assuming there isn't absorption or noise. If ISY#1 does not have the X10 module installed, you will not be able to "name" X10 units or track their status. The ISY will still be able to detect and act on Raw X10 signals. You should be able to communicate between systems using X10. Check your "Event Viewer" to make sure you are not receiving X10 between the ISY's. If not, you likely have a powerline issue. I have multiple Insteon PLM's and X10 Controllers in my home. All can send/receive X10. That said, I do take great pain in keeping X10 off the powerline (mostly RF) because it is sooo SLOW. If there is a network module solution that would accomplish the same task, I would recommend that instead. Unfortunately, I'm network module "challenged" and can't offer a solution.

Hello zorax2, Before investing in a truckload of filterlincs, I would suggest focusing on the Scene Test itself. The Scene Test can be a powerful tool, but it can also be tripped up and give misleading results. Performing a scene test of 42 devices increases the likelihood that external communications will interfere and cause a scene test failure. What the scene test does: 1) ISY executes a Group "fast on" command for your selected scene. Unfortunately, the ISY will quickly reset the event viewer window (2 seconds) and overwrite this command. I managed to grab a screen capture of one of my smaller scene tests this morning. The first line below is the ISY instructing the PLM to issue a "Group fast on" to group x27. The 5th line is a question mark - I had no clue this was occurring. The ISY is issuing a second "Group fast on" command to group x30. In short, I think this in incorrect (i.e. I have an issue with this scene). 2) ISY executes a All link "fast off" command for the selected scene. The following is the all link command for my group 27 scene. Sun 09/22/2013 10:19:18 : [GRP-RX ] 02 61 27 13 00 06 3) The PLM interrogates all the scene responders. When complete, the PLM will respond with a "Clean up Report" of the results. A "06" in the last position indicates success. A "15" indicates that the polling was interrupted. Any activity will cause the PLM to abort the polling process (motion sensors, wired transmitters, X10 devices, programs, ELK commands). In short, the difficulty in successfully completing a scene test increases quickly for a large scene. I intentionally interrupted the Poll below by pressing the "ON" button of a KPL during the poll process. Sun 09/22/2013 10:28:19 : [std-Cleanup Ack] 19.46.CE-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 09/22/2013 10:28:19 : [CLEAN-UP-RPT] 02 58 15 ----- SC BSMT Test Results ----- [Failed] BSMT Bed (14 78 3B 1) [Failed] BSMT Video Cans (17 F7 B6 1) [Failed] BSMT Fam Cans (1A 4F 19 1) [Failed] Master KPL G - BSMT (A E5 EC 7) [Failed] Christmas Tree (13 A 51 1) [Failed] BSMT KPL Game (F FF F1 1) [succeeded] Master Table KPL G - BSMT (19 46 CE 7) [Failed] BSMT Stair (1A 5D 6D 1) ----- SC BSMT Test Results ----- Sun 09/22/2013 10:28:25 : [iNST-TX-I1 ] 02 62 00 00 27 CF 13 00 Sun 09/22/2013 10:28:25 : [iNST-ACK ] 02 62 00.00.27 CF 13 00 06 LTOFFRR(00) How to make the Scene Test (more) reliable: [*:2cndqvnb]As the test indicates, you must disable programs. Any program that is initiated by a change in device status WILL interrupt the PLM polling. I've created a "conditional" folder with a variable for enabling/disabling programs. Set the variable, and the folder (and all programs) are off. [*:2cndqvnb]Pending updates to devices - If you have devices with pending updates (green arrow), the updates will initiate during the scene test (causing it to fail). Disable automatic updates or (better) resolve the pending updates. [*:2cndqvnb]Motion sensors, IOlincs, Devices with load sensing (etc.) are a problem. No good way to disable these. The network must be quiet during the test or the PLM will abort. [*:2cndqvnb]Use smaller, Logical scenes - less chance of interruption during the test. [*:2cndqvnb]Always watch the PLM status response. A 15 indicates that the PLM was interrupted. Sun 09/22/2013 10:28:19 : [CLEAN-UP-RPT] 02 58 15

Depending on your location, many areas also specify foil backed foam panels between the garage and heated areas of the Home. I have this in my garage (Northern Indiana) and have powerline only in the garage as a result.

Hello swnewman, Glad to hear that the grass is doing well. With bermuda grass, you should be using a Kc of 0.6 (warm season grass). If you have the network module, you can periodically log data to the ISY in a comma delimited format (.CSV) that Excel can import. I've been logging data at 10 minute intervals (when I poll Weatherbug) for about 5 months now. File size is at 3 M. The notification file formats are located here: http://forum.universal-devices.com/viewtopic.php?f=25&t=10905&p=86231&hilit=network#p86231 Instructions for creating the output file are here (instructions are for an Elk file - use the formats in the link above): http://forum.universal-devices.com/viewtopic.php?f=51&t=11753&p=90748&hilit=network#p90821

Hello swnewman, First and foremost, you need to be running ISY V4.0.5. Earlier versions did have some issues with the date calculations. Beyond that, I've checked your weather site and your area. KHSV Weather Site: 1) Weatherbug appears to be reporting data accurately at this time. I have no way of determining if there were data losses in the past. 2) WeatherUnderground shows the site history from June to present. No indications of problems. Your Soil: 1) The soil map from UCdavis has your area listed as having "silt loam". That's as good as it gets for water retention: http://casoilresource.lawr.ucdavis.edu/soilweb_gmap/ 2) From the table below, your soil can hold 0.2 inches of water per inch of root depth. 3) If your grass has 6 inch root depth, your soil retention would be 1.2 inches of water. 4) The table recommends a maximum 50% depletion - you should irrigate when your ET exceeds 0.6". Field Capacity Table You have had a lot of rain this summer. I'm wondering if this hasn't changed your irrigation from what you would call "normal". The table below shows your historical Eto for your area. For irrigation, you need to compute Etc (crop evapotranspiration) for your specific plant type: [*:6hu1e1cs]Etc = Eto * Kc (where Kc is a crop coefficient). Use Kc = 0.8 for cool season grass and Kc=0.6 for warm season grass. [*:6hu1e1cs]For your hottest months you would normally get a Eto of .17" per day. Using a Kc of 0.8 would reduce this to 0.136" per day. [*:6hu1e1cs]From the field capacity table above we determined that you should water when you've depleted your soil water balance by 0.6". [*:6hu1e1cs]At a rate of 0.136" per day, you would need to irrigate every 4.4 days (about what you had figured). Local Data The plot below shows what I believe the ISY should be calculating based on actual data as reported by stations KHSV and KALMADIS16. As I mentioned above, you've had a lot of rain. [*:6hu1e1cs] The ISY calculated Eto for KHSV is running a bit higher than normal. I believe that this is because this station is reporting wind at the NOAA height of 10m rather than the NWS height of 2m. The station is reporting "average" windspeed of between 4 and 6 mph. That is very high and is causing the calculation to overstate Eto. [*:6hu1e1cs] The windspeed for that KALMADIS16 station (0 to .27 mph) is much more in-line and the calculated Eto is closer to historical values. [*:6hu1e1cs] The stations pretty much agree on the July rainfall (which was excessive), but differ on June and August. I don't have a good explanation for this other than topography in your area (you know this better than I). Even though the totals differ, the events occur on the same days. Running through the numbers, I believe the ISY should have scheduled irrigation between 3 and 4 times per month over that period. [*:6hu1e1cs] Answers to your questions: [*:6hu1e1cs]Eto is calculated at midnight. [*:6hu1e1cs]Rainfall is totaled at midnight and subtracted from the Irrigation required. [*:6hu1e1cs]Irrigation is subtracted from Irrigation required immediately when you execute the "irrigation complete" command Since both Eto and Rainfall are tabulated at midnight, it is possible for ET to be close to rainfall resulting in no change in the "irrigation required". It would be very odd for this to happen over a period of days. Based on the above data from stations nearby, I disagree that your lawn needs watering every three to four days. I'm basing this on many assumptions about your soil and grass, so I may be off. My questions: [*:6hu1e1cs]How does your grass look? Under watering can cause it to go dormant (not harmful). Over watering will kill grass - particularly with your humidity. [*:6hu1e1cs]What settings are you using in the irrigation panel (below)? [*:6hu1e1cs]Do you believe that the rainfall reported at either of the sites above is accurate for your area?

Backyard stations appear to be on line today (my area at least). I am still missing all but one of the local schools.

This seems to be a bit more than a simple loss of the backyard stations. Most of my local schools and businesses have disappeared as well. Currently, with a 40 mile radius, I have 2 NWS stations (airports) and 1 school showing up. Previously, there were at least 30 stations. Most of these were schools and businesses. For the time being, I would regard only the NWS stations as reliable.

Hello Jim, I have multiple programs that function properly as you have posted below. This should work. Today I tried constructing a program using dual band KPL's to see if there was an interaction. I could not come up with a configuration that would misbehave (the program always responded properly). From your post below, it appears that you actually deleted/re-installed your devices. That would eliminate the possibility of scene cleanup messages (i.e. the only responder was the PLM). My subject devices were older dual band KPL relays. They do not support "Group cleanup direct retries" as described by LeeG here: http://forum.universal-devices.com/viewtopic.php?p=89144#p89144 Your 2334 KPL's are very new. It is possible that they are sending additional communications to the PLM that are "re-triggering" your program to a false condition. I do not have any of these devices to test. As posted by Lee and ARW01: 1) Inspect the program summary tab. It is possible that the program is triggering true, then re-triggering false before the X10 command can be sent. 2) Please post a "level 3" event viewer log. I suspect that your 2334's are sending something that causes a re-trigger.

In addition to the above suggestions... If the triggering devices are Scene controllers, they will transmit device cleanup messages to the responders after the ON message. These cleanup message can interfere with the X10 transmission. If they are controllers, try a wait statement before your "X10 on " command. The duration of the wait may depend on the number of scene members.

LeeG has given you the most appropriate response - I agree with it. The motion sensor is a controller - the "control condition" is the most appropriate. I the ISY does not detect a control ON activity, it cannot (by definition) detect a status activity. Beyond that, the motion sensor is a two state device: 1) "Is on" = "Is not off" 2) "Is off" = "Is not on" 3) I don't think that "Is not responding" makes sense for a motion detector since it is a controller. The ISY only provides a response after it has already received a transmission from the motion sensor. Bottom line - use the example that Lee provided. Do not forget to provide both a subject and body in your email notification.

Hello Mike, The table below is based on readings from the KBAB weather site at Beale AFB. It shows what the ISY should be calculating for the PM and HS ETo. The HS method is extremely simple. It relies on Min/Max temperature alone. The only way that I can see that you could be getting an ETo of zero would be if WeatherBug was misreporting the Min or Max temperature. if Max - Min goes to zero, your ETo also goes to zero. I simulated a "mis-reported" low temperature in the second table. This produces an varying error in the PM calculation. The HS calculation goes to zero. Could you check the ISY irrigation display and see if high and low temps are being displayed properly? IM

Hello Tim, I believe I understand what you are trying to accomplish. I don't see anything "wrong" with the implementation - it's rather resourceful. Unfortunately, I'm not sure how useful your added programing will be. Based on the KBAB data so far this year, you would have triggered your program a maximum of 2 times so far. The last time you had rainfall > than .38" was on April 4th (0.47 inches). You are now headed into your dry season. Based on 2012 data, you're unlikely to trigger this program until October. Seems like a lot of work... Hopefully Michel's announcement regarding the Weatherbug servers will improve reliability to the point where your workaround won't be required.

Hello dpark, The calculation times have not changed in recent versions. Irrigation Required is still calculated at midnight. If you are currently seeing Irrigation Required as 0.38, it should have been the same value at 5:00 AM. Would you mind posting your program? It's possible that another condition prevented it from running. IM

jmed, You should be using the "interior plains" setting for your area. This yields ETo values nearly identical to those predicted for your regional airport. I downloaded data and CRONOS predictions for your Airport. The following is a comparison for the past month. The data is actually for 90 days, even though I'm only showing a month. 1) ETo comparison: The ISY and the NCSU CRONOS system agree within 0.0315" over 90 days. The equates to 0.00035" difference per day. 2) ETc comparison: The ISY is using a Kc of 0.6 for warm season grass. The NCSU CRONOS system is using a Kc of 0.8 for the same grass. I don't know why. All of the literature that I can find indicates that a Kc of 0.6 is correct for warm season grass.

Jmed, I downloaded data from one of your local WeatherUnderground sites for the past month (below). I ran the P-M calculation on this data and produced the values in the table below. I used the following resource to look up predicted ETo for states in your area: http://www.nc-climate.ncsu.edu/ETdynamic2.php?date=2013-05-27&unit=inches. One of the locations listed is your regional airport. ETo values from that station appear to track the ISY calculation within 0.01". Not sure what to tell you about last years values. Your current values are tracking the NCSU predictions for your location.

Jmed999, A little criticism - all that I can tell from your post is YOU DON"T LIVE NEXT DOOR TO ME! My ET is running 0.07 for the past few days (overcast). I'm more than willing to help, but you have to toss me a bone. 1) location 2) Crop coefficient (Kc setting) 3) Calculation method (P-M or S-H) Feel free to PM me if you don't wish to post on the forum.

Hello dpark, Executing the "Irrigation Complete" command will prompt the ISY to deduct the amount of water you are applying from "Irrigation Requirement". Since you are using "Irrigation Requirement" to trigger your program, the condition is likely turning false, causing the program to exit. Try eliminating any delay statements between the "Irrigation Complete" command and the Email command (may work) or Move the notification prior to the "Irrigation Complete" command.

Hello Pete, I pulled down your weather statistics from 5/11. Based on this data, the ISY calculations are shown below. With a Kc of 0.6 (warm season grass), I'm calculating a ETc of 0.1637 in/day. This is very close to your value of 0.1575 (-0.0062 inches). I also looked at your local Arizona METEOROLOGICAL site "Mohave 2" which appears to be near you. They predicted a ETo of 0.28 inches/day which compares very well with the ISY calculated 0.2729 inches/day (0.0071 inches). The differences here could easily be attributed to differences in local temperatures and windspeed. The Arizona Mohave #2 site is located here : http://ag.arizona.edu/azmet/28.htm. Use the "monthly data" tab to see predicted ETo. From what I can see, your current values should be correct for "warm season grass" using a Kc of 0.6. You mentioned that you also have Palms that you are irrigating. I know absolutely "beans" about Palms and can't advise you on how to adjust Kc to account for them. The current ISY implementation does not account for multiple species of plants or multiple zones. If you determine that the requirements of your Palms are significantly different than your grass, I would encourage you to use a Kc of 1.0 (true ETo) and handle the irrigation requirements for grass/Palms separately via programs.

Hello Mark, My personal experience is that dropouts (Weatherbug no-response) occur more frequently when the polling interval is decreased. I use a minimum polling interval of 5 minutes in my area. I've recently backed off to a 20 minute poll with no obvious impact on the Penman-Monteith calculation. The ISY implementation of the Penman-Monteith calculation uses averages of Temperature, Depoint, and Windspeed. The temperature and depoint inputs are rather slow moving. The Windspeed is fast moving, but weatherbug provides averages (between samples) to the ISY. The ISY calculates averages by dividing a total by the number of samples acquires ( Total Temperature/#samples = average_temp). In a perfect world, the samples would be evenly spaced (5 minute intervals) so that the calculation provides a correct average. Dropouts will affect the spacing of the samples, and thereby skew the average. Normally, this is not significant since the variables move slowly. A significant dropout (hour(s)) will affect the average. The effects on the calculation will be totally dependent on the duration of the dropout and the time of day (can't quantify). The Hargreaves-Samani calculation is sample rate insensitive. In theory, you could acquire 2 samples (11:59 PM and 12:01 AM) and provide all the information necessary. It is used worldwide in locations where reliable Windspeed and dewpoint data are not available. The calculation is NOT as accurate as the P-M. It will significantly underestimate ETo in dry/hot/windy areas and overestimate in humid/cool areas (like mine). I would be very interested in your observations of the new implementation(s). PM me with your location, and I may be able to provide some local state/federal resources that you can use for a comparison. IM

So warm season and cool season grasses Kc are both 0.8? Thanks for the instructions!!! jmed999, Good catch! I had a typo in the warm season grass Kc. This should be Kc = 0.6. I've corrected it in the post above.

pyroman175 and jmed999, Michel had requested a updated Wiki some time back - I'm delinquent. Work has again intruded. In lieu of a good Wiki description, here are the basics: Calculation Method Penman-Monteith: Accurate, but relies on averages of Temperature, Wind speed, and Dewpoint throughout the day. Some users had reported problems with communication to the Weatherbug servers which can cause errors in the averages. Hargreaves-Samani: Less accurate, but relies on Min/Max temperatures alone. These can be acquired during one snapshot at the end of the day. As a result, the calculation is far more robust in the presence of Weatherbug access issues. Absorption Factor 80% absorption is recommended for level ground. This is a generally accepted industry % absorption for rainfall. Users with steep slopes can apply lower percentages to compensate for runoff. Absorption is applied to both rainfall and irrigation: 1) Rainfall .5 inches: Effective rain = 0.8 * .5 = .4 inches 2) Irrigation 0.5 inches: Effective irrifation = 0.8 * 0.5 = .4 inches Crop coefficient Plant needs are species dependent and defined as ETc = ETo * Kc (Kc = crop coefficient). Cool season grasses (Bluegrass, Rye, Fescue) use Kc of 0.8 Warm season greasses (Bermuda, Saint Augustine, Zoisya, and Centipede) use a Kc of 0.6. Edit: corrected Kc for warm season grasses. Additional values are provided to encompass a range of plants/trees/gardens. Note: the current Evapotranspiration variable is actually ETc (=ETo * Kc) Pryroman, Wind speed will significantly affect your ETo calculations. If you feel that the updated calculations are different than local predictions, PM me with your location (weatherbug) and I will run some calculations. IM

True, the ISY could calculate average rate if it had a reliable Weatherbug feed (xx readings per hour) to calculate an average. Many sites do not support multiple readings/hour and other factors such as user network issues and Weatherbug server loading make this a questionable calculation. If a rain rate could be determined, we would then be faced with how to apply it. Level clay soil would generate standing water that would eventually be absorbed (80% absorption). Clay soil on a slope would generate runoff (10% absorption). In order to apply the information, we would need a multi-zone setup with information on the soil type(s) and slopes. The above sounds as if I'm making excuses. I have put a fair amount of time into researching different ET system implementations. The commercial systems that try to achieve the level of precision required for rain rate/runoff calculations use dedicated sensors and muti-zone definitions. Neither are currently available to the ISY. Stepping down from the podium... From your example program below - Your ET will not change significantly in the morning hours due to high humidity and no sun. Rather than checking to the 0.5 limit, why not check a range of depletion and simply run at 4am: If irrigation requirement > 0.4 (run) This will help cover your 0.15 ET for the day. For the rain instances, you can use a series of programs to program a state variable: State 0 (rain 0 to .1) if Rain_today> 0 and Raid_today <=0.1 Then Rain_state = 0 State 1 (rain .1 to .2) if Rain_today > 0.1 and Rain_today <=.2 Then Rain_state = 1 Irrigation if irrigation requirement > 0.4 and Rain_State = 0 Then Run irrigation Other comments - 1) Your silt loam is actually a much nicer soil than what I have. Use the charts above to gauge your watering needs (after the sod is established). 2) After the initial 10 days your sod will still have next to no roots (maybe 2"). I have no personal experience with sod. I would listen to your sod installers on how much water/how often to apply. You are installing at a really tough time of year. The 0.5" in your program examples should be excessive given the short roots (but listen to your sod people). 3) I am not a fan of watering in the evening in our areas (I'm 90 miles east of you). Prolonged wet periods in the summer promote nasty diseases. I would rather underwater than water after 6 PM. 4) The chart below shows the monthly average ETo for your area. This includes rainfall/cloudy cool days. Some hot summer days may be significantly higher (2x). Even so, you should not have a problem with odd/even watering once your sod is established.

During a rain event - my ISY shows the rate in Rain_Rate coming from Weatherbug - and manual measurements I am planning to do will give me the inches/hour of my system. Does the ISY not take this into account at all? I would think that it could. Anyway - I'm really not needing/wanting to get into this. Just adjusting the amount applied responding to the climate (ET and rain). Michael. Michael, The manual measurements of your irrigation system are correct. You do want to control the irrigation rate to make sure you aren't getting runoff. The "Rain Rate" provided by Weatherbug is a maximum that does not include a duration. When Weatherbug shows a maximum rate of XX inches/hour, the ISY cannot determine how long the event lasted (seconds, minutes, hours). As a result, the ISY can't determine how much water may be lost to runoff. There are systems that can determine actual rain rates and durations - they use dedicated sensors and are not inexpensive.