- This topic has 68 replies, 15 voices, and was last updated 5 years, 3 months ago by
.
-
Posts
-
I compared Wunderground with Openweathermap on that location just for interest and there is a bit of difference..
https://openweathermap.org/city/5341145
https://www.wunderground.com/forecast/us/ca/cupertino?cm_ven=localwx_10day
I checked a nearby Australian site Oberon, NSW
https://openweathermap.org/city/2154537
https://www.wunderground.com/forecast/au/oberon?cm_ven=localwx_10day
I checked my nearest local Canberra, AU with OWM, WU and our local BOM, was a little bit out, but not +10C
Keep in mind the Zimmerman model calculations on the Opensprinkler weather app is running on predicted temps.
I reckon I’d just adjust the temp baseline and tweak your watering times,
It’s not like you’re running a nuclear reactor 😉A bit of a difference? 20 F is a bit of a difference?
You’re right, I’m not running a nuclear reactor. What I’m running is an appliance that was advertised to adjust based on the weather.
Since WeatherUnderground is no longer available, it seems we’re stuck with OpenWeatherMap. And apparently for parts of Australia and certainly for my part of the US, OpenWeatherMap is useless.
Ray recommended I try nearby cities. Well, I tried 4 that are nearby, and NONE of them has a correct forecast on OWM; they’re all low by 10 to 20 F.
Yes, the Zimmerman model is running on predicted average temps, and the OWM predicted average temps for my area are consistently wrong. Garbage in gives you garbage out.
There’s no point in continuing this discussion. Unless OWM gets fixed (apparently about the same time Hell freezes over), I’m simply going to have to turn off the weather adjustment. And honestly, I’m no longer going to recommend OpenSprinkler to anyone.@Peter –
Our coords are 33.6774 lat and -117.2157 long …
There’s one specific thing about OWM that confuses me. Our OWM data came from the other side of the valley, about 5 miles away. Generally, that location’s data is similar data as far as I’ve seen on WU. (OWM still has never had our PWS data available, even after submitting for many months now.)
But for OWM, it almost seems like their data is not even real. It’s like it comes from some third party service, or fabricated based off of some forecast data or something. Or even when there is actual data to use, I have no idea what they are actually doing there with that data, because it’s horribly wrong.
When I said that OWM caused us “damages” on our landscape, that is entirely true. We never had an issue with OS until OWM. We’ve actually had to invest quite a bit more than stated in my previous post due to the OWM data, but I really don’t know to what extent that data directly affected our landscape. (It was bad, believe me, we went for probably 2-3 weeks or more of zero water before I even noticed — all our watering happens before the sun comes up — so of course I should have been more attentive.)
What I know for sure is that the OWM data was so completely different compared to reality that I can’t even think for one second that the data was coming from a legitimate source — even for 5 miles away. Though it was coming (supposedly) from the other side of the valley, what OS was using wasn’t even close to reality.
48 hours after switching back to our PWS, the OS weather data was 100% different and we were actually having proper irrigation on our land.
So I’m a bit confused where OWM actually gets their data. We have been “submitting” our PWS data to them for the past few months, and they have accepted it as far as the API is concerned, but I’m positive that our data isn’t even being made available. There is no way to verify that they are receiving it or not. Their entire system (in my opinion) is fatally flawed. There’s something very very wrong with their data.
Using their web UI, I can’t even find the actual location that they were providing to OS. And — while very pretty — their weather data in the UI isn’t usable to me in general … Not that I absolutely require Fahrenheit, when switching to Fº on their website, everything is still in Celsius. But most importantly, the data in our area is *bad*. Aside from the usability issues that their service has for an “average user”, I am still confident that they are not using real data, or that something in there is fabricated to some degree from data that may or may not have ever even existed — or maybe it is a terrible AI product. I honestly don’t know where they are getting their data from, because at our location, it isn’t even close to real life.
THANK GOODNESS for your efforts in allowing us to use our PWS again. I was manually doing every single watering station each day just to get by. I honestly don’t care about OWM now, so don’t invest your time to look into it. I am just grateful and happy that I don’t have anything to do with them anymore.
I truly believe that there is a real issue with OWM. Something that’s not apparent on the surface. If there is an actual problem, it would be that we don’t have the ability to verify if they even have real data for any given location — not that the data is “bad”, per se. Bottom line: something is very wrong with their data. The UI and maps are very pretty, though. And everything is quite attractive on the surface … Under the hood, though, it’s complete trash as far as I’m concerned.
~Laz
@Sturdley, I’m right there with you. I think their data is fabricated from third party weather data.
I would really like to verify if my PWS data is even getting received and digested by their web services. I don’t think it is.
Something is very, very wrong with their service …
Sorry to hear of your loss Paravis. I don’t really recall how I spotted the crazy values but it was early on thankfully.
After setting up a local weewx station to serve weather report to open sprinkler I was still exposed if the internet or UW service stopped as I was sniffing the data. Well the internet did go down due to a botched upgrade from the national telco for several hours. During the outage have now redirected the PWS to the local webserver that then simply forwards on the same url to UW. The sniffer continues to function. So now internet connection loss does not have an effect on OS.
For those interested, below is the local php that forwards onto UW I am using. As I was already sniffing I was able to cut the script down from https://obrienlabs.net/redirecting-weather-station-data-from-observerip/
<?php // Parse the wunderground packets sent from the ObserverIP // Pat O'Brien, 1/14/2016 // Make sure the ID and PASSWORD fields match what we think it should match. If it does, this update is valid and continue. if ( ($_GET["ID"] == "yourPWMID") && ($_GET["PASSWORD"] == "yourPWM_PW") ) { //============================================// // Auto send data query right to wunderground // //============================================// $wunderground = file_get_contents("http://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?" . $_SERVER['QUERY_STRING']); echo $wunderground; } else { header('HTTP/1.0 401 Unauthorized'); echo 'failure'; die(); } ?>@BinaryOS – yea, it was frustrating, but thankfully everything has recovered (minus a handful smaller things that bit the dust). I guess that I’m mostly irritated at the fact that I didn’t notice for a while, then spent time trying to get OWM to work proper but it never did.
And I think it’s a real shame that WU made those changes to their API service. For crying out loud, their entire database is made up of contributions from us.
Oh well. It is what it is.
On the bright side, we had a spot that would generally get too much water, since it would all run down and pool there. I never had the chance to fix that previously, since there was a lot of stuff growing there. Now, since that all died (haha), I can go and fix it.
So there is a little bit of a silver lining! 🙂
@paravis, you can query OWM for your particular PWS data. I have been sending in my PWS data for a few months now and have checked that it is being received using their new v3.0 api. You can make a call to the url below substituting in your api key and station id to get the last weeks worth of daily values:
https://api.openweathermap.org/data/3.0/measurements?station_id=<station id>&type=d&limit=100&appid=<app id>&from=1559476800&to=1560081600As far as I understand it both WU and OWM have in effect have two loosely coupled solutions each. The first allows users to store/receive PWS tagged weather observations. They both then use this data to help “teach” their predictive solution. The predictive solution allows the user to query the weather for any lat/lon and WU/OWM apply their “artificial intelligence”, “crowd sourced”, “interpolated”, “micro-location” (buzzword buzzword) algorithm to predicts the current/forecast weather at that location. It is a little un-intuitive that querying based on your PWS ID and then querying based on your PWS lat/long can give very different results. This is because WU and OWM weight the value of PWS information to reflect that most personal weather stations are both poorly sited and poorly calibrated (I suspect they positively bias information from national observers and airport stations that might be further away from the requested position).
@sturdley, I have just started to log Cupertino data. One initial question, can you confirm whether there was heavy rainfall overnight in Cupertino?
OWM was reporting 40mm/hour of rain around 1-3AM on the 8th June. I didnt see any reported rainfall on any of the major weather sites and neither DarkSky nor WU reported rainfall. I have included a screen capture of their report at 09:30 BST today. The fact that the same image shows humidity at just 35% suggests something wrong in the back-office. I have submitted a ticket and curious if they will respond and what they say.
Attachments:
@peter, there was no rain overnight in Cupertino. In fact, there’s been none this month.@Sturdley, so I have 48-hours of data (except for an annoying 6 hour internet outage) in the attached image. In each graph the thick yellow line is what OWM thinks the conditions are at that point in time. I don’t have easy access to your national provider so I have used two local Weather Underground PWS as a proxy for the actual conditions on the ground. I have also included comparable data from DarkSky as they are a leading alternative.
For temp, so far I think OWM is doing an OK job. It tracks the PWS references and does a better job than DarkSky that has some divergence in some circumstances. There is perhaps a few degrees Celsius error (this would be +/-15% on zimmerman)
For humidity, the OWM data is “choppier”, my guess is that they don’t update humidity as often as temp and that leads to some timing bias. But again OWM tracks the PWS conditions better than DarkSky. Perhaps with ~15% error in certain areas (this would be +/-15% on zimmerman).
For precipitation, the values just look wrong. They are reporting rainfall, and heavy rainfall at that, when all other services are reporting dry. I have raised this with OWM so will see what happens. I suspect that OWM are leveraging PWS data and that something has gone wrong in the mapping of PWS locations (i.e. they are pulling in some data from non-local PWS – pure speculation on my part). Not exactly confidence building.
On each chart (temp, humidity, precip), I have also shown a grey, dashed line. This is the information used by the OWM Zimmerman calculation. The grey line is the average of the next 24-hour forecast data. So you can see that over the course of the two days, OWM was predicting temp to increase over the period and humidity to decrease i.e. weather will get hotter and dryer. What is interesting is the grey line for precipitation is zero for the duration. I think this is further evidence that OWM has a “problem” in the model. I would have expected the grey line to show forecast precipitation before the yellow line showed what they think is actual rain. This is somewhat curious ! Again, I have raised this with them.
The final graph shows the Zimmerman water level calculated for the period. I forgot to update my logging software to use a Cupertino-friendly baseline so the graph values are based on London setting. So the absolute values are not representative but the shape of the curve is relevant. In essence the values look reasonable given the grey lines for the temp/humidity/precip graphs i.e. increasing the watering level as the forecast predicts hotter/dryer conditions.
This is only a couple of days worth of data and hardly conclusive. I just wanted to get something out quick. I’ll keep it running for the week and we can see how it goes.
Attachments:
I just noticed that the weather adjustment wasn’t working (I should have caught this before, but…) and this discussion tells me that the new weather provider doesn’t work. I guess my option right now is to just shut off the weather adjustment? It’s summer here in California so that’s not a big deal, we’ll just run everything at 100% on the drip system.
But is any kind of a fix in the works?
@jeffhaas, the new weather service has gone through a number of fixes/tweaks over the last few months and should be providing reasonable watering levels if correctly configured. However, some users have reported that the OpenWeatherMap data is not an accurate/reliable service for their particular location. This seems to come down to specific micro-climate conditions that OWM isn’t able to model or errors in the OWM data for a particular location.
To help us understand your situation, can you expand on “the weather adjustment wasn’t working” ? Is it that it is “stuck” on 0% or is it that the watering level changes but doesn’t reflect your particular weather conditions? It would help if you could let us know the version of App, Firmware and Hardware you are using (see the About menu item in the app), as well as, providing a screen shot of the System Diagnostic page and the Zimmerman Adjustment Options page. You can upload images using the “Attachments: Choose File” button when submitting a reply.
I’m in the SF Bay Area. It only got hot recently, and we have a lot of drought-tolerant plants, so we only noticed recently that they weren’t getting the water we expected. I set the adjustment method to Zimmerman and the restrictions to California-based – and get a Water Level of 8%. It hasn’t rained in days and it’s really hot, so this is incorrect.
Screenshot of the current water level and the version are attached.
Attachments:
@jeffhaas, I’m also in the SF Bay Area (south bay), and have found that the OpenWeatherMap forecast for Cupertino, Sunnyvale, and Los Altos simply reeks. It’s garbage; apparently OpenWeatherMap can’t handle the Bay Area’s microclimates. In my case, Monte Sereno is a reasonable approximation; certainly better than the forecasts for the cities I list above. I suggest you try nearby cities and zip codes; I had to go through half a dozen before I found one that worked.
It’s too bad that we’re stuck with a service that produces such crap, but that’s the way it is. Hope this helps.
Wow, you’re not kidding. Take a look at the Weather Underground record for 6/23/19 vs. the Open Weather Map record in the screenshots.
How the heck is Open Weather Map so far off?! It reported that today’s high was 58F. It was 81F!
No wonder the weather adjustments aren’t working.
mikebrennan,
[I received an email referring to your post about Canberra this morning, but can’t find it in the Forum? the link in the email doesn’t link to anything?]
I don’t have a rain monitor, I check the rain forecast in the morning and set a rain delay if there is >60% chance of more than 10mm, for as many days forecast. Most of my system is garden drippers with only one in-lawn sprinkler system which runs at 10pm at night once a fortnight. I aim is to water consistently, and only enough to stop the plants dying completely.
I’ve been away from home for a few days and discovered my system had not enjoyed the recent upgrade, the phone app showed the weather report was in imperial and watering on 140% after 7mm rain last night.
Canberra rainfall: http://www.bom.gov.au/products/IDN60903/IDN60903.94926.shtmlI went into the app settings and reset it to metric and the watering percent dropped to 72%. I haven’t updated the firmware yet so will try that and see what’s going on.
You can check the recent Canberra Airport Evapotranspiration here:
http://www.bom.gov.au/watl/eto/tables/nsw/canberra_airport/canberra_airport.html
It’s computed once a day at a particular time, whereas I think the OS WeatherApp algorithm calculates it instantaneously as it’s about to run a schedule. You can’t easily compare the two as ETo is not recorded in the OS unit’s logs.Having said that, if you chart the recent Canberra Airport evapotranspiration above, it doesn’t appear to change that much with rain, see attachment. Perhaps because we get so little rain and the evaporation here is pretty severe. It’s very windy here on Saturday and that would keep it dry.
But I’ve been thinking running the OS on Evapotranspiration is putting the cart before the horse. Currently we set a watering schedule, which might be once a week, and defeat that with ETo when it’s time to water. Ideally we would monitor the ETo and turn the sprinklers on as required, only putting on that much.
CanTurf recommends deep watering lawns:
“The most important ingredient in maintaining a healthy happy lawn is the development of a deep watering routine. Deep watering will encourage the roots of your lawn to grow deep into the soil enabling it to source increased water and nutrients-saving you time and money.
To develop a deep watering routine you should water infrequently and give your lawn a very good soak, ideally 12 mm (or half an inch) of water over the whole area every 10 to 14 days, or as required.”
So I have mine putting that much on every second Thursday in several bouts of 10 mins, 30 mins apart so it does soak in and allow the ETo watering defeat to modify that. I don’t want a bowling green, just enough so it won’t die, and I recently reduced the number of bouts to see if it was really needed.
I hope that helps and will report back when I update my OS controller’s firmware.
Attachments:
@Ian – thx for your reply. Not sure what happened to my post. … I Made an edit and “gone”. None the less, I have been thinking about a solution to what appears to be gap in the options in OS … What “I” really need is a weighted moving average of the calculated %watering since the last watering (I think), or at least the last several days … say 3 … This way, both the OWM and ETo or Zimmerman data come in to play – say a weighting of 60%(watering day = today), 30%(yesterday) and 10%(day before). … Or, since I have an OS3 I might try implementing something through the second sensor switch and a sonoff relay – effectively a shut-off if there has been enough rain in the last n days (similar weighting as above) … but for now I will adjust manually, but this is like having a dog and barking yourself.
Because the Weather App doesn’t yet have cloud support to save your local weather data predictions and observations and how much water is applied, it’s not possible.
As far as I can tell, the Weather App computes an instantaneous fudge factor (Zimmerman or ET0) to apply to each hard wired watering sequence just before the OS Controller runs a schedule. In Queanbeyan you often only get rain if you are lucky enough to be under a cloud if it drops, one side of town can get 20mm and the other side none, so it’s hard to predict. The BoM rainfall prediction for 3rd Nov is 95% chance of 15-20mm which is 95% chance of any rain, 50% chance of 15mm and 25% chance of 20mm, I’m not sure how the Weather App handles that. My experience locally is I’d rather it water anyway but reduce it to 10% min so if it doesn’t actually rain the plants won’t suffer too much.
When I retire I’ll learn to program JavaScript to stave off dementia, work out how to parse the BoM data predictions and observations. I’d like to add another page to the weather app that shows a chart something like this, but not necessarily as fancy.
I’m wondering if I could knock up a prototype in Google Sheets that does this, there must be a way to get GS to send API calls to the controller.
- You must be logged in to reply to this topic.