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,
Shawn