Alltime.ini
This page is about the file where all-time extreme records are tracked. The file now known as alltime.ini, was originally in a binary format when it was named alltime.rec (and this latter file will be described first).
Which Cumulus 1 build are you using?
Cumulus maintains a number of 'all time records' for the station -- highs and lows and their timestamps for many of the readings. For more information on this file see in the Cumulus help file, in the section “The Data log files”.
Up to Build 920 (version 1.8.9)
The highs and lows were stored in a database file (alltime.rec), this was efficient for Cumulus 1 to read and update.
As the file format was in binary code, it was hard for any corrections to be made outside Cumulus.
Build 920 (28 Feb 2010) initiated the use of a log of changes to the "alltime.rec" records, called alltimelog.txt, which can be found in the data folder. That file was in text format and it was easier to see changes to all-time extreme records there. It is also a useful log of when records were actually broken. An entry is added to this file every time an all-time record changes, with details of the old and new records. This log can then be used to 'backtrack' if spurious data causes an all-time record to be broken incorrectly.
Builds 921, 922, and 923 were never released, so in fact the next change was seen in the next public release as described next.
From Build 924 (4 March 2010 beta version 1.8.9)
Starting with Build 924 (still version 1.8.9) the Cumulus highs and lows and their timestamps are stored in a text file "alltime.ini" which can be easily edited if needed.
The first time you run Build 924, if will look for a "cumulus\data\alltime.rec" file. If it finds that file, it will read it, converting the database records into the text format used by alltime.ini file, which it creates.
If it does not find a "cumulus\data\alltime.rec" file, or it it finds both "cumulus\data\alltime.rec" file and alltime.ini file, then it simply uses the latter file whenever it needs to update an all-time extreme record.
There was a major issue with this change, some people installed Cumulus 1 into a write protected folder (C:\Program Files) and in this case with build 924 Microsoft Windows might create the new file in a folder where writing was permitted, meaning Cumulus could not find the file when it tried to read/update it. Please see this FAQ.
Although there were no changes to this file in the next few builds, another change was made as described next.
From build 927 (8 March 2020 beta version 1.8.9)
The alltime.ini file is now explicitly located in the "data" sub-folder of the path where your Cumulus.exe is installed, to stop Microsoft Windows relocating it.
Cumulus MX
The alltime.ini file is located in the "data" sub-folder of the path where your CumulusMX.exe is installed. If you are moving to MX from Cumulus 1, you can copy the contents of the Cumulus 1 "data" folder into the MX "data" folder, but you will need to edit this alltime.ini file as described below.
Just as the sections in the file varied with different Cumulus 1 versions, so in MX a new [FeelsLike] section was added by version 3.6.0.
Important Note
This page was written for the (legacy) Cumulus 1 software. It has been partially updated to cover MX, but that was for a MX release that is no longer latest!
Please can a contributor update content, so it is more friendly for those using latest release, while still helping those using older MX releases and the legacy Cumulus software.
Format of the file
This is as described at Category:Ini_Files, where some differences between the legacy Cumulus and MX are noted. Therefore if you use decimal commas and are migrating this alltime.ini file from Cumulus 1 to MX, you need to do an edit so all the values entries are converted to use a full stop as decimal separator.
The following table shows just one section from the file, that dealing with wind, as an example of the two formats with the Cumulus 1 side showing use of the comma that MX will not accept.
You do not need to edit the date/time entries as MX can read those in Cumulus 1 format, they will only change in "alltime.ini" when a new all-time extreme occurs and MX rewrites the file.
|
|
|---|---|
| [Wind] | [Wind] |
| highwindvalue=44,0676460266113 | highwindvalue=9 |
| highwindtime=09/02/2020 07:51:08 | highwindtime=2016-03-07T11:49:52 |
| highgustvalue=62,0693855285645 | highgustvalue=29 |
| highgusttime=09/02/2020 07:31:50 | highgusttime=2019-03-14T02:53:00 |
| highdailywindrunvalue=477,365875244141 | highdailywindrunvalue=89.6165924072266 |
| highdailywindruntime=09/02/2020 23:59:00 | highdailywindruntime=2014-03-26T23:59:00 |
The wind speed and gust speed may be shown as integers if that is how your weather station outputs them, and you have not asked Cumulus to calculate them in different units. The two columns shown represent different locations, that is why the contents do not match, this table is just to illustrate different formats.
How alltime.ini is used
If you restart Cumulus 1 during the day it will read this file at startup, so it can resume tracking extremes of the key parameters starting from latest stored values in alltime.ini. Equally, if you close Cumulus 1 during the day it will write the final values for highs and lows and their timestamps to alltime.ini as part of the close down process. Remember, while Cumulus 1 is running, the values shown in the table will usually be up to date, but there may be some time lag as it can hold values in an internal memory.
For Cumulus MX, the developers have not documented how it works, and I have not examined the code to this detail, but I believe it reads this file at start up and updates the file when necessary as it processes the various reads from your weather station. I saw no evidence of it being featured in the close down process.
Editing this log file
For full details see Correcting Extremes page.
It is possible that rogue values read from your weather station will cause this log file to show an incorrect extreme. As mentioned earlier, there is a log of changes to the "alltime.ini" records, called alltimelog.txt, so look at that to see when your rogue value was processed and what was the previous extreme that you should reset to in "alltime.ini".
Also note that the timestamp shown in alltime.ini includes a calendar date, so if you use a 9 or 10am rollover and you are trying to correct highs or lows for times between midnight and rollover, don't forget you need to look for the meteorological date (the date before the calendar date for those early hours) when seeking the relevant line in the daily log (dayfile.txt) to check in case if it too needs updating.
Editing alltime.ini within Cumulus
Remember, normally any rogue values are corrected in the monthly or daily log files first, and then resulting lows and highs are copied across to this all time log file using the in-built editor. However, you can also just edit any low, high or timestamp in this log file manually after looking at Alltimelog.txt for current and previous values.
Both Cumulus 1 and MX have internal editors for this file.
Expanding what it says in FAQ: FAQ#How_do_I_correct_my_all-time_.28or_monthly.29_records.3F, the stored values can be corrected in Cumulus 1 using the All time records screen on the Edit menu.
For Cumulus MX the editor is found in the admin interface.
- Both Cumulus editors allow you to read from the daily log or the monthly Standard_log_files, in case you created rogue values there first as advised above.
- In the cumulus 1 editor you can click to copy figures across,
- in the MX editor you can only manually overwrite with the revised figure.
Editing alltime.ini outside Cumulus
It is unlikely that you need to do this, given the functionality of the in-built editor.
Tips -- take a copy of the original log file before you work on it outside Cumulus.
Edit the original file using an editor that treats all fields as text [either any text editor, or a spreadsheet program that can be instructed not to recognise special field (like date) types]. All values have to be specified in the correct section, see #Post_Build_924_(version_1.8.9) above and follow the format of the property lines in the example below. Note that figures are held internally in Cumulus in binary, and converted to Base 10 numbers for the value shown. Since fractional binary values cannot be converted exactly to base 10 decimals, real numbers appear to be given to a strange decimal resolution with multiple decimal places.
Viewing the all-time highs and lows
Select Highs and Lows - All time from View menu.
Example of a larger part of the Cumulus 1 file
[Temperature] hightempvalue=30.7999992370605 hightemptime=27/06/2011 12:58:00 lowtempvalue=-12.5 lowtemptime=20/12/2010 07:17:00 lowchillvalue=-12.5 lowchilltime=20/12/2010 07:17:00 highmintempvalue=17.2999992370605 highmintemptime=10/07/2010 lowmaxtempvalue=-4.30000019073486 lowmaxtemptime=20/12/2010 highapptempvalue=33.7999992370605 highapptemptime=27/06/2011 12:50:00 lowapptempvalue=-15.8000001907349 lowapptemptime=20/12/2010 07:17:00 highheatindexvalue=34.2000007629395 highheatindextime=27/06/2011 13:09:00 highdewpointvalue=21.8999996185303 highdewpointtime=27/06/2011 13:09:00 lowdewpointvalue=-13.5 lowdewpointtime=20/12/2010 07:20:00 hightemprangevalue=20.3999996185303 hightemprangetime=20/04/2011 lowtemprangevalue=1.29999995231628 lowtemprangetime=31/12/2010 [Rain] highrainratevalue=114.300003051758 highrainratetime=23/09/2010 14:13:00 highdailyrainvalue=34.9000015258789 highdailyraintime=17/07/2011 22:19:00 highhourlyrainvalue=15.8000001907349 highhourlyraintime=23/09/2010 22:08:00 highmonthlyrainvalue=103.599998474121 highmonthlyraintime=01/02/2011 longestdryperiodvalue=17 longestdryperiodtime=24/04/2010 longestwetperiodvalue=16 longestwetperiodtime=16/02/2011 [Pressure] highpressurevalue=1043.30004882813 highpressuretime=26/01/2010 10:44:00 lowpressurevalue=965.700012207031 lowpressuretime=08/11/2010 15:42:00 [Humidity] highhumidityvalue=100 highhumiditytime=23/01/2010 01:10:00 lowhumidityvalue=21 lowhumiditytime=24/04/2010 12:10:00
