Cumulusmx.db (preserving history): Difference between revisions

m
no edit summary
mNo edit summary
Line 7: Line 7:
This file holds a SQLite3 database.
This file holds a SQLite3 database.


There are many software tools available that can read/edit SQLite3, this is not the place to get too technical, but take a look at '''sqlitebrowser''' in a Linux environment, and '''phpLiteAdmin''' in Microsoft Windows.  Also, you could use any application that can read ODBC files (e.g. Libre Office's Base functionality), these can read the MX databases.


=Releases 3.0.0 to 3.11.4 inclusive=
=Releases 3.0.0 to 3.11.4 inclusive=


The database only contains one table '''StandardData'''.
The database only contains one table '''StandardData'''. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=123594#p123594 this forum post] Steve Loft describes this table as being for a possible future enhancement.  It is believed this is the table that Steve had developed in Cumulus 2, as a replacement for the [[Monthly_log_files]]. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=113475#p113475 another forum post] he does give a little more detail about his proposal for Cumulus 3 (MX), and this is backed up by his choice of [[Standard log files|table name]] which suggests he was planning to either replace, or duplicate, the use of text files for logging data.  It appears he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]] from his inclusion of "Lo" and "Hi" values in the column list.  Despite the evidence supporting that idea, it is a possible alternative that Steve Loft actually thought he could improve on the [[Recent history]] functionality, by storing the highest and lowest readings read from weather station in-between the one minute resolution.  Whatever context it was to have been implemented in, its purpose was to improve the ability to [[Correcting Extremes|Correct Extremes Records]] by storing the most frequent and accurate extremes possible.


Here is the relevant create table instruction, so this tells you the 17 fields in the file:
Here is the relevant create table instruction, so this tells you the 17 fields in the table as Steve created it (these have never been changed):
CREATE TABLE "StandardData"(
CREATE TABLE "StandardData"(
"Timestamp" datetime primary key not null ,
"Timestamp" datetime primary key not null ,
Line 34: Line 35:
Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table.  This is because although MX creates the table, currently it does not actually use it.
Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table.  This is because although MX creates the table, currently it does not actually use it.


In [https://cumulus.hosiene.co.uk/viewtopic.php?p=123594#p123594 this forum post] Steve Loft describes this table as being for a possible future enhancement. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=113475#p113475 another forum post] he does give a little more detail about his proposal and this is backed up by his choice of table name. The table name suggests he was planning to duplicate the [[Standard log files|Standard log text files]] with a database equivalent.  I suspect he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]] from his inclusion of "lo" and "Hi" values in the column list.


This table still exists in release 3.12.0 that introduces the second table described below.  I wonder whether MX in the future will actually implement the intended use of this first table.
This table still exists in release 3.12.0 that introduces the second table described below.  


=Release 3.12.0 onwards=
=Release 3.12.0 onwards=


Release 3.12.0 introduces a second table '''RecentData''' into the same database.  This is documented in the update.txt for CumulusMX at release 3.12.0 (beta build 3134) as "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data
The first table, described above, remains in the database, but is still not being used.  I wonder whether MX in the future will actually implement the intended use of this first table, as described above.
- This means that charts, recent webtags, and internal calculations for trends and periodic values will be more accurate after a restart
 
Release 3.12.0 introduces a second table [[Recent history|'''RecentData''']] into the same database.  This is documented in the update.txt for CumulusMX at release 3.12.0 (beta build 3134) as "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data
- This means that charts, recent web tags, and internal calculations for trends and periodic values will be more accurate after a restart
- If Cumulus MX is offline for a prolonged period, data for that offline period will obviously still be at the station logging interval resolution".
- If Cumulus MX is offline for a prolonged period, data for that offline period will obviously still be at the station logging interval resolution".


This second table has the following columns:
This second table has the following columns:
5,838

edits