Cumulus Support

Hi Mark,
Not sure what's going on here (or if anyone else has even noticed it).
This is not current version related as I have been dealing with it for years (all previous versions).
Every no and then (I can not find a common cause) my "Rainfall So Far" get's carried forward to the next day, let's say previous day ended with 1.0mm at 23:59:59, sometimes in the Monthly Log the next day at 00:00:00 has 1.0mm and then 00:01:00 is back to 0.0mm, or sometimes 00:00:00 is 0.0mm and 00:01:00 is 1.0mm the 00:02:00 back to 0.0mm.
Note the "Rainfall Counter" is not affected. But the "Rain Since Midnight" is. In addition this also uploads to MySql Monthly table.

I usually check these regularly and correct the Monthly Logs, which is easy now with the editor, which also updates the MySql table.

On the very odd occasion like today, the Monthly Log file is fine, but MySql Table had value carried forward from yesterday's 2.2mm to today at 00:01:00.

I would be curious to know if anyone else has noticed this issue.

Kindest regards,
Tony

Hi Tony, I suspect I know what is happening, but could you provide a MXdiags log of a rollover where this happens with Debug logging enabled please.

Hi Mark,
Appreciate response, will do, I have set Debug logging to enabled.
Looks like Rain coming this Thursday, Saturday and maybe Sunday, so if it occurs again will send MXdiags Log.

Kindest Regards,
Tony

The same thing is happening to me as well. For example, at the beginning of this month, the total rainfall counter was at 647.8. We had 19.4 mm on October 1, and the rainfall counter at the end of the day was 667.2 as you'd expect, however, at midnight, the 19.4 mm didn't reset to 0, so it added another 19.4 mm making the counter jump up to 686.6.
This basically happens every single day, so as a result, the monthly rainfall for this month is currently at 174.4 mm despite the fact we're only 7 days into the month.
What's weird though, is that at the time Cumulus MX is actually launched, the total rainfall counter is decreased by the same amount. For example, it went from 694.2 to 674.8 (a decrease of 19.4 mm equal to the previous day's rain), which means the total rainfall seems to suddenly increase by the previous day's rain from midnight until the time you launch but is then reset to what it should be. In terms of the total rainfall counter, this isn't too much of a problem, however, if more rain falls on one day than the previous day, before Cumulus is launched, then it subtracts the previous day's total at the time Cumulus is launched. As an example, we had 3.8 mm one day. Then, the next day, by the time Cumulus was launched, we had 28.8 mm, but then the Oct21log.txt file suddenly showed that it dropped from 28.8 mm to 25.0 mm (which obviously is exactly 3.8 mm difference). We had another 0.2 mm of rain later, which meant the total rain for that day was recorded as 25.2 mm, when it was actually 29.0. I have attached an image of the graph showing the 3.8 mm from the previous day, the 28.8 mm up to just before 14:00 and then a sudden drop by 3.8 mm to 25.0:

This whole thing then affects the total monthly rain, as it will add the previous rain to the next rain, but will also subtract the previous rain from the daily rain total.

The actual daily rainfall totals should be
1st - 19.4
2nd - 38.6
3rd - 0.2
4th - 3.8
5th - 29.0
6th - 0.0
totalling 91.0 for this month so far.

However, what they are recorded as in dayfile.txt
1st - 19.4
2nd - 38.6
3rd - 0.2
4th - 3.8
5th - 25.2 (equal to the actual total, minus the total on the 4th, which only happens if the amount of rain is higher than the previous day, before cumulus is launched, otherwise, it remains the same)
6th - 0.0
totalling 87.2 for this month so far.

