OpenSprinkler Forums OpenSprinkler Unified Firmware Penmen-Monteith ETo method python script for possible use as weather script

Viewing 15 posts - 51 through 65 (of 65 total)
  • Author
  • #42778


    When I wrote the script I had no direct interaction with anything on the controller, other than sending the program update to it. To stop for rain, high wind, or freezing it would set all the starttime values to -1. This would effectively say “we need to run ‘x’ amount, but not now because of precip, wind or temp.” I would occasionally run into a situation where the ET would be just less than required to run the program when forecast precip was factored in, and cause the exact scenario you are seeing. In the long run it won’t cause any problems simply because it would subtract a small fraction of a mm from the result of the mmfromlogs, typically resulting in about a second or less difference in run times, which is lost by the granularity of the OS anyway.

    I ran for a full season and saw about 3 seconds of water time lost, due to what I assume are rounding issues in python. To be honest though I’m not sure why it is writing anything to the logs if it is less than the minRunmm value…unless maybe you have it set to 0 which I never tested.

    I’ll attach the most recent version I have of that script, I’m not sure if you are using the same one, maybe I changed something without making notes to myself. You’ll need to edit the lines with “YOUR” in them to get it working, or I suppose a simple comparison should work.

    I’m also getting the code cleaned up and doing a bit of testing on the modified firmware which means I should have a replacement for this workaround in easy to use form soon.



    Thanks Shawn. I appreciate the answer!

    It sounds like if there are no calculated watering times for the day, then there shouldn’t be data pushed for the stations. I just wanted to make sure of that, or if there was another calculation or reasoning behind it.

    Thanks for the code, I’ll look through it to see if there are any logic changes. So far the script is working well — grass is green and I have shorter, but more frequent watering.



    Okay I found out what the heck I was doing. I wrote everything after watering season here in Colorado, so I had it disable the starttimes but create the logs as though it ran to make sure it was working. If all the start times are turned off it would be easy enough to check for and clear the log, or use the logs from the controller.

    I can edit it if you need, but it seems like you have a solid grasp of how to do it as well, so just let me know.



    OK, I’m trying to get my head around this. So the logic is, if any station runtimes have been calculated to address the water balance, then times should always equal at least 1.

    Looking at the original python, the times calculation is:

    for each mmTime entry: times = int(max(min(aET / maxRunmm, 4), times)) # int(.999999) = 0
    -so for each station, take the minimum of aET / maxRunmn or 4 (since we only have 4 time slots), or if times has been previously set, then take its value.

    So should this be,

    for each mmTime entry:
    if (aET) times = 1 #run once if there is any water to distribute
    times = int(max(min(aET / maxRunmm, 4), times)) # int(.999999) = 0



    You are correct, if the balance is over the minimum it will water, if over the maximum divide watering over the available time slots until all are maxed.
    So you will only have watering times if the adjusted ET (aET) is over the minRunmm.



    @Martin – If you compile the firmware and load it, as long as you have no need for the “CA restriction,” the ui works well enough to get up and running at

    A few quirks are still present, but are pretty simple to work with. Just make sure Use ET is checked on any program you wish to use weather adjustments with. ET is the only weather algorithm, working on my site. You should enable logging, as currently it is the only way to see your current ET.

    Everything is of course use with the knowledge this is not a completely tested solution, and may have problems. If you decide to stop using it just flash back to 2.1.6.

    Hope this helps, and please be aware I don’t have a ton of free time to support any of this, so answers to questions may be really slow. I also disappear from the internet at odd times, without warning, sometimes for months.



    Thanks Shawn,

    Forgot about minimum. I can’t quite see how you disabled start time, nor do I see the actual mininum being factored in (this is your older code, the the logic is the same):

    minRunmm = (min(minmax) if len(minmax) > 0 and min(minmax) >= 0 else 5)
    maxRunmm = (max(minmax) if len(minmax) > 1 and max(minmax) >= minRunmm else 15)
    times = 0


    for x in range(len(data[‘mmTime’])):
    aET = safe_float(ET[data[‘crop’][x]] – todayRain – ymm[x] – tadjust) # tadjust is global ?
    pretimes = times
    times = int(max(min(aET / maxRunmm, 4), times)) # int(.999999) = 0

    So thinking this through logically you’d want times > 0 _if_ the aET /minRunmm > 0 so maybe:

    if (aET / minRumm > 0) times = 1;
    times = int(max(min(aET / maxRunmm, 4), times)) # int(.999999) = 0

    Make sense?



    Hi to everybody,

    I have written a c++ code that run on an ESP8266 as a OpenSprinkler master/controller !

    Hart of the code is a computation based on Penman ET method on the amount of irrigation required to be compared to the actual OS watering schedule.

    I have found this thread very interesting and I would like to discuss some of the issues I have encountered writing my code:

    First and most important getting good weather data, to be used for ET calculation, like sun radiation values that are difficult to get from WU stations. Using monthly average data as well as evaluating sun rad. from other parameters doesn’t lead to good results.
    I understand that your calculations are based on cloud coverage forecast and you derive from that the hour of sunshine value to be used in calculations.
    I think that since ET water needs are only relevant to future irrigation will be better to use actual data.

    Second is how to account of different kind of vegetation and ground coverage and seasonal as well as how to account for water runoff and percolation.

    Third have you foreseen any possibility to use local sensors?



    Hey ppbecchi,

    Firstly thanks for your interest, a lot of the script was written before I knew a lot about the OS firmware, so it may take a bit of work to use it. Secondly, a quick physics joke to help explain my background…there are a million ways to skin a cat, but a physicist will be stuck trying to prove the cat exists. Schrodinger’s cat reference, I will explain in a second. Anyway on to your questions…
    1) Data availability, ground solar radiation can be derived quite accurately, if you know location (specifically latitude), day of year, time (or longitude), and the exact amount of solar radiation lost by atmospheric scattering. The first 3 parts are easy and exact, the 4th is the joke reference. I could spend days pouring over data and never get to solve the problem, or I could make some assumptions and get a “good enough result.” So what I did was use a solar radiation meter, and some historical data, then using the 2 determined, for the sprinklers, I didn’t need to be perfect. With the method I used, I could get results withing, an few thousandths of a mm. Unless you were watering on a medium sized country wide scale you wouldn’t over or under water by enough to matter. Since a better method doesn’t exist for most I decided “good enough.” As a heads up the script will use ground solar radiation data if available.
    2) Satisfaction of variables…seasonal change is exactly what Penman and Monteith set out to account for. Their calculation uses all the appropriate data to figure water loss by plants within a normal growing set of points (ie above freezing, a certain amount of light, and wind not strong enough to remove the plant being observed). Next, vegetation type, for sprinklers I reduced the data set to above and below 4 inches, trees once greater than sapling are essentially self sustaining. All grasses, under 4 inches use or lose about the same amount of water. Most leafy shrubs, flowers and grasses above 4 inches do the same. Again I had to pick a solvable problem that would satisfy the majority of cases. If a plant/grass is not getting enough or too much water the base times can be adjusted to account for this. I used this point after a lot of research into calculated constants. Above an below this mark, there is so little change it would never be noticed, in a standard residential watering system. Soil drainage and absorption, was a bit trickier. I tried so many different runs at this problem my head still hurts a year later thinking about it. For this the end user has to adjust the number of cycles, and base times. Otherwise the program will not fit on the controller, there are simply too many scenarios to include them all. I hope you understand. The coverage area is the responsibility of the end user, as there is simply no way for me to know this. It can be calculated with area divided by flow rate, or a quick measurement of precipitation from the sprinklers.
    3) Local or personal data is baked in to the script, just point to your data uploaded to WU, or have your weather station output a json similar to the WU setup and it will work. I can not possibly be asked how to do this for everyone’s individual setup, as I would spend a lifetime helping everyone with every station while I remained unpaid for my services. You will find yourself in the same scenario if you choose to explore this route with your setup.

    In conclusion, I made reasonable and educated assumptions where it would satisfy the majority of cases. And I excluded the notion of satisfying every individual setup, for the sake of my sanity. Essentially my script works well for myself and most cases, it will not work perfectly for every outlier. The beauty of open-source is exactly this, if you don’t like it or it didn’t work for you, observe, learn, correct and improve it. Then give your time back to those you drew information from.

    Hope that helps,



    Hi Shawn

    thank’s for your immediate and comprehensive answer.
    Since you have been very detailed your explanations , I would like to describe to you what I have done in my code , hoping to get some advice and suggestions.
    I have started last year to try to automatize my garden irrigation system consisting in several units about 100mt away from my home.
    I was thinking to use Arduinos that I normally use and program. Then I discovered ESP8266 and OpenSprinkler and I understood that porting OpenSprinkler to ESP8266 was the way to go! I have completed the porting 3-4 month ago and I have now 5 units running 24h a day.
    But I am missing a tool to manage those units (checking status and functions of the units and regulate intervals depending on weather).
    I started that my OpenSprikler Manager that will be ready for first upload to GitHub soon. The code measure the water flow from the main supply valve and is WiFi connected to all the units, with Api calls. This way if the flow for a certain interval is not correct will warn that the unit or the irrigation devices are not working correctly.
    Coming to the weather controls routines ….I am reading WU json /conditions/pws:XXXXXX output and recording temperatures,humidity,wind,rain and sun radiation.
    I have followed tightly the Allen-Pereira :Crop evapotranspiration – Guidelines for computing crop water requirements – FAO Irrigation and drainage paper 56. It provide all needed info to compute irrigation needs. A comprehensive database is included of different crop behaviours and assumptions to be taken.
    According to the above I have evaluated actual daily ET0 and used Kc parameters for the areas with different (from grass) vegetations.
    The ET0 equations are straight forward…. but measured sunrad is sometime unreliable…therefore I have corrected the reading if are very far from clear sky radiation . This lead to good result that shown daily values ranging fro 1.9 to 4.5 ( I live in Italy!).
    I was thinking anyhow to get some local measurement to verify those values or using a solar panel or using the “pan evaporation” method applied to my swimming pool.
    Those calculations are used to draw a water balance versus time plot of the different zone so that water shortages can be easily seen and corrected .
    The programs correction can be done automatically , but I prefer supervision and manual controls of the units ( at least at this time!).

    I look forwards to your welcome comments




    Solar radiation will always be the most difficult data to acquire. Firstly, the equipment to measure it correctly and accurately is expensive. You can pick up cheaper units that will swing wildly throughout the day, and may end up providing useless data. The other way to get the data is mathematical deviations from a normal, or mean/average. You can use a small solar panel with a good specification and decay rate for watts/meter over time. Then infer solar radiation using charge rate.

    The solar panel, or photovoltaic cell method is what most home based weather stations use. So you will only receive data as good as their calculation. I say do that part yourself, then you can tailor the calculations and assumptions to your specific needs. As far as working out the solar radiation, most of the methods are available online, and I encourage you to research which would provide exactly what you are looking for. Once you’ve found what you want to use I will be more than happy to help you with the calculations.

    The biggest piece of advice I have is really think about how accurate you need to be. Remember, keep it simple, you’ll have much less headache, and an easier to use product. Grass is quite forgiving, it didn’t always have people around to help it grow 😀 Mine probably hates me because I’m always testing on it.

    I honestly think you have gone much more into detail than I ever worried about. A lot of people will never understand the magic part of the code in the little box, they just want it to water, and keep things alive. You have done quite a bit of work and it shows, keep it up, I look forward to seeing what you are able to achieve.



    Thanks again for the speedy answer:

    You can use a small solar panel with a good specification and decay rate for watts/meter over time. Then infer solar radiation using charge rate.

    That exactely the way I want to do it:

    I have an Arduino connected to Solar Panels that measure the KWHour produced: it is enough to use in ET0 formulas the ratio between max daily power to the actual one.

    I will also try the PAN EVAPORATION method applied to Swimming Pool!

    I will tell you the results!




    I am back with some encouraging results!

    This is what I have done:
    -I have solar panels in the roof of my house and an Arduino measure the KWh produced
    -I have a swimming pool of 95 m2 and with expansion tank of 8 m2.

    -I have a ESP8266 connected to an ultrasonic meter HC SR04 that:
    measure the level of the expansion tank
    get temp, humidity wind and solar radiation from 2 WeatherUnderground stations.
    get KWh produced from home solar panels
    calculate hourly ET0 with WU solar radiation and with solar radiation derived from Solar Panel
    all data are recorded every 5 min. in a log file (in json format)

    Results shows good agreement (in a stable weather day) between Solar panels and WU solar radiation data.
    There is also a good correlation between the daily pool level change and daily ET0 values.

    If anybody is interested I can provide log file printouts in Json format and additional details.

    The code of this ESP8266 “Pool, Weather and ET0 logging station” will be on github soon.





    In Europe at least, seems to be quite popular. Most of the weather stations have also solar radiation data. There is also information about the make and model of the particular weather station. The only problem is that there’s no API (or at least I couldn’t find one). Anyway, one of the graphs displays the selected weather data in a rolling 24 hour period, which is quite convenient for calculating and comparing the ET values.




    I have finally uploaded to OpenSensor that run on ESP8266 .
    The code compute hourly ET0 based on data from nearby WU meteo station and use solar radiation from another station 40Km away. The ET0 are also computed from my house solar panels. Both value are very similar and correlate quite well.
    The code read also the rainfall and can directely control OpenSprinkler water delay.
    I use it now since 4 month with good results.
    If you want more info on the code visit or the topic

Viewing 15 posts - 51 through 65 (of 65 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Penmen-Monteith ETo method python script for possible use as weather script