Evapotranspiration widget
Moderators: leecollings, remb0
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Evapotranspiration widget
Domoticz features, among many others, leafwetness, soil moisture widgets. I would be great to have an evapotranspiration widget as well (measurement unit mm). Why it is so important: https://extensionaus.com.au/irrigatinga ... igations/
Do you support this request?
Thank you
Do you support this request?
Thank you
Debian buster on NUC and three RPi with buster.
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Re: Evapotranspiration widget
Almost same widget as Rain, without rate data and a new icon
Debian buster on NUC and three RPi with buster.
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
ET is a very local value, like all meteo-info!
Perhaps the visual layout for an ET-widget might be similar to Rain, Moisture or Leafwetness, but the background and required effort is different.
ET usually is calculated only once per day at the end of the day, based om the accumulated meteo-data over that day.
Not without reason, because quite some calculation effort for the Meteo-software (if taking into account all aspects).
IMHO, performing your own, complete, local ET-calculation therefore is something for brave people!
If you have 'real' Meteo-software, it is possible that such software already can export the ET-value.
Or could you read the ET-value from neighbour's configuration?
Perhaps the visual layout for an ET-widget might be similar to Rain, Moisture or Leafwetness, but the background and required effort is different.
ET usually is calculated only once per day at the end of the day, based om the accumulated meteo-data over that day.
Not without reason, because quite some calculation effort for the Meteo-software (if taking into account all aspects).
IMHO, performing your own, complete, local ET-calculation therefore is something for brave people!
If you have 'real' Meteo-software, it is possible that such software already can export the ET-value.
Or could you read the ET-value from neighbour's configuration?
Last edited by Toulon7559 on Wednesday 17 November 2021 15:40, edited 2 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Re: Evapotranspiration widget
As a matter of fact I have a Davis Pro 2 including solar radiation sensor, so I get the value straight away. This is a very interesting information, especially nowdays where there is a clear rise in temperature, and less rain. I'd love to a have a widget for that. For the time being I'm using leaf wetness, which is not very satisfactory. Sent to influxdb and displayed by grafana. A must have!
Debian buster on NUC and three RPi with buster.
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
@Number8
Hello meteo-friend!
Unfortunately for my location in a suburban area not so 'effective' to have a Davis Vantage.
Application of PWSes TFA_Nexus + LaCrosse WS7000 (expanded with all kinds of devices controlled by Domoticz).
Both PWSes directly feed to WsWin-software, and that software calculates ET etc. from their data-inventory.
WsWin-software also can generate an XML-file including ET_Day, ET_Month, ET_Year, Rain_ToDay, Rain_Week, Rain_Month and Rain_Year (and much more). Other meteo-software has comparable generation & export-functions.
E.g. many meteo-programs can generate clientraw.txt, but I have no experience (yet) in extracting data from that file-format towards Domoticz.
When your software has such capability, the solution is rather simple (although not said that it is quick & easy!):
1. Get the XML-file (or other textfile-format) from the meteo-software.
2. With a script (using Python, lua or dzVents) you can extract (by detection of defined header&tail text-strings) the desired string from the file
3. Extracted string + processing => data to Domoticz' Virtual Device => Widget!
Because ET is only calculated at the end of the day, I myself stopped after stage 2.
Having the extracted string from the XML-file, no conversion to data, but put that string in a txt-file which is in the righthand side-window at my website at http://www.vannwnhzn.nl/PV_Meteo.html#31
['Neerslag' is dutch for precipitation]
On my ToDo-list to make data-extraction from the extracted textstring, in order to feed database-applications, to make nice graphs, etc.
Hello meteo-friend!
Unfortunately for my location in a suburban area not so 'effective' to have a Davis Vantage.
Application of PWSes TFA_Nexus + LaCrosse WS7000 (expanded with all kinds of devices controlled by Domoticz).
Both PWSes directly feed to WsWin-software, and that software calculates ET etc. from their data-inventory.
WsWin-software also can generate an XML-file including ET_Day, ET_Month, ET_Year, Rain_ToDay, Rain_Week, Rain_Month and Rain_Year (and much more). Other meteo-software has comparable generation & export-functions.
E.g. many meteo-programs can generate clientraw.txt, but I have no experience (yet) in extracting data from that file-format towards Domoticz.
When your software has such capability, the solution is rather simple (although not said that it is quick & easy!):
1. Get the XML-file (or other textfile-format) from the meteo-software.
2. With a script (using Python, lua or dzVents) you can extract (by detection of defined header&tail text-strings) the desired string from the file
3. Extracted string + processing => data to Domoticz' Virtual Device => Widget!
Because ET is only calculated at the end of the day, I myself stopped after stage 2.
Having the extracted string from the XML-file, no conversion to data, but put that string in a txt-file which is in the righthand side-window at my website at http://www.vannwnhzn.nl/PV_Meteo.html#31
['Neerslag' is dutch for precipitation]
On my ToDo-list to make data-extraction from the extracted textstring, in order to feed database-applications, to make nice graphs, etc.
Last edited by Toulon7559 on Monday 01 June 2020 9:19, edited 4 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 85
- Joined: Thursday 12 May 2016 15:47
- Target OS: Linux
- Domoticz version: 11838
- Location: South of France
- Contact:
Re: Evapotranspiration widget
I'm calculating ET from meteo values for watering my garden. I successful store the result in a dummy rain sensor, it does the job quite well
Envoyé de mon moto g(6) en utilisant Tapatalk
Envoyé de mon moto g(6) en utilisant Tapatalk
Last edited by aleph0 on Monday 01 June 2020 9:28, edited 1 time in total.
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
Have been looking at http://www.fao.org/tempref/SD/Reserved/ ... per_56.pdf
Got tip to look in Github to: https://github.com/allanglen/evapotrans-php
That PHP-script looks most useful, with limited, simple inputs, but stuck at implementation, lacking experience in PHP.
Comparison of the numbers for Precipitation and ET is easy enough, but looking at use for my garden the question is what info to take from the FAO-document (or elsewhere) for application or decision-making.
@aleph0
Could you make your script available?
Got tip to look in Github to: https://github.com/allanglen/evapotrans-php
That PHP-script looks most useful, with limited, simple inputs, but stuck at implementation, lacking experience in PHP.
Comparison of the numbers for Precipitation and ET is easy enough, but looking at use for my garden the question is what info to take from the FAO-document (or elsewhere) for application or decision-making.
@aleph0
Could you make your script available?
Last edited by Toulon7559 on Tuesday 02 June 2020 10:17, edited 3 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 22
- Joined: Sunday 03 May 2020 7:33
- Target OS: Raspberry Pi / ODroid
- Domoticz version: 2020.2
- Location: Netherlands
- Contact:
Re: Evapotranspiration widget
Evapotranpiration is a combination of plant transpiration( active plants transpirate water) and evaporation. There are more ET calculations ( like Makkink, Hargreaves-Samansin). You always need at least a temperature and a radiation figure.
The ET is calculated per 5 minutes and the day sum can be used for irrigation calculations. When the ET is higher than the precipitation you will face a water shortage in the soil, but how to handle with an irrigation system depends of soil moisture (VWC%), the type of crop and the type soil. See this link for turfgrass: https://aces.nmsu.edu/pubs/_circulars/CR660.pdf
The Davis weather station with solar sensor calculate the ET. I use this type of weather station now for more that 18 years. In combination with a Meteobridge it is easy to make an XML or Json file with a 5 minute upload. See here an example I use (thanks to the great help in this forum)
The ET is calculated per 5 minutes and the day sum can be used for irrigation calculations. When the ET is higher than the precipitation you will face a water shortage in the soil, but how to handle with an irrigation system depends of soil moisture (VWC%), the type of crop and the type soil. See this link for turfgrass: https://aces.nmsu.edu/pubs/_circulars/CR660.pdf
The Davis weather station with solar sensor calculate the ET. I use this type of weather station now for more that 18 years. In combination with a Meteobridge it is easy to make an XML or Json file with a 5 minute upload. See here an example I use (thanks to the great help in this forum)
- Spoiler: show
Davis Vantage Pro2 special, Meteobridge, Leuven HWS-template, TTN gateway, home made TTN nodes, Dragino LSE01soil moisture node, Dragino LHT65 node
-
- Posts: 85
- Joined: Thursday 12 May 2016 15:47
- Target OS: Linux
- Domoticz version: 11838
- Location: South of France
- Contact:
Re: Evapotranspiration widget
Here is my script to calculate EVP based on weather sensors. Calculations are from Penman Monteith formula and FAO-56 method (http://edis.ifas.ufl.edu/pdffiles/ae/ae45900.pdf). The code below is an extraction from my global watering script, so maybe I introduced some syntax bug on the process. If you notice any, let me know I'll correct them.
For solar irradiance, I don't have a sensor so I'm using estimation from this script, but it works rather well
Code: Select all
-- Script to estimate potential evapotranspiration according to Penman Monteith formula and FAO-56 method
-- Weather sensors for EVP
local dev_THB="Conditions extérieures" -- Outside temperature (°C), relative humidity (%) and Atmospheric pressure (hPa)
local dev_Rn= "Lux" -- Global sun radiation (lux)
local cst_G = 0 -- Thermal flux to the ground (MJ/h/m²)
local dev_U = "Vent" -- Wind speed
local cst_h = 5 -- height of wind speed mesurement (m)
-- EVP sensor (must be of type rain sensor)
local dev_EVP="EVP"
local debug=false
local frequency_EVP=1 -- script runs every 1 min with local wind meter; can be slowed down to 1h with stabile wind measurements
function UpdateDev(device,nvalue,svalues)
-- Update a domoticz device
if device~=nil then
commandArray[#commandArray+1] = {['UpdateDevice'] = otherdevices_idx[device]..'|'..tostring(nvalue)..'|'..tostring(svalues)}
end
end
commandArray = {}
time = os.date("*t")
if (time.min % frequency_EVP)==0 then -- Run every "frequency_EVP" minutes.
--Constants
Cn=37 --Hourly steps...
if (timeofday['Daytime']) then
Cd=0.24 --at day and 0.96 at night !!
else
Cd=0.96
end
if debug then print("Cd="..tostring(Cd)) end
-- reading of sensors
P =otherdevices_barometer[dev_THB] -- hPa
T =otherdevices_temperature[dev_THB] -- °C
Hr=otherdevices_humidity[dev_THB] -- %
Rn=otherdevices_svalues[dev_Rn]*0.0079 -- W/m²
U2=otherdevices_windspeed[dev_U] -- m/s
if debug then
print("Pressure "..tostring(P).." hPa")
print("Temperature "..tostring(T).." °C")
print("Relative humidity "..tostring(Hr).." %")
print("Solar irradiance "..tostring(Rn).." W/m²")
print("Wind speed "..tostring(U2*3.6).." km/h") -- Wind speed is internally stored in m/s
end
-- unit convertions
P=P/10 -- must be in kPa
Hr=Hr/100
Rn=Rn/277.77778 -- must be in MJ/h/m²
U2=U2*4.87/math.log(67.8*cst_h-5.42) -- windspeed at 2m height, in m/s
-- Intermediates calculations
Esat=0.6108*math.exp(17.27*T/(T+237.3)) -- saturated vapor pressure (kPa)
Ea =Hr*Esat -- current vapor pressure (kPa)
Delta=4098*Esat/((T+237.3)^2)
Gamma=0.665*P/1000
if debug then
print("Pressure of saturated vapor "..tostring(Esat).." kPa")
print("Pressure of actual vapor "..tostring(Ea).." kPa")
print("Delta "..tostring(Delta))
print("Gamma "..tostring(Gamma))
end
ET0=(0.408*Delta*(Rn-cst_G)+Gamma*Cn/(T+273)*U2*(Esat-Ea))/(Delta+Gamma*(1+Cd*U2)) -- EVP in mm/h
if debug then print("ET0 "..tostring(ET0).." mm/h") end
-- Updating the counter
-- EVP_Act=otherdevices_rain[dev_EVP] buggy :( Get an offset at midnight
rate, EVP_Act = string.match(otherdevices_svalues[dev_EVP],"(.-);(.-)$")
if debug then
print("rate "..tostring(rate))
print("EVP_Act "..tostring(EVP_Act))
print("EVP Ct b4 "..otherdevices_svalues[dev_EVP])
end
svalue=tostring(ET0)..";"..tostring(EVP_Act+ET0*frequency_EVP/60)
UpdateDev(dev_EVP,0,svalue)
end
return commandArray
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
@aleph0
Thanks!
Your choice for solar radiation from the estimation algorithm brings some, nice stability for that input:
not bad, because otherwise the resulting data might be 'flying' in all directions ....
Below are some practical arguments why I support use of that input.
Because my PWSes are lacking a light-sensor, I made some experimental setups linked to Domoticz.
See the attached graph with results for yesterday and today: the weather is quiet, with sunny clear sky.
Beware, that the graph shows unfiltered, hardly calibrated measured data => levels from sensors are not absolute & correct!!!!!
The thick red line (=Light Calc) is coming from the same algorithm you apply,
with pressure from local barometer in Domoticz (not PWS, but better BMP180+BME280) and octa straight from Ogimet.
SI1145 is a dualsensor looking up, reading light & IR (and calculating UV, but that is not in this graph)
WS7000_TH and Nexus_TH are modified thermo-sensors (= LDR and/or Photodiode at place of NTC-resistor) with line-of-sight at approx. +45 degrees elevation
TLS2561_East, TLS2561_West and BH1750_Zenith are 'real' lightsensors, aimed in the indicated directions.
My evaluations/observations:
- the red line from the calculation is nicely smooth with a graph to be expected for this undisturbed weather,
- the curves from the modified sensors have almost no resemblance to real light-intensity (but more a 'light presence-indication', somewhat useful to calculate sunduration),
- some 'real' sensors are heavily fluctuating (although sky is clear) probably due to their high sensitivity and due to obstruction by trees etc.
As 'real' sensor the SI1145 presently seems best, approaching the calculated curve.
Under another 'project' I found that MAX44009 is also a very good sensor.
My experience now is that the position and aiming of a light sensor is very critical for intial stable data:
- zenith scanning has least problems related to obstructions
- filtering of the data may help by smoothing, but not too much.
Thanks!
Your choice for solar radiation from the estimation algorithm brings some, nice stability for that input:
not bad, because otherwise the resulting data might be 'flying' in all directions ....
Below are some practical arguments why I support use of that input.
Because my PWSes are lacking a light-sensor, I made some experimental setups linked to Domoticz.
See the attached graph with results for yesterday and today: the weather is quiet, with sunny clear sky.
Beware, that the graph shows unfiltered, hardly calibrated measured data => levels from sensors are not absolute & correct!!!!!
The thick red line (=Light Calc) is coming from the same algorithm you apply,
with pressure from local barometer in Domoticz (not PWS, but better BMP180+BME280) and octa straight from Ogimet.
SI1145 is a dualsensor looking up, reading light & IR (and calculating UV, but that is not in this graph)
WS7000_TH and Nexus_TH are modified thermo-sensors (= LDR and/or Photodiode at place of NTC-resistor) with line-of-sight at approx. +45 degrees elevation
TLS2561_East, TLS2561_West and BH1750_Zenith are 'real' lightsensors, aimed in the indicated directions.
My evaluations/observations:
- the red line from the calculation is nicely smooth with a graph to be expected for this undisturbed weather,
- the curves from the modified sensors have almost no resemblance to real light-intensity (but more a 'light presence-indication', somewhat useful to calculate sunduration),
- some 'real' sensors are heavily fluctuating (although sky is clear) probably due to their high sensitivity and due to obstruction by trees etc.
As 'real' sensor the SI1145 presently seems best, approaching the calculated curve.
Under another 'project' I found that MAX44009 is also a very good sensor.
My experience now is that the position and aiming of a light sensor is very critical for intial stable data:
- zenith scanning has least problems related to obstructions
- filtering of the data may help by smoothing, but not too much.
Last edited by Toulon7559 on Monday 01 June 2020 16:03, edited 1 time in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 22
- Joined: Sunday 03 May 2020 7:33
- Target OS: Raspberry Pi / ODroid
- Domoticz version: 2020.2
- Location: Netherlands
- Contact:
Re: Evapotranspiration widget
great script aleph0.
Davis Vantage Pro2 special, Meteobridge, Leuven HWS-template, TTN gateway, home made TTN nodes, Dragino LSE01soil moisture node, Dragino LHT65 node
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Re: Evapotranspiration widget
Hello meteo-friendToulon7559 wrote: ↑Sunday 31 May 2020 20:37 @Number8
Hello meteo-friend!
On my ToDo-list to make data-extraction from the extracted textstring, in order to feed database-applications, to make nice graphs, etc.
When I see what you have achieved guys, I feel a bit lazy since VP Pro 2 delivers updated values every minutes and computes the accumulated month value. I ran Meteohub for more than 10 years and I just transitionned to Meteobridge Nano HD https://www.meteobridge.com/wiki/index. ... ge_NANO_SD, which is a terrific module. Thanks to the template functionnality https://www.meteobridge.com/wiki/index.php/Templates it is straightforward to get the desired values every minutes with a dzVents script. I just remembered that Custom sensor is at our disposal. I grabbed an icon on the Web, resized it and imported it in domoticz (pretty tricky process). Here is the result. Basically here is my dzVents script to grab various meteo value, either directly from VP2 or thanks to wunderground API. Some code is deprecated I haven't removed yet. I wish Domitcz tick is one second instead of one minute in order to get gust value every, say, 5 seconds. This is achievable either with cron or the new emitEvent command. I may give a try some day.
I take this opportunity to thank waaren who is always reacting promptly to questions and give good advices.
Meteo rig
Code: Select all
return {
active = true, -- optional
on = {
timer = {'every minute'},
httpResponses = {'wundergroundResponse', 'wundergroundResponseForecast1', 'wundergroundResponseForecast2', 'localMeteoResponse'}
},
-- logging = {
-- level = domoticz.LOG_INFO,
-- marker = "meteo script"
-- },
data = {
loop = { initial = 0 },
wheatherForecast1 = { initial = 'noinfo'},
wheatherForecast2 = { initial = 'noinfo'}
},
execute = function (dz, item)
local forecastNarrative
local daypartName
local _u = dz.utils
local _h = dz.helpers
local _d = dz.data
local _ = dz.utils._
-- best match with wunderground forecast unfortunately domoticz is way beyond wunderground capabilities
-- see https://docs.google.com/document/d/1eKCnKXI9xnoMGRRzOL1xPCBihNV2rOet08qpE_gArAY/edit
local wheatherForecastTHB = {
[0] = dz.BARO_CLOUDY,
[1] = dz.BARO_CLOUDY,
[2] = dz.BARO_CLOUDY,
[3] = dz.BARO_RAIN,
[4] = dz.BARO_RAIN,
[5] = dz.BARO_RAIN,
[6] = dz.BARO_RAIN,
[7] = dz.BARO_RAIN,
[8] = dz.BARO_RAIN,
[9] = dz.BARO_RAIN,
[10] = dz.BARO_RAIN,
[11] = dz.BARO_RAIN,
[12] = dz.BARO_RAIN,
[13] = dz.BARO_RAIN,
[14] = dz.BARO_RAIN,
[15] = dz.BARO_RAIN,
[16] = dz.BARO_RAIN,
[17] = dz.BARO_RAIN,
[18] = dz.BARO_RAIN,
[19] = dz.BARO_CLOUDY,
[20] = dz.BARO_CLOUDY,
[21] = dz.BARO_CLOUDY,
[22] = dz.BARO_CLOUDY,
[23] = dz.BARO_CLOUDY,
[24] = dz.BARO_CLOUDY,
[25] = dz.BARO_CLOUDY,
[26] = dz.BARO_CLOUDY,
[27] = dz.BARO_CLOUDY, -- shoud be BARO_PARTLY_CLOUDY (value not yey supported in this domoticz version?)
[28] = dz.BARO_CLOUDY, -- shoud be BARO_PARTLY_CLOUDY
[29] = dz.BARO_CLOUDY, -- shoud be BARO_PARTLY_CLOUDY
[30] = dz.BARO_CLOUDY, -- shoud be BARO_PARTLY_CLOUDY
[31] = dz.BARO_SUNNY,
[32] = dz.BARO_SUNNY,
[33] = dz.BARO_SUNNY,
[34] = dz.BARO_SUNNY,
[35] = dz.BARO_RAIN,
[36] = dz.BARO_SUNNY,
[37] = dz.BARO_RAIN,
[38] = dz.BARO_RAIN,
[39] = dz.BARO_RAIN,
[40] = dz.BARO_RAIN,
[41] = dz.BARO_RAIN,
[42] = dz.BARO_RAIN,
[43] = dz.BARO_RAIN,
[44] = dz.BARO_NOINFO,
[45] = dz.BARO_RAIN,
[46] = dz.BARO_RAIN,
[47] = dz.BARO_RAIN,
}
-- "fc" reports the station's weather forecast (0 = rainy, 1 = cloudy, 2 = some clouds, 3 = sunny, 4 = snowy, 5 = clouds at night, 6 = clear night)
-- domoticz BARO_CLOUDY, BARO_CLOUDY_RAIN, BARO_STABLE, BARO_SUNNY, BARO_THUNDERSTORM, BARO_NOINFO, BARO_UNSTABLE
local fc = {
["0"] = dz.BARO_CLOUDY_RAIN,
["1"] = dz.BARO_CLOUDY,
["2"] = dz.BARO_CLOUDY,
["3"] = dz.BARO_SUNNY,
["4"] = dz.BARO_CLOUDY_RAIN,
["5"] = dz.BARO_CLOUDY,
["6"] = dz.BARO_STABLE,
}
-- 0 = No info, 1 = Sunny, 2 = Partly cloudy, 3 = Cloudy, 4 = Rain
local wheaterForecastJSON = {
[dz.BARO_CLOUDY] = 3,
[dz.BARO_RAIN] = 4,
[dz.BARO_SUNNY] = 2,
[dz.BARO_NOINFO] = 0,
-- [dz.BARO_PARTLY_CLOUDY] = 1,
}
local forecastHomeIDX = {
[1] = 359,
[2] = 355,
[3] = 357,
[4] = 399,
[5] = 401,
[6] = 402,
[7] = 404,
[8] = 405,
[9] = 406,
[10] = 407,
}
local forecastSeaIDX = {
[1] = 356,
[2] = 358,
[3] = 400,
[4] = 403,
}
local meteohubIP = '192.168.21.100'
if (item.isTimer) then
local apiKey = 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
dz.data.loop = dz.data.loop + 1
dz.log ('loop = ' .. dz.data.loop)
if dz.data.loop % 20 == 0 then -- call this station once every 20 minutes
local station = 'IPAYSDEL120' -- Ile d'Yeu
local wunderURL = 'https://api.weather.com/v2/pws/observations/current?stationId=' .. station .. '&format=json&units=m&numericPrecision=decimal&apiKey=' .. apiKey
dz.openURL({
url = wunderURL,
callback = 'wundergroundResponse'
})
end
if dz.data.loop %1 == 0 then
-- localMeteo = "http://" .. meteohubIP .. "/meteohtml.cgi?file=domoticz-template"
localMeteo = "http://" .. _h.meteobridgeUser .. ":" .. _h.meteobridgePass .. "@" .. _h.meteobridgeIP .."/cgi-bin/template.cgi?templatefile=domoticz.html"
-- dz.log (localMeteo)
dz.openURL({
url = localMeteo,
callback = 'localMeteoResponse'
})
end
dz.log ('loop number : ' .. tostring(dz.data.loop))
dz.log('dzVents version - '..dz.settings.dzVentsVersion)
if dz.data.loop >= 180 then -- was 60
dz.log ('calling forecast')
dz.data.loop = 0
wunderURL = 'https://api.weather.com/v3/wx/forecast/daily/5day?geocode=47.097,1.966&language=fr-FR&format=json&units=m&apiKey=' .. apiKey
dz.openURL({
url = wunderURL,
callback = 'wundergroundResponseForecast1'
})
-- wunderURL = 'https://api.weather.com/v3/wx/forecast/daily/5day?geocode=46.721,-2.347&language=fr-FR&format=json&units=m&numericPrecision=decimal&apiKey=' .. apiKey
wunderURL = 'https://api.weather.com/v3/wx/forecast/daily/5day?geocode=46.721,-2.347&language=fr-FR&format=json&units=m&apiKey=' .. apiKey
dz.openURL({
url = wunderURL,
callback = 'wundergroundResponseForecast2'
})
end
end
if (item.isHTTPResponse) then
if (item.ok) then
if item.trigger == 'wundergroundResponse' then
if item.json.observations[1].stationID == 'IPAYSDEL120' then
temp = item.json.observations[1].metric.temp
humidity = item.json.observations[1].humidity
pressure = item.json.observations[1].metric.pressure
wheatherForecast = wheaterForecastJSON[dz.data.wheatherForecast2]
local humStatus = dz.helpers.humidityStatus(dz, humidity)
dz.devices(334).updateTempHumBaro(temp,humidity,humStatus,pressure,dz.data.wheatherForecast2)
end
elseif item.trigger == 'wundergroundResponseForecast1' then
-- get icon code in order to retrieve forecast
icon = item.json.daypart[1]['iconCode'][2]
-- save forecast in a persistent variable. Device will be updated next round
dz.data.wheatherForecast1 = wheatherForecastTHB[icon]
for k, v in pairs(forecastHomeIDX) do
forecastNarrative = item.json.daypart[1]['narrative'][k]
if forecastNarrative == nil then forecastNarrative = '--' end
daypartName = item.json.daypart[1]['daypartName'][k]
if daypartName == nil then daypartName = '--' end
dz.devices(forecastHomeIDX[k]).rename("Chez nous - " .. daypartName)
dz.devices(forecastHomeIDX[k]).updateText(forecastNarrative)
end
elseif item.trigger == 'wundergroundResponseForecast2' then
-- get icon code in order to retrieve forecast
local icon = item.json.daypart[1]['iconCode'][2]
-- save forecast in a persistent variable. Device will be updated next round
dz.data.wheatherForecast2 = wheatherForecastTHB[icon]
for k, v in pairs(forecastSeaIDX) do
forecastNarrative = item.json.daypart[1]['narrative'][k]
if forecastNarrative == nil then forecastNarrative = '--' end
daypartName = item.json.daypart[1]['daypartName'][k]
if daypartName == nil then daypartName = '--' end
dz.devices(forecastSeaIDX[k]).rename("Ile d'Yeu - " .. daypartName)
dz.devices(forecastSeaIDX[k]).updateText(forecastNarrative)
end
elseif item.trigger == 'localMeteoResponse' then
local body = item.data:match('%b{}') -- extract part of item.data that is between {} ( including the outer {} )
local rt = dz.utils.fromJSON(body) -- convert the json string to rt ( Lua table )
-- dz.utils.dumpTable(rt) -- dump the contents of the table in your log
dz.log ('wheatherForecast1 -- ' .. dz.data.wheatherForecast1)
dz.log ('wheatherForecast2 -- ' .. wheaterForecastJSON[dz.data.wheatherForecast2])
local temp = tonumber(rt.realtime.temperature)
local windChill = tonumber(rt.realtime.temperature_au_vent)
local solarRadiation = tonumber(rt.ensoleillement.radiations_solaires_wlk)
local evapotranspirationDay = tonumber(rt.ensoleillement.evapotranspirationDay)
local evapotranspirationMonth = tonumber(rt.ensoleillement.evapotranspirationMonth)
local humidity = tonumber(rt.realtime.humidite)
local pressure = tonumber(rt.realtime.pression)
local pressureSea = tonumber(rt.realtime.pression_mer)
local precipRate = tonumber(rt.realtime.pluie_intensite)
local precipTotal = tonumber(rt.realtime.pluie_actu)
local windBearing = tonumber(rt.realtime.vent_dir_moy)
local windDirection = rt.realtime.vent_dir_txt
local dateReleve = rt.realtime.date_releve_local
local heureReleve = rt.realtime.heure_releve_local
local windSpeed = tonumber(rt.realtime.vent)
local windGust = tonumber(rt.realtime.vent_rafales)
local windGust15m = tonumber(rt.realtime.vent_rafales_15minutes)
local windGust60m = tonumber(rt.realtime.vent_rafales_60minutes)
local windGustH = tonumber(rt.realtime.vent_rafales_heure)
local windGustD = tonumber(rt.realtime.vent_rafales_jour)
local forecast = tonumber(rt.realtime.prevision)
-- local wheatherForecast = fc[(forecast)]
local wheatherForecastText = rt.realtime.previsionText
local windGust24h = tonumber(rt.historical.vent_rafales_24heures)
local windGustM = tonumber(rt.historical.vent_rafales_mois)
local windGustY = tonumber(rt.historical.vent_rafales_annee)
local windGustRecord = tonumber(rt.historical.vent_rafales_record)
local windGustRecordDate = tonumber(rt.historical.vent_rafales_record_date)
local ageOfData = tonumber(rt.realtime.ageOfData)
local ageOfData = tonumber(rt.realtime.ageOfData)
dz.log ('Ancienneté des données : ' .. tostring(ageOfData))
if ageOfData < 10 then
dz.devices(427).updateAlertSensor(dz.ALERTLEVEL_GREEN, "Fonctionnement normal")
else
dz.devices(427).updateAlertSensor(dz.ALERTLEVEL_RED, "Temps de réponse > 10 secondes")
end
-- to be finalized
local wheatherForecast
if _h.vantageFC[forecast].fr ~= "" then
wheatherForecast = _h.vantageFC[forecast].fr
else
wheatherForecast = _h.vantageFC[forecast].en
end
local humStatus = dz.helpers.humidityStatus(dz, humidity)
dz.devices(414).updateRain(precipRate*100,precipTotal)
dz.devices(415).updateTempHumBaro(temp,humidity,humidityStatus,pressureSea,wheatherForecast)
dz.devices(416).updateRadiation(solarRadiation)
dz.devices(432).updateCustomSensor(evapotranspirationDay)
dz.devices(433).updateCustomSensor(evapotranspirationMonth)
dz.devices(417).updateWind(windBearing,windDirection,windSpeed,windGust,temp,windChill)
if dz.data.loop % 60 == 0 then dz.devices(426).updateText(wheatherForecastText) end
end
end
end
end
}
Debian buster on NUC and three RPi with buster.
-
- Posts: 85
- Joined: Thursday 12 May 2016 15:47
- Target OS: Linux
- Domoticz version: 11838
- Location: South of France
- Contact:
Re: Evapotranspiration widget
Wow ! That's a big mast
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Re: Evapotranspiration widget
Anemometer is at 13m from ground
Debian buster on NUC and three RPi with buster.
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
(Not having better software and examples) was accustomed to ET-calculation once per day @ end of the day => always ET-info of yesterday.
The script of Aleph0 has the nice twist that it calculates in realtime as kind of semi-rain, enabling instantaneous comparison of evaporation and precipitation.
Clever use of Domoticz' capabilites for numeric integration, automatically yielding cumulating info over longer perriods.
If not applying the light-calculation model as input, but a real solar-sensor, this script will actually include any weather variations over the day:
as calculation more accurate than just taking max. and min. of a day, as some other solutions do.
Testing the pudding is by eating:
next days compare what this script and WsWin report at the end of each day.
Suggestion:
The script results in a value towards the Virtual Device with many digits which are not really effective.
Inserting a 'Round'-function you could limit to a more meaningful display, at cost of some loss of resolution towards the Virtual Device.
The script of Aleph0 has the nice twist that it calculates in realtime as kind of semi-rain, enabling instantaneous comparison of evaporation and precipitation.
Clever use of Domoticz' capabilites for numeric integration, automatically yielding cumulating info over longer perriods.
If not applying the light-calculation model as input, but a real solar-sensor, this script will actually include any weather variations over the day:
as calculation more accurate than just taking max. and min. of a day, as some other solutions do.
Testing the pudding is by eating:
next days compare what this script and WsWin report at the end of each day.
Suggestion:
The script results in a value towards the Virtual Device with many digits which are not really effective.
Inserting a 'Round'-function you could limit to a more meaningful display, at cost of some loss of resolution towards the Virtual Device.
Last edited by Toulon7559 on Tuesday 02 June 2020 10:34, edited 2 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 85
- Joined: Thursday 12 May 2016 15:47
- Target OS: Linux
- Domoticz version: 11838
- Location: South of France
- Contact:
Re: Evapotranspiration widget
You're right about displaying not meaningful digits. The problem is calculating ET every minutes, or even hours, gives very small amounts. If you round the result, those small amounts will be lostToulon7559 wrote: Suggestion:
The script results in display at the widget with many digitis which are not effective.
Inserting a 'round'-function you can limit to a more meaningful display.
Preferred solution would be to specify the number of digits to display at display time not at calculation time. But this feature is not available in domoticz. A workaround would be to accumulate ET in a variable and round it for display in the rain widget.
Envoyé de mon moto g(6) en utilisant Tapatalk
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
True
Understood, as you can see by the extension in my previous message, after I realised this aspect.
Your script is nice short: 'solving' this aspect would extend & complicate.
Would be fun to have a dedicated icon for this type of rain-widget.
WsWin in it's collection of usericons has 2 gif-files visually explaining the whole cycle:
own, private use has been permitted by the author [obviously giving him credit!].
Understood, as you can see by the extension in my previous message, after I realised this aspect.
Your script is nice short: 'solving' this aspect would extend & complicate.
Would be fun to have a dedicated icon for this type of rain-widget.
WsWin in it's collection of usericons has 2 gif-files visually explaining the whole cycle:
own, private use has been permitted by the author [obviously giving him credit!].
- Attachments
-
- evapo_big
- evapo1.gif (56.31 KiB) Viewed 2893 times
-
- evapo_small
- et.gif (1.16 KiB) Viewed 2893 times
Last edited by Toulon7559 on Monday 26 February 2024 17:19, edited 2 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 843
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Evapotranspiration widget
Calculation of day-values and linking to a virtual device & widget is just the start.
Meteo-enthousiasts are (also) interested in the related longer term statistics from the same set of data:
longer term statistics from another set of data is not the 'real thing'.
Domoticz is already performing all kind of related functions in the background (probably based on the standard SQLite database) and showing the results at the dashboard.
For other applications, has somebody developed/found some nice, compact scripts/routines to extract & compile & export cumulative values from that Domoticz database for selected devices?
- value this week
- value this month
- value this year
Meteo-enthousiasts are (also) interested in the related longer term statistics from the same set of data:
longer term statistics from another set of data is not the 'real thing'.
Domoticz is already performing all kind of related functions in the background (probably based on the standard SQLite database) and showing the results at the dashboard.
For other applications, has somebody developed/found some nice, compact scripts/routines to extract & compile & export cumulative values from that Domoticz database for selected devices?
- value this week
- value this month
- value this year
Last edited by Toulon7559 on Monday 08 June 2020 12:26, edited 1 time in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 85
- Joined: Thursday 12 May 2016 15:47
- Target OS: Linux
- Domoticz version: 11838
- Location: South of France
- Contact:
Re: Evapotranspiration widget
I back up the point for the icon, it would be nice
Regarding export of data, I had this need for electricity, and choose to export to a MySQL dB. Simply by running an SQL query via an os.execute in a lua script. I think we could do the same here
Envoyé de mon moto g(6) en utilisant Tapatalk
Regarding export of data, I had this need for electricity, and choose to export to a MySQL dB. Simply by running an SQL query via an os.execute in a lua script. I think we could do the same here
Envoyé de mon moto g(6) en utilisant Tapatalk
-
- Posts: 374
- Joined: Friday 23 May 2014 7:55
- Target OS: Linux
- Domoticz version: 2022.1
- Location: Saint Pierre de Jards
- Contact:
Re: Evapotranspiration widget
For that i’m using influxdb/grafana. This is just great, very easy to set upToulon7559 wrote: ↑Sunday 07 June 2020 9:20 Calculation of day-values and linking to a virtual device & widget is just the start.
Meteo-enthousiasts are (also) interested in the related longer term statistics from the same set of data:
longer term statistics from another set of data is not the 'real thing'.
Domoticz is already performing all kind of related functions in the background (probably based on the standard SQLite database) and showing the results at the dashboard.
For other applications, has somebody developed/found some nice, compact scripts/routines to extract & compile & export cumulative values from that Domoticz database for selected devices?
- value this week
- value this month
- value this year
Debian buster on NUC and three RPi with buster.
Who is online
Users browsing this forum: Bing [Bot] and 1 guest