Amending dayfile: Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
4,520 bytes added ,  14:40, 19 June 2021
m
Spelling corrections
m (Spelling corrections)
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Cumulus uses a daily summary log file, the fields in that file are listed at [[Dayfile.txt#List_of_Fields]].  The information about amending the file that was originally on the same page has been moved to this page.
Cumulus uses a daily summary log file, the fields in that file are listed at [[Dayfile.txt#List_of_Fields]].  The information about amending the file that was originally on the same page has been moved to this page. {{Version badge 1}}When the text was first created (on the other page) it was for the (legacy) Cumulus 1 software. {{Template:Version badge Mx}}As MX was developed, the text here has been amended to keep up, it currently applies up to release 3.12.0.
 
[[Category:Cumulus Files]][[Category:MX txt Files]]
This page was created with text for the (legacy) Cumulus 1 software, but it has been amended to cover MX as well.
{{Version badge 1}}{{Template:Version badge Mx}}[[Category:Cumulus Files]][[Category:MX txt Files]]


=How Cumulus uses the daily summary log=
=How Cumulus uses the daily summary log=
Line 12: Line 10:
For MX release 3.9.2 - build 3097 onwards, when the software first starts, the whole of '''dayfile.txt''' is read, the contents are used to drive the [[Highcharts_-_Historic]] functionality.
For MX release 3.9.2 - build 3097 onwards, when the software first starts, the whole of '''dayfile.txt''' is read, the contents are used to drive the [[Highcharts_-_Historic]] functionality.


The file is also read, if you are using the editor provided in Cumulus.
The file is also read, if you are using the editor provided in either Cumulus flavour.


==Writing a new line to the daily summary log file==
==Writing a new line to the daily summary log file==
Line 27: Line 25:
As discussed in [[Correcting_Extremes]], it is possible for rogue values to be read from a weather station, and propagate into various log files. An error in many of those files, corrupts a particular extreme record (or more than one), but generally does not stop Cumulus working.
As discussed in [[Correcting_Extremes]], it is possible for rogue values to be read from a weather station, and propagate into various log files. An error in many of those files, corrupts a particular extreme record (or more than one), but generally does not stop Cumulus working.


Since MX now reads the entire daily summary log when you start it up, an error in '''dayfile.txt''' can cause a more significant problem, most likely for historic charts, but it can affect other functionality!
Since release 3.9.2 (build 3097) MX now reads the entire daily summary log when you start it up. This implies that an error in '''dayfile.txt''' is now always picked up when MX starts, error messages will be added to the latest file in [[MXdiags folder]], but most Cumulus users will not realise there is a problem until they use historic charts (either in the local admin interface, or on a external web server).  There is other functionality that uses recent lines in the '''dayfile.txt''' for certain calculations.
 
== Thoughts required ==
 
To correct '''dayfile.txt''', you might think the best approach is to look in your [[standard log files|log file]] covering the relevant date, or to use "Create Missing" (which works differently for the legacy software and MX as explained later). Often that is not a good idea, your standard log file might be corrupted as well, and since these log files only record spot values, they miss any extremes occurring between the log entries. 
 
Equally, to stop Cumulus, and make it rewind, may worsen the problem, because you throw away the good data you have on other derivatives just to try to resolve one rogue value. 
 
If you discover the corruption within a few days of it happening, you can make use of an earlier [[Backup folder|back-up]] as explained later.




Line 55: Line 61:
| Moving from one device to another (and not ensuring same locale on both devices)
| Moving from one device to another (and not ensuring same locale on both devices)
| Correct "locale" and/or use an external editor that offers "Replace all" (see [[#Validation by in-built editors]])
| Correct "locale" and/or use an external editor that offers "Replace all" (see [[#Validation by in-built editors]])
| Use '''Control Panel''' to correct region. Correct "locale" and/or use an external editor that offers "Replace all"
| Use '''Control Panel''' to correct region (that defines decimal symbol). To edit the file, use an external editor that offers "Replace all"
|-
|-
| Inconsistencies in list separator (what comes between fields)
| Inconsistencies in list separator (what comes between fields)
| Moving from one device to another (and not ensuring same locale on both devices)
| Moving from one device to another (and not ensuring same locale on both devices)
| Correct "locale" and/or use an external editor that offers "Replace all"
| Correct "locale" and/or use an external editor that offers "Replace all"
| Use '''Control Panel''' to correct region. See [[#Using the Cumulus 1 editing feature]] to check file is now consistent.  
| Use '''Control Panel''' to correct region (that defines list separator). See [[#Using the Cumulus 1 editing feature]] to check file is now consistent.  
|-
|-
| Duplication of dates between lines (either consecutive lines, or non-adjacient lines)
| Duplication of dates between lines (either consecutive lines, or non-adjacient lines)
Line 72: Line 78:
# Restarting Cumulus after a crash, either manually using "Rewind" approach or Cumulus is confused by a corrupted file
# Restarting Cumulus after a crash, either manually using "Rewind" approach or Cumulus is confused by a corrupted file
| Manual editing outside MX in a text editor, if particular dates appear twice, see [[#Dates restart/repeat]]
| Manual editing outside MX in a text editor, if particular dates appear twice, see [[#Dates restart/repeat]]
| Manual editing outside Cumulus in a text editor, if particular dates appear twice, see [[#Dates restart/repeat]]
| The legacy editor can resequence lines for you, if no duplicates. However, if particular dates appear twice, see [[#Dates restart/repeat]]
|-
|-
| Some lines with fewer fields than others
| Some lines with fewer fields than others
| As explained at [[Dayfile.txt#List_of_Fields]], as Cumulus has developed, more fields have been added
| As explained at [[Dayfile.txt#List_of_Fields]], as Cumulus has developed, more fields have been added
| Use [[Calculate_Missing_Values#CreateMissing.exe|CreateMissing.exe]]
| Use [[Calculate_Missing_Values#CreateMissing.exe|separate CreateMissing.exe utility]]
| Use workaround described at [[#Legacy Workaround]]
| Use workaround described at [[#Legacy Workaround]]
|-
|-
Line 86: Line 92:
| Use [[#'''Create Missing''' on legacy dayfile editor]]
| Use [[#'''Create Missing''' on legacy dayfile editor]]
|}
|}
== Editors built into Cumulus ==
If you need to view, or edit, a line in the [[dayfile.txt|daily summary log]:
* MX: Use [[MX_Administrative_Interface#The_Data_Log_Viewing_and_Editing_interface|Edit menu in MX's admin interface]]
* C1: Use [[Cumulus_Screenshots#File.2FEdit.2FHelp_Menu|Edit menu on Main Screen]]
===Validation by in-built editors===
Both  the legacy editor and the MX editor will ensure that the correct number of fields is stored (as defined at the release where you do editing) (one common error in an external editor is to accidentally add/delete a field).
The legacy editor will allow you to edit the date field, the MX editor cannot change the date field.  The MX editor, reads the file into an array, it uses the array index for all actions on a particular line, and it then writes the array back to the file when you finish editing.
The legacy editor will validate any edit you make to individual fields; it checks for appropriate content (integer, real number, time-stamp).
Unfortunately, '''the editor provided with MX does not validate any fields'''.  In MX, the editor will save an edited line, even if there are errors in individual fields:
* you can put inappropriate content in a particular field  (integer, real number, time-stamp)
* you can use the wrong separator in fields you do edit (i.e. between hour and minute for time-stamps,  or between integer and decimal parts in any real number)


==Missing or Corrupted past ''dayfile.txt'' lines in any Cumulus software==
==Missing or Corrupted past ''dayfile.txt'' lines in any Cumulus software==


If you accidentally corrupt a line in the [[dayfile.txt|daily summary log]], then view the resulting file:
* MX: Use [[MX_Administrative_Interface#The_Data_Log_Viewing_and_Editing_interface|MX's admin interface]]
* C1: Use [[Cumulus_Screenshots#File.2FEdit.2FHelp_Menu|original Cumulus software]]


Note that both flavours have editors that can be used to check the file contents, even if you don't need to edit any line.
If you have one, or more, dates missing in your dayfile.txt file, then the first question is:
* '''Has the line been deleted by accident?'''
* ''Is the line missing because it was never saved into the file?''


If you have one, or more, dates missing in your dayfile.txt file, then the next question is, '''has the line been deleted by accident?'''
* If a line for a particular date was present before, but is now corrupted or missing:
 
*# See if you have a back-up of '''dayfile.txt''' with the line present, and correct
If a line for a particular date was present before, but is now corrupted or missing:
*#* If the missing/corrupted line is for a recent date, then Cumulus makes '''a backup of dayfile.txt every time it is restarted and after every end-of-day rollover'''
#See if you have a back-up of dayfile.txt with the line present and correct
*#* If the missing/corrupted line is for an older date, then ''maybe you took a back-up onto a separate drive or separate device''
#*If it is a recent date, then Cumulus makes a backup of dayfile.txt every time it is restarted and after every end-of-day rollover
*# If you have a suitable backup available, '''take a copy of that back-up file'''
#*If it is an older date, then maybe you took a back-up onto a separate drive or separate device
*# Append onto the copy of the backup, '''any dates after when that copy ends''', taking the extra lines from the current dayfile.txt
#If you have a suitable backup available, take a copy of that file
*# Rename the current dayfile.txt to say dayfile.old
#Append onto the backup, any dates after when that copy ends, taking the extra lines from the current dayfile.txt
*# Rename the copy you have edited to dayfile.txt and place into '''[[Data folder|data]]''' sub-folder
#Rename the current dayfile.txt to say dayfile.old
*# Cumulus will now use the file with all days correct
#Rename the copy you have edited to dayfile.txt and place into '''[[Data folder|data]]''' sub-folder
* If Cumulus never saved the line in the file in the first place
#Cumulus will now use the file with all days correct
*# The missing line will not be in any back-up
*# If it is the last line on the file that is missing (i.e. last rollover failed), take a copy of the whole [[data folder]], and keep that copy in a safe place
*# Now look in [[backup folder]], and open the '''daily''' sub-folder
*# If there is a subfolder within "daily" that was successfully created during the rollover that failed, rewind Cumulus by overwriting the contents of '''data'' folder with files from the backup in '''daily''' sub-folder. Restart Cumulus, and let it create a new dayfile.txt line.  Stop Cumulus again, restore the original files (except "dayfile.txt) from the copy you put in safe place
*# If the rollover failure meant a backup was not created in the "daily" sub-folder, this will usually be the case, you need to follow instructions for the MX, or legacy, Create Missing




''One lesson here, is to try to remember (once a week), to check your dayfile.txt log file is okay, because Cumulus retains back-ups for only the last 7 days''
''One lesson here, is to try to remember (once a week), to check your dayfile.txt log file is okay, because Cumulus retains back-ups for only the last 7 days''


'''Another lesson here, is to periodically take a backup, stored away from your Cumulus running environment in case you ever corrupt an old line'''
'''Another lesson here, is to periodically take your own backup, stored away from your Cumulus running environment in case you ever corrupt an old line'''


==Dates restart/repeat==
==Dates restart/repeat==


If you have a Cumulus crash (either because the connection between the weather station and Cumulus fails; or because there is a untrapped error in the Cumulus code; or because there is a power issue), then when it restarts it is possible that Cumulus will think it is doing catch-up from an earlier day, and the ''dayfile.txt'' may end up with consecutive lines being in date ascending order until the problem, then jumping back to an earlier date, before continuing in date asceneding order (but repeating one, or more, dates already in file).
If you have a Cumulus crash (either because the connection between the weather station and Cumulus fails; or because there is a unmanaged error in the Cumulus code; or because there is a power issue), then when it restarts it is possible that Cumulus will think it is doing catch-up from an earlier day, and the ''dayfile.txt'' may end up with consecutive lines being in date ascending order until the problem, then jumping back to an earlier date, before continuing in date ascending order (but repeating one, or more, dates already in file).


If Cumulus was working correctly before the problem, then the lines stored before the problem should be okay, just delete the lines that repeat earlier dates, so the file ends up being date ascending order with no dupicates. Similarly, if Cumulus was working correctly after the problem, but there was an issue before the restart, then keep the lines that repeat the dates, but delete the earlier lines with same dates, so the file ends up being date ascending order with no dupicates.
If Cumulus was working correctly before the problem, then the lines stored before the problem should be okay, just delete the lines that repeat earlier dates, so the file ends up being date ascending order with no duplicates. Similarly, if Cumulus was working correctly after the problem, but there was an issue before the restart, then keep the lines that repeat the dates, but delete the earlier lines with same dates, so the file ends up being date ascending order with no duplicates.


If there are two lines with the date when the problem occured, then it is likely you will manually have to edit the two lines into one line.  Any field with a time-stamp before the problem will be kept unless it is obvious that extreme was correctly broken (i.e. not rogue restart value) after the problem.
If there are two lines with the date when the problem occurred, then it is likely you will manually have to edit the two lines into one line.  Any field with a time-stamp before the problem will be kept unless it is obvious that extreme was correctly broken (i.e. not rogue restart value) after the problem.


If the dates restart in your daily summary log file, because you manually stopped Cumulus close to a rollover time, or you corrupted a file perhaps by regressing to an older release and back; then it is likely you will need to merge the two lines with same date, deciding for each value field which is more likely to be right, and matching it with correct time-stamp. A rainfall (or wind run) total might require summing totals in the two individual lines, or discarding a rouge value and accepting the other, your judgement!
If the dates restart in your daily summary log file, because you manually stopped Cumulus close to a rollover time, or you corrupted a file perhaps by regressing to an older release and back; then it is likely you will need to merge the two lines with same date, deciding for each value field which is more likely to be right, and matching it with correct time-stamp. A rainfall (or wind run) total might require summing totals in the two individual lines, or discarding a rouge value and accepting the other, your judgement!


==Validation by in-built editors==


Both  the legacy editor and the MX editor will ensure that the correct number of fields is stored (as defined at the release where you do editing) (one common error in an external editor is to accidentally add/delete a field).
==Correcting date separator errors==


The legacy editor does also validate individual fields for appropriate content (integer, real number, time-stamp).  
Cumulus uses a format of "day of month in 2 digits", separator, "month number as 2 digits", separator, "last 2 digits of year" in the first field of every line stored in '''dayfile.txt'''. It might be expected that "separator" is consistent throughout the file, because the device/locale when the line is created determines the separator.  The problem comes when a user moves their Cumulus installation to a new device, and forgets to ensure that new device uses same (Microsoft Windows PC) region, or (Unix, Linux, and other operating systems) locale, settings.


Unfortunately, '''the editor provided with MX does not validate any fields'''.  Thus you can use the wrong separator (between date elements, between hour and minute for time-stamps, between integer and decimal parts in any real number) in the MX editor and the incorrect line will be accepted.
Historic notes:
*In Cumulus 1 builds, any symbol (including ;, :, /, &, -, and .) character (excluding what is defined as list separator) within the first field of each line was treated as part of separator characters when parsing for date.  Thus Cumulus 1 was reasonably tolerant when someone moved to a new device.
*For builds 3000 to build 3049, MX used fixed offsets to find day, month, year in date field. This meant MX could process any file that the legacy software had accepted. The issue was this did not work for locales that used two characters for separator, and with MX now working with far more locales, this proved to be a serious problem.
*From Build 3050 MX uses the separators, defined by the locale, to split the values (so allowing for multi-character separators).  The same character(s) had to be used in every line of the file, or this gave a new problem.


==Correcting date separator errors==
Some [[Daily Summary|third party routines]] for reading dayfile.txt take a different approach, they check the first field for the first character that is not a "0 to 9" digit, take that as start of separator, then look for the next "0 to 9" digit, that belongs to next part of the date, so the separator ends at previous character.  Other third party routines, ask user what they use as date separator


=== Date Separator in MX===
=== Date Separator in MX===
Line 146: Line 175:
The legacy software accepts any character (except space) as the separator between the day of month, the month, and the year, elements of the date.  Therefore Cumulus 1 does not care if that separator is sometimes "/", sometimes "-", and/or sometimes ".".
The legacy software accepts any character (except space) as the separator between the day of month, the month, and the year, elements of the date.  Therefore Cumulus 1 does not care if that separator is sometimes "/", sometimes "-", and/or sometimes ".".


Historic note: In Cumulus 1 builds, any symbol (including ;, :, /, &, -, and .) character (excluding what is defined as list separator) within the first field of each line was treated as part of separator characters when parsing for date. For builds 3000 to build 3049, MX used fixed offsets to find day, month, year. From Build 3050 MX uses the separators defined by the OS to split the values (so allowing for multi-character separators), but it does mean it will be sensitive to the separator value changing.


= Importing data not recorded by Cumulus =
= Importing data not recorded by Cumulus =
Line 152: Line 180:
You might have been using your weather station with some other weather software before you installed Cumulus.  If you can get weather data in the format of daily summaries (and the rollover times match), you can import that data into the Cumulus '''dayfile.txt''' file using a script or spreadsheet package.  All you have to ensure is that you can arrange the output to be in lines with fields in sequence shown in [[Dayfile.txt#List_of_Fields]].  There is more guidance later on this page about the rules you must obey for this file.
You might have been using your weather station with some other weather software before you installed Cumulus.  If you can get weather data in the format of daily summaries (and the rollover times match), you can import that data into the Cumulus '''dayfile.txt''' file using a script or spreadsheet package.  All you have to ensure is that you can arrange the output to be in lines with fields in sequence shown in [[Dayfile.txt#List_of_Fields]].  There is more guidance later on this page about the rules you must obey for this file.


If you have imported the data from the other weather software into the [[Standard_log_files]] format, then in the Cumulus 1 editor, ''Create missing'' can insert the new rows for those days previously missing in dayfile.txt, as explained below.  
If you have imported the data from the other weather software into the [[Standard_log_files]] format, then
* a separate utility "CreateMissing.exe" can create the new rows, for MX users, for those days previously missing in dayfile.txt, as explained below.
* in the Cumulus 1 editor, ''Create missing'' can insert the new rows, for those days previously missing, in dayfile.txt, as explained below.  


= Using CumulusMX.exe editing functionality =
= Using CumulusMX.exe editing functionality =
Line 169: Line 199:
Pick '''Edit''', click that, and an editing dialog pops up (MX uses '''altEditor ''' software for this). The pop up window does not let you change the line number nor the date, but all other fields show their current contents and you can overtype as necessary. Scroll down to see 2 buttons (how they are labelled depends on which version you are using), the left hand button ignores any edits you have made (it is labelled 'Close' or "Cancel" and simply does same effect as clicking the "x" in the top right corner), it prevents the api sending any replace message back to the MX engine. The right hand button saves your changes (even if it is labelled 'Edit' rather than "Save" in the version you are using) by using the api to send the replacement array back to the MX engine where it will replace the relevant line number before writing back to the log file.
Pick '''Edit''', click that, and an editing dialog pops up (MX uses '''altEditor ''' software for this). The pop up window does not let you change the line number nor the date, but all other fields show their current contents and you can overtype as necessary. Scroll down to see 2 buttons (how they are labelled depends on which version you are using), the left hand button ignores any edits you have made (it is labelled 'Close' or "Cancel" and simply does same effect as clicking the "x" in the top right corner), it prevents the api sending any replace message back to the MX engine. The right hand button saves your changes (even if it is labelled 'Edit' rather than "Save" in the version you are using) by using the api to send the replacement array back to the MX engine where it will replace the relevant line number before writing back to the log file.


There is no validation in the MX editor that was set up relatively quickly in version 3.4.5 as the first of 3 log file editors to plug a gap in MX functionality in earlier versions:
There is no validation in the MX editor that was set up relatively quickly in version 3.4.5 as the first of 3 log file editors to plug a gap in MX functionality in earlier versions, so you must manually ensure you enter correct data:
*some fields can only accept integers, other expect decimals,
* some fields can only accept integers, other expect decimals,
* and some fields can accept negatives, others don't accept signed numbers
* and some fields can accept negatives, others don't accept signed numbers
*some fields have a minimum and/or maximum acceptable value
* some fields have a minimum and/or maximum acceptable value
* time-stamps must use a colon between the 24 hour time sections for hours and minutes


As all lines are passed back via an application programme interface to the MX engine, there is no validation there either, the new line replaces the old one when the whole file is recreated. It is likely that the next time MX attempts to read the dayfile.txt it will find any error.  There was a third-party proposal to add simple validation into a replacement editor, that would hav
As all lines are passed back via an application programme interface to the MX engine, there is no validation there either, the new line replaces the old one when the whole file is recreated. It is likely that the next time MX attempts to read the dayfile.txt it will find any error.  There was a third-party proposal to add simple validation, as listed above into a replacement editor, as well as adding in-line editing, but it could not be made compatible with the particular third-party modules used by the admin interface at release 3.6.0.


Pick '''Delete''', click that, and a simple dialog pops up (MX uses '''altEditor ''' software for this) showing all the fields in the selected line and asking you to confirm that you want to delete it. Again, the labelling on the buttons varies depending on which version you are running, one confirms the deletion (which sends the array back to the MX engine with an instruction that line number is to be deleted.  Despite the MX engine getting a copy of the fields that are to be deleted, it does not validate the fields, just the line number. The button labelled 'Close' or 'Cancel' does the same effect as clicking the "x" in the top right corner, it prevents the api sending any deletion message back to the MX engine.
Pick '''Delete''', click that, and a simple dialog pops up (MX uses '''altEditor ''' software for this) showing all the fields in the selected line and asking you to confirm that you want to delete it. Again, the labelling on the buttons varies depending on which version you are running, one confirms the deletion (which sends the array back to the MX engine with an instruction that line number is to be deleted.  Despite the MX engine getting a copy of the fields that are to be deleted, it only checks the line number. The button labelled 'Close' or 'Cancel' does the same effect as clicking the "x" in the top right corner, it prevents the api sending any deletion message back to the MX engine.




==Cautions if using an obsolete MX release==
==Cautions if using an obsolete MX release==


* '''Cumulus MX beta version 3.0.0 (checked at build 3043) does not provide an editor'''
* '''Cumulus MX beta version 3.0.0 (checked at build 3043) does not provide an editor'''
5,838

edits

Navigation menu