5,838
edits
Dayfile.txt: Difference between revisions
From Cumulus Wiki
Jump to navigationJump to search
m
→Introduction: Changing section structure
m (→Introduction: Changing section structure) |
|||
|
{{TOCright}}
* 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.
* 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.
*A new row is appended to dayfile.txt, the values are prepared from reading "today.ini" file, not all values available in "today.ini" are stored in dayfile.txt.
* Some people require a copy of the local file to use on their web server. Consequently, after it has been updated they file transfer it to (or if their web server is local, copy it to) their web server. One way of doing this is [[Upload_Dayfile| described here]].
*Some people take a copy of the local file, and use it locally for other purposes. See [[#How you can use the daily log|How you can use the daily log section]] and also the [[[[User Contributions|Cumulusutils]]]] link.
*For
=== 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. However, be aware that the later versions of that script have bee edited for MX, so you will need to use an older version of the script that fits the version of Cumulus 1 you are using.▼
*There is a section at [[Cumulus_MX#Optional_Sections|Cumulus MX]] to explain how MX includes the ability to generate SQL for creating the database table, for updating it with past data, and to
==== Using that table ====
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 (Cumulus [[Category:User_Contributions|user contributions]]) using the database daily summary table see [[Daily Summary#Some_example_Scripts|here]]. Of course there are also a lot of tools written to use a copy of the dayfile.txt log file, and some of these could be adapted to use the database table instead, if you are a programmer.
In my case I also store the equivalent of what appears on my version of "thismonth.htm" each month in another database table, i.e. I have one database table column for each of the weather derivatives I show on my web page that show this month's values; it is many more derivatives than are shown on the standard web page, but some are initially hidden. Consequentially, when my daily update script detects from the date that it is processing the last day of a month, it then starts another script that reads all the rows in the daily summary table for that month, and stores the highest/lowest/total (as relevant) in my monthly_summary table (nothing to do with the "monthly" table that MX can generate). This monthly summary table allows me to have web pages that compare consecutive months or compare months between years. Just another example of how much you can get from just one log file!
==== Alternative schemas ====
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.
{{Version badge 1}}
With Cumulus 1, you would need to be a programmer and write your own script to update the database table with your own schema. You might use the importCumulusFile article to start you off.
[[File:Badge vMx.png]]
MX allows you to specify a different schema in the SQL it generates, but it does not offer that validation feature I just mentioned. I continue to use my Cumulus 1 script (with some changes as for example the weather diary works differently) now I use MX.
MX automatically stores all end of month figures as log files, a feature that Cumulus 1 and 2 lacked, but as yet it does not actually use this extra data, and provides no simple facility to put what is in these files into database tables. There is no end-of-month selection for updates in MX, so you can't easily get as much from dayfile.tx as I do.
== When Cumulus is restarted after a break in running ==
* 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#Optional_Sections|Cumulus MX]] includes the ability to generate SQL to update a database table version of this daily summary 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 contents of the Weather Diary, the time of the last rain tip, wind bearings as compass characters (e.g. NNW) as well as numerical bearings). When I used Cumulus 1 I wrote a 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, and I continue to use this script (with some changes as for example the weather diary works differently) now I use MX. 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 automatically stores all end of month figures, a feature that Cumulus 1 and 2 lacked, but as yet it does not actually use this extra data.
== Viewing or Editing the daily summary log ==
| |||
