5,838
edits
Category:Cumulus MX: Difference between revisions
From Cumulus Wiki
Jump to navigationJump to search
m
→Stopping MX
m (→Stopping MX) |
|||
|
The MX source listing suggests it also accepts ''control and break'', '''Close main window''', ''user logoff'', and '''system shutdown''' and should still attempt to stop running tidily. There are various tasks like writing final values to log files and recreating the configuration file, [[Cumulus.ini]], that it needs to do as part of the MX closing routine, and obviously early closure of the device running MX (such as that caused by a power cut) will prevent a tidy end to MX.
= Executables =
The MX package, at time of typing this, includes two executables:
== CumulusMX.exe ==
Whilst effectively MX is run by a '''CumulusMX.exe''' or '''sudo mono CumulusMX.exe''' depending on device, you actually need to ensure all the other components are loaded, so you either have a package that runs it for you, or you click a shortcut that includes the necessary path setting.
== ExportMySQL.exe ==
This second exe file has been available since the original MX package as Steve Loft developed this in April 2015, but sadly few people even notice it exists, and if they do, it is unlikely they know how to use it. Hopefully, some people will read this section and find out!
Obviously it was updated when Mark Crossley added the Feels Like fields to log files.
Put simply, this executable will read log files and insert (insert ignore) rows into an existing database table. Since it only does inserts, despite the name of this function, it is not just for MySQL tables, the included SQL should work with whatever database table type you have.
The executable has a mandatory single parameter that tells it which log files to read, there are only 3 possible parameters ("dayfile", "monthly", or path to a file). It needs to know what locale (or culture settings) it is to use to work out what character separates each item in the log file list. It also needs to read your Cumulus.ini file, as it takes these "input parameters" from MySQL section in that:
*Host
*Port
*User
*Pass
*Database
*MonthlyTable
*DayfileTable
=== Daily summary log file ===
# Use the feature in the admin interface:
#* Settings menu
#* MySQL settings page
#* In '''Dayfile.txt upload''' section, give your database table a name, or accept default ''Dayfile''.
#* Click '''Save''' to ensure this setting is updated
# Now scroll down to '''Create database table (save settings first)'''
#* Here click '''Create Dayfile'''
# Now you have a database table ready, you can use the executable to read all lines in your '''CumulusMX/data/dayfile.txt''' log file.
# Open a terminal display (if you are using Windows then, open a Command Window, a Windows Powershell window, or a Windows Terminal window)
# Run this executable in that terminal display (or command window) by using '''sudo mono ExportMySql.exe daily''' or <tt>ExportMySql.exe daily</tt> depending on device.
# In the terminal display (or command window) you will see '''Parameter = daily''' confirming what you entered and in the line below that a rapidly updating code that is the primary key displayed for each row it tries to insert into the table. If that primary key already exists in the table, it will still show the key, but no insert will take place.
#If you want MX to continue adding new rows to this database table, still in the admin interface, still in MySQL settings page:
#* Return to '''Dayfile.txt upload''' section, and select '''Enable'''.
=== Standard Log files ===
# Use the feature in the admin interface:
#* Settings menu
#* MySQL settings page
#* In '''Monthly log file upload''' section, give your database table a name, or accept default ''Monthly''.
#* Click '''Save''' to ensure this setting is updated
# Now scroll down to '''Create database table (save settings first)'''
#* Here click '''Create Monthly'''
#If you want MX to continue adding new rows to this database table, still in the admin interface, still in MySQL settings page:
#* In the same '''Monthly log file upload''' section, now select '''Enable'''.
# Now you have a database table ready, you can use the executable to read all lines in either one (if path to that file is in parameter), or every (if parameter is monthly) standard log file.
#*If the parameter is "monthly" it will look in folder '''data''' for every file it can find with a file name of datestring + "log.txt" where datestring is a 3 letter code (in your locale) for each month (1 to 12) followed by a 2 digit year (from "00" to "99") so that is how it finds every standard log file in the folder.
# Open a terminal display (if you are using Windows then, open a Command Window, a Windows Powershell window, or a Windows Terminal window)
# Run this executable in that terminal display (or command window) by using '''sudo mono ExportMySql.exe monthly''' or <tt>ExportMySql.exe monthly</tt> depending on device.
#* Alternatively, replace '''monthly''' parameter by a full path to a single standard log file, and it will process just that log file.
# In the terminal display (or command window) you will see '''Parameter = monthly''' confirming what you entered and in the line below that a rapidly updating code that is the primary key (omitting the first two digits of the year) displayed for each row it tries to insert into the table. If that primary key already exists in the table, it will still show the key, but no insert will take place. So you can run this again to pick up any additions to the latest log file since the original run. Also notice that if you use the parameter "monthly" the order in which it will process different standard log files is not predicable, they probably will not be in any particular order, but as one feature of SQL databases is that the row order is not able to be determined, it does not matter if rows are not added in chronological order.
#* It is worth noting that it is safe to run this procedure while MX is also running, because this procedure only updates log entries that exist as this procedure reads the logs, and MX only adds new entries to the log and at the same time uploads that new entry (if enabled) to the database table.
Please be aware that the transfer to the database table adds two columns where bearings in the original log file given in degrees are output as compass directions, and these use up to 3 letters of how the compass directions are defined in the '''strings.ini''' file. Thus the number of columns in the database table will be at least 2 more than the number of fields in the log files. It is also important to stress that whilst the database table must contain one column defined for each field (plus the extra 2) being uploaded, you can add even more columns to your table if you want and populate those some other way. For example, I have added a Canadian Humidity Index (Humidex) column which is not in the standard logs, but is calculated by Cumulus, and can be calculated from columns that are uploaded from the standard log. Humidex is not uploaded by either ExportMySQL or the normal CumulusMX process, but neither objects to extra columns being there.
When testing this, I had some log files produced by various old versions of Cumulus 1 in my MX data folder as well as the log files in has generated since I swapped to MX. Plus I had used a PHP script to add feels like to those log files produced before version 3.6.0 and to correct feels like for those log entries made by versions 3.6.0 to 3.6.9 inclusive because they used a different formula to the one being used from version 3.6.10. This php script is a web page with a HTML form and can be obtained from the forum in [https://cumulus.hosiene.co.uk/viewtopic.php?f=18&t=18096 Create Missing for MX]
I notice that the database rows produced by those short log file lines produced by say version 1.9.0 had nulls entered for all subsequent columns, except '''Feels Like''' and this column was initialised at 0.0!
For those log files produced by the final version 1.9.4, all columns are populated although feels like is set to 0.0.
= Optional parameters to add to the instruction to run the MX engine =
| |||
