IndyMike

I'm showing 0.05" rain today. Last recorded rain at KSBN was 0.07" on 9/15 <climate enabled="true" locationId="KSBN" rss="http://wx.hamweather.com/?pands=KSBN" lastUpdatedTS="2014/09/18 16:42:23"> <Temperature>72 F</Temperature> <Temperature_High>72 F</Temperature_High> <Temperature_Low>43 F</Temperature_Low> <Feels_Like>72 F</Feels_Like> <Temperature_Average>52.7 F</Temperature_Average> <Humidity>41 %</Humidity> <Pressure>30.11 psi</Pressure> <Dew_Point>46 F</Dew_Point> <Wind_Speed>7 mph</Wind_Speed> <Wind_Direction>ENE</Wind_Direction> <Gust_Speed>17 mph</Gust_Speed> <Total_Rain_Today>0.05 inches</Total_Rain_Today> <Light>93 %</Light>

Thanks Michel, No rain in the forcast until the weekend. Will report back when I have some data.

The chart below is a comparison of Weatherunderground VS ISY/HAM reported rain for September. I can't even hazard a guess at how HAM is currently rolling up daily rain or when they implemented changes. I would normally try to offer some insight on where the errors might lie in this type of calculation. I have no explanation for the differences I see below.

Hello Michel, Things have definately changed on my end. Not for the better... KSBN is showing 1.09 inches yesterday and .05 inches since midnight. ISY is showing .07 inches yesterday and .04 inches since midnight. I suppose it's possible that HAM's updates were rolled out after the storm went through yesterday evening. I have no way of telling from this end.

Hello Michel, My appolgies for the tardy response. I am repairing a number of PC's after a previous storm event (family members). This is good news. I have a new storm front approaching this evening. Will hopefully be able to confirm the updates by monring. As a side note - I may have been a bit harsh in my appraisal of HAM's service. While they have had issues, the version history you provided indicates that they are working to resolve them. I had not seen this previously, and am encouraged by it. IM

Hello Michel, I understand that UDI chose HAM and is responsible for the climate module performance. I forgive HAM for the normal startup issues like station coverage, lags in reporting (delays), and such. Howver, the accuracy of the data should NOT have been an issue. I will begin re-checking after the Thursday updates. Please recognize that I need an afternoon rain event in order to check for rollover.

Hello Michel, Thank you for investigating this issue. Please understand that my frustration is not directed at UDI. Just to re-enforce the fact that this is not an isolated issue - I checked Chicago O'Hare. On October 31 HAM is showing rain of .26" for KORD at 5:51. NOAA, Weatherunderdround, etc. are showing no rain for the 31st. jmed999, That was exactly my question. I am unclear whether the "fix" was immediate, or was taking place in stages.

I am not sure where HAM stands on it's rollout for correcting the "Rain Today" issue. My understanding was that this was to be corrected weeks ago. From my standpoint - zero improvement. I am continuing to see a "roll-over" of rainfall from the previous day into the current day. With pop-up afternoon thunderstorms a regular occurance this time of year, the roll-over issue make's it impossible to use the HAM data for calculating ET. I am using the local airport station KSBN which is THE NWS/NOAA station for the area. HAM is currently showing 0.34" rain today whereas the NOAA, NWS, Weatherunderground, and Weatherbug are all showing 0.09". The following screenshots are from the NOAA site and HAM. These should be 1:1, but HAM is showing 0.34" in the "6 Hour" column at 6:54 AM. NOAA is showing 0.09" in the same column at 7:54 AM. I am using the NWS site because I thought is would be a standard data format and "easy" for HAM to roll up the data. Very disappointed that they cannot seem to get a handle on what seems to be a very basic issue.