Additionally, Cumulus MX is creating duplicate dayfile.txt entries. One of them is showing actual times for any records, e.g. Max temperature time, but the other one shows just 00:00 for everything. As a result, not only is the monthly rain total wrong because of the daily rain totals, it actually doubles the wrong amount so it would actually say 174.4 mm instead of 87.2 mm (both of which are wrong, since it should be 91.0)
This part can be fixed by deleting every entry that has a duplicate and then using CreateMissing.exe to recreate them. Normally I hibernate my PC (with Cumulus running), then when I wake my PC up, I'll then close Cumulus, copy the 'data' folder contents from the midnight backup, then run Cumulus, so it creates the missing data during the time the PC is hibernated. Normally, and for years, this has never caused a problem, so I'm going to assume that this is not what is causing the dayfile.txt entries to be duplicated.

I can't attach any MXdiag logs since the log for the last day that any rain was recorded, is too large (6404 KB) - this also means I can't "pastebin" it either.

However, here's some of the entries in the MXdiag log that mentions anything to do with "rain" if this helps.

2021-10-05 13:42:23.607 ReadTodayfile: Rain day start = 710
2021-10-05 13:42:23.607 ReadTodayfile: set initialiseRainCounterOnFirstData false
2021-10-05 13:42:23.611 G:\Desktop\CumulusMXDist3148\CumulusMX\data\alltime.ini
2021-10-05 13:42:23.611 Alltime.ini file read
2021-10-05 13:42:23.616 MonthlyAlltime.ini file read
2021-10-05 13:42:23.619 Month.ini file read
2021-10-05 13:42:23.622 Year.ini file read
2021-10-05 13:42:23.623 LoadDayFile: Attempting to load the day file
2021-10-05 13:42:23.713 LoadDayFile: Loaded 2557 entries to recent daily data list
2021-10-05 13:42:23.715 Finding raintoday from logfile data\Oct21log.txt
2021-10-05 13:42:23.715 Expecting listsep=, decimal=.
2021-10-05 13:42:23.747 Midnight rain found in the following entry:
2021-10-05 13:42:23.747 04/10/21,00:00,8.5,95,7.7,0,0,0,0.0,0.2,1021.1,706.2,22.2,70,0,8.5,8.5,0.0,0,0.00,0.00,8.0,0,0.0,360,0.0,0.0,8.5,8.5
2021-10-05 13:42:23.756 Midnight rain found, setting midnight rain count = 706.2
2021-10-05 13:42:23.756 Checking rain counter = 713.8
2021-10-05 13:42:23.756 Rain counter set to = 713.8
2021-10-05 13:42:23.757 Getting rain totals, rain season start = 1
2021-10-05 13:42:23.757 Today = 05/10/21
2021-10-05 13:42:23.758 Rainthismonth from dayfile: 120.2
2021-10-05 13:42:23.758 Rainthisyear from dayfile: 316.8

Normally this issue is caused by Cumulus not be allowed to run during the rollover time due to the computer being suspended or hibernated.

