Cumulus Support

An unusual problem has occurred a couple of times now.
After midnight all the daily summaries of the previous day are set to whatever the value was at 00:00. The time being registered as 00:00. This is recorded in yesterday.ini
The actual monthlog data is ok, but of course it does affect some 'all time records', especially the daily temperature range which stands at zero since both the highest and lowest temperature are recorded as the same value.

I am using Cumulus 1.9.4 1074
The computer is on 24hrs a day.

This is the contents of yesterday.ini as copied at 9:13 on Sunday morning (28th).

[General]
Date=28/07/2013
[Wind]
Speed=4.9
SpTime=00:00
Gust=3.8
Time=00:00
Bearing=225
Direction=SW
Windrun=0.161345034837723
DominantWindBearing=200
[Temp]
Low=14.7
LTime=00:00
High=14.7
HTime=00:00
HeatingDegreeDays=0.00499999942258
CoolingDegreeDays=0
AvgTemp=14.6999998092651
[Pressure]
Low=1005.4
LTime=00:00
High=1005.4
HTime=00:00
[Rain]
High=0.0
HTime=00:00
HourlyHigh=0
HHourlyTime=00:00
RG11Yesterday=0
[Humidity]
Low=85
High=85
LTime=00:00
HTime=00:00
[Solar]
SunshineHours=0
HighSolarRad=0
HighSolarRadTime=00:00
HighUV=0
HighUVTime=00:00
[HeatIndex]
High=14.6999998092651
HTime=00:00
[AppTemp]
Low=13.859769821167
LTime=00:00
High=13.8746633529663
HTime=00:00
[WindChill]
Low=14.5539646148682
LTime=00:00
[Dewpoint]
Low=12.2104835510254
LTime=00:00
High=12.2104835510254
HTime=00:00

----------------------
Edit- I just noticed that there are 2 lots of data for the 27th July in the dayfile.txt

27/07/13,9.2,180,09:29,11.2,04:11,23.1,11:04,1005.0,20:59,1012.2,00:02,0.0,00:00,0.0,16.4,69.1,6.1,09:25,56,10:55,93,06:01,0.00,0.0,23.1,11:04,23.5,11:06,10.5,04:33,0.0,00:00,11.2,04:11,15.2,09:23,10.0,04:11,151,2.6,0.8,0,00:00,0,00:00
27/07/13,3.8,225,00:00,14.7,00:00,14.7,00:00,1005.4,00:00,1005.4,00:00,0.0,00:00,0.0,14.7,0.2,4.9,00:00,85,00:00,85,00:00,0.00,0.0,14.7,00:00,13.9,00:00,13.9,00:00,0.0,00:00,14.6,00:00,12.2,00:00,12.2,00:00,200,0.0,0.0,0,00:00,0,00:00

Please zip up the diags folder and attach it.

The diags zip, as requested.

Your PC clock went backwards just after midnight, so it became the previous day again; I suspect you have Windows set to adjust the clock at midnight. You'll need to set it to do it at a more sensible time.

Cumulus does normally cope with this, but in addition, for some reason it was force closed (or it crashed - is there a bugreport.txt file?) at almost exactly midnight, just after the clock change, so when it started up again the last time it had written today.ini was before midnight, so it did the rollover again.

Note that you are using an out of date version of Cumulus; if you are going to use the beta version, you should really keep up to date with the updates. If the cause of the restart was a crash, it may well have been caused by a bug which was fixed in a later version.

Many thanks for your help, Steve.

A very interesting conclusion. The PC clock is synchronised with the internet time, and seems to do this once a week. I have now updated it this morning at 11:11 am and I assume that means it will update again at the same time next week. (hopefully) It is an aspect of the computer's operation that I hadn't really considered before.

The computer was on its own at midnight so I don't know what it was doing. Possibly Windows closed itself and restarted for some reason. I can't find any bugreport for last night.

I normally do regularly check the updates page for the reasons you stated, and thought I had updated last at the beginning of July. However, I copied the programme to another computer, and back again a week ago. I do this occasionally if I need to use another computer. I always leave a copy as a backup, and I may have somehow reintroduced an older version by mistake. Easily fixed!

I assume I can correct these errors by deleting the second '27th' in the dayfile, and editing the 'yesterday.ini' with the correct values, then editing the monthly and all time record files.

logjam wrote:I have now updated it this morning at 11:11 am and I assume that means it will update again at the same time next week.

No, it will do it at the configured time. You'll need to go into the settings and change it. Unfortunately I can't remember how you do that in Windows 7.

I assume I can correct these errors by deleting the second '27th' in the dayfile, and editing the 'yesterday.ini' with the correct values, then editing the monthly and all time record files.

Yes. An alternative would be to restart from the the latest backup before the problem occurred (i.e. with Cumulus stopped, copy the files from the backup folder to the data folder and then start Cumulus)

It took a little while to dig it out, but for the benefit of anyone else, it seems you need to do it through 'Administrative Tools'
'task scheduler'
'synchronize time'
and the 'trigger' tab.
use 'edit' on the right hand pane.

It was actually set for 1am, so I don't know what happened there. I reset it for 9pm, which should be safe.

logjam wrote: It was actually set for 1am, so I don't know what happened there.

Corrected for DST perhaps?

Steve suggested that the Internet clock check might had been set for midnight, but it turned out that wasn't the case. As I understand it, Windows sets the internet clock check for 1am local time as default, and that was the case with my computer. There is not normally a DST clock change at the end of July either. Cumulus somehow experienced 2 midnights. I did change the unit's sample period to 2 seconds before going on holiday a few weeks before. That might have wrong footed Cumulus' with its 1 second sample rate, especially if there was some other problem. I have put the unit back to 1 second, and it hasn't happened again. - yet. It wasn't difficult to correct the data error.

I think the most important thing is to report it. It might prove valuable if another related problem crops up elsewhere.