- This topic has 15 replies, 12 voices, and was last updated 5 years, 7 months ago by
.
-
Posts
-
I just recently installed OpenSprinkler pi at my house and I have noticed that the weather adjustment changes drastically throughout the day.
Early in the morning when I am actually watering and it is still cold I seem to get decreased watering times (this morning I was at 81%). Then in the heat of the day OpenSprinkler shows much higher watering times like 180%. It is definitely hot and dry enough that my watering should be increasing.
If the Zimmerman algorithm were actually using the average temperature from the previous day I wouldn’t be seeing large swings like this. I am wondering if it is somehow using the current temperature instead of the average? Is there any way to get this working properly so that I don’t have to manually adjust my watering times?We will check: due to WUnderground discontinuing their service recently, we have switched to OpenWeatherMap and due to the API change we may be using the current temperature as opposed to average temperature yesterday (it’s possible that they don’t provide yesterday’s temperature unless if you go with a paid service).
I’m noticing the same thing. Big changes in water level. I have mine set to run at 4am and the sprinklers almost never run, or if they do it’s somewhere around 20%. I tried doing some troubleshooting and realized with OpenWeatherMap I needed the paid service to get historical data.
Yes, same behaviour here after I switched to OpenWeatherMap: As temperatures go down at night, watering level drops dramatically.
Have you looked into Dark Sky? Their api offers each user 1,000 free calls/day. Seems like it would work pretty similar to weather underground. Their forecasting is the best too, imho.
https://darksky.net/devSorry Jemba, that was directed towards the developers. As the weather adjustment runs on the server, not the firmware, I don’t know if there’s a way to change it yourself.
New to OpenSprinkler and just had my first somewhat successful weather adjustment with the Zimmerman option enabled. I have noticed the same thing. Last night before heading to bed, the water percentage on the home screen was at 111%. I thought, good, it’s hotter that usual lately so it’ll be nice that the watering times will increase automatically. But this morning it was down to 24% and my morning program only ran for a couple minutes, instead of the 20 minutes it was programmed for. Our high was around 90 with a low in the mid 50s. So it appeared that the adjustment was at the time the program ran, which based it off of the low temp.
To get around this, I would need to do one of the following:
– set the program to run in the evening so it adjusts based on the high temp of the day
– adjust the zimmerman option for a lower baseline temp
– adjust the program sprinkler times to something outrageous like 2 hours(if I wanted a 10-20 minute watering time).Am I understanding that correctly?
Same here – It’s the height of summer here, and we just had a series of days over 30C and my OSPi watered for 27 seconds per station this morning – 3% – this didn’t happen with WU data.
Is there a fix for this?
Same here! To give an idea how time-of-day dependent opensprinker Zimmerman turned after switching to OWM, please see the attached data from the last days, oscillating between 0% and 138% in a few hours:
value acknowledged from timestamp 86 true parser.0 2018-12-31T12:21:29.356Z 66 true parser.0 2018-12-31T13:21:29.426Z 27 true parser.0 2018-12-31T15:21:29.555Z 23 true parser.0 2018-12-31T17:21:29.708Z 0 true parser.0 2018-12-31T18:21:29.764Z 6 true parser.0 2019-01-01T07:21:31.067Z 0 true parser.0 2019-01-01T08:21:31.196Z 97 true parser.0 2019-01-01T09:21:31.319Z 113 true parser.0 2019-01-01T10:21:31.424Z 125 true parser.0 2019-01-01T11:21:31.475Z 123 true parser.0 2019-01-01T12:21:31.552Z 75 true parser.0 2019-01-01T13:21:31.692Z 15 true parser.0 2019-01-01T15:21:31.916Z 11 true parser.0 2019-01-01T16:21:32.158Z 0 true parser.0 2019-01-01T18:21:32.468Z 77 true parser.0 2019-01-02T09:21:33.675Z 105 true parser.0 2019-01-02T10:21:33.803Z 133 true parser.0 2019-01-02T11:21:33.996Z 138 true parser.0 2019-01-02T12:21:34.086ZI’ve several systems deployed here and definately need a fix soon.
Greetings,
GregorRay – Any feedback here? I built my OS last year. Very dependable, but when I switched to Zimmerman, I saw the same thing – doesn’t seem to be looking at yesterday’s average but rather current data. I switch Zimmerman off for the winter, but now that it is starting to heat up here central Texas, I’m trying to get the automated weather adjustment running.
On another thread Ray suggested putting in a bug request, he doesn’t continuously watch the forum. I’m sure he is aware of the problem.
Of course OS is Open Source software and you’re encouraged to get your hands dirty, but I only know enough to be dangerous.I had a play with the OpenWeatherMap API to see what is being returned, this is from Canberra Australia id=2172517
You need to register for an AppID code which I have replaced with #### here. The one baked into the OS I suspect is a paid one owned by Ray(?) which calls the 16 day forecast, you need a paid account to call that one, so the one below is the 5 day. Note it asks for imperial units.http://api.openweathermap.org/data/2.5/forecast?id=2172517&APPID=####&units=imperial
Looking at the OpenSprinkler code on GitHub, I’m just assuming this is the right place to look.
https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/weather.js
Line 46: is the API call to OW
forecastUrl = "http://api.openweathermap.org/data/2.5/forecast/daily?appid=" + OWM_API_KEY + "&units=imperial&lat=" + location[ 0 ] + "&lon=" + location[ 1 ];My call above trying to emulate the GitHub code, calls Canberra, 5 days, imperial (I used the station ID as suggested by OW)
The call returns a heap of data in 3 hourly chunks over the next 5 days.
The next step is to see how all this feeds into Zimmerman. I suspect it stores all of the above data in a buffer to compute the Zimmerman parameters but I would have thought you’d ask for actual weather. In Canberra it only rains on you if you happen to be lucky enough to be under a passing cloud.
I wish I was retired so I had time to dive deeper into this.
[UPDATE] Found this: https://www.benlcollins.com/apps-script/beginner-apis/
[UPDATE} I just noticed on the web app, left hand side menu item > ‘System Diagnostics’ when clicked opens a dialog box which states the ‘Mean Temp 17.2C’ which is the current temperature at 9:27pm.
But the high temp today was 24.6C at 4:26pm and the minimum was 8C at 7:30am which makes it 16.3C ? Perhaps it’s reading the current temperature as the average?
[UPDATE] found this https://www.w3schools.com/js/js_json_parse.asp
I thought the Zimmerman function was applied to yesterday’s average temps not the average forecast?[UPDATE 10 April] I’ve had a closer look and noticed a separate post about the API always returning mm not inches.
LINKI had a play with the OWM API’s again specifically the code line 46 above, which I can’t test as it is a paid service.
It appears this is a forecast, and the max and min temps are fed into the Zimmerman calculation at line 130.
If there is no rain at the requested OWM site the json feed excludes a rain parameter and value, returning NaN (not a number), there is a test for this at line 73 which I haven’t been able to reproduce.I found a few useful tools to look at this:
an online json viewer http://jsonviewer.stack.hu/
and the tryit javascript editor https://www.w3schools.com/js/tryit.asp?filename=tryjs_myfirst
You have to get your own APID as described above.I couldn’t get line 73 weather.precip = data.list[ 0 ].rain ? parseFloat( data.list[ 0 ].rain || 0 ) : 0;
to work in tryit Editor, I’m still working on it.Lets see what happens with the incorrect rain units…
Thank you very much for all of your research! You are exactly right it was a unit issue and also not using the best data. We have now resolved this thanks to @PeteBa’s PR. This should be out in production now.
Please let us know if you have any issues or need any assistance further debugging/exploring our code.
Thanks again!
I’m not sure, but this doesn’t look right. I noticed that under the “System Diagnostics” the “Mean Temp” is the same as the “Current Temp”. Please see the attached screen shot.
OSPI
App Version 1.8.8
Firmware: 2.1.8 (4)Update, after looking at it over a few hours and checking against other zip code weather stations, the issue is consistent.
Attachments:
- You must be logged in to reply to this topic.