I usually always hibernate/suspend my PC after midnight. One thing I did notice, was that the duplicated dayfile entries started on July 20, 2021, and in the date column, up until July 19, the date format was 4 digits, but then changed to 2 digits, i.e. it was 19/07/2021, then 20/07/21 and ever since that point, the dayfile entries have been duplicated. It can't be anything to do with a recent build of Cumulus MX, since the only dates I've ever actually updated Cumulus MX are January 14, 2018 to build 3043; May 26, 2021 to build 3107; June 17, 2021 to build 2133; and October 3, 2021 to build 3148 (I haven't updated to 3149 yet); but nothing in July. Basically, I've been doing the same thing I usually do, but suddenly the dayfile date format changed slightly from dd/mm/yyyy to dd/mm/yy, and the dayfile entries are being duplicated. I did try setting my PC to automatically close Cumulus when the PC is hibernated, but somehow, "Scheduled Tasks" works maybe a little more than 1% of the time how you want them.

The date format is taken from your Windows date /time format settings. Did you change those in July? Or perhaps there was a Windows update around then?

My Windows date format is set to dd/mm/yyyy e.g. 08/10/2021, but the dayfile.txt dates are displaying just 08/10/21 so it can't be that.
What ever it was, I just changed the years up to 19/07/2021 to show just the last 2 digits (didn't take that long, I just opened the txt in Notepad, then did replace "/201" to "/1" to replace /2014 with /14, /2015 with /15, etc, up to 2019, then "/202" with "/2" for /2020 and /2021 to /20 and /21 respectively). Still desn't really explain why the dayfile.txt is duplicating entries with one entry being the actual dayfile data based on the "Oct21log" (or similar) data, and the other simply being midnight readings.
For example, for the September 28, 2021 entry, the correct one shows a minimum temperature of 7.1 at 02:40, and a maximum temperature of 17.0 at 115:10.
The duplicated log for that same date however, shows a minimum temperature of 11.6 at 00:00, and a maximum temperature of 11.6 at 00:00
In the "Sep21log.txt" file, the actual temperature reading at 00:00 on that date (September 28), was actually 7.7, not 11.6 - the 11.6 reading was actually taken at 23:59 on September 28. So, basically, the dayfile log is creating an entry, taking the last readings for that day, but putting them as being at 00:00, almost 24 hours earlier, along with the correct dayfile entry.

The dayfile always uses a two digit year. If yours has a four digit year for part of it then I think you may have edited using something like Excel in the past (dangerous - always use a text editor)

That might explain it, but still, the mystery of why it seems to take the readings from the end of the current day, and put them as a dayfile entry, along with the correct dayfile entry, still doesn't make sense, especially since I've been letting it run past midnight before hibernating, and then filling the gap after resuming, by letting it download the data from midnight, by using the daily midnight backup for the last almost 7 years, and never had a problem with it before.

Please zip up your MXdiags folder and attach it here and I'll take a look.

Done.

(The "No monthly data was found, not creating a record" errors in the CreateMissing logs are intentional, either because the battery died, or when I changed from Fine Offset to Vantage Vue, for example, and the much larger CreateMissing log, was due to the dayfile.txt originally having the yyyy years instead of yy, so it was reading the '2014' as something like '3914', which I fixed, as mentioned earlier - the reason for using CreateMissing in the first place, was because I deleted all the dayfile entries that were duplicated then used it to recreate those entries normally)

Looking at when you restarted CMX on the 5th October, there is something odd.

CMX was shut down on 5th Oct @ 13:41, that was the last time written to today.ini

When CMX was restarted on the 5th @ 13:42, it read today.ini and the last update time it contained was 4 Oct @ 23:59. Did you restore a backup whilst CMX was stopped for that minute for some reason? You need to explain exactly what you are doing as the behaviour you are seeing is not "normal".

I cannot see what happened on the 1st Oct as those logs no longer exist.

From what I can see from the logs that do exist (apart from 4/5th) is that the rollover happened correctly, and the rainfall totals continued as expected the following day. Your graph above does not show the rainfall from the 4th being carried forward to the 5th either.

Basically what I do, and what I've been doing since 2014 with usually no issues is:
Hibernate PC after midnight (with CMX still running)
Resume PC sometime later that day, with CMX running, but with data missing during the hibernation period
Close CMX
Restore backup from either midnight, or the most recent backup before PC was hibernated
Launch CMX and let it download the archive data including the missing data from when the PC was hibernated
99% of the time, this has not had any issues. The duplicated day entries only began earlier this year, and the rainfall errors either began at the beginning of October, or possibly earlier.

As for "your graph above does not show the rainfall from the 4th being carried forward to the 5th either" it did. I just have logging intervals set to 1 minute, so it's hard to see. You can see the 3.8 mm drop at about 13:42 as well.

Here's a much more zoomed in graph showing the rainfall data on the 5th being carried over at 00:00 on the 6th, but only resetting to 0.00 at 00:01: Here are the logs for September 30th and October 1st, if necessary:

Hows about shutting down MX before you hibernate, and then launch MX when you come out of hibernation? It's a well documented fact that you should not hibernate or sleep your system with MX running.