DayFile - Annual Evapotranspiration bug

[TgT]

Wiki says:
23 (X): Total evapotranspiration (Only valid for Davis stations, shows zero otherwise)

but on a new years day (1.1. aka 1st Jan) i get huge negative value, possible previous year sum?

yes, i just sum whole year ET and it matches a negative number on new years day.

[steve]

The ET value provided to Cumulus by the console and/or DLL is buggy and unreliable. It often shows a negative value.

[Mapantz]

I know this is a problem on the Davis side of things, but this hit me hard again.
I had a complete log full of this:

Code: Select all

2018-01-01 00:49:58.293 *** ET Reset
2018-01-01 00:50:00.298 *** ET Reset

But it didn't reset until midnight on the 1st of January, which meant that I had a whole day's worth of data logged, with a value that looked like this
-732.66 the value slowly decreased in size throughout yesterday, and then also logged it as -731.69 in yesterday dayfile.

In the end, I had to manually edit Jan18.txt, Dayfile.txt and all of the rogue values in sql - took me ages!

Does anyone have some kind of workaround for this? I know it's only once a year, but it happened the year before as well. My console date and time match my computer perfectly.

[mcrossley]

I didn't have a great problem. It detected the negative values just after midnight, but they stopped after 40 seconds, and at 00:00:45 I got...

Code: Select all

2018-01-01 00:00:45.816 StartofdayET set to 0

And that was it.

I have never looked at the year rollover before - interesting to see the rain counter reset to zero - obvious that it is a year total but I hadn't thought about it before.

[Mapantz]

I didn't have a great problem. It detected the negative values just after midnight, but they stopped after 40 seconds, and at 00:00:45 I got...

Code: Select all

2018-01-01 00:00:45.816 StartofdayET set to 0

And that was it.

I have never looked at the year rollover before - interesting to see the rain counter reset to zero - obvious that it is a year total but I hadn't thought about it before.

I never got the 0, it just started as this:

Code: Select all

2018-01-01 00:00:01.070 StartofdayET set to 732.663

and then had these for an hour:

Code: Select all

2018-01-01 00:00:07.411 *** ET Reset
2018-01-01 01:00:00.279 *** ET Reset

It wasn't until Jan 2nd that it corrected itself:

Code: Select all

2018-01-02 00:00:01.477 StartofdayET set to 0.8636

I hadn't realised until then, so that's when I had to go through everything to remove the rogue values.

[mcrossley]

Not a great deal of help, but you could add a pre-insert check on the SQL tables for negative values and set them to zero.

[HRVistaWeather]

Hi Mapantz,
You are not on your own there, dito here.
To the point that after many years i have decided to ditch my "Monthly" table altogether.
Unlike many I pushed mine to the limit purposely at a one (1) minute Log time to see how far it would go.
I started recording in 2010 at (5) min intervals then over time changed to (1) that coupled with numerous Software and Hardware changes over the years resulted in my culling of all data pre 2013 last year in order to omit erroneous data from the display on my site.
However as of earlier today, my host server based MySql Monthly Table finally locked up for one reason or another, so I decided that was it.
I killed it and amended all scripts to not use it.
Pity on one front I suppose, but a major breath take on the other not having to be concerned about it any longer and too boot my envisaged thought that it may eventually fail due to size (whether it be in 1/5/10 whatever min intervals was like death, it is inevitable).
Regards,
Tony