Weather Adjustment Behavior Weather Underground compared to OWM

[dun4cheap]

I just do not get it. Why are the numbers so skewed.

I have 23 OS Smart Controllers. With the fact that the WU Api will not longer be supported I decided to start switching over and the results just have me baffled.

I am in San Diego, CA 92126 zip code.

My adjustments are as follows Temp F = 64 Rain=0 and Humidity = 70. With the Weather Underground water percentage is showing 84%

Removing the WU API my settings are Temp C = 17.8 Rain=0 Humidity = 70. With these numbers the OWM water percentage is showing 200%

Is anyone else seeing weird behavior like this?

Also, Rey, I never received that OLED screen for my bad controller. I tried reopening the ticket and never heard anything back. Can you tell me if it has been sent out.

Thanks,

Ed

[yellowgecko]

Same for me. Was a really hot day and %water is down to 0%. The idea that it only takes the current temp, rain and humidity mentioned in August in the forum:

https://opensprinkler.com/forums/topic/weather-adjustment-using-current-temperature-instead-of-average/

seems to be true [rather what it is supposed to be used is the average of the previous day].
[[Best would be actually the average across the days since the last watering was performed]]

The forum never reached a conclusion but Ray said he would look into it.

[yellowgecko]

Hi admittedly I am not sure if I searched at the right position. I tried to find the position where the weather data is downloaded.

If I am not mistaken the adjustment for the openweathermap data is done in the OpenSprinkel Weather javascript (hosted on Amazon).

The latest fix is called “Average out the incoming data from OpenWeatherMaps” and was done 4 month ago.

Here I find the following api call to owm:

forecastUrl = “http://api.openweathermap.org/data/2.5/forecast?appid=” + OWM_API_KEY + “&units=imperial&lat=” + location[ 0 ] + “&lon=” + location[ 1 ];

which is a forecast the next days (3 hourly up to 5 days).

THen the temperatures, humidity, rainfall etc. are averaged across the first 10 entries (which essentially is 30 hours). A potential problem here is that if a data point is missing, hence as the algorithm sums over values if NaN is added then at least the denominator of 10 is false, but not sure if that does not lead to an NaN overall.
There is also a comment by tekshed that this might be a problem.

Finally I am also a bit puzzled that the forecast data is used here. Zimmerman relies on the previous data not the future data, but not sure if this call is also used by the Zimmerman algorithm.

So potentially here could be the problem (wrong averaging if data is missing (NaN)) and also using forecast instead of historical data.

Anyone out there with a better understanding that might be able to have a look at it.
github link to the commit

[yellowgecko]

just tested it:

(parseInt(“-“)+1+2+3+4+5+6+7)/10

results in NaN
so if there is a missing value temperature, rainfall etc. are not defined…

[Ray]

About Nan: I am pretty sure we encountered this issue in the past and fixed it. But perhaps this is a new issue. Can you let us know your location (GPS coords) so that we can debug the algorithm? If you don’t want to publish it here, you can send a support ticket.

@dun4cheap: what’s your support ticket number? I am pretty sure we’ve responded to all support requests, but perhaps we’ve missed yours?

[dun4cheap]

Ray, can you respond to my post on the weather matter since I opened the threat. Maybe you can explain why I would see such a skewed difference.

Here is the ticket number on the OLED screen.
Ticket# 6510

I received an email asking if I felt comfortable swapping screens. I had replied yes, but never received the replacement. I re-opened the ticket but it auto closed.

[Ray]

OK, I just responded to your ticket and re-opened it.

[Author]

Posts