Add ETo calculation

[Derpthemeus]

The main feature of this PR is the addition of the ETo watering adjustment method. This method itself is pretty primitive, and it just compares the current ETo to a baseline ETo to determine how to scale the watering. A more sophisticated version should eventually be created that considers the crop coefficients and watering rate to determine exactly how much water the zone needs, but this current version is very convenient because it can easily replace the Zimmerman method without requiring any additional data provided by the user (once automatic base ETo calculation is completed). Note that the only WeatherProvider currently supported by this adjustment method is Dark Sky, and we still need to resolve the Dark Sky attribution issue before we can use that in production.

ETo scaling has been added as adjustment method 3 and accepts 2 optional adjustment options:

• elevation is the watering site elevation (in meters feet) and defaults to 150 meters if not set. This value seemed like a reasonable default and should not matter too much since it does not have a very significant impact on the end result.
• baseETo is the average daily ETo of the watering site (in millimeters inchest per day) and defaults to 2 mm/day if not set. This default value was chosen arbitrarily and should be specified by the user if they want to ensure the calculated watering percentage will be accurate. Since the accuracy of this value is very important and it may be too much work for some users to calculate it themselves, I'm working on an update that will automatically choose a more reasonable default based on their location. The names and units of both of these parameters can be changed if necessary. In a similar vein, I'd like some feedback on which values should be included in the rawData property returned by the server, what their names should be, and what units they should use.

This PR also refactors the way that the watering scale is calculated so that each adjustment method's individual logic is more isolated. This should allow us to add new adjustment methods or modify existing methods with less risk of interfering with another method's behavior and makes the logic flow of each method easier to understand. This change can be split into its own PR if necessary, but this felt like a good time to add it since adding the ETo adjustment method required adding even more method-specific handling to weather.ts. Although most of the changes in this update shouldn't affect the data returned by the server, there are a few potentially breaking changes:

• Less raw data is returned by adjustment methods if watering is delayed due to rain.
• Attempting to use an invalid adjustment method will now error instead of defaulting to the rain delay method.

[Derpthemeus]

This will have to be updated to reflect the changes in #53 before it is ready to merge Resolved

[PeteBa]

A few additional thoughts (that may be separate PRs but wanted to capture):

0) Seperate PR, we should extend OWM and Local to support ETo

1) I think WateringData should be extended to include ETo requirements (excluding lat, dayOfYear as parametrs to calcETo...). So Weather Providers and Adjusment Methods can be agnostic of each other. e.g. calculateEToWateringScale should not need to call WeatherProvider.getETOData(). But we should have some logic in Weather.ts to determine whether a Weather Provider supports a particular Adjustment Option and, ultimately, UI should include validation code to ensure we can only setup the right combinations.

2) I think we should raise exceptions in Weather Providers and Adjustment Options rather than returning "undefined" or "100%". We cannot be certain of the error cause nor whether the integrity of any data has been compromised. Firmware should manage fallback in a consistent manner (currently it reverts to last know good value). Superseded by issue #54

3) I think we should "omit" returning values rather than returning "-1". I am not sure why either of ManualWatering nor RainDelay should modify scale. At the moment Firmware doesn't differentiate between "-1" and omitted.

4) Would it be better to treat raining as an "override" (like california restriction) rather than part of Zimmerman/ETo Adjustment Method. My thinking is that this would be consistent with a physical Rain Sensor that "overrides" watering programmes. So if METHOD > MANUAL and raining == true then scale = 0 as a final check. This would make it easier to leverage the calculateAdjustment() routines, for example, it would be cool to provide "forecast" Eto and Zimmerman scale as part of the getWeatherData() so App can include in the weather outlook popup.

[rmloeb]

What/whose ETo formula are you using? Mostly just curious, because I've looked at several of them and the necessary data wasn't readily available. I'm a bit uncomfortable with historical data, primarily because the weather in my area is highly variable. (OWM consistently forecasts daily temperatures that are absurdly high, at least for this year.) ETo is probably more consistent because temperature is such a major factor.

I note that the one calculator I found on Github (at https://github.com/davemiedema/envirotranspiration ) utilizes a local file to retain observation data and uses WU data. Thus far your (collective) effort has avoided any data persistence. Would having persistence change your approach to any of the other services? Example: the current Zimmerman calculation depends upon data elements that are retained in memory. One consequence is that if the weather-server is stopped and restarted, then the current and next day's Z calculation will be based on incomplete data.

[Derpthemeus]

@rmloeb It uses the Penman-Monteith FAO-56 method. Data currently comes from Dark Sky and we'll be looking at adding support for OWM too.

[rmloeb]

Thank you. If local data is available, will you use it? In particular, if local solar radiation is available, will you use it in place of the estimate derived from location and day-of-the-year? Using local data factors in cloud cover. Similarly, both local humidity and wind speed are essential factors. Just curious. Any ETo estimate is likely to be better than Zimmerman.

[rmloeb]

Added thought: one of the limitations of the Zimmerman method is that neither OS or weather-server provide a mechanism to accumulate water deficiency, i.e., we water the lawn at intervals of 2, 2, and 3 days; the amount of water necessary to maintain the lawn consequently varies with the interval. (We water on a weekly schedule because we need the predictability so the person who mows the lawn isn't dealing with wet grass.) ETo would be a more accurate calculation of water deficit and I would be interested in accumulating that deficit and driving water level from the accumulated value. This changes the meaning of the values supplied as baseline for Zimmerman. The user needs to provide some value for how much net water they want to actually be applied, although I'm not sure how they derive that. Then the calculation involves the number of days since the last watering cycle and an ETo factor (or amount). (The time of day that water is applied is also relevant; we water starting around 3 a.m. to minimize the evapotranspiration. I don't know whether there are water districts where the time-of-day is mandated...)

[Derpthemeus]

We hope to eventually setup a full water balancing system that tracks the ETo, precipitation, and watering each day to determine exactly what the water deficiency is and water accordingly. However, doing this will require some pretty extensive changes, so we're using this basic percentage scaling method as a stepping stone.

[rmloeb]

Good answer. I agree with the strategy. Built a lot of big systems in my day. Every one of them started out small and magically grew :-)

[Derpthemeus]

This PR is being closed and will instead be split into several smaller PRs that are easier to work with. There are a few changes in here that aren't directly related to ETo and a few additional changes we need to make before we're ready to add ETo support, and this should go a lot smoother if we make those changes individually rather than all together in a single bloated PR.