Monthly log files

Please see Standard log files, Extra Sensor Files, Air_Link_Log.txt, Month.ini, or Monthlyalltime.ini, as relevant.

Please be aware that all of the above links lead to documentation about files that may be described as monthly log files when reading individual Cumulus forum and wiki references.

Potential Name Confusion

Those who used early versions of Cumulus will remember that the term Log File was originally used for Log.xml, but Steve Loft later accepted that all the files with a .ini file extension could be described as log files, so he introduced the term Weather Diary. A bit later, the detailed data file, began to be also called log files, and the confusion grew. When Extra Sensor Files were added, these also became log files. The Wiki page now called "Standard Log Files" was first called "Log files", then became "Monthly Log Files" because "Log files" became a category. Then "Extra Sensor Files" were added and "standard log files" replaced "Monthly Log Files" to make it clearer which file held the standard values, and which file held values for extra sensors.

Steve Loft wrote the Cumulus software mainly for his own use, although after a while he let others use it and added features that others requested. Cumulus was developed in his spare time outside a full-time employment, and consistency and terminology were not issues he worried about.

During the development of the original Cumulus software (Cumulus 1 and 2) by Steve Loft, the name "monthly log" was most frequently used as a collective term for the last two (.ini) files linked above because those files tracked the monthly extreme records.

When Steve Loft was working on his MX Beta, he decided to implement within MX functionality the database schema that Mark Crossley had designed on this page, where Mark selected the name Monthly for the table. David A Jamieson created versions 1.0 and 1.1 of ImportCumulusFile for creating a single table called dayfile, but Mark extended it to cover realtime and what he called monthly log files. That means the standard log can in MX optionally feed data into a database table called Monthly by default in MX.

This database table terminology can be misleading as that database table is not organised by month in any way, a single table contains every logged line that has been inserted into it by Steve's ExportMySQL.exe, Mark's ExportToMySQL.exe, or by CumulusMX.exe itself. In fact MX allows you to give this table another name, which it will then use in all SQL.

Mark Crossley has taken over development of MX, the terminology "monthly log" is now being used for the first linked file (standard logs) instead of for month.ini the file that is truly logging monthly extremes. The name has been adopted simply because a new log file is started for each month.

For novices, there can be a feeling of confusion:

• The new practice leaves "month.ini" without a descriptive name
• Each "dayfile" line represents a new day so the filename matches the content, but a line in "Oct16log.txt" does not represent a month, and the file name does not contain the phrase "month"
• The names "Month.ini" and "Monthlyalltime.ini" do contain the phrase "month", they do contain monthly data in each line, and do log extreme records that clearly identify with a particular month

A future Wiki editor may decide on a different strategy, but at the moment the Cumulus Wiki has returned to the original Steve Loft terminology for each of the log files, for consistency with older articles in this Wiki, and the oldest posts on the forum.

Enhancement never implemented

Steve Loft was several times asked if he could change the design of his software and what it stored in Standard log files, Extra Sensor Files and the other detailed logging files.

All these files currently periodically store spot readings. Some of the competition in weather software, periodically store the highest and lowest since the previous line was stored.

One advantage of the alternative approach is that you never lose any extremes. Another advantage is the alternative allows people to report extremes for parts of days. For example, some people wanted 9 am to 9 pm reported separately to night time extremes, in other nations, the dividing time was 3 pm not 9 pm.

Steve Loft would respond he had made many design decisions that were not ideal, but the software was based on his own needs. If people wanted drastic changes, they should do what he had done, and write software that did what suited them.

Yet it appears he did plan to implement this suggestion in MX, see Cumulusmx.db#Releases 3.0.0 to 3.11.4 inclusive.