Forum Replies Created
-
Posts
-
@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! 🙂
@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 …
@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
Yea I think the bottom line (and what we are all trying to communicate in general) is that OWM is appealing on the outside, but total garbage for everything we expected it to do. Or just garbage in general.
If we base anything off of trash data, the best we will get is trash result. OWM data actually destroyed a noticeable chunk of our landscape … unfortunately … and we are now fixing it. And it sucks because it only took 6 weeks to destroy it with OWM. (Don’t overlook my negligence in not noticing fast enough.)
But looking at reality: humidity, temperatures and rain are variable. And plants and trees are obviously still alive today (humans, now that is a questionable existence, no idea how that’s continuing on).
So even with OWM’s horrible faults, and the fact that I would never use them for anything I value – and honestly wouldn’t wish them on my enemies – the plants and trees do recover, but something needs to change real quick.
Or they won’t recover next time.
We have spent probably $1K USD to fix what the OWM data screwed up. And that isn’t including my pain, time and anger dealing with it.
The OWM service has no legit support, we can’t even identify whether or not they are receiving our weather data, and the best I can say is “THANK GOODNESS FOR THE INDIVIDUALS WHO HAVE INVESTED THEIR TIME AND RESOURCES INTO ALLOWING US TO USE OUR PWS AGAIN.”
Cheers to them, including Peter, Ray and Samer, and the others who have contributed. I feel bad that OWM didn’t work the way it should have. But it has got to go.
Whatever the solution is, we are more than happy to donate datacenter resources to the cause. Email me at [email protected].
We have datacenter services we could share. Is it possible to run one WeeWX and allow others to send data to a central server? And then use that for their weather data?
Or is this something that has to be local to the user’s situation?
Hey there – I’m having the same problem. They switched from WeatherUnderground to OpenWeatherMap, and that made the issue.
So when it’s raining, we are at 100% and then when it’s 80ÂşF it waters at 0%.
I think we need some help from the devs.
I see. So does WeeWX have native built-in support for OS? Or is that something you have to manually add and then connect using the API?
The chicken cooling is similar to what we want to do. Some days in summer here are ultra-hot and in winter are very cold, and so we would love to drip some extra water depending on weather events.
BinaryOS, is Weemx a service or ? I saw some things on that, it’s where I learned how to add my PWS to OWM. Didn’t look much beyond that though.
Side note, so I checked watering level right now, when our stations are programmed to run, and it is 0%. So nothing is running. By midday yesterday, the watering level was at about 45%. But for our programmed times, definitely not helping.
This is much different behavior than when WU was used.
Attachments:
Yea USA here.
It’s got to have something to do with OpenWeatherMap.
I would say allow for some sort of local database connection and let us skip the middleman for local actual data, and then supplement that with forecast data from a public service.
Obviously if we are forecast for 100% chance for 100mm of rain, then maybe don’t water … but for the California watering restrictions or watering requirements in general, the existing weather history from that location should be able to know if the soil is or air is moist (or higher chance of). Then combine that with the forecast. Or maybe that’s already how it works.
Also would be excellent to use solar radiation or UV if our weather stations support it. We get some random days out of the year where the radiation spikes and big chunks of our bushes literally burn to a crisp. I would love if OS could also take that into consideration for recent weather.
We live where it is rock hard soil. And get both snow and nearly 48°C in summer. So I would also love to see some way of seasonal adjustment based on time of year. Based on Zimmerman, our winter adjustments should realistically be about 40% of our summer adjustments (after all adjustments are made).
Or more realistically, Spring should be baseline at 100%, summer at 130%, fall at 80% and winter at about 65% of what we currently (or used to before OWM) have adjusted.
If that makes any sense. Obviously off topic now …
I think I should also mention that OWM seems to be retrieving the nearest weather (not even sure it’s a personal weather station, either) to the GPS coordinates.
And the weather we’re getting is really not appropriate for where we’re at, even though it’s only 10 miles away. It is on the other side of the valley (I can see the area from my house) and they have remarkably different temperatures/humidities at each point of the day.
Short of programming my own watering app (PHP?) and controlling OS from that thru the API, or watering manually, I’m really not sure where to go from here.
Hello everyone, an update to my situation … So we’re finally getting >0% watering, though the number has been bouncing all over the place (between 10% and 45%) over the past couple hours. Currently at 22%.
Which leads me to believe that if I have my watering scheduled to start in the early morning (as opposed to the middle of the day, as it is now where I’m at) then my watering levels are going to be consistently near 0%. Even during the hotter period of the summer.
Another super odd issue I’m seeing is that only one of our stations is running “automatically” when the water level is >0%. Or maybe it is that it is barely over 0% and then goes to 0% partway during the programmed schedule?
We are using Meteobridge Pro for uploading our weather data. It’s been working great, though I can’t confirm whether the data is being sent to OpenWeatherMap. I did, however, find some documentation on how to actually get my weather data to go there (by creating the weather station thru raw API call). It’s very complicated, and I wish we could just nail down a specific method of reliably submitting and using our own weather data.
For example, we have a MySQL database that’s local here which has all of our weather station data saved each minute. It would be best if we could just have OpenSprinkler query that, instead of dealing with all these mad online services.
hey BinaryOS – are you sending your weather data to OpenWeatherMap?
I’m trying to figure out how to verify that it is receiving our weather data. But the user interface is terrible, and I am struggling.
It was great with WU when you could specify your own station. I wish OWM worked like that …
The wrong location we are getting weather from now hasn’t had any rain at all. All 0’s though.
Attachments:
Yea – I think we might all have the same issue (or similar) going on. I made another thread too, because there are some differences.
In our case, the station we are now apparently using is far away. And I cannot confirm that OpenWeatherMap is even getting our data. They seem to have no way to verify that …
But the odd thing is the station that we are now using (?!) has had no rain at all recently, but we still have 0%.
Watering manually now these days … glad I caught it was 0% because we are about to get into the scorch season.
~Laz
Hey Samer,
For me, it is a little less specific to reproduce. I don’t necessarily have to start any stations. Sometimes just opening the app will have it freeze.
I will mention, I’m on iPhone X, not sure if that makes any difference … but seen a similar issue with another app after they updated it to allow for the larger screen.
I would say that 9 times out of 10, I can get the “freezing” to happen from just normal use. But like Jeremy, letting the screen sleep and then unlocking it back into the app is almost surefire way to do it.
Hope any of that rambling gibberish helps. 🙂
Thanks Samer.
~Laz
Yep, same here. On iPhone X, not sure if that matters.
But I don’t think the app is frozen, it just isn’t accepting any touch input from the screen.
It seems that it is still running though.
Been doing lots of tests with our irrigation lately because it is getting hot, and the freezing app has been a problem.
My pleasure!
Also, don’t forget about leaf wetness.
Not entirely sure what to do with that as well, but what I’ve noticed is that when we have mornings where the leaf wetness is 10+ (generally 0 by about 9a), the soil is pretty much damp and nothing needs water at all. Someone with more understanding about these measurements would know a lot more legitimate truth about the value of these …
But they said they are also adding evapotranspiration this year. So that should make things even more interesting.
A question about solar radiation too … If solar radiation is low (i.e., cloudy day), that would mean that any moisture in the soil or irrigation would most definitely stick around longer. So a cloudy day in summer should be taken advantage of. No idea how this could be implemented, but this type of sensor would have to be very close by the OpenSprinkler user’s location to be relevant. But for us out in the California desert, this could be unbelievably valuable.
Anyway, we are REALLY looking forward to the summer time with OpenSprinkler. We started in December, so we are getting to see the lower water levels. Summer should be fun.
Is there anything in the algorithm that can detect “ultra dry conditions”, and increase the water level over 100%? Last summer, our entire grass got fried and the whole lawn died. The issue was a combination of very high solar radiation and very low humidity. And we were already watering a lot more than normal … so that was a huge bummer!
Anyway, OpenSprinkler is one of my top 5 toys and tools right now. Cheers for the beautiful product. Take care Ray.
Hey there Ray!
I just checked the API from WU for our weather station and the soil moisture/temperature and leaf wetness data is indeed there.
Do you think it would be possible to also integrate this data (when available) to OpenSprinkler’s water management?
~LazET data is not yet provided from WU, but I did get confirmation from their developers that it is something on their priority list for 2017. I am not sure if they are going to be simply calculating it on their end, or receiving it from (for example) our Davis Vantage console, but they definitely said they are adding it.
Regarding the WU API, I have not really looked at it to see what data it provides. But our WU station does have soil moisture and temperature, as well as leaf wetness data there. So I would hope that their API is able to provide that data to us. It is extremely valuable!
I will check on it and see what we can get … Possibly the API does not return any data if it does not exist as a measurement for that area?
Oh great, I didn’t even think of using the IFTTT! I thought it only worked with Alexa and those things ha ha ha.
I am definitely going to check that out. Thanks, Ray!
(And as a side note, I really need to learn Python!)
Great, thank you for the clarification.
I’m still trying to wrap myself around the amazing possibilities that OS can provide. Together with our Meteobridge and weather station, we are already getting warnings via SMS when certain weather events are happening in our area.
One example that doesn’t have anything to do with irrigation would be strong winds from the north. We recently had some new trees put in, and with any winds from the north greater than 10mpg sustained or gusts upwards of 20mph, one of the poor guys starts to lean a bit. So, unlike a weather event that could trigger an irrigation action, in this case, I have to go out with a strap and a pole, and anchor the tree down to support against the wind.
One approach could be to create programs specific for weather events (or any event, for that matter) that are not scheduled to run. Then, on demand, those particular programs could be run when necessary and comply with the current definitiosn to reset all stations.
However we are limited to what, 19 programs I think I read somewhere? Is it possible to increase that maximum without too much effort?
That would be awesome to see OS provide that type of compliance automatically. I think it is such a shame how we waste water simply because we (and I speak generally here ha ha) do not understand the environmental/physical nature of water in our yards.
The company I work for is trying to get into some state-level compliance projects, through our cloud services and government APIs. We will hopefully provide data to allow businesses easier methods to keep compliant. I’m just one of the tech guys involved, but hey – if anything like what you are saying gets a pair of legs, and there is something that I can do to help, I would love to donate network resources or my time for something like this. (I may have said it before, but my programming skills are probably a 1/10 compared to yours, but it would be my pleasure to give back as I can.)
Now, the amount of water used to make beef (we like to watch a lot of documentaries) … not sure what can be done about that one, except for eating less burgers!
Cheers to that one, Ray!
So, currently we are (obviously) pulling our data from Weather Underground. That’s totally fine, since it is from our own personal weather station that sits in the yard. I’ve been talking with the developers over at WU and they are also working on receiving ETo data from PWS such as ours. Good news there as well.
Here’s my question … With Shawn’s algorithm being based off of available data from WU (I believe — I looked at it and it’s WAY over my head ha ha), will you make sure to have this number be taken from WU when they are ready with the data through their API?
I actually did a few queries to Shawn’s Python script, and it pretty much matches up (almost exactly) with the ET data that our Davis station is calculating. So his work is most definitely on point. But will OS pull the data from this WU data source as opposed to calculating, *if* it is available?
And also, how about the currently available soil moisture/temperature and leaf wetness data from WU? Is that possible to be incorporated as well? I know it’s getting complicated at this point — but my goodness how amazingly powerful this could be.
By the way, your product is so unbelievably awesome. It’s most definitely my most favorite gadget of the entire year! Thanks again, Ray.