CPUJohn, The light% does appear to work for my site (KSBN - northern Indiana). This is the local airport which is a NWS/NOAA site. I will say that I believe that the data is "calculated" based on the time of day and reported cloud conditions. Neither the NWS, NOAA, or WeatherUnderground report light% for this site. I have other PWS sites that report actual solar radiation - they are far less granular and indicate rapid transients with passing clouds. Using a different site may resolve the issue (it can work). Understand that a different site may not be the best for local climate data. My use of KSBN is purely for data collection as it is 15 miles away. Today KSBN has received .21" of rain where I have 0". Balancing climate needs for irrigation against light% needs for scheduling may prove to be difficult. IM

Unless something has changed, light% is not used in the ET calculation. Daytime sun exposure is based on your lat/lon and month/day.

I've been seeing similar things with my local airport station (official WBS/NOAA station). Seem's to be linked to the HAM "rain in the past 6 hours" which can roll into the next day. The following is a comparison of Weather Underground reports VS HAM (ISY). The second and third tables are HAM reports from 7-14 and 7-15. The discrepancy between Weatherunderground and HAM seems to be due to a HAM rollover of 0.46" from the previous day. No explanation for the discrepancy on 7-14

Hello Waketech, The amount of water "deducted" from the irrigation required depends on the values you specified for "absorption factor" and "water applied per irrigation" In the expample below I specified 80% for absorption and .42" for water applied. When I execute the "irrigation complete" command, the ISY subtracts 0.336" (.42" X 0. from the irrigation required value.

johnnyt, That's the point I was trying to get you to. I guess I misunderstood what you were trying to accomplish. I thought you had link table mis-matches and were trying to correct using I1 messages. In my experience, I2 is actually more reliable in reading/writing the link tables. You are writing the tables 8x faster and are therefor less likely to have problems with transient noise (motors starting, etc). If you are trying to eliminate the multiple responses, I agree that disabling the dual band devices is a good approach. I do not see any doublet/triplet responses in my system. I have very few (3) dual band devices installed and have a hardwired coupler at the PLM. No clue if this has anything to do with my NOT seeing multiple responses. Other than slowing down the read process, I'm not sure that the duplicates harm anything.

Hello Johnnyt, Your V.36 KPL and IOLinc are being read in standard message mode (I1). Both of these devices are extended message capable (I2). You apparently have your ISY set to "Automatic" message mode where it selects what it believes is the most compatible mode (I1 or I2). This is what UDI recommends. You can "force" I2 communication by going to Link Management/advanced options and selecting "device reported" mode. The ISY should then use extended messaging (I2) during your link table reads. I have been using this since I2 came out - but it is not the recommended mode. This will speed the link table reads by 8X. It may not be compatible with your Icon switches (won't do any harm). The newer Icons have a smaller link table and may generate an error "Unexpected Response (i.e. DB range): ignored" when read using I2. Switching back to automatic mode will resolve this.

Mike, We have two different problems here: 1) CTRSH is transmitting temperature reliably - it is not resetting during the day. The problem is that it does not transmit rain data. It provides "N/A" in the rain data field. 2) I think you have uncovered a bug in the handling of the "N/A" response. The ISY is expecting numeric data and can't convert the text provided. As a result, I believe it is using the last valid data it received (From KAUN?). If you switch to KAUN (currently at 0.05") and switch back to CTRSH the KAUN value will be retained. Could you try switching to FRKSH? It does provide rain data and is currently registering 0.02 inches. On the subject of a wireless moisture sensor - I purchased a Toro Xtra Smart Soil Sensor last year http://www.amazon.com/Toro-53812-Smart-Moisture-Sensor/dp/B007J0M93U The sensor uses soil conductivity to "estimate" the water content. It uses two 4"(??) metal probes to measure the conductivity. In my mind, the probes should be at least 6". Battery powered, it transmits RF to a base unit and has decent range (I have it roughly 150' from the base). The base is basically a programmable switch that can be used to "inhibit" your irrigation system. I had the switch connected to a IOlinc so I could log it's activity and compare it with the ISY ET calculations (I used the ISY to control my system). I can't give you a good or bad review on the unit. We had so much rain last year, I rarely had to run my irrigation system. I did get the impression that the unit's probes would sometimes become "isolated" from the soil causing low readings. I don't have definitive data on this, and it could be due to my very sandy soil. Unfortunately, winter came quick and hard this year. I barely got my sprinkler system blown out before the first storm. The transmitter is still in the back yard buried under several feet of snow. If it survives, I'll give it some points for durability.

