Migrating from Cumulus 1 to MX: Difference between revisions

This page was inspired by this [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17749 update from Cumulus 1] forum topic.  That post was made in January 2020, and therefore the bulk of the text on this page relates to Version 3.3.0, which was the MX release that was in use at the time.

[[File:Crystal Clear info.png|40px]] This page was last partially updated for the MX release in July 2020; that is no longer latest!

Appeal to contributors: Please work through all MX release announcements and work out all the many updates needed for this page, it may even need a redesign for more recent releases!

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 is the subject of the rest of this article.

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 change first letter to a capital even when a file 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 any 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.   

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'''.  

If you use PHP Hypertest 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" 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!

MX's [[Cumulus.ini]] has different content to the legacy [[Cumulus.ini_(Cumulus_1)|'''cumulus.ini''']].

MX only recognises "Cumulus.ini".

The old approach for migration, was to copy across your existing file, and let MX ignore all the parameters that do not apply to it.  To add the parameters that MX does need, you would then go to the [[MX_Administrative_Interface#Changing_Settings]] pages and work steadily through ALL the options.  For any parameters that were not set by the admin interface (and there were many "read-only" parameters in early releases of MX), one assumed these also existed in Cumulus 1 and so were already in your file.

At releases like 3.3.0 and 3.6.0, amongst others, there were changes to "read-only" parameters for MX. These could not be adjusted through the admin interface, and needed to be entered manually as listed on [[Cumulus.ini (MX 3.0.0 to 3.7.0)]] page. If you choose to migrate to an old MX release, to simplify some data file issues listed below, then refer to that page for the new parameters, and refer to [[Cumulus.ini (Cumulus 1)]] if you need to check if particular parameters were used by the legacy software.  However, you should reuse your old file, and just use the admin interface to work through all settings pages and finalise the new settings.

Substantial changes to changes were made from release 3.8.0 onwards, hence [[Cumulus.ini]] is a new page applicable from that release. More changes were made in 3.10.0, and subsequent releases, as settings that used to have to be made directly in file were gradually moved to be advanced settings controlled in the admin interface.  From release 3.12.0,many more new settings were added, more settings were removed, and some parameters in the file were renamed.

==Settings==

* If there is no Save button anywhere on the screen (as in Extra Web Files) then the setting is saved when you move to next field/line.   

Be aware that you should restart MX after changing settings, as many settings are only read from file when MX starts.

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.

'''CumulusMX.exe''' uses this parameter to determine the first standard log file to start reading from, it will ignore any log files for earlier dates. Thus if you were to migrate your Cumulus 1 configuration file into MX, you should check the "StartDate=" line 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. It is "hidden" as an "advanced" setting, with a strict danger warning, but it is there!

You can skip this sub-section if your weather station connects to mX either by uSB or by wireless connection.

If your weather station used a port to connect to Cumulus 1, that port was set on the settings screen as a number and stored in Cumulus.ini_(Cumulus_1) in the station section as a parameter in the format '''Port=n'''.  

If your old parameter had a value of '''3''', and you are still using Windows, the new setting would have value of '''COM3'''.   

A typical parameter value for other serial connecting devices might be "/dev/ttyUSB0".

*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.

From release 3.10.1, there appear to be other new parameters, not yet documented.

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.

Please see [[Reports_folder]] for full information.  Cumulus software creates reports, it does not edit existing reports, so migration is simple. Just copy the contents of the '''Reports''' folder in your original Cumulus installation into the folder in the new installation.

* files can be encoded (how individual characters are represented by binary codes) in 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 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.

 

There are some complications:

Your Cumulus 1 '''.ini''' files can be read in all release versions from 3.0.0 to 3.5.y. Steve Loft did make two changes in his beta MX, these mean your .ini files may look strange while they have some entries made by Cumulus 1 and some made by MX:

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 log files (both those ending in '''.ini''' and those ending in '''.txt''', and only adding extra fields to the end.