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.
Please read the posts in the Announcements section about the current status of Cumulus development now that I have retired
Please read this post before posting
Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3043 Jan 20 2017. See this post for download
Please read this post before posting
Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3043 Jan 20 2017. See this post for download
DayFile - Annual Evapotranspiration bug
- steve
- Cumulus Author
- Posts: 26468
- Joined: Mon Jun 02, 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: DayFile - Annual Evapotranspiration bug
The ET value provided to Cumulus by the console and/or DLL is buggy and unreliable. It often shows a negative value.
Steve
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876
Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876
Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job
- Mapantz
- Posts: 523
- Joined: Sat Dec 17, 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 10 x64 - A beast.
- Location: Wareham, Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
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:
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.
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
- Posts: 5102
- Joined: Thu Jan 07, 2010 9:44 pm
- Weather Station: Davis VP2
- Operating System: Stretch Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
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...
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.
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
- Posts: 523
- Joined: Sat Dec 17, 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 10 x64 - A beast.
- Location: Wareham, Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
mcrossley wrote: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
- Posts: 5102
- Joined: Thu Jan 07, 2010 9:44 pm
- Weather Station: Davis VP2
- Operating System: Stretch Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
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
- Posts: 199
- Joined: Mon Apr 09, 2012 2:38 pm
- Weather Station: Davis VP2 Plus - 24hr FARS
- Operating System: Windows 10 Home (64bit)
- Location: Franklin, Huon Valley, Tasmania
- Contact:
Re: DayFile - Annual Evapotranspiration bug
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
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
Who is online
Users browsing this forum: No registered users and 4 guests