Welcome to the Cumulus Support forum.
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
DayFile - Annual Evapotranspiration bug
-
- Posts: 132
- Joined: Thu 26 Jun 2008 5:51 am
- Weather Station: Davis VP2 + Solar
- Operating System: A20 TV box + CumulusMX
- Location: Slov.Konjice, Slovenia
- Contact:
DayFile - Annual Evapotranspiration bug
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.
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
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 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
-
- Posts: 1817
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: 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
-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: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye 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
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.
-
- Posts: 1817
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
I never got the 0, it just started as this: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...And that was it.Code: Select all
2018-01-01 00:00:45.816 StartofdayET set to 0
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:01.070 StartofdayET set to 732.663
Code: Select all
2018-01-01 00:00:07.411 *** ET Reset
2018-01-01 01:00:00.279 *** ET Reset
Code: Select all
2018-01-02 00:00:01.477 StartofdayET set to 0.8636
- mcrossley
- Posts: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye 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.
- BeaumarisWX
- Posts: 375
- Joined: Mon 09 Apr 2012 2:38 pm
- Weather Station: Davis VP2 Plus - 24hr FARS
- Operating System: Windows 10 Pro Hades Canyon
- Location: Beaumaris, Tasmania, AU
- 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
Tony Beaumaris, Tasmania (AUS)
CMX Mobile : https://beaumaris-weather.com/BWX/
CMX Default: https://beaumaris-weather.com/cumulusmx_default/
Colour Dashboard : https://beaumaris-weather.com/dashborad_color.php
Click below for Saratoga Template :
CMX Mobile : https://beaumaris-weather.com/BWX/
CMX Default: https://beaumaris-weather.com/cumulusmx_default/
Colour Dashboard : https://beaumaris-weather.com/dashborad_color.php
Click below for Saratoga Template :
-
- Posts: 1817
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
.. and again..
I dunno why mine never resets?
And of course, my diag file is filling up fast again.
I stopped CMX I quickly edited it out of today.ini and jan19.txt before it got out of hand.
Everything reset on the console though.
I dunno why mine never resets?
And of course, my diag file is filling up fast again.
I stopped CMX I quickly edited it out of today.ini and jan19.txt before it got out of hand.
Everything reset on the console though.
- mcrossley
- Posts: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
Weird, mine reset after retrying for 34 seconds this year.
What console firmware version are you running. Mine is v3.12
What console firmware version are you running. Mine is v3.12
-
- Posts: 1817
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
I'm on 3.15 mark.
I should've worded it better. It doesn't reset it to zero. It went to -801.8
2019-01-01 00:00:01.910 StartofdayET set to 801.7764
Then I had the log filling with
2019-01-01 00:00:08.931 *** ET Reset
Until I stopped CMX and changed it in the today.ini
I should've worded it better. It doesn't reset it to zero. It went to -801.8
2019-01-01 00:00:01.910 StartofdayET set to 801.7764
Then I had the log filling with
2019-01-01 00:00:08.931 *** ET Reset
Until I stopped CMX and changed it in the today.ini
- jdc
- Posts: 142
- Joined: Tue 19 Jun 2012 8:51 pm
- Weather Station: Davis VP2 : Instromet
- Operating System: Win 10
- Location: Portsoy,.
- Contact:
Re: DayFile - Annual Evapotranspiration bug
FWIW my MXdiags has 'ET Reset' up until 01:00 when 'hour changed' seems to clear it.
Code: Select all
2019-01-01 00:59:53.095 *** ET Reset
2019-01-01 00:59:55.220 *** ET Reset
2019-01-01 00:59:57.080 *** ET Reset
2019-01-01 01:00:00.345 Hour changed:1
2019-01-01 01:00:00.345 Calculating sunrise and sunset times
2019-01-01 01:00:00.345 Sunrise: 08:37:47
2019-01-01 01:00:00.345 Sunset : 15:45:39
- mcrossley
- Posts: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
I'll take a look at how the code is handling this and see if there is anything I can do. The problem will be reproducing it, I don't really want to mess up my live data by resetting the clock for an extended period to build up some et for a year rollover.
Some logs with debug and data logging on over the rollover period may be a help, but again too late for this year
Some logs with debug and data logging on over the rollover period may be a help, but again too late for this year
- mcrossley
- Posts: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
Tina, could you send me your diag file for the full rollover period please. Plus the sections of data logs file covering the same period.
- mcrossley
- Posts: 12763
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
OK, after much stepping through the calculations in various scenarios in Excel! I can see why you are having the issue, and why it stops at the first daily rollover. I'll put a fix in the next release.
The *think* reason some people see the issue and others don't is down to a timing thing. I saw the "*** ET Rest" messages between midnight and rollover processing being done. So if there are loop packets coming in over the 00:00 period and MX sees the ET reset before the rollover processing and the counters get reset correctly. If it sees ET reset after the rollover processing the counters are not reset correctly until the next rollover.
I'd need to see some diag files to confirm this though.
I'll add the change and amend it slightly so it detects not just a reset to zero, but a reset to any value lower than current - just in case that can occur as well.
The *think* reason some people see the issue and others don't is down to a timing thing. I saw the "*** ET Rest" messages between midnight and rollover processing being done. So if there are loop packets coming in over the 00:00 period and MX sees the ET reset before the rollover processing and the counters get reset correctly. If it sees ET reset after the rollover processing the counters are not reset correctly until the next rollover.
I'd need to see some diag files to confirm this though.
I'll add the change and amend it slightly so it detects not just a reset to zero, but a reset to any value lower than current - just in case that can occur as well.
-
- Posts: 1817
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: Dorset - UK
- Contact:
Re: DayFile - Annual Evapotranspiration bug
Apologies Mark. I missed it.
Interesting. I figured it might have been a bug with the 3.15 firmware due to the lack of reports.
Interesting. I figured it might have been a bug with the 3.15 firmware due to the lack of reports.