My SKY precipitation readings have been consistently reporting less than my Stratus rain gauge. Although the readings are better now than they have been since I got the station, they are still significantly off. For example, yesterday’s storm in Cypress, CA recorded 0.51" on the SKY and 0.76" on the Stratus rain gauge.
Mine performed like this when I had Sky mounted on a 10’ steel pipe.
I noticed at 25mph or higher Sky would sway just a little but it caused vibrations
which were recorded as precipitation. I’ve since mounted Sky on a 4x6" treated
beam and have not had any instances of false precip recordings. Just my experience but
it may apply to others
As the northeast storm continues its development; graupel
has begun falling with cyclogenesis off the North Carolina coast this evening.
Graupel is registering as “Heavy” precipitation and driving up precipitation
totals at an usually high rate for adjacent Sky units. This may be exactly what Sky is supposed
to do, I’m just sharing it with users as this is my first experience with graupel mixed with heavy snowfall rates. This may be similar to small hail and its influence on precipitation measurement.
Mine is mounted on a 6’ galvanized pole. It’s ‘S’ shaped to mount just under the eaves of a roof and pass around and away from gutters etc. I read one on this forum to fill with sand or something similar to make the pole less susceptible to vibrations - I’ve not done that yet!
I should probably mount the Sky on something more rigid. I’ll send an updated photo sometime.
Since my first post, something has changed on the backend as the behaviour is now different. This concerns me somewhat as you, the station owner, never know what’s going on and whether or not what you’re seeing is true.
After the series of California storms this past week tapered off, I ran a check of the week’s data on my station and stations within a 2 mile radius of my station. My Weatherflow reported 2.15 inches of rain, most of the adjacent stations reported between 3.38 and 3.92 inches, with an outlier of 5.98 inches. I think we still have the under reporting issue in the instrument.
Most of the rain periods also had drizzle periods accompanying the rain periods, and the weatherflow was not recording any rain accumulation during the drizzle period.
Here is a comparison of today’s precipitation. Very light rain, can be said drizzle, started early in the morning. After the first couple of hours of drizzle, after that the rain fell with light intensity.
My handy rain meter measured 0.9 mm.
The WH 1080 station also recorded 0.9 mm.
Weather Flow records 0.7 mm.
There is a lack of precipitation from the beginning when a very light rainfall or drizzle fell.
My weather seems to be reporting less rain with every storm.
I have rain overlay on my weather cam that’s pulled straight from the stream so it shows how much rain my sky has detected which is pretty close to what other stations near me report. It’s usually less since it’s poor at detecting light rain but close.
Now this is what I don’t understand, I was just told in another thread that the AI isn’t deployed so why does the weather flow app only show 25-50% rain as what is pulled from the stream for my overlay.
I’m even more confused because I was told that AI was being used to help with false rain but I never really noticed much change in that since most of mine was due to bird landings and I only got it from wind at certain speeds (some where around 16 mph but higher or lower non detected) at least from the times I could check on what might have caused it.
I’d like to know why there’s such a big discrepancy between what’s is sensed and reported but more than that I’d like the reported to be at least somewhat close to correct as it’s hasn’t been at all. One of the the main reasons for this station is to give my smart irrigation local data so I don’t waste water by over/under watering. the EvapoTranspiration seems to work well based of the temp/solar/wind but the rain part not so much. We just got a few inches of rain over 4 days last week, the soil is still soaked yet my sprinklers ran this morning because it doesn’t think it rained that much and it was actually only delayed until then because of the physical rain sensor.
Thanks for the detailed report @bocestar. Correct, the haptic sensor is not perfect when very light drizzle is falling. This is why the rain intensity values will be just one of many data points used to determine your accumulation amounts once our CL System for Rain is deployed (not deployed yet). It’s a fairly sophisticated system: see abstract summary here.
Hi @lovemyram4x41 . Thanks for your questions. We love the idea of weather data overlays on cam images — we have actually developed a system to do just that for NEST cams (not yet released). Can you share the details of your overlay system so we can comment more directly?? How exactly are you pulling “from the stream”? Are you pulling data from the WeatherFlow API? (If so, the discrepancy doesn’t make much sense as the Smart Weather App queries data from the same API. Something must be amiss in the integration.)
There are algorithms (not AI) in the HUB software that sense and filter out signals that look like ‘bird rain’ etc and disqualify the data dynamically.
We’re not crystal clear on what you mean by “discrepancy between what is sensed and reported”. Can you be more specific? We’d like to know too. . And as this thread title implies, the CL System for Rain is yet to be deployed. It will do many things; the main impact you will notice = 1) better individual SKY sensor calibration based on each and every unique installation, 2) massively more accurate hourly and daily accumulation values based on the assimilation of comparison rain data from multiple high resolution sources including but not limited to the rain intensity values from your SKY.
@WFmarketing. My weather flow is integrated with my home automation controller using a node server. I didn’t write the node server myself (it’s existence is how I learned about the WF station a little over a year ago and why I ordered one for myself). It’s written to not rely on cloud services so yes it uses the API to pull data straight from the UDP stream. I wrote several programs on my HA controller that sends the overlay data (when ever something changes or removes it if =0 for rain and solar data) to my Blue Iris server which places the overlays on my weather cam.
The discrepancy I’m talking about is like on the last day it rain my overlay showed .2x" of rain ,which was slightly less than the to closest weather stations to me-all the others were about twice as high but I think that we just got less localized rain that day as usually most in the area report fairly close except for mine (my overlay is close but slightly lower). WF app and WU (gets data from WF) both only showed .07" and this has been the case with every single rain storm that has came through since I got my WF and the error has been getting bigger each time it rains.
Since there is something going about false rain it now makes a bit more sense why they are off and have been getting worse. Since I get bird landings pretty much daily (weather cam picked up a nice shot of the local American Kestrel landing on my sky yesterday-most frequent lander is a Black Phoebe that nest under my water fall) when it’s not raining this may explain why WF is reporting much less rain than my Sky is sensing.
My Sky sensing a little less rain the other local stations also makes sense since it’s a bit poor at sensing light rain but initially wasn’t that bad. More recently though I believe it was on the storm prior to the last it had started raining over night (early morning) and I didn’t even getting rain on my over lay until sometime in the morning (maybe around 9 or 10) and only about 15 min prior to my irrigation rain sensor tripping (I believe it’s set at .25"). In the past it wouldn’t pick up the misty sprinkles that were more negligible anyways but this was hard enough I could hear while I was in bed.
The ISY node server uses the RAW UDP data and not the REST API. Therefore there will be a difference as the WeatherFlow servers manipulate the data AFTER it is sent by the Hub.
@lovemyram4x41, do make sure you’re using the most up-to-date node server, especially if you’re using the polyglot based node server. Early versions may be rounding the rain values to 0 until there’s about .05" of rain accumulated.
Yes, and that data seems to be pretty accurate but still often lower. I’d take that over what WF is currently giving.
I’m on v18.104.22.168 which I believe is most recent. I haven’t checked for awhile since I getting ready to move onto something else other than ISY for my controller (or at least in conjunction at least until I can get everything moved over-the weather node stuff would be last).
eh? You will take what over what?
The data that the node server pulls over what WF app reports.
Okay. The REST data is likely to be more accurate when it comes to rain. Otherwise it’s the same data.
Hi @lovemyram4x41 . Appreciate the clarification! And thank you to the others who have shared insights here.
Ahh, you are using raw UDP data instead of the REST API for reasons stated. For most values, the raw UDP stream is fine, but rain is a little different. The WeatherFlow system is predicated on the notion that distributed low-cost sensing networks are significantly more valuable if there is way to QC/assure all the data is homogenous/dependable/calibrated/corroborated. (This is the key failure of most other networks…especially ones installed by consumers using different equipment.)
For rain in particular, the haptic sensor is unique as it can tell you instantaneous rain intensity which a tipping bucket cannot. Sensitivity tuning limitations wane at the lighter end of the rain intensity spectrum (ie. light drizzle). This is where some of the backend magic comes into play – we will use an array of other high-res precip data in addition to augment haptic’s rain intensity raw values to QC and compile hourly and daily accumulation values. This is accomplished on WeatherFlow network servers and is available via REST API, but is missed by the local-only UDP stream. The raw intensity data and subsequent accumulation values broadcast by the HUB via UDP will continue to improve with in-situ calibration, but the UDP stream will not benefit from the other network intelligence . — which is why you will see a difference in rain accum API vs UDP.
Is this ‘array of other high-res precip data’ a live adjustment requiring connection to the WF servers OR is it only to aid the long term calibration?
I wish to know if I have the latest firmware and calibration if I am not connected to the WF servers could my instantaneous rain amounts record a different amount compared to if I was connected to the WF server?
Ok, so I’m clear on why it’s so far off.
So I should I expect the network intelligence to get better any time soon. When I first got my station last summer and read all the complaints about the rain sensing and how it will learn and get better I was worried since it doesn’t rain much here but while we got a decent amount a of rain last year this so far it seems to be raining far more often but the rain detection seems to just get worse.
The last storm gave us 3-4" over 5 days but WF only shows under 1" over that time period.