Category:Cumulus MX: Difference between revisions

380 bytes added ,  09:24, 29 April 2020
m
Line 627: Line 627:


=== MySQL settings ===
=== MySQL settings ===
Cumulus MX includes functionality not in Cumulus 1, and this is one example of a new feature. It was developed from [[ImportCumulusFile|this script]] for Cumulus 1. It is designed to automate updating of MySQL databases whose schema has each table based on one of the Cumulus log files. The optional settings described below, allow you to choose which log file to use for such automatic updates and what to call the table uploaded to (uploads will not work before the required table has been created). Alternatively, you can devise your own schema, create that table, and then write the SQL to update your table using web tags to supply all the values.
Cumulus MX includes functionality not in Cumulus 1, and this is one example of a new feature. It was developed from [[ImportCumulusFile|this script]] for Cumulus 1. It is designed to automate updating of MySQL databases whose schema has each table based on one of the Cumulus log files. The optional settings described below, allow you to choose which log file to use for such automatic updates and what to call the table uploaded to (uploads will not work before the required table has been created). Alternatively, you can devise your own schema, create that table, and then write the SQL to update your table using web tags to supply all the values. You need to turn on enhanced debug logging to see any confirmation that the SQL has run.
<pre>2020-04-09 10:00:01.047 MySQL: 2 rows were affected.</pre>


If you want to insert historic data (i.e. from before you first use this feature in MX), the Cumulus 1 script just referenced can be used, or you can write your own SQL to do this one-off task.
If you want to insert historic data (i.e. from before you first use this feature in MX), the Cumulus 1 script just referenced can be used, or you can write your own SQL to do this one-off task.
Line 657: Line 658:
*2. ''Custom upload - at rollover''
*2. ''Custom upload - at rollover''
** In the previous option, you have no ability to vary the schema, it will update a column for Total Evaporation even if your weather station cannot calculate that. It will update columns for total hours of sunshine, highest solar radiation level, and the maximum UV in the day even if you cannot measure these. It will not record whether snow was falling or lying, or the depth of snow even if you are recording those.
** In the previous option, you have no ability to vary the schema, it will update a column for Total Evaporation even if your weather station cannot calculate that. It will update columns for total hours of sunshine, highest solar radiation level, and the maximum UV in the day even if you cannot measure these. It will not record whether snow was falling or lying, or the depth of snow even if you are recording those.
** MX provides this alternative option, again doing an upload as part of roll over to next day, but here you can specify the schema, and say which columns are to be updated with three selections:
** MX provides this alternative option, again doing an upload as part of roll over to next day ([[#MX_End_of_Day_Process|sequence shown below]], the Custom EOD SQL is run after the day reset to new date, but before the dayfile.txt update with existing values and so before today.ini to yesterday.ini processing).
**In this section you can specify the schema, and say which columns are to be updated with three selections:
**# Save - a button after all option sections, until you click it any changes you make in this section have no effect
**# Save - a button after all option sections, until you click it any changes you make in this section have no effect
**# A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
**# A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
5,838

edits