@BinaryOS, did you take a look at this version of the OS Weather Service OS GitHub PR. It lets you send your local PWS data to a local version of the OS weather service without requiring WeeWX. It takes the PWS data and uses the same weather underground logic as before with the exception that it also replaces (Low-High)/2 with an average across all data points for a slightly more accurate calculation. I would suggest this is the simplest way of moving to a local solution if you have a PWS that generates WU format stream.
I do see some more advanced options that come available by introducing WeeWX into the equation. Namely, you could create a WeeWX Custom Report that calls the OpenSprinker API on an hourly basis to set the manual watering level. That way you wouldn’t need the OS weather service at all and could create whatever calculation method you wanted (e.g. ET based). Looks as though you need to know a bit about python to make this work but their architecture seems to support it. Have you looked into this ?
@paravis, I think the first option I mention above would work for a Meteobridge setup as I see that MB provides the ability to send data to other servers (RESTfull endpoints) in a format of your choosing. Add a post here if interested and I would be happy to help try and get it up and running.
I guess this is really off-topic now as the OP was all about improving the OWM logic. I think this is challenging as OWM does not provide historic data unless the OS guys stump up c.$1000/month which would be a tall ask or radically change their software to build up history over time for every OS weather service user which probably violates OWM T&Cs. At the end of the day, this was down to WU changing their API / Business Model and I can understand if the OS guys want to avoid having to continually chase changes in 3rd Party interfaces. Weather service providers seem so volatile at this stage.