Dayfile.txt: Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
6,345 bytes added ,  13:55, 18 March 2020
m
→‎Introduction: add sentence about Cumulus 1 and mX
m (→‎Manipulation outside Cumulus: re-sequenced points after adding MX caution)
m (→‎Introduction: add sentence about Cumulus 1 and mX)
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Introduction =
Cumulus maintains a daily log file that holds the highs and lows of each day, as well as a few other nuggets of information.  The figures contained in the file are used for the 'This period' display accessed from the '''View''' menu and to build any graphs based on daily values.
Cumulus maintains a daily log file that holds the highs and lows of each day, as well as a few other nuggets of information.  The figures contained in the file are used for the 'This period' display accessed from the '''View''' menu and to build any graphs based on daily values.


The format of this file is the same for both Cumulus 1 and Cumulus MX. It can be ported between them only if both run with exactly the same locale settings, as using a different locale may change the field separator or the symbol used for decimal points.


== How Cumulus uses the daily log ==
== When Cumulus is left running ==
*Cumulus is frequently reading observations from your weather station.
* Cumulus is frequently reading observations from your weather station, but these don't affect the daily log "dayfile.txt" as it is only updated once a day.
*It tracks the highs and lows in those observations by comparing read values against those it has stored in [[Today.ini]], updating that file as required.
* There are no updates to dayfile.txt at any other times, but the contents of the file are read and processed for many of the display and edit menu options when selected from the main Cumulus 1 screen.
*(It also updates [[Alltime.ini]], [[Monthlyalltime.ini]], [[Year.ini]], and [[Month.ini]] when appropriate.
* Cumulus tracks the highs and lows in weather observations by comparing read values against those it has stored in [[Today.ini]], updating that file as required. (It also updates [[Alltime.ini]], [[Monthlyalltime.ini]], [[Year.ini]], and [[Month.ini]] when appropriate.
See the Wiki pages for these files or the Cumulus Help for more information, including the details of where the previous values are logged for updates to these highs and lows).
* Cumulus will not mind you accessing the daily log outside its software, except when it needs write access for processing end of day.  
*When Cumulus processes the end of the (meteorological) day, the highs, lows and other information in 'today.ini' are used to append a new line into dayfile.txt, then a new 'today.ini' is created initialised with the observations just read from the weather station.  
* If you do need to correct some rogue data in the log file, first take a copy and work on that copy, because any edits you do could muck up the specific format that Cumulus 1 or MX needs, there is a section on dealing with rogue data below. Only when you are absolutely sure that your edited copy meets all the constraints listed later, should you replace the original.
*When Cumulus is restarted after a break in running,
*#it uses the rainfall totals for each day stored in the daily summary log to calculate the rainfall for this month, and this year/season (see [[FAQ#Where_does_Cumulus_get_its_this_month_and_this_year_rainfall_totals_from.3F|FAQ]])
*#depending on the make of weather station:
*#*read observations from the station's log into the Cumulus monthly log, updating today.ini as it processes the station log;
*#*otherwise the observations in the station's current measurements holder at the Cumulus logging interval are what gets written into the monthly log, and update today.ini.
*Back ups of all the files mentioned here are copied to the 'cumulus\backup\daily' folder.
*There are no updates to dayfile.txt at any other times, but the contents of the file are read and processed for many of the display and edit menu options when selected from the main Cumulus 1 screen.


=== When Cumulus processes the end of the (meteorological) day ===
*It updates the daily log, the highs, lows and other information in 'today.ini' are used to append a new line into dayfile.txt, and some of this information is also stored in [[yesterday.ini]].
*Back ups of all the log files mentioned here (not all the log files) are copied to the 'cumulus\backup\daily' folder, a total of 9 sub-folders are retained.
* Some people take a copy of the local file, after it has been updated and store it on (or file transfer it to) their web server. One way of doing this is [[Upload_Dayfile| described here]].
=== When Cumulus is restarted after a break in running  ===
* It reads the daily log and uses the rainfall totals for each day stored in the daily summary log to calculate the rainfall for this month, and this year/season (see [[FAQ#Where_does_Cumulus_get_its_this_month_and_this_year_rainfall_totals_from.3F|FAQ]])
* Thus you must not have another process attempting access to the daily log when Cumulus is re-starting.
* Back ups of all the log files mentioned here (not all the log files) including dayfile.txt are copied to the 'cumulus\backup' folder, the last 8 only are retained.
== How you can use the daily log ==
== How you can use the daily log ==
*If you want to run scripts that use the daily log, it is best if you take a copy first, I take a copy that is put onto my web server by using the '''Daily''' box in the bottom left of the ''Sites/Options'' frame within the ''Internet'' options screen from the '''Configuration''' menu to safely take a copy of 'dayfile.txt' after it is updated.  See Cumulus '''Help''' for information on using this feature, I add a redirection ">daily_batch.log" in the parameter box alongside so that any output from my "T:\Cumulus\daily_batch_all.cmd" in the main box is sent to a log file overwritten in each run; this enables me to see the reason for any failure.  My Cumulus 1 batch command also runs PHP to create SQL to update a database table version of the log, but my database table version also contains some additional information from the daily backup '[[today.ini]]' log.  
* If you want to run scripts that use the daily log, it is best if you take a copy first, you can ask Cumulus 1 to take a copy after each update by using the '''Daily''' box in the bottom left of the ''Sites/Options'' frame within the ''Internet'' options screen from the '''Configuration''' menu; that will safely take a copy of 'dayfile.txt' after it is updated. This has the advantage it happens even if Cumulus has been stopped and restarted and rollover is happening during catch-up and so not at usual rollover time according to the computer clock.  See Cumulus 1 '''Help''' for information on using this feature, I add a redirection ">daily_batch.log" in the parameter box alongside so that any output from running the command file I specify in the main box is sent to a log file overwritten in each run; this enables me to see the reason for any failure.   
*The system routines that Cumulus uses to access dayfile.txt require exclusive use of that file, so if you have any other process trying to access that file at end of the (meteorological) day, or when a relevant option is selected from View or Edit menus, one or other may fail.  
* Cumulus MX has option to list files to be transferred once a day as part of rollover, so you can use that to generate your extra copy. This has the advantage it happens even if Cumulus has been stopped and restarted and rollover is happening during catch-up.
*You can find examples of code that uses the daily log elsewhere in this Wiki and on the support forum.
* A third party toll "Cumulus Toolbox" can also be used to copy/transfer files at a particular time. Note this cannot tell whether Cumulus has done its rollover at the normal time, or during catch-up.
*Cumulus MX includes the ability to generate SQL to update a database table version of the log. Using that database table avoids any clash with the Cumulus MX update of the daily summary log.
* There are other ways to specify that when a file changes it is copied somewhere.
*The system routines that Cumulus uses to access dayfile.txt require exclusive use of that file, so if you have any other process trying to access that file when Cumulus restarts, when Cumulus processes end of the (meteorological) day, or when a relevant option is selected from View or Edit menus, either your external process or the Cumulus process may fail.
 
== Populating a database table ==
* The [[ImportCumulusFile|article here]] describes a method that can be used with Cumulus 1 to mimic the contents of dayfile.txt in a database table.
* Cumulus MX includes the ability to generate SQL to update a database table version of the log.  
 
In both cases, your web site can use that database table avoiding any clash of timing with the Cumulus 1 or MX use of the daily summary log. For examples of some of the third party tools using the database daily summary table see [[Daily Summary#Some_example_Scripts|here]].
 
Of course you do not need to exactly mimic the log file with the schema in your database table, your weather station may not produce solar values so those fields in dayfile.txt need not be columns in your database table, or you may wish to add other values from external sensors or other log files. MX allows you to specify a different schema in the SQL it generates. In my own case, my daily summary table has no solar columns but it does have several additional columns (including the daily increment of chill hours, the cumulative chill hours, the time of the last rain tip, wind bearings as compass characters (e.g. NNW) as well as numerical bearings). I use Cumulus 1 so I have written the PHP script to find all these additional values, for example it reads the [[today.ini]] stored in the end of day backup, but other sources are also used. In my case I also store the equivalent of what appears on my version of "thismonth.htm" each month in another database table. This monthly summary table allows me to have web pages that compare consecutive months or compare months between years. Again MX has the ability to store end of month figures, a feature that Cumulus 1 and 2 lacked.
 
== Viewing or Editing the daily summary log ==
 
=== Editing the file or other Manipulation outside Cumulus ===
The file is <tt>data\dayfile.txt</tt> within the directory holding the Cumulus executable, it can be viewed in a text editor, imported into various database systems, or imported into spreadsheets, to manipulate as you wish.  Just remember that Cumulus reads it when it is restarted, and updates it as part of the rollover process, so never attempt to work on it either when Cumulus has just been restarted and is checking/updating (and possibly doing a rollover of logs), or around the midnight/9am/10am local rollover time when Cumulus is writing a new row.
 
'''Tip''':  Take a copy of the file before you do any edit outside Cumulus, so you can revert to old file.
 
'''Note''': Since new versions/builds can add to number of fields, Cumulus will accept lines of 15 fields or more (including without the more recent fields at the end).  (Additions by versions are indicated below, you can explore details of earlier versions via the official [Software software/download] page).
 
'''Important Rules''':
These notes were written for Cumulus 1, at the time this article was updated MX had not introduced any changes to the Cumulus 1 version of this daily log file, but check release notes in case that is no longer true in the future.
* The file must never be edited with a word processor, as they store many control and identification characters that prevent Cumulus correctly reading the values.
* It is recommended that you use either a specialised "Comma Separated Value" file editor or a text editor, both of these can be easily used. You can use a spreadsheet tool, but if you do, there may be a number of settings to change from their defaults to ensure the file remains in a readable format for Cumulus.
* All rows must ''start with date'' and include some of the parameters listed ''in correct sequence''.
* The file should be saved without "Byte Order Mark", specialised text editors will include a menu where you select the encoding and can select not to include BOM.
* The (meteorological) date format uses ''two digits for the year''. This is one reason why you need to edit this file using an editor that treats all fields as text (a text editor, a CSV editor, or a spreadsheet program that can be instructed ''not'' to recognise special field types).  For software (e.g. Excel) with default of recognising formats, ensure that such recognition is turned off, as it is likely to change the dates to either a number representing days since e.g. 31 Dec 1899, or to change it to four figure years, and then Cumulus will no longer be able to use the log file.
* (Remember the month must be the middle figure in the date, USA convention cannot apply within logfiles). The separator between the three parts of the date should be a '-' hyphen or a '/' slash, it cannot be a space. Although, use of comma or point for separating parts of the date is allowed by Cumulus, it is not recommended as it can cause issues for subsequent edits.
** If you move your software to a new device, or you change from Cumulus 1 to Cumulus MX (or back), then you must ensure your dates still use the same separator, so all lines are consistent. Equally if you use any third-party packages like for example "Cumulusutils", the separator used in first line is assumed to be true for all lines. Some third-party tools have to be told what separator you use for dates.
* The fields are separated using the Windows (or whatever operating system you are using for MX) list separator (e.g. a comma or semi-colon)[[File:Open office (editing cumulus log files).png]] If you wish to use Excel, or to use "Calc" in 'Apache Open Office', "Libre Office", or similar, you may on opening the file need to pre-select the field separator you use (in this illustration comma is selected, but your file might use semi-colons between fields, don't select commas if your real numbers use comma between integer and decimal parts) and leave "Detect Special Numbers" (or whatever similar feature name your tool uses) unselected. Again third party packages processing dayfile.txt will need to recognise your field separator, and some may need to specify it.
* Rows can vary in length but only by missing off ''fields at the end''.
* Most value fields are in ''real number format x.y'' using your system decimal notation, a few (e.g. bearings, solar, humidity) are ''integers'' (see [[#List_of_fields_in_the_file]]). Whilst an integer can be used for a real number field, decimals are not allowed in an integer field.
* If you insert a ''lowest or highest value'' for a new day, where there was no record before, insert a ''time-stamp'' too, as a dayfile.txt row is only accepted by the Cumulus editor if each value has any related time-stamp. (Use a time-stamp of your rollovertime 00:00, 09:00 or 10:00 if you have not looked up the precise time). If you are using a 9am or 10am rollover time, create missing in Cumulus inserts 00:00 for null time-stamps, but normally Cumulus uses the rollover time for null time-stamps.
* Times appearing for some of the fields must always be in ''format HH:mm'' i.e. 2 digit hour, followed by a colon, then 2 digit minutes (Be aware you will have problems if you, or your editing software, add seconds). Except for wind gust (start of line), each time field will immediately follow the value for that parameter.
* Shorter lines can have multiple field separators added at end of row added either when editing within Cumulus or when editing using a spreadsheet tool. (during editing after all available valid parameters inserted, extra field separators may be added at end of shorter lines inserted by 'Create Missing' or by a spreadsheet as these make all lines end up with same number of fields)
* Nulls (2 field separators without something between them ',,') are thus allowed at end of line, but are not allowed within the part of the line with values and time-stamps. If you are editing out rogue values and if you do not know the value for a particular field within the line, then type in a zero or 9999 for nulls in integer format and an extreme with opposite value (e.g. -999.9 for a signed decimal maximum, and 9999.9 for a decimal minimum) for nulls in decimal format (replace the full stops with your decimal separator).
**Beware - if you do insert zero or an obviously wrong extreme value, Cumulus will display those in any editing screen where you wish to update the all-time, monthly-all-time, this month, or this year, extremes.  This can make editing by picking values in logs harder.
**Cumulus itself will use zero for any parameters (e.g. solar) not provided by your station, and will repeat the last valid value if the station fails to send a value it should provide, so if a station fails to send a value for more than a day, dayfile.txt may show the same value as the previous day.
*** Note that Cumulus will stop if your station fails to send what it considers as a vital reading, like pressure or temperature, so the previous point does not apply in all cases.
**Some third-party scripts read the file to calculate averages or other statistics, and their authors suggest you remove rogue values (creating the ',,' that Cumulus objects to). You must never do this in the dayfile.txt that Cumulus processes. My suggestion is use the 'External Program' facility to create a copy of ''dayfile.txt'', make any such changes only on that copy, and set the third-party script to read this copy. 
*** Alternatively, do as I do, clean your data as you upload the file into a database. I use a script with validation code checking for  rogue values and recognising the -999.9 etc., in all cases my script will store a '''NULL''' value as default in the database table if that validation finds any obviously invalid figure.
* The row terminator for Windows is ''CR LF'', ensure any external editor does not change the two character terminator into a single character. Similar rules apply for terminators used by other operating systems, so be careful if you edit the file on a different device to that running Cumulus.
* Make sure that any editing does not create any ''blank lines'' in the file. Cumulus assumes an empty line means end of processing.
* Don't add a header line to the file, Cumulus expects all lines to be data lines.


== Viewing or Editing the daily summary log within Cumulus ==
=== Editing daily summary in Cumulus ===
'''This section applies to Cumulus 1.x.y only - Cumulus MX v3.0.0 (checked at build 3043) does not provide an editor'''
'''This section applies to Cumulus 1.x.y only - Cumulus MX v3.0.0 (checked at build 3043) does not provide an editor'''


Line 28: Line 75:
Click the ''Help'' button for detailed instructions.  Cumulus Help is comprehensive.
Click the ''Help'' button for detailed instructions.  Cumulus Help is comprehensive.


If a particular day does not exist as a row on the daily summary log, then 'create missing' can search the observations in the relevant monthly log, and calculate approximate highs, lows and totals to insert as an exta row in the daily summary log. These are approximate because the actual highs and lows for that day are quite likely to have occured at moments inbetween those that were logged.
If a particular day does not exist as a row on the daily summary log, then 'create missing' can search the observations in the relevant monthly log, and calculate approximate highs, lows and totals to insert as an exta row in the daily summary log. These are approximate because the actual highs and lows for that day are quite likely to have occurred at moments in-between those that were logged.
 
=== Editing daily summary in Cumulus ===


If there is an error in ''dayfile.txt'', then it is most likely to be found when you are viewing its data on one of the screens for editing the monthly, annual or all-time extremes.  Cumulus will illuminate its ''Error'' light if it finds an error in such cases and tell you the line/row number of the first found error, together with some details of the error it found. For example, if a row is blank, a row is duplicated, a field is corrupted, a field does not have an acceptable value, or a field is missing so subsequent fields are to the left of where they should be.
If there is an error in ''dayfile.txt'', then it is most likely to be found when you are viewing its data on one of the screens for editing the monthly, annual or all-time extremes.  Cumulus will illuminate its ''Error'' light if it finds an error in such cases and tell you the line/row number of the first found error, together with some details of the error it found. For example, if a row is blank, a row is duplicated, a field is corrupted, a field does not have an acceptable value, or a field is missing so subsequent fields are to the left of where they should be.
Line 36: Line 81:
You can use this editor as follows:
You can use this editor as follows:
*use '''insert''' key to add one or more missing rows (complete days) manually,
*use '''insert''' key to add one or more missing rows (complete days) manually,
*correct individual values by overtyping,
*correct individual values by over-typing,
*use '''delete''' key to remove an entire day (e.g. if you get a 'duplicate' error message),
*use '''delete''' key to remove an entire day (e.g. if you get a 'duplicate' error message),
*use '''Create missing''' button to insert missing rows (complete days) by reading from [[Monthly_log_files]] and automatically calculating the best approximations for each field for those missing days.
*use '''Create missing''' button to insert missing rows (complete days) by reading from [[Monthly_log_files]] and automatically calculating the best approximations for each field for those missing days.
Line 75: Line 120:
== Using the daily summary log on your web-site ==
== Using the daily summary log on your web-site ==


If you upload the file to your web site, then see [[AnnualDataSummary]] for information about one of the ways to show values from this file. Search the Cumulus support forum to see ways that others extract information from dayfile.txt to display on their web page a set of fields similar to those shown for 'Yesterday' web page for other dates in the past. Other people use dayfile.txt for [[ImportCumulusFile|updating databases]] stored on their web sites so that SQL can be used to display all sorts of statistics, again postings on the forum discuss this.
If you upload the log file to your web site then (with the help of JavaScript) you can read the log file to obtain information to show on a web page.  You could have a web page that shows a today.htm like table for the last 7 days by combining reading Cumulus web tags with reading from the log file.  
 
Search the Cumulus support forum to see (for example) how others extract information from dayfile.txt to display on their web page a set of fields similar to those shown for 'Yesterday.htm' web page for other dates in the past, such as one year ago.  
 
If you use a script to read what is in the  daily summary log file into a database table, or use the functionality in Cumulus MX to upload automatically to a database table, then see [[Daily_Summary]] article for information about ALL of the ways to show values from this database table.


==Viewing summary figures for a month or period==
==Viewing summary figures for a month or period==
Line 98: Line 147:
**The web tags report longest dry or wet period in the month.
**The web tags report longest dry or wet period in the month.


==Manipulation outside Cumulus==
The file is <tt>data\dayfile.txt</tt> within the directory holding the Cumulus excutable, it can be viewed in a text editor, imported into various database systems, or imported into spreadsheets, to manipulate as you wish.  Just remember that Cumulus updates it as part of the rollover process, so never attempt to work on it either when Cumulus has just been restarted and is checking/updating (and possibly doing a rollover of logs), or around the midnight/9am/10am local rollover time when Cumulus is writing a new row.
'''Tip''':  Take a copy of the file before you work on it outside Cumulus, so you can revert.
'''Note''': Since new versions/builds can add to number of fields, Cumulus will accept lines of various lengths without the more recent fields at the end.  (Additions by versions are indicated below, you can explore details of earlier versions via the official [http://sandaysoft.com/products/cumulus product] page).
'''Important Rules''':
These notes were written for Cumulus 1, see the MX part of the forum for any differences introduced in the future.
* All rows must ''start with date'' and include some of the parameters listed ''in correct sequence''.
* The (meteorological) date format uses ''two digits for the year''. Edit this file using an editor that treats all fields as text (a text editor or a spreadsheet program that can be instructed ''not'' to recognise special field types).  For software (e.g. Excel) with default of recognising formats, ensure that such recognition is turned off, as it is likely to change the dates to either a number representing days since e.g. 31 Dec 1899, or to have four figure years, and then Cumulus will no longer be able to use the log file. (Also the month must be the middle figure, USA convention cannot apply within logfiles).
* The fields are separated using the Windows list separator (e.g. a comma or semi-colon)[[File:Open office (editing cumulus log files).png]] If you wish to use "Calc" in 'Apache Open Office', "Libre Office", or similar, select the field separator you use (in this illustration comma is selected, but your file might use semi-colons between fields, don't select commas if your real numbers use comma between integer and decimal parts) and leave "Detect Special Numbers" unselected. 
* Times are in ''format hh:mm'' (Be aware you will have problems if you, or your editing software, add seconds).
* Rows can vary in length but only by missing off ''fields at the end''.
* Shorter lines can have multiple field separators added at end of row (during editing after all available valid parameters inserted, they may be added at end of lines inserted by 'Create Missing' (or your external editing software) as all lines end up with same number of fields)
* Most value fields are in ''real number format x.y'' using your system decimal notation, a few (e.g. bearings, solar, humidity) are ''integers'' (see [[#List_of_fields_in_the_file]]). Whilst an integer can be used for a real number field, decimals are not allowed in an integer field.
* If you insert a ''lowest or highest value'' for a new day, where there was no record before, insert a ''time-stamp'' too, as a dayfile.txt row is only accepted by the Cumulus editor if each value has any related time-stamp. (Use a time-stamp of your rollovertime 00:00, 09:00 or 10:00 if you have not looked up the precise time).
* Nulls (2 field separators without something between them ',,') are not allowed within the part of the line with values and time-stamps, so if you do not know the value for a particular field within the line, then type in a zero for integer values and an extreme with opposite value (e.g. -999.9 for a signed decimal maximum, and 9999.9 for a decimal minimum) for decimal format (replace the full stops with your decimal separator).
**Beware - if you do insert zero or an obviously wrong extreme value, Cumulus will display those in any editing screen where you wish to update the all-time, monthly-all-time, this month, or this year, extremes.  This can make editing by picking values in logs harder.
**Cumulus itself will use zero for any parameters (e.g. solar) not provided by your station, and will repeat the last valid value if the station fails to send a value it should provide, so if a station fails to send a value for more than a day, dayfile.txt may show the same value as the previous day.
**Some third-party scripts read the file to calculate averages or other statistics, and their authors suggest you remove rogue values (creating the ',,' that Cumulus objects to). My suggestion is use the 'External Program' facility to create a copy of ''dayfile.txt'' and make any such changes only on that copy, and set the third-party script to read this copy.  Alternatively, do as I do, upload the file into a database, with validation code checking for the -999.9 etc, and store a '''NULL''' value as default in the database if that validation finds such an obviously invalid figure.
* The row terminator for Windows is ''CR LF'', ensure any external editor does not change the two character terminator into a single character.
* Make sure that any editing does not create any ''blank lines'' in the file.


==List of fields in the file==
==List of fields in the file==
5,838

edits

Navigation menu