Forum Replies Created
-
Posts
-
Maybe an approach for you:
Install the alternative firmware (‘SIP’) if you have the Opensprinkler board on top of a normal Raspberry.
,,This is an updated version of the Python Interval Program for OpenSprinkler”
see https://github.com/Dan-in-CA/SIPWorking flawless since 5 years here and has IMHO much more flexibility as the unified firmware.
In this firmware You can add my plugin (see seperate topic with the updates) and everything works again with wunderground.Sorry to spent some confusion here.
I realized that this is the wrong forum, as the script is for the alternate Firmware called ‘SIP’ from Dan-in-CA/SIP which is a fork of the OSPI firmware
https://github.com/Dan-in-CA/SIP
I leave it here; maybe useful for someone who likes to adopt the approachCheers
Update: Version 1.2 attached
# Change log
# Version 1.1
# Added description and installation documentation
# NEW Probability factor – how the sum of forecasted rain from WU is used in calculation – included as config-parameter
# Version 1.2
# NEW consistency check on reported history rain amount. value must not be higher than e.g. 120mm (after my PWS reported 2540mm rain today and this shi* was returned by WU history! I always thought that wrong data feeds is filtered by WU.. (WTF…)
#For all who has the OSPI version – this might help:
Migrated script – weather_level_adj.py – for new Weatherunderground API (OSPI)
Migrated script – weather_level_adj.py – for new Weatherunderground API (OSPI)
Moved to seperate topic (including updated version)What do U mean with ,,..can’t be included into OSPI main code”?
This script is intendet to be included into the main code (if you mean the python version of the program, not the microcode version). It replaces 1:1 the existing plugin (in the OSPI version). You don’t need any coding skills for this, only basic linux skills (copy a file, change file permissions(set executable bit with chmod).
See also the comments in the script header for further & detailed information and setup documentationRegarding forecast:
– In the script, forecast summary (3 days) of rain will be rated with a probability of 50 percent as defaultYes, you can ‘disable’ the forecast function as follows (See lines 246 in the code):
rain_mm = rain_hist + (rain_fc * float(0.5))
If you change the factor from 0.5 (which means 50% propability of the sum of rain forecast) to a lower value (e.g. 0.1 = 10%) or to zero (which will complete disable the consideration of forecasted rain).But good hint; in the next version I’ll include this factor as a configuration-parameter in the header.
@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
@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%@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.
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@franzstein
thanks for the feedback and hints. Seems that Node MCU / a normal ESP8266 doesn’t have a RTC (only software emulated). Then it’s clear that the statement runs into errors.Which means that I’ve to order this ESP32 module… sig…
After downloading the ESP32 board definitions and used the ‘ESP32 Wrover Module’ as board for a test run, compiling suceeded without any errors! GBY… 🙂
The second issue while compiling before was also related to that:
,,OS_WU_WeatherService_V2:121:26: error: ‘esp_deep_sleep_start’ was not declared in this scope”
After reading the article about deep sleep on ESP32 it’s clear that this must be included in the ESP32 board definitions. Hey joe 😉Furthermore it also resolved the issue with errors from
#include <WiFi.h>
#include <HTTPClient.h>(as idiot…) I tried to use
#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>Just for information to others who might also struggle with this.
enyou your vacation! Will come with an update when the module arrives and set up…
@franzstein
I agree with your wish to ‘only’ adopt the weather-adjustment plugin to the new API structure, but also struggeling with coding skills. BTW: the new API is based on JSON data returns, the old one (or the plugin) uses XML structures which drives things for me not easier trying to ‘rewrite’ the code.Nevertheless: I tried your ESP8266 solution but struggled to compile the code. An error occurs within the “RTC_DATA_ATTR int raindelayCount = 0;” data definitions. I tried to include the RTC libraries in Arduino IDE but without success. My platform would be an ESP8266 NodeMCU 1.0 (ESP-12E) module. Do U use a special ESP module here which has other RTC capabilities or definitions?
@samer
Thanks for the hint. moving to github now..
pre-requisites are given (more than 1 24/7 server and different raspi’s for weewx, ospi, home-automation…
Cheers@samer
Hi, is there any progress with this locally service solution from @PeteBa or additional information/doc?
I tried to migrate the existing script to the new WU API structure but struggled (as I’m not a programmer).Thanks in advice!