Unfortunately, the backyard stations appear to be offline as well. Weatherbug is in the process of migrating them to the cloud: http://www.wxforum.net/index.php?topic=21904.0

Hi Tim, I started monitoring KMYV after I saw your post. The Airports have been going haywire just after 16:00 your time daily. Today was no exception. The temperatures and rainfall on all three of the following stations reset at 16:15 your time. I actually checked ~ 15 NOAA stations from San Diego to Seattle. All of them reset after 16:00. I'm 2,100 miles away in Indiana. My Airport station (KSBN) is due to go down at 19:54 tonight (assuming the pattern is consistent).

Hello Mike, I've been monitoring 3 airports and 2 schools in your area. The feeds from the schools (CTRSH in particular) look good. The airport data is too screwed up to even comment on. High and low temps are being reset multiple times during the day. Using these values to calculate ET will be totally nonsensical. I've also monitored stations in my own area. Same result - the school feeds look good while the airports are totally out to lunch (one actually reverses it's time feed). I do not know when when this started. I was using my airport feed at times over the summer and this was not occurring. I captured the following data using an Excel program to call the Weatherbug API. It was totally independent of the ISY. Data from Weatherunderground shows the Airport sites as reliable. Good feed: 1) Low temperature hits a minimum and maintains until the midnight reset. 2) High temperature hits a maximum and maintains until the midnight reset. Bad Feed 1) Low temperature reset at 16:00 2) High and low temp track current temperature from 16:00 to midnight. 3) Midnight data captured by the ISY: High temp = Low Temp; Average temp is actually > High temp.

Mike, Weatherbug appears to be having problems with data from the Airport stations. The feeds from the local Schools and backyard stations (still verifying) appears good. Please try switching to a School in your area. I'll post some data this weekend.

ELA, I happened to be going through the HL2 release notes today. Revision 2.9.94 (released 5/3/2013) has the following note: • Increase "smarthops" hop count on retries Like you, I have theories on what this might include. Zero evidence to back up any theory.

I don not know what is causing the dropouts, but they appear to be occurring at a specific time. For the last 3 days Weatherbug has been dropping the KAUN precipitation to 0 around 16:00 Pacific Time. The same KAUN feed on Weatherunderground is intact.

Nope - I was. The times are my local times (Indiana-East). Somehow I made myself believe that the 20:12 reset was due to the midnight reset. Not even close. Weatherunderground data from the same station shows rain continued through midnight. Sorry, no good explanations from my end.

mbrossart, Glad you found your way through the Weatherbug setup. One additional request: Please increase to polling interval to 300 seconds (or greater). Using a 1 second poll results in a lot of needless communication and could be interpreted as a attempt to overload the Weatherbug server. I normally use a minimum of 10 minutes (600 seconds) for my polling interval. Many National Weather Sites (NWS) like airports only send updates at 30 or 60 minutes.

The rain didn't get reset - Weatherbug switched to another station that hadn't received any rain. When Weatherbug switched back to station KAUN the rain tabulation continued normally (no loss of data after it returned). As I explained, I do not know what causes Weatherbug to switch stations. I can say that when I use a local "backyard station", it does not switch.

Mike, Glad to hear there's no shaking going on there. I have relatives, friends, and co-workers spread all along the fault lines. I use the network module to log data to the ISY whenever there is a change in the weatherbug data. This comes in extremely handy for back-checking when things don't seem correct. The file itself is a comma separated text file (.csv) that I download directly to Excel.