5,838
edits
Dayfile.txt: Difference between revisions
→How you can use the daily log: added new section "Populating a database table"
(revised '''Important Rules''': to make them cope with MX and non-windows devices) |
(→How you can use the daily log: added new section "Populating a database table") |
||
|
* 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 ==
* If you want to run scripts that use the daily log, it is best if you take a copy first,
* Cumulus MX has option to list files to be transferred once a day as part of rollover, so you can use that. This has the advantage it happens even if Cumulus has been stopped and restarted and rollover is happening during catch-up.
*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. ▼
* A third party toll "Cumulus Toolbox" can also be used to transfer files at a particular time. Note this cannot tell whether Cumulus has done its rollover at the normal time, or during catch-up.
* There are other ways to specify that when a file changes it is copied somewhere.
*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.▼
▲*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
== 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 ==
| |||