Migrating from Cumulus 1 to MX: Difference between revisions

If you want to continue using the same weather station, and you are not moving to a different home, you will want to maintain the data you collected using Cumulus 1 in your MX installation. This is what is meant by migration, and there is thequite subjecta bit to read, taking up most of the rest of this articleWiki page. The Cumulus configuration files for Cumulus 1 and for MX share the same name, but their content is very different, so these are discussed at length in subsections below.

Note that if you run MX on a UNIX based operating system (e.g. Linux or Raspberry Pi OS) all file names are case-sensitive, please read documentation to see where capital letters are required in those file names. Be aware that Wiki pages always change first letter to a capital, evenso whendo check carefully if that wiki page is describing a file name that must be all lower-case is being described.

If you are not running MX on a Microsoft Windows computer, ideally you should change the characters appearing at the end of every line in anyevery file you move from Cumulus 1.

I say ideally, because although Microsoft is fussy, and determined to be different by insisting files match its choice, most other operating systems can tolerate different line terminators. This means that MX will generally tolerate files using a mixture of line terminators. However, if you are using third-party routines, please be aware that these are often written to expect a particular line terminator, and they may give unexpected results when used with files that do not match that expectation!

To change end of line characters, run each file through an editor designed for programmers. Various editors are available but "Notepad ++" is one that is popular on Windows, but can run on other operating systems. In its '''Edit''' menu, choose '''EOL conversion'''. On a Linux system like a Raspberry Pi computer, please see [[MX_on_Linux#Changing_line_terminators]].

If you use PHP HypertestHypertext Pre-processor anywhere on your installation, normally that is written for "Line-feed" as line terminator and any "carriage return" in your files may mess up the content unless you code in a "trim" function to remove it. Hopefully, if you use PHP, you are technical enough to realise you may need to edit the code depending on which device it is being run on!

For Cumulus 1, this parameter appeared in two places on the example web template for all-time records, but was otherwise ignored. Thus if you decided to import into your data logs readings from before you first ran Cumulus, the legacy software would be able to find those earlier records, without you needing to change the date that appeared on the web page.

'''CumulusMX.exe''' uses this parameter to determine the first standard logdata file to start reading from, it will ignore any logdata files for earlier dates, it will also ignore any lines with an earlier date in the first data file. Thus if you were to migrate your Cumulus 1 configuration file into MX, you should check the "[[Cumulus.ini#Data_Logging|'''StartDate="xxxxx''']] lineparameter in the '[Station]' section is correct for your earliest data before you let MX read this configuration file for first time. If you need to make any edit, ensure you stick to exactly the same date format.

From release 3.10.1, MX allows you to edit this start date within the admin interface, just select ''Station Settings → Common Options → Advanced Options → Records Began date''. It is "hidden" as an "advanced" setting, with a strict danger warning, butbecause itof isthe thereimportance of sticking to exactly the right date format when you edit it!

''You can skip this subsection if your weather station connects to MX either by USB or by wireless connection''. It is relevant if your station connects by a serial connection and MX needs to be told which port. It also applies if the serial connection is converted to USB.

A typical parameter value for other serial connecting devices might be "/dev/ttyUSB3" where the final digit will change depending on the new connection. You can search for posts on the support forum that talk about how to find out what connection is being used, depending on what hardware you are using.

*Replace: '''RG11port=n''' and '''RG11port2 =n''' (Cumulus 1) where n is a number, by '''RG11portName=xxxx''' and '''RG11portName2=yyyy''' (Cumulus MX on Windows) where the value is a string with values as per previous paragraph depending on device on which Cumulus MX is running.

Check your existing '''strings.ini''' file against the ''samplestring.ini'' file in the MX distribution you have. If the attribute names (left hand side of the equals sign) match for the parameters you selected to include in your '''strings.ini''', then you can reuse your existing file. If your file includes attributes that are no longer in the MX ''samplesting.ini'' file, then you will need to edit your '''strings.ini''' file that is placed in the folder containing CumulusMX.exe. You may also need to add new items into your '''strings.ini''' based on new content in ''samplestring.ini''.

Please see [[Reports_folder]] for full information. Cumulus software creates reports, it does not edit existing reports, so migration is fairly simple. Just copy the contents of the '''Reports''' folder in your original Cumulus installation into the folder in the new installation. Of course, nothing is totally simple, the encoding default changes between Cumulus 1 and MX, and once again we might need to consider end of line characters!

* files can be encoded (how individual characters are represented by binary codes) by Cumulus in two different ways. There is more about encoding at [[Reports_folder#Encoding]], the relevance here is that if your MX settings and Cumulus 1 settings use different encodings (as they will if you let this default) you may find some characters (e.g. degree symbol) do not appear correctly when viewing some of your reports.

You should copy all files in the [[data folder]] from your legacy Cumulus installation to your MX installation if you want to be able to see past data., but as mentioned earlier there are some complications:

When Steve Loft designed his original Cumulus (1), he had no experience to draw upon as to the best way to treat items like dates. He wrote the software originally just for his own benefit and did not need to worry about time zones. Subsequently as he enhanced his software to make it usable by others, he faced many issues on how to cope with different time zones, and different weather stations having different sensors. In Cumulus 1, he basically focussed on compatibility by keeping to his original design for the data loglogging files (both those ending in '''.ini''' and those ending in '''.txt''', and only adding extra fields to the end.