Month.ini
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 redesign this page and 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.
Introduction
The log file "month.ini" is where Cumulus software tracks the extremes for this month, the file is divided into a number of sections headed by a name in square brackets [].
The sections (after the first [General]) can be in any order, Cumulus will maintain whatever order the sections are currently in.
Each section has a number of parameters listed below it. Each parameter is in the format "attribute=value". For readability you can insert blank lines into this file, Cumulus will not mind.
Do not introduce any punctuation into this file. Do not change the format of any parameter line.
This log file holds the information that feeds the Webtags#Monthly for the 'thismonthT.htm' web template. So you won't find the monthly rainfall total in this file, that is not in that template.
Which build are you using?
Prior to Cumulus 1.9.1 (build 958 - Mon 01 Nov 2010)
There was no monthly functionality in Cumulus. This monthly log ini file did not exist.
Cumulus builds 1041 to 1088
Month.ini is one of the files that is included in the back up made each time there is a roll-over at the end of a meteorological day. All the files stored reflect the position as the day ended, not always the position as the new day starts. For example, Cumulus stores the Month.ini for the month just finishing when it does end of month roll-over.
Prior to Cumulus 1.9.3 beta build 1048
Month.ini contains the highest daily value for certain derivatives in the month, those daily values are supposed to be accumulated over a meteorological day, so the accumulation resets at rollover time. Due to a programming bug, some were reset at midnight irrespective of actual rollover time. Prior to build 1048 this meant that for those using 9am/10am rollover, wind run accumulated between midnight and rollover was assigned to the following day. Equally, some values where peaks at a particular time were tracked in this file, the date logged was adjusted to the correct calendar day, but between midnight and rollover it should be assigned to meteorological date (the previous calendar date) to ensure peaks were not assigned to wrong month. The full description of bugs was not recorded as it was assumed everyone updated to fixed build, and people did not care about past records (Cumulus 1 at this stage discarded records for past months). It was subsequently discovered that the bugs were not fixed completely in build 1048!
Prior to Cumulus 1.9.3 beta build 1053
Before to the release of build 1053,
- If your rollover time was NOT midnight
- If you restarted Cumulus 1 on the first day of a calendar month, before your rollover time on that day
- Cumulus created a new meteorological month early, and updated the month.ini as if it had started at midnight, losing everything in the month.ini for the previous month, and corrupting the month.ini for the meteorological month that correctly starts only after rollover.
Cumulus version 1.9.4: From build 1089 to final Cumulus 1 build
On the end of month roll-over back-up folder, Cumulus stores the month.ini after it has been initialised for the new month. No copy is retained of the month.ini at the end of the month.
Cumulus MX version 3.0.0 onwards
MX uses the same month.ini file to record extreme records for current month. At start of each meteorological day, MX backs up the current file as in its /data, so when the month changes, this backs up the (empty) file for new month. The content is essentially same as other flavours except that when new extremes occur the date format used has year first as shown in example in table below. 3.6.x releases of MX add Canadian Humidity Index and Feels Like Temperatures to what is stored.
From build 3035 onwards, MX archives the month.ini and year.ini file at the end of the month/year as monthYYYYMM.ini and yearYYYY.ini. This means that although the file saved in the back up daily folder contains the month.ini for the new month and so does not back up the end of month position, the old monthly log ini file is preserved for true end of month state in the data folder with a new name.
Differences between Cumulus 1 and MX versions of file
Any date/time entries are in different formats as this example from the wind section shows.
More importantly, note that Cumulus 1 will use a comma for representing the decimal point if that is how a decimal point is defined for the locale defined in your device, but Cumulus MX always expects periods/full stops in .ini files regardless of the locale in use. Thus if you want to swap from Cumulus 1 to Cumulus MX during a month, you will first copy your existing Cumulus 1 "data" folder to within your MX installation, but then you will also need to manually edit your month.ini file if you had a "," used as decimal separator to change those to ".". (While Steve Loft was working on MX he did say he was trying to find a way to get MX to accept ",").
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.
 |
|
|---|---|
| [Wind] | [Wind] |
| Speed=33,5540428161621 | Speed=7 |
| SpTime=12/03/2019 12:39:35 | SpTime=2019-03-16T15:11:32 |
| Gust=42.8843040466309 | Gust=20 |
| Time=12/03/2019 14:50:45 | Time=2019-03-16T12:45:00 |
| Windrun=29,2999992370605 | Windrun=29.2999992370605 |
| WindrunTime=11/03/2019 23:59:01 | WindrunTime=2019-03-10T19:54:00 |
From version 3.6.0, an additional [FeelsLike] section is added to this log file.
Retaining month.ini after month changes
In Cumulus MX, at the end of each month, the final month.ini for that month is renamed monthYYYYMM.ini (where YYYY denotes the year using 4 digits and MM denotes the month using two digits) e.g. month201703.ini, thus ensuring that statistics for all past months remain accessible.
There is no obvious facility to achieve a similar retention automatically in Cumulus 1, although all the information can be generated by doing calculations from the relevant lines in dayfile.txt and those calculations are very easy to code in SQL if the daily summary is available in a database. However, there is an inefficient (because there is no facility within Cumulus 1 to perform an action only when month ends, and this technique therefore adds an action each time Cumulus does an update) work-around using the "extra files" feature that you can include "<currentlogfile>":
ExtraLocal25=data\month.ini ExtraRemote25=data\month<currentlogfile>.ini ExtraProcess25=0 ExtraUTF25=1 ExtraBinary25=0 ExtraRealtime25=1 ExtraFTP25=0
This will save a file with a name like monthMar19log.txt.ini in your data folder. Note that there might be changes to month.ini after the last time the above work-around copies it, because the copy happens before the end of the month rollover and so will not pick up any extremes recorded in closing seconds of the month.
Meaning of the different parameters
You have probably worked out that the attribute Speed in the examples in the above table is the maximum wind speed, that Gust is the maximum gust speed in the month and that Windrun is the maximum daily wind run. Those are the three rows that appear in the wind section of the table in the thismonth.htm web page. But you might be puzzled that the web page only shows a date for the maximum daily wind run, yet the month.ini entry includes a time. All that means is there was no wind after that time on that day, in Cumulus 1 if you edit your template thismonthT.htm and specify <#MonthWindRunHD format=HH:nn> you will see the time appear instead of the date. Put simply, the date/time entry is when Cumulus last updated that figure. In this particular case its calculated wind run never exceeded that figure in this month, so the entry has not been updated.
In the [Temp] section, some of Steve's attribute names might be slightly less obvious. Low= is obviously the lowest temperature in the month and High= the highest. Comparing entries against the web page; Highest Minimum is obviously HighMin= and HighRange= the Highest Daily Range. All the rest are easy to work out. For the date/time entries High is frequently (not in 'HighRange' example) abbreviated to 'H', Low to 'L' and the characters 'Time' are appended.
Dealing with Errors
For full details see Correcting Extremes page.
The diagnostic logs (for cumulus 1 in Diags folder) record before and after values for updates to highs and lows for monthly and annual extreme records, and can help if this file is corrupted by a false extreme. The stored values can be corrected in Cumulus 1 using the This month's records screen on the Edit menu. In MX the equivalent editor is accessed via the user interface you see in a browser.
If you cannot find the file when using Microsoft Windows see this FAQ.
Viewing and Editing in MX
There is limited viewing functionality prior to version 3.2.2 build 3058. From then onwards there is a monthly records viewer (that also works as editor) in the admin interface for each month in all years, consequently in first year of operation this effectively allowed editing of any single month. An editor specifically for this file for the current month is not available in MX until version 3.2.5 build 3061.
Cumulus 1 functionality
Viewing month.ini in Cumulus 1
These lows and highs and their timestamps can be seen (in Cumulus 1) by picking the Highs and Lows - This month screen from the View menu, see screenshot above. Like alltime.ini the file has section headings with lists of properties (attribute = value). For more information on this file see in the Cumulus help file, in the section “Data log file format”.
Editing in Cumulus 1
This monthly ini log file can be edited in Cumulus 1 using Edit menu This month's records screen.
