Pro2/Envoy: Strange value for Evapotranspiration

[Hathor27]

Already a few times I wondered about the value of sol1_et_mm (evapotranspiration):

• Meteohub shows daily values around 15..25mm
• If I have a look at my Vantage I read 2.8mm where Meteohub says 15.3mm
• Meteohub reset its daily value at every noon (?)

For a graph on et and radiation look at http://untersiggenthal.meteo.selfip.inf ... 12_m10.png

Has anybody an idea for this phenomena?

[YJB]

Same here,

We did discuss this issue already back in Februari: viewtopic.php?f=14&t=8370&p=9591&hilit= ... tion#p9591 but were not able to get down to the bottom of it.

It would hel Boris if we can point out what is going wrong, but the numbers reported by Davis are completely different from the ones reported by MH. Since MH is simply using the data from Davis, there might be a conversion error, or the wrong field in the loop command is referred.

Ysbrand

[Hathor27]

It would hel[p] Boris if we can point out what is going wrong, ...

What do you think we could do to go ahead?

[YJB]

What do you think we could do to go ahead?

I really don't know. See if we can find out if this is a simple conversion issue (like ET reported by MH is always 2 times as high). Unfortunately it doesn't seem to be that simple, but once we can identify a pattern, it might be easy to fix.

[Hathor27]

Wouldn't there be a way to stick Meteohub-Support and Davis-Support together?
Davis should be able to tell what they send and Meteohub should know what they calculate

Is there a support-form for Meteohub issues?

[wfpost]

that´s the description from
Vantage Pro and Vantage Pro2 Serial Communication Reference Manual what values ET is providing ...

ET accumulated over the last hour.
Only records "on the hour" will have a non-zero value.
Units are (in / 1000)

[Hathor27]

ET accumulated over the last hour.
Only records "on the hour" will have a non-zero value.
Units are (in / 1000)

sounds serious...
...but Meteohub is doing something strange anyway: It starts every day at noon (mid-day, 12 o'clock) with value zero. Then it counts thru the day and night until next mid-day. As I believe, Meteohub should start at mid-night and count ET-value similar to rain_total_mm - shouldn't it?

There should probably be two vaules for ET on Meteohub:
- a value et_mm similar to rain_rate
- a value et_total_mm similar to rain_total_mm

So we could display the hourly value plus the total amount over a day, month, year and so on.
(I hope to be correct in understanding the mechanism of evapotranspiration...)

If you have a look at my weather site (see signature) you can find the actual graph of solar-power and evapotranspiration over 12 hours respectively over 3 days

[Hathor27]

...but Meteohub is doing something strange anyway: It starts every day at noon (mid-day, 12 o'clock) with value zero. Then it counts thru the day and night until next mid-day. As I believe, Meteohub should start at mid-night and count ET-value similar to rain_total_mm - shouldn't it?

oops... I probably found an error within my vantage settings: The clock of was lagging 751 minutes (12.5h) - I'll observe the behaviour of ET for another time frame

[Hathor27]

oops... I probably found an error within my vantage settings: The clock of was lagging 751 minutes

Ok ok, the timing problem was a self-made one. After adjusting the clock ET-value begins to count at 00:00 and ends at 24:00 - great

But the value itself is still incorrect. Readings for today:
- Vantage : ET = 0.8mm
- Meteohub : ET = 6.4mm

Has anybody got a clue?

[YJB]

Here are the current values for my station for today (18:00):

MH: 17.0
Vantage Console: 2.0mm
Weatherlink: 2.16mm

@Boris:
Is there any way we can see (for debug purposes) the raw field that you get from the Vantage?

[wfpost]

Today my ET (daily) values are

MH: 0.52mm
VP2: 0.5mm

My ET values are always accurate and without gaps between MH and what´s displayed at VP´s console.

Could it be, because my VP2 is a US-version?

To me it looks like the time gap between ET and solar radiation does not reflect what´s going on in nature.
Too large
Highest ET two hours behind highest solar radiation. my feeling tells me, that´s not the case in reality.

[YJB]

Today my ET (daily) values are

MH: 0.52mm
VP2: 0.5mm

My ET values are always accurate and without gaps between MH and what´s displayed at VP´s console.

Well, there is something funny, look at your graph, its shows 5mm for today, while you are reporting 0.52 mm.

This is what I noticed as well that depending on the interval chosen, the graphs are not always in sync with what MH reports:
(While looking at this, keep in mind that the Vantage only runs the ET calculation on top of each hour for the preceding hour, so the value for ET will remain unchanged for the duration of the entire hour.)

Look at this:
The hourly interval shows results that are at least in sync with my MH numbers:

ET_Hourly.png (4.82 KiB) Viewed 12395 times

Now let's change the report to 6 hours, still ok:

ET_6Hourly.png (3.93 KiB) Viewed 12395 times

But looking at the daily values something goes wrong:

ET_Daily.png (4.03 KiB) Viewed 12395 times

As one can see the daily values are only a fraction of the numbers reported (when comparing with 6 hour or 1 hour interval).

[wfpost]

you´re right. I was only looking at the value meteohub prints into my website.

I´m using this line for output, which gives accurate values for ET.
{math* [actual_sol0_evotranspiration_mm:-] 0.1}

Graph values are wrong, I recall now that bug always existed.


I noticed that the size of the time intervall is problematic with temperature and other sensors also.
At least for non min max parameters!
e.g. printing a graph for a longer period and using a large intervall leads to the highest and lowest temperatures simply left out.
only if using temp_max or temp_min will reflect those maximums or minimums regardless of the intervall size.

It could be a similar case with ET graphs.

[YJB]

I´m using this line for output, which gives accurate values for ET.
{math* [actual_sol0_evotranspiration_mm:-] 0.1}

.

Hmm, so you are saying that MH reports the value as being multiplied by 10? Might be cause by the inconsitent way Vantage is reporting ET values:

Code: Select all

Day ET 56 2 This value is sent as the 1000th of an inch.
Month ET 58 2 This value is sent as the 100th of an inch.
Year ET 60 2 This value is setnt as the 100th of an inch.

Boris, can you check if you are taking the "1000th of an inch" into consideration?

It would not make the numbers completely accurate, but at least closer.

[Hathor27]

This is what I noticed as well that depending on the interval chosen, the graphs are not always in sync with what MH reports

You're right, but as Meteohub doesn't interpret the et_mm as a total_mm value, it's also a correct graph when Meteohub calculates et_mm as mean-value over a different aggregation time...

...as I believe, there are two bugs in there:

• 1st: The factor x10 (or x8? as my values show)
• 2nd: There should probably be two vaules for ET on Meteohub (as I already mentioned below):
  • et_mm similar to rain_rate for the hourly et-value
  • et_total_mm similar to rain_total_mm for the sum over a day, week, month, ....

Meteohub gives only the total_mm-value over a day, but not a rate-value for each hour

Can anybody aggree with this intrepretation?