- This topic has 11 replies, 7 voices, and was last updated 9 years, 9 months ago by
.
-
Posts
-
I personally feel that 4% for each Farheneit is too much of a reduction in water flow.
Would there be any possibility that this parameter be set on my OS interface and be used in the computation instead of the fixed 4% ?
Thanks a lot
I agree with rjalex comment. I’ve had to modify the OS code down to 2% for each degree F, and prefer that. My last smart commercial irrigation controller used the predicted high temp and 1% for each degree F. The Zimmerman algorithm uses the MEAN/Average (not MAX) temperature and 4%. It seems to work pretty well with 2% on the mean temperature. I do believe it would be great if we could plug in scale factors for each weather parameter to adjust watering. The OS does get a few of the parameters, then you can code your own based on those parameters, but again it would be nice to have more flexibility on the OS to allow the user to configure it.
The zimmerman algorithm takes into account only one days data point for temp and humidity even though most people don’t water every day (i.e. water every 2nd or 3rd day). Uses average humidity, temp from previous day and precip from yesterday and today. Highly recommend we take into account (or have the option of) humidity, precip. and temp for yesterday, today and tomorrow with a percent chance of rain % threshold to not water for today and tomorrow (forecast).
So having each parameter roll over 3 days for example, with a baseline for each (like 80F or 70F) and a multiplier like 4% or in our case 2% for each degree F would support more customization and more accurate & water savings.
FYI wunderground kept returning summary data for MEAN temp incorrectly that OS was using (it appeared to return MIN temperature instead of MEAN temperature). I contacted wunderground via email and a few days later it seems to have stopped doing that. Not sure if anyone else observed this a few weeks ago, but having the MIN temperature for the MEAN, and having 4% scaling factor, it would get to 80F outside and decide almost not water because the low was 55 at night.
We did think about allowing some parameters to be changed and there is no technical barrier to implement this. On the other hand, we also want to be cautious exposing these parameters to average users, who may not want to see these options. Anyways, for the sake of getting started, are there any other parameters of the Zimmerman method that you’d like to be able to adjust?
We are also working towards adding the California watering restriction, and working out ET based weather algorithm (which hopefully will become the default algorithm to use once it’s done).
What follows is only my personal opinion of course 🙂
Re the current Zimmerman algorithm I’d like to be able to change the % factors (4 per Farhe and 1 per deg mean hum) and also the thresholds (70F for temp and 30% for hum). I live in a coastal town and the current computed values are way too low since the average hum is always VERY high.
Also empirically I believe the average (?) wind speed could be usefully benefit in the simple algorithm since windy days tend to dry the plants.
ET would be far more sophisticated probably. But the simpler algo with modifiable parameters would be very good I think.
Are you looking at this ? http://en.wikipedia.org/wiki/Penman–Monteith_equation
The only problem I see is the relative scarcity of meteostations which give radiation values (my neighbour’s station I use has it luckily) and the fact that for instance a lot of my little garden gets the shadow of buildings and one large tree and therefore the radiance factor in ET would be almost totally useless.
Thanks so much for making OS more and more of a GREAT BEAUTIFUL USEFUL tool !
I would also like to be able to change/add an option to this. The Zimmerman method uses mean temperature to control watering. Here in IN, the outside temp is only 65F and the program is already calling for water. I think it is too cold to be using the sprinklers right now.
Is it possible to implement an option that doesnt start watering until a certain temp is reached?
According to the Zimmerman algorithm:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099525/articles/5000017312-using-weather-adjustments
70F is used as the reference temperature (i.e. temperature above that will result in more watering and temperature below that will result in less watering). Because the algorithm calculates a watering percentage, it will go smoothly to 0 as temperature lowers.I am trying to think how to balance customization need vs. simplicity. As is, you can always customize the weather script (which is written in Python) and host it on your own server. This way you have complete control over how you’d like to implement the rules. However, this will be a technical barrier for average users. I think it should be possible to support a per-user, customizable script stored on the cloud server. Users can modify the script according to their own need (and we can provide a few default ones). This will provide the most flexibility.
Those of us who have OSPi, especially powered by Pi version 2, probably have the CPU and storage to save the script locally and run the algorithm autonomously.
Could you…
- Include a check for Raspian (or PiV2 if the A & B+ are underpowered), and if present…
- Present options in the advanced section to …
- Store the Zimmerman (or later ET) variables locally and …
- Then modify the Zimmerman (or later ET) perimeters.
This would allow users to continue to function if your site went off line. It would give us the option to alter the weather algorithm’s variables, or not. As more people used stronger processors, the amount of user variables stored on your server would decrease.
Ray I like your idea but I think that in my case it wouldn’t work.
My OS (not OSPI) sits in my garden and is connected via WiFi but the wireless stage of my home router is turned off for most of the day (for health precautions reasons as I have little ones in the house) and is turned on only to check/modify the OS station.
So in my case I guess I’m back to square one and will not be able to use the weather modification unless the computing was done on the Arduino.
Thank you so much.
Hi Ray, excellent idea about having your server host the custom scripts for weather adjustment. Perhaps some would use your Zimmerman default, some would design their own, and others might see a custom script they would like to use (in case they don’t want to design their own). Then you could have a list of the custom ones people submitted and see if others want to use those or modify for their own needs? If you could host the script I’d like to write one that takes into account the day before, the day of, and the day after for humidity, temperature, rainfall, etc. I looked at ET and it seemed quite complex and I’m thinking all that people need is a relative change of watering based on those 3 parameters typically (humidity, temp and rainfall, actual and forecast).
rjalex – perhaps you could modify your OS to check at a certain time of the day only when your wifi is on and remember that watering % for the whole day. Also having tomorrow’s forecast might be of benefit to you even more since you would only be checking the weather once a day instead of throughout the day. (i.e. if no rainfall yesterday or today yet, but it’s going to rain tonight or tomorrow you wouldn’t probably want to water anyway).
@rjalex: if your OS is not connected to the Internet most of the time, the weather feature would not work at all, less to say varying the parameters. The weather feature requires querying the cloud server for weather data. So without Internet connection it won’t work.
Maybe you can use a download tool like FlashGet which support resuming download if it gets disconnected for any reason.
Also, in case you are using Windows, be sure to use a third-party unzip tool, like 7-zip or WinRAR. Do NOT use Windows’s build-in unzip tool because it’s a piece of crap and cannot handle large files.
I second this idea. The baseline values and factors probably work well only for certain climates, and won’t be correct for most users. It’d be great to have the script integrated into the local OsPI firmware (I actually was surprised not to find it there). I mean, even an early Raspberry Pi has the power to run a short python script before calculating the water cycle. For me, that would be enough as I then could alter the values in the python script itself. I wouldn’t mind doing that in imperial units.
Edit: I think landscaping experts agree that you shouldn’t water your garden a bit every day as the water then has no chance to reach the roots. It’s better to water only once or twice a week, but then thoroughly. In summer I usually water twice a week for one hour per zone. If this scheme is used, then the weather algorithm has to consider the weather of the past week and average it out to produce usable results.
Sincerely,
Michael
- You must be logged in to reply to this topic.