- This topic has 57 replies, 15 voices, and was last updated 4 years, 11 months ago by
.
-
Posts
-
Gents,
good input from all. But none of this approaches is working for my requirements.
I’ve looked to the ESP-32 solution, but this script is also based on Zimmerman….Main concerns:
– the Zimerman method is worse in my eyes (see above comments); esp. because there is no forecast included, only based on history data (..?), also to high factors for humidity and so on.
– i don’t trust OWM
– I don’t use the ‘Weather adjustment’ in the OS version which is also based on Zimmerman. I use only the plugins on the OSPI main firmware/websiteMy requirements:
– I need a simple approach with replaces the OSPI included plugin WEATHER-BASED water level (which is based on the old WU API and therefore not working anymore)
This plugin has been running since 5 years with very good results (for my needs); not high sofisticated but reliable. It just adds a correction factor to all running main programs. This is exactly what I need..– works with the new WU API
– includes history data from own PWS to calculate the effective rain amount
– includes FORECAST (!!!) data (from WU or similar)
– so it has to be able to calculate condiditions based on 3 days history + actual day + 3 days forecast; so the basis for the adjustment will be one complete week
– adoptabe to local weather conditions (here in Germany, the average needed irrigation for my garden/grass (-> water-base in mm/day) is totally different from e.g. California)
– tuneable correction factors: includes rain (history, forecast), [humidity optional] and temperature (Max Value! not average) for the calculation, NOT more! (in my eyes, wind, shades etc. are more or without any big impacts here for me; we don’t have this extreme climate conditions here in Germany)My solution:
In the last 3 days I compiled a script in python which can be directly executed on the OSPI (or another 24*7 running server). Mainly based on a mixture of the old plugin and other stuff found on internet (got serveral good ideas from other stuff on github and this forum here/ other approaches) and enriched with own stuff (e.g. the MQTT part)The script is
– based on the new WU api (yes, only available for personal PWS users…)
– includes the publishing of all data in parallel to an MQTT broker (where the data can be analyzed or used in parallel, or the routine to push the updates per OSPI API handled by complete other systems / rule engines (e.g. pimatic, ioBroker)
– pushes the waterlevel% correction factor directly to the OSPI without any ‘man in the middle’ hardware, ESP-instances or weewx hacks…I’m just in testing phase (the script is working right now and producing correct output).
Have to tune some parts (error handling, code optimization. Afterwards I’ll publish the script if there’s interest here@fennsen Interesting approach. In regards to using forecast weather data, especially rain prediction I see some problems. I’m using Zimmerman since last year and don’t see any bigger issues. The parameters can be easily adjusted. For example I use a humidity base of 65%, which I found more suitable for German weather conditions. There is a chance of watering the garden in the morning and not taking the afternoon rainfall into account. Happened last Wednesday! But this situation is very rare and I can live with that. I see a bigger problem if rain is forecasted and never took place for consecutive days. This happened very often during our hot summer last year. With the Zimmerman Method using only historical data my garden green survived.
Nevertheless, it’s good to see some other approach and I’m well interested in your scripts.@franzstein
good point! but:
I’ve a survival strategy to avoid total dryness:My setup is as follows: 3 circuits, zone 1 for the main green and ‘uncovered’ plants (back yard), zone 2 for the less important zone (front yard, no green), zone 3 for the terasse with a micro drip system (covered area, so there isn’t any natural irrigation there)
The zone 1 is the critical one, because if there’s to much irrigation there, my grass gets like a ‘Sumpfloch’Zone 3 has to run ALWAYS, independent from weather (15 minutes in the morning); if zone 3 runs, also zone 2 runs in parallel (to avoid to high pressure on the pump/system if only the micro drip systems runs)
Solution:
If you open the OSPI-webpage and select the ‘STATIONS’ page, there is an option ‘Ignore Plugin adjustments?’
I enabled this for the zone 2 and 3, so they will always run with 100%.
(hint: I don’t use the iOS software version for settings because the plugins are not accessible from there, only the native web-page)-> Zone 1 is dependent from the weather-based adjustment, the others not.
@franzstein
In addition to this:
I’ve a rule in my central home control (pimatic) which triggers an ‘extra’ run on the OSPI via API zone call if the temperature goes above 26 degrees for one our (30 minutes) and a second one which adds one hour run time on top if temp goes above 32 degrees (as often happenend in the last year here) on late afternoon.
So: i’m on the safe side 😉
The script is still in final production test phase.. stay tuned 😉
The actual output (values calculated on 3 days hist + today + 3 days forecast) is as follows (hey joe: why should I irrigate if we have 22Liters within few days??) 😉
Waterbasis (7 days): 14.0mm
Average Temp : 13.6C
Average Humidity : 79.8%
Water needed (7 days): 6.8mm
Total rainfall : 22.0mm
——————————-
Irrigation needed : 0.0mm
Weather Adjustment : 0.0%@fennsen Very interesting. How often are you updating the watering results for OpenSprinkler? I think the ‘floating’ updates of the official OWM weather adjustments cause the problem that there are water% variations during the day.
@samer It is maybe worth to think about updating the water% only once per day, e.g. at midnight or before sunrise and only change it during the day in case of rain occurence or rain forecasts?Sorry. Just get told that there are no night and day variations anymore using the OWM weather adjustment feature. No worries!
@franzstein & all
After testing phase and final code optimization:
Here is the script for the OSPI – migrated to the new WU API and enhanced by MQTT and standalone capabilities : weather_level_adj.pySee remarks and hints in the header of the script before using.
Also included is an Excel File which shows the used parameters / calculation and provides a ‘WHAT IF’ calculation if U like to test adjustments before editing the parameters.Cheers
Migrated script – weather_level_adj.py – for new Weatherunderground API (OSPI)
Moved to seperate topic (including updated version)
- You must be logged in to reply to this topic.