I looked hard at this approach myself, because as you say it is the one most commonly used by commercial irrigation solutions.
What stopped me was the difficulty in getting accurate ET data. According to the Texas A&M site and papers, they stated that you had to have a soil moisture reader and solar radiation sensor to generate accurate ET values. This stopped me because neither are commonly returned values from Wunderground and aren’t common on most home weather stations. But, there is a Texas A&M official ET station about 35mi from my house that could be leveraged. I figured once I had the more traditional system done I would return to this ET-based idea and see what I could do.
I like your simulation and it makes me want to run the numbers and compare that to the more simplistic system I have come up with with in order to determine how much water would actually be used with each. I’m going to see how difficult that would be to add.
As for adding it to OSPi – I think I can see a way. You would have to collect the zone-specific data similar to what I have done that includes irrigation capacity, water needs, run-off limit, etc. Then you would have to model the individual zone needs, adjusting for the weather data. When it is time to water you program the OSPi model directly by setting gv.rs[zone] for a given amount of time respecting any filters (such as limited days, limited hours, run-off limits, soak time, etc.) Soak time is an interesting filter, by the way, one that fits relatively well within the current model.
I’d probably do something like wake up a thread every hour and run through all the checks/filters for each zone, and water if needed/allowed.