Migrating from Cumulus 1 to MX

From Cumulus Wiki
Revision as of 09:49, 29 January 2021 by Sfws (talk | contribs) (ADD Notice)
Jump to navigationJump to search

This page compares functionality between Cumulus 1 and MX.

This page also covers moving from Cumulus 1 to MX, and in particular it explains exactly what is required to run MX on the Windows Operating System.

It was partly inspired by this update from Cumulus 1 forum topic. As that post was made in January 2020, 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.


Crystal Clear info.png This document was written for a MX release that is no longer latest!

The text needs to be updated so that it covers those who move from Cumulus 1 to a version of MX up to 3.5.y (which is an easy transition), and those who subsequently move to the latest MX release and wish to take advantage of extra functionality that provides.

Comparing Cumulus 1 and MX

An introduction to Cumulus can be found at About Cumulus. That explains some of the background to its development and what functionality it offers.

Cumulus 1

  • Cumulus 1 is software that only runs on Windows Operating System
  • Cumulus 1 has an installer that you download and run to create all the files that are needed
  • Cumulus 1 has a built-in Graphic User Interface
    • The main screen summarises key current values (with some extra ones revealed when you mouse over parts of the screen) with a menu giving access to the other screens
    • The View menu let you view data (e.g. View period shows you data for any one day, for any week, month, year, season or any other period)
    • The Edit menu lets you edit the extreme records and some of the log files
    • The Configuration menu lets you adjust the most useful of many settings available
    • The file menu lets you request an upload, print a screen shot, or exit the software
    • Select-a-graph gives you ability to plot whatever variable and period you want
  • Cumulus 1 comes with an example set of web templates (showing how Web tags can be used to add the weather outputs that Cumulus generates to a web page
  • Cumulus 1 can generate graphs that you can view (and customise) on the view menu, and optionally upload to a web server (web site).

Cumulus MX

Comparing with list above there are various Cumulus 1 features that are not in MX. Initially, there was an attempt to add some Cumulus 1 features that were not in the MX beta. But MX development is now focussed on resolving bugs and adding new functionality.

There are no plans to add two useful Cumulus 1 features to MX

  • Select-a-graph
  • View Period

There are also differences between the ways that Cumulus 1 and MX do various calculations:

  • rain rate
  • dew point
  • wind chill
  • heat index
  • humidity index (humidex)

Finally there are some weather station specific differences between Cumulus 1 and MX for reading variables from the station.


Steve Loft says

NOTE: This section is based on Steve Loft's wording taken from the support forum with minimal alteration (clarification in []) for its new context.

Cumulus MX aims to be as compatible with Cumulus 1 as possible with 3 exceptions:

  1. Like Cumulus 2, MX separates:
    • the engine (reads weather station, calculates derivatives, creates web server for user interface, and sends updates to various external web sites), and the
    • administrative (shortened to admin hereafter) interface (currently [in the beta] it only displays basic information [and] allows you to vary settings).
  2. Like Cumulus 2, MX runs on Linux and OS X as well as (like Cumulus 1) Windows.
  3. Like Cumulus 2, MX learns from some of the mistakes made in early part of design of Cumulus 1, that limited further development.

Because the development environment for Cumulus 1 is no longer available, it cannot have any extra functionality added. Thus I [Steve Loft] had to start afresh.

Development Environments

I won't worry about the technical details of the development environment for Cumulus 1, but will mention it was abandoned because Microsoft started development of the .NET family of development environments.

One of those new development environments was the .NET Framework, and this (that is being phased out in 2020) is what Steve selected for Cumulus 2 and several years later for his Cumulus 3 beta (which he gave an alternative name to "MX" for reasons that have not been documented).

MX uses standard language C# (pronounced "C Sharp"), an object-oriented programming language created originally by Microsoft for use with the .NET Framework when that was launched. It also works with Mono (an open source implementation of Microsoft's .NET Framework) based on the European Computer Manufacturing Association (ECMA) standards relating to C# and the Common Language Runtime.

I am typing this in 2020, and C# has evolved a long way, the latest version being 8.x. But the .NET Framework is on its way out, Microsoft made it increasingly more specific to the Windows Operating System (that is why Mono has evolved so much) and then focussed on .NET Core which took out all the Windows specific parts and another .NET product (without any supplementary name) that focussed on integration with other Microsoft products. Again, trying not to get too technical, in November 2020, there will be change around of names, and the multi-operating system .NET Core product will take over the .NET name (i.e. the product that had no supplementary name). I don't pretend to understand the technical details, but the impression I get is that the new .NET in November will be similar to Mono, so apps designed for that will still work, but apps using .NET (the one without the supplementary name) to make code designed for windows will stop working

Considerations when moving between Cumulus flavours

NOTE: This section is also based on Steve Loft's wording taken from the support forum with minimal alteration (clarification in []) for its new context.

You can move between [Cumulus flavours] fairly easily, but you should really read all the guidance.

  • In particular if you use decimal commas with Cumulus 1, then you MIGHT have issues when MX tries to read existing log files.
  • [For separator characters in dates and lists] whilst Cumulus 1 only takes settings from the control panel in Windows,
    • MX running in a Windows environment, takes settings from the locale you specify in a parameter when starting MX, or the Control Panel in Windows,
    • MX running in a non-windows environment takes settings from the locale you specify in a parameter when starting MX, or the default locale in your Mono installation
    • MX [may] take some [settings from] interaction between the two [the specified locale and the default locale], and MX may struggle to read file [lines] created by Cumulus 1 if the MX locale is not precisely same as settings when that file [line was] created.


Moving files from Cumulus 1 to MX

  • Steve Loft designed MX so that in general it was able to read log files created by the original Cumulus.
  • See individual articles for more details on such differences.
  • Please note, the information for MX is taken from notes by Steve Loft, and applies to MX 3.0.0.
  • If you move from Cumulus 1 to a version of MX up to 3.5.y, the transfer is likely to be significantly easier. This is because Steve Loft was keen to keep forward compatibility in his beta MX, and it took a while for Mark Crossley to revise the part of the MX code that reads log files.
    • Cumulus 1 is tolerant of various separators for dates and times.
    • Cumulus MX 3.0.0 insists all times use a colon separator (says Steve Loft), and all dates are in ISO format.
  • This means, MX releases from version 3.0.0 to 3.5.4 can read the date/time entries in the Cumulus 1 format and in the MX format.
  • When the MX software needs to update a particular entry (e.g. an extreme) in a particular file, it will subsequently save the file and change the content for the affected line to the new format.
  • Consequently, within a single file both formats will co-exist, you may see lines using Cumulus 1 format for the extremes that have existed for a while, and Cumulus MX format for any new extremes.

Update as at MX release 3.7.0

In particular internal changes mentioned in release announcements for various 3.6.x versions, and for release 3.7.0, have made MX work significantly differently and it is now more fussy about content of log files having to be in correct MX format.

    • It is difficult to move from Cumulus 1 to a release of MX that is 3.6.z or higher, mainly because you may find that Cumulus 1's .txt, and .ini, files can no longer be read.
    • This is because for releases 3.7.0 onwards, each log file in modern MX releases must have lines that match what is in the local settings absolutely perfectly;
    • this means MX is now very fussy about the symbol that separates the 3 parts of a date, very fussy about decimal symbol, and expects the number of parameters/fields in files to be consistent with release 3.7.0.
    • Thus modern releases are less tolerant of log files created by the original Cumulus software;

General points

  • 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.
  • Cumulus 1 is reasonably tolerant of numbers using a comma to separate the integer and decimal part of real number.
    • MX 3.0.0 will accept both decimal commas and decimal full stops in the standard log files, the extra sensor log files, and the daily summary log file.
    • In all versions of MX, the software expects periods/full stops in .ini files regardless of the locale in use, please see the Cumulus MX Announcements and Download - PLEASE READ FIRST for details, but generally if you want to transfer these files from Cumulus 1 to MX, it is best if you edit them so all decimal numbers have a "." between the integer and decimal parts.
  • In individual articles, any differences in the precise content or format within individual files will be highlighted.

Moving Files from MX to Cumulus 1

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. When he designed Cumulus MX, he was able to learn from his experiences with both Cumulus 1 and Cumulus 2, and he decided to use dates to an ISO specification (ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times), and therefore log files are not backwards compatible.

That said, there are some features in Cumulus 1 that are missing in MX, and there are Cumulus users who have migrated back either on a temporary basis (to use a missing feature before they return to MX) or in a very few cases decided to stay with Cumulus 1 (because they prefer it).

Key differences and similarities between Cumulus 1 and MX

NOTE: This section is also based on Steve Loft's wording taken from the support forum with minimal alteration (clarification in []) for its new context.

  • While Cumulus 1 has a tool to generate graphs itself and then uploads them to your website, the graphs used in Cumulus MX are drawn when the end-user loads the web page, they use Highcharts routines that are free for non-commercial use only, i.e. you may not use MX with these graphs on a company web site.
  • While Cumulus 1 runs as an application that includes a main screen, and other screens, that appear when you start it, Cumulus MX is two separate applications, there is the "engine" that connects to your weather station and processes that data, but there is also a separate administrative interface. The latter is viewed on a browser on any device connected to the same local network as the device that runs the engine. On this admin interface you change settings, you can edit the various logs, and you can view a series of web pages that allow you to see all the weather derivatives output from MX.
  • The settings for both Cumulus 1 and MX are held in Cumulus.ini. For MX the file name is case sensitive [on non-Windows devices] and must have capitals where shown.
    • The case sensitivity of MX [on all devices, even Windows,] also applies to the section names within the file e.g. [FTP site] must use capitals for the FTP and must use lower case for site. Edit any section names that do not follow format in the wiki article for this file referenced above.
    • All the characters used within this configuration file must be within ASCII range (represented by binary 0 to 127, basically A to Z, a to z, 0 to 9, and some punctuation), any extended characters (such as those used for accented characters, symbols and non English characters) must be removed.
    • Whilst many settings are common between both flavours, some are not used by MX and MX has some new ones. In particular if you used Port in Cumulus 1, that will not be carried across to MX, and you will need to set ComPort instead. You are advised to check all Settings using the MX admin interface.
  • The contents of your Cumulus 1 Reports folder (NOAA style reports) can be read by MX.
  • The contents of your Cumulus 1 data folder (log files ending with extension .ini or .txt) can be read by MX.
    • However, if you use decimal commas in your Cumulus 1 '.ini' files then you do need to change, in each stored value, the decimal commas into periods/full stops.
    • MX when it needs to update these files will change the way dates are stored, see the Log File pages in the Wiki for more information.
    • The '.txt' files in the data folder will work with both Cumulus 1 and MX - assuming you are using the same decimal and list separators in MX as you used in Cumulus 1 (i.e. the same locale).
  • The Cumulus 1 web templates (files using web tags) will not work with MX (whether you use the standard files provided or have written your own replacements)
    • The reason is because the content of the standard web pages is different. For any web templates you have written, you will almost certainly need to change some web tags, and you may find this difficult because certain formatting characters (e.g. H or M) have different meanings when they appear in isolation in an output format to what they mean when combined with others (e.g.H:mm or 'd M'). See the Webtags page for full information on how to change these, and ask in the support forum if you have difficulty.
  • (Other file names within MX will be as supplied in the zip that you download, or as Cumulus MX decides when it creates the file).
  • The settings in Cumulus 1 and MX work differently, for Cumulus 1 you choose to save changes by clicking OK, for MX changes are only saved when you click a Save button if one is provided. 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.

Finally if you are moving from Windows to Linux, remember you need to learn a host of new commands!

Derived Values

(This section is new for this article)

Although some weather stations calculate various maxima/minima and so on; Cumulus of all flavours ignores these extras. All flavours of Cumulus calculate their own maximim and minimum for all relevant weather items, partly because not all weather station supply these and partly because Cumulus was initially designed just to work on a meteorological day running from 9am GMT one day to just before that on next calendar day (and no weather stations work like that).

Some weather stations calculate dew point and wind chill. Both flavours allow you to choose whether to use these readings, alternatively Cumulus can calculate them.

From the basic temperature, humidity, and wind speed, both flavours can work out dew point (if required), wind chill (if required), Canadian Humidity Index (humidex), USA Heat Index, and Australian Apparent Temperature. The actual formulas used for these calculations vary (except for last) between Cumulus 1 and MX (and were not calculated in Cumulus 2). Consequently you may see a discontinuity in your data from that recorded in Cumulus 1 when you move to MX.

This period.PNG

Cumulus 1 (but not MX) calculates various additional parameters for any period from one day, through a month or year, to any number of days, in current or past years (you select start and end dates):

  • Average temperature from all readings (at 1 minute intervals if Cumulus is left running) in period
  • Average temperature from daily highest plus lowest in each day in period
  • Average of all daily maximum temperature
  • Average of all daily minimum temperature
  • Number of gale days (when average wind speed sufficient to earn Beaufort description as a gale)
  • Snow index for period (cumulative totals of snow depths over days in period)
  • Number of days with snow falling
  • Number of days with snow lying
  • Number of dry days in period (threshold set in settings, counts days in period below threshold)
  • Number of wet days in period

Features and functionality

Cumulus 1 features not ever going to be included in MX

Unfortunately, there is no list anywhere of all features in Cumulus 1. About_Cumulus does not cover all features. Nor is there a list of features still to be introduced into MX. Thus this section is neither authoritative nor definitive.

One big feature that Cumulus 1 had was this view period screen as illustrated here and described above, where you could specify any start and end dates, so it was easy to see a summary for any day in the past, any week in the past, any month, year or season, whatever you needed. MX does not offer anything like this.

Cumulus 1 creates a special log containing just temperature and humidity values, this is NOT available in MX.

Although from version 1.7.5 onwards the original Cumulus counts air frosts and gale days, this feature is not in MX.

Another feature still missing from MX is the "Create Missing" feature that read the standard logs to work out approximate (because not accessing values for every second of day) entries to go in dayfile.txt.

Cumulus 1 Functionality Missing in beta MX

Many other features of Cumulus 1 were missing in the beta MX, as written by Steve Loft.

However, subsequent developments headed by Mark Crossley have now added the majority of the missing features and the list of missing features added is below.

It is still difficult for a Cumulus 1 user to work out the disadvantages of leaving Cumulus 1. There are some obvious advantages in moving to MX, there are a lot of extra new features, there is ongoing support in the forum, and there is prospect of more improvements in the future. Cumulus 1 will never be enhanced.

The look for web site

Cumulus 1, and later Cumulus MX versions - generate a moon image that can use FTP to place it on your web site.

Cumulus 1 generated a number of chart images. MX generates a number of JSON files with data for graphs instead.

The "bird" image used as a background on standard web pages is still provided with MX.

The actual web pages provided in MX fulfil same range of outputs as Cumulus 1, but these are not interchangeable.

  • The Trends page of Cumulus 1 will not work as that simply displayed uploaded images, the MX Trends page uses HighStock to draw graphs from the data pairs in the uploaded JSON files.
  • The old gauges page is replaced by Steel Series gauges.

Enhancements during Beta stage for MX and after MX came out of beta

While MX was in beta, there was limited documentation about what features were included and why, there was some fault reporting and a tracking list that showed when some of those issues were fixed, also initially the documentation on how MX had implemented features it did have was very sparse. The lack of a list of features in Cumulus 1, meant it remains difficult to track which Cumulus 1 features are or are not implemented in MX. Steve Loft said parts of MX were simply machine code level copies of parts of Cumulus 1 functionality, and parts were trying to offer better functionality, but he never said what was included in these two categories.

There was a list of enhancements requested by users for Cumulus 1, but that list was deleted before work on MX started. Despite that, it does seem that some features that were on the now lost list of enhancements for Cumulus 1 that never got implemented in Cumulus 1, have been implemented in MX, although again there is no definitive documentation.

The documentation that does exist is the release notes issued by Steve or Mark. In the next few sections, an attempt is made to prećis such announcements to track when the basic functionality from Cumulus 1 made it into MX.

Of course weather station design evolves, and the sensors available vary. Thus another feature of MX development is adapting to new weather station dongles and new sensors (which obviously cannot be added to Cumulus 1). Once MX came out of beta, the changes in each release are being tracked in another article. Obviously, you still need to look at the support forum for the detailed information in full release announcements about fixes, functionality changes, and actions needed to update to new major versions.

Version 3.0.x

   build 3023 - you can now control the output format of <#tomorrowdaylength> using an entry in strings.ini like this example:

[Solar] MoreDaylightTomorrow=Il y aura {0} minutes {1} secondes plus la lumière du jour demain LessDaylightTomorrow=Il y aura {0} minutes {1} secondes moins la lumière du jour demain 

   Build 3025 - new MySQL (6 options) and custom HTTP uploads (can invoke a PHP script) facilities
       Also introduces a second pass to read archive records in catch up for Davis stations only
       Debug logging, diagnostic data logging, and ftp logging can now be set in the UI
       Changes for reading from Fine Offset and Davis stations
       Improved console messages at start up to indicate whether station has been connected successfully
       Makes sure dayfile.txt entry is always logged to MXdiags to help in case has problems writing file
       'Stop second instance' option now implemented (there were problems with this, see later versions)
       Graph periods can now be configured

   build 3035 - archives the month.ini and year.ini file at the end of the month/year as monthYYYYMM.ini and yearYYYY.ini.
   Build 3041 - Support for FTP over SSL/TLS (FTPS) - enable in Internet Settings
   build 3046 - added weather diary database (Note the MX diary file is different to the Cumulus 1 diary file).
   build 3047 - Web token parser updated to cope with html tag characters "<>" in the format string (see web tag page).
   build 3049 - This build enables ability to upload data to Windy.com.

Version 3.1.1

This release is mainly part of my attempts to add some of the Cumulus 1 features that are missing from CMX. 

   build 3054 - Adds a Current Conditions editor and an All Time Records editor to admin interface
   Build 3056 - Fix for the All Time Records editor

Version 3.2.5

adds editors for files that track extremes previously missing from MX 

   Build 3061 - that completes all the missing record editors from Cumulus 1

Version 3.4.0

The big change for this release is adding historic data "catch-up" for Davis WeatherLink Live devices. 

   Build 3064 - fixes bug in Monthly Records editor for dry/wet periods.

Version 3.4.5

This release continues attempts to add some of the Cumulus 1 features that are missing from CMX. 

       Build 3069 - Adds Editors for: Dayfile, Monthly Logs, Extra Logs

Version 3.5.0

adds the generation of a Moon phase image, and the ability to push data to MQTT brokers.

Version 3.5.4

Adds "Feel like temperature" as alternative to "apparent temperature"

The difference in how a Cumulus 1 user and a MX user see current values and change settings

Cumulus 1

Cumulus 1 was an all in one application, it both read the data from the weather station and provided the user interface for you to see the derived data and change the settings.

'Engine' and 'Admin Interface' for MX

MX is different, it consists of a stand-alone 'engine' which performs the reading and logging of data, uploading to a web site etc. This 'engine' is a command-line/terminal/console application which has no user interface. It does write diagnostic information to a diagnostic log, but many people run it on a device that has no monitor and so the terminal output (if any) is not monitored.

When you successfully start MX, the engine is running, and it continues, until it is terminated by control C (or its equivalent in a Mac environment).


The separate admin interface is provided by virtue of the engine acting as a web server. You can view the admin interface by typing the URL of the built-in web server into your browser, either on the same machine, or on a separate machine sharing the same local network. The default URL if the browser is on the same machine as MX is http://localhost:8998/.

If you are using the browser on a different device on your local network to the device running MX, you cannot use that local host shortcut. Instead you specify a IPv4 address, that is listed in your router (might be called a hub) for the device running MX, this IPv4 address will look like '192.168.y.z' (where y and z are numbers that vary between implementations).

Equally, if "localhost" is already in use for another web server (that you already run on your device), unless you can differentiate purely by port number you may need to use the correct IPv4 address as above, even on the same device.

For security reasons, the admin interface should not be accessible via the public internet.

Operating Systems for Cumulus 1 and MX

As expressed by Steve Loft MX runs on:

  1. Microsoft Windows operating system (Cumulus 1 only runs on this)
    • To run MX on Windows, you need .NET installed which is included on Windows 7 upwards.
  2. Unix derivatives Linux and Mac OS X.
    • To run MX on the additional platforms, it requires the Mono runtime, and you will need to install this

As mentioned in the comparison between Cumulus 1 and MX section, Mono is the open source version of the propriety .Net. Both are sponsored by Microsoft.

Configuration, Log, and Web files

Both Cumulus 1 and MX both use the same basic files:

  • Cumulus.ini,
  • dayfile.txt,
  • today.ini,
  • month.ini,
  • year.ini,
  • alltime.ini,
  • monthlyalltime.ini,
  • indexT.htm,
  • todayT.htm,
  • yesterdayT.htm,
  • thismonthT.htm,
  • thisyearT.htm.

But there are differences in content in all these, and the web pages not mentioned there are totally different (see earlier section).

The configuration file Cumulus.ini has some differences between Cumulus 1 and MX, see that wiki page for more information, but essentially each flavour will ignore the parts they don't understand, and add the additional parts that they need but the other did not use.

  • Cumulus MX can read the today.ini produced by Cumulus 1,
  • you probably need to edit the date format in the date at the start of that file before Cumulus 1 can read a today.ini produced by MX.
  • MX uses ISO format dates with year first, Cumulus 1 uses the date format defined on your PC system that might have year last.

Look up in this wiki pages for the Log Files index page or the individual file pages to see the differences between file content, and what you may need to edit to use Cumulus 1 files with MX.

Both Cumulus 1 and Cumulus MX supply a number of templates that are processed into web pages, although the end produce web pages are (except for trends.htm and gauges.htm) identical, the templates are not interchangeable.

  • However, there are files that Cumulus 1 uses (for example it uses several image files for the trends web page and a weather diary in a XML file) that are not used by MX
  • and also many files that MX creates (for example json files and a weather diary in a SQlite file) that were not part of Cumulus 1.

Changing from Cumulus 1 to MX

If you are going to run MX on a different device to that running Cumulus 1, see Setting up Raspberry Pi article for details. Although those notes are applicable to Linux operating systems, other Unix based systems, and those using the Mac operating system also need Mono to be installed. There is more information about Mono in the main Cumulus MX article, and you should also read that.

The remainder of this article was written assuming you are installing MX on the same Windows Operating System as you used for running Cumulus 1. However, the files that you need to copy across from your Cumulus 1 installation to your MX installation remain the same whatever device you are installing MX on, although you may need to use File Transfer Process or a USB storage device to move the files to the new device.

If anyone is willing to rewrite this article to cover moving to other devices better, please do.

Cautions to be aware of should you already use library software prior to installing MX

  • If you have been using Cumulus 1, and you decided to customise your web site:
    • you may already be using highcharts, jQuery, bootstrap, and other library software
    • and you may have selected to load latest versions for maximum functionality.
  • You might be enhancing what is provided with Cumulus 1,
  • or you might use your web site for other purposes (not just Cumulus).
  • If so, you may find some Cumulus MX web pages do not work correctly.
    • This is because Cumulus MX uses obsolete versions of library software and the way it is coded means MX is not compatible with current versions.
    • For Cumulus MX to work you need to ensure the versions of such software loaded for your web pages, are not used by your browser when viewing MX admin interface or MX web pages.
  • Equally, ensure that the versions of library software loaded by MX, do not stay loaded when you wish to view any of your web pages that use these libraries, as your desired functionality might be limited by the library versions MX uses!

Files to copy from Cumulus 1 into where you are installing MX

Subsequent sections will deal in more detail with various aspects like editing existing files, that are relevant to all the approaches below.

But first, let us focus on what to do to actually get the MX release distribution installed. It does not come with a installer, it comes as a zip of all the files that are needed. So first we will summarise the MX install options for someone currently using Cumulus 1, then we will explain the approach in more detail both in respect of that install of MX and the incorporation of Cumulus 1 files.

There are three approaches to installing a MX release distribution zip:

  1. Install MX OVER your Cumulus 1 installation (this only works if you want to run MX on same PC as you have been running Cumulus 1)
    • This means that all your existing files will be available to MX
    • This is simplest approach for those who want a simple install
    • You may need to edit a few files, please see references to files that might need editing later
    • Because you have Cumulus 1 and MX executables in same location, you would expect it is easy to run either, but as already explained some files can not be read by Cumulus 1 after MX has changed their content
  2. Take a copy of your Cumulus 1 installation and store that copy where you can use it if you want to return to Cumulus 1
    • In original Cumulus 1 location, delete Cumulus.exe (or whatever your Cumulus 1 executable was called)
    • Now follow the instructions for first approach, installing MX over the existing files (but ignore the point about running both executables)
  3. Install MX in a NEW location (this might be on your PC that was running Cumulus 1 or onto another device such as a Pi)
    • This approach requires you to manually copy various files from old folders to new location
    • MX requires all files from "data" and "Reports" folder created by Cumulus 1.
    • You also need "strings.ini" (if you use that), and "Cumulus.ini", plus any other tailoring set-up files, batch processes etc. you might use.
    • This approach is generally easier if you want to be able to go back to running Cumulus 1

1: SIMPLE OVERWRITE APPROACH

Unzip the MX download (from Software for latest version or from https://github.com/cumulusmx/CumulusMX/releases if you want an earlier release version) so the folder CumulusMX is the same folder as that which has "Cumulus.ini" in it. The unzip ensures all the files that need to be in sub-folders go into correct sub-folders.

Your in the data folder and any NOAA reports you may (they are optional) have created in Reports folder are available to MX. You should read the page in that log file link, as you might need to edit some items in the .ini files. For the .txt files, you need to check that all lines are consistent in using the same character to separate the 3 parts of the date, and the same character is used throughout to separate the items in list of fields.

  • Cumulus 1 will accept any character (except space, a digit, or the character used to separate fields in a list) as a separator for the date parts
  • MX will only accept the character defined in your locale (for a Windows pc that is actually set in Control Panel which Windows does not make easy to access preferring you to use its Settings app.
  • There is a Clock and Region section in Control Panel and in the Region window you define the separator MX will use in the Short date item, most easily by clicking additional settings).
  • Now ensure that is same character as used in al lines of your .txt log files.
    • If you have some lines using say "/" and some using "." or "-" as date separator, then there are many editors available that offer a global replace.
      • As an example, Notepad++ has a Replace All in All Opened Documents, so you can open multiple documents and do a global replace of "/" into "-" very easily. Notepad++ saves the file in the same encoding as it was before, but you can also check it is UTF-8 with no Byte Order Mark via the menus.
      • Note that you cannot easily replace "." or "-" globally in dates, because those appear as valid characters in fields. To edit those, you would need to open the files in a spreadsheet editor like Libre Office, you need to ensure that the dates column is treated as text, then select that column and do a replace in just the date column, and then save as a CSV format file changing the extension to .txt. There is more information on this in relevant log file articles.
    • The basic Microsoft Notepad that comes with Windows has a Replace option in its Edit menu, but some versions of this editor (check Save As options) don't allow you to pick "UTF-8" encoding (if that is not already shown) when saving to ensure MX can read the output.
    • Also be aware when using Google editors that they may save the file in the wrong format unless you can choose a UTF-8 no BOM option.


2: COPY C1 AND OVERWRITE ORIGINAL WITH MX APPROACH

Alternatively, to run Cumulus MX with your existing Cumulus data, first take a back up copy of your existing Cumulus directory.

Next obtain the MX distribution release as a zip as per previous option.

Now unzip Cumulus MX into the original Cumulus folder. The new CumulusMX.exe should end up in same folder as existing Cumulus.ini, there will be other files in this folder, and there will be some new folders you have not seen before like interface and MXDiags, but MX continues to use the existing sub-folders without any change of name.

This saves you from copying any of your Cumulus 1 files, they just stay where they are and get used by MX.

Where your existing Cumulus.ini file makes reference to local folders (in say Extra Web Files), those references stay valid. The only edit you will make to configuration that affects Cumulus.ini is dependent on your weather station type, as explained later MX uses a different parameter to refer to the port used by the weather station.

Be aware that MX changes the date formats in some files, so that Cumulus 1 can no longer understand them, so be cautious about copying log files (.ini and .txt) back to your Cumulus 1 back-up should you want to revert to using Cumulus 1.

Some other issues that were described in previous sub-section will apply in this case, because for MX this approach (preserving Cumulus 1 in a new location) is no different to previous.

3: NEW LOCATION APPROACH

These notes apply whether you are installing in a new location on your PC or installing MX on a different device.

Obtain the MX download (from Software for latest version or from https://github.com/cumulusmx/CumulusMX/releases if you want an earlier release version).

When you do the unzip as explained below, it ensures all the files that need to be in sub-folders go into correct sub-folders. You then add various folders and files from your Cumulus 1 installation into correct places. As said before, this sub-section gives only a brief mention of possible issues with existing files, later sections will explain those in more detail.

  1. First create a new directory (recommended name CumulusMX) and unzip the contents into it.
    • For a pi, the instruction might be unzip -o CumulusMXDist3nnn.zip where nnn is the last 3 digits of the build number.
  2. Then copy (or file transfer over)
    • your previous data folder contents into the new data folder created by unzipping, as before you might need to edit some log files
    • your previous Reports folder contents (if any) into the new Reports folder created by unzipping
    • your Cumulus.ini file goes into the top level folder, the one with ExportMySQL.exe, CumulusMX.exe and the .dll files,
      • Check that destination file, it must be "Cumulus.ini" (ensure it starts with capital letter and all other letters are lower case)
      • In the new "Cumulus.ini" edit any lines that made reference to the old windows location. Remember, that only windows uses "\" in paths, and your new device will require reference to new locations. Even if you are still using windows, you may need to make changes to reflect that the files are now in a new location.
      • You can delay changing other settings (like the port used to access your weather station which uses a different parameter in MX) when you have access to the Settings pages in the MX admin interface
    • any other configuration files that you may have created (e.g. strings.ini, twitter.txt etc).


The big advantage of this approach is that anytime you are not running MX you can go back to Cumulus 1 and let it run from where it left off (subject to availability of past data in your weather station, and possibly unplugging weather station from one device and plugging it into PC). Obviously you cannot run Cumulus 1 and MX at the same time accessing the same weather station (even if both are on same device and so no unplugging and plugging in is needed).

Editing files

Do remember that with Cumulus 1 on Windows, each line in every file ends with both carriage return and line feed. If you are moving to MX on a Mac, each line should end with just a Carriage Return. For all Unix-based operating systems (Linux, Raspberry Pi OS, and other variants), each line should end with just a Line Feed. There are various editing tools that can do the necessary modification of all lines for you in just a couple of clicks; one such tool is Notepad++ (which although mostly used on PCs, can be used in other operating systems).

Log files

See individual log file pages already referenced (alternatively access from Log Files index page) where there is more information for how to edit your .ini files to work with MX, they may work without change as MX is generally designed to accept Cumulus 1 files, but it does depend on how you have set up the device on which you are running MX (and may depend on version of Mono or .NET you are using). You may need to alter format for various date fields, and if you use decimal comma, you may need to change some figures to use decimal full stops. You may need to experiment, try first without editing, if that fails then edit dates and real numbers.

Cumulus.ini

If you are running MX on Windows, filenames are not case sensitive, so MX will recognise "Cumulus.ini" or "cumulus.ini". But although Cumulus 1 might recognise "Cumulus1.ini" or anything else other than "Cumulus.ini", MX only recognises "Cumulus.ini".

If you are planning on running MX on another device, filenames are case sensitive, and your Cumulus 1 configuration file must be called "Cumulus.ini" with an initial capital followed by lower case, so it might need to be renamed.

If you read the Cumulus.ini article, you will see that some parameters in the configuration file are only used by Cumulus 1, some only by MX, and some apply to both. MX will ignore any Cumulus 1 parameters it does not recognise, so you don't need to edit out lines. MX will also add any parameters it needs as read/write parameters for its settings, so in general you do not need to add them manually, you can simply set them using the relevant page in the settings part of the admin interface. There are of course a number of read-only parameters (these are ones that are entered directly into the configuration file and cannot be edited using settings), and there are some of these that are Cumulus 1 only and some that need to be added manually if you want to change the default.

There are a few exceptions to the above paragraph, if you look at Cumulus.ini#Parameters_changed you will see the list of a few parameters that may need to be changed in this configuration file (it depends on what type of weather station you use). But you don't need to look them up as they are also mentioned in next 2 sections (station settings and web pages) below.

There are also some differences in how some parameters in this file are used in the 2 flavours.

One to remember now is to 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, as CumulusMX.exe uses that to find the first log file to start reading from, it will ignore any log files for earlier dates; whilst Cumulus 1 and ExportMySQL.exe can process all log files in the data folder as they look for file name pattern and do not check dates.

It is advised that you work through all the MX settings screens once you have the Admin interface working, ensuring they do represent how you want MX to work. Some of the settings are for functionality you did not have in Cumulus 1 versions, and for these you will need to look up the link earlier in this sub-section.

For the read-only settings in Cumulus.ini, you may need to read the documentation in the forum. The Cumulus.ini article in this wiki has had read-only parameters added to it now, but it is impossible to know if all have been covered there.

Station connections

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 in the station section as Port=n. In Cumulus MX, as it runs on various operating systems, the port is specified using text (instead of a number), again you select it within settings, on Station settings screen, but that is stored within Cumulus.ini in the station section as Comport=tttttttt. If your old number was 3, and you are still using Windows, the new setting would have value of COM3, for other devices it might be /dev/ttyUSB0.

web pages

There are differences in how to upload the standard files between Cumulus 1 and MX.

It is best to work through the Internet settings screen in the MX admin interface.

Consequently, there is a difference between the entries in Cumulus.in,

  • for example remove the IncludeSTDImages=1 used in Cumulus 1
  • and replace it with IncludeGraphDataFiles=1 used in MX.
  • whilst the former included the moon image for Cumulus 1, the latter does not affect the moon image for MX

If you have been using the Cumulus 1 supplied web pages, you will find they do not work with MX, there is a new set provided with MX that work slightly differently.

  • Cumulus 1 uploads a number of images, these include a couple of images that combined show the moon phase, and a number of graphs are also uploaded as images (used on Cumulus 1 trends page).
  • Prior to release 3.6.0, Cumulus MX does not upload any images
  • From release 3.6.0, Cumulus MX can upload a moon image (again derived from another base image), as an option (2 settings, one to generate, another to upload)
  • Cumulus MX uploads a series of .json files that hold time and value pairs that can be used to draw graphs. (Hence the difference in settings mentioned above). Thus the trends web page works totally differently.
  • The gauges page provided with MX is based on Mark's implementation of steel series, so it is different to the old "Web Dashboard Components for FreeWX and FreeWX-Wi " that Cumulus 1 used.
  • The other web pages look the same, and indeed are effectively functionally same. You might see some derivatives on MX pages that were not seen on Cumulus 1 pages.

What I did to Install MX

I have used Cumulus 1 for a decade or so, and been very happy with it, but I wanted to give MX a go without affecting my Cumulus 1 installation.

Here is exactly what I did on my ex NHS Windows 10 Pro PC, step by step; I am hoping this list might help some readers.

Can I just stress I downloaded version 3.4.5 (build 3069), there may be some changes that affect what I record below in more recent versions, I just noted what I had to do at that moment in time (March 2020).

Do check, as the version of MX you choose to move to may have more or less, folders and files, included in the package.

Download and unzip

  1. I downloaded the CumulusMXDist3069 zip from the Current Release section on the downloads page. Although 3069 is no longer the latest distribution, still use the same link as it will always give you latest available.
  2. I unzipped the contents into a partition I use just for software downloads.
    • You don't have to have somewhere separate to the installation, but many people will want to download on a separate device to the device where they will install MX
    • Downloading to somewhere other than where you will install it, also makes it easier if you do any customisation of particular files and wish to keep copies of originals.
  3. I used a package (no external software tools named here) that verifies the files it copies to duplicate the folder CumuluxMX within the zip onto the drive where I wanted to run Cumulus MX.
  4. As I was not intending to use the web pages that come with MX, so I selected to exclude in this verified copying everything from the "\CumulusMX\webfiles\*.*" folder, and its sub-folders in the download.
    • If you intend to use the standard MX web pages, then you will need to:
      • Ensure you do copy these files from download into where you are installing MX.
      • You will also need to FTP all files and sub-folders within the webfiles folder (not the actual folder itself), to whatever folder on your web server you specify as the directory in the Web/FTP site part of the settings for MX.

Copying Cumulus 1 files into MX folder

The locale I used for Cumulus 1 is going to be the same I will use for MX (same PC!) so my copying across of my existing files was easy:

  1. First, I copied my \Cumulus\strings.ini to \CumulusMX\strings.ini. This preserves any tailoring I have done of terminology.
    • Remember, "\Cumulus\web" and "\CumulusMX\web" have different content, so don't do any copying between these.
  2. Next, I copied my existing Cumulus 1 alarm sounds in "\Cumulus" across to MX folder "\CumulusMX\interface\sounds" as these were referenced in my main Cumulus.ini file (I will edit that file next to reference the new location of these files).
  3. Now, I copy my \Cumulus\Cumulus1.ini (don't worry why my file had a "1" in its name, just remember that yours probably won't) to \CumulusMX folder as "Cumulus.ini". I then edit the MX "Cumulus.ini" file:
    • In the [Alarms] section (your Cumulus.ini may have sections in a different order to mine) I edit all the parameter lines where the attribute ends in "File" to reflect their MX location in the sounds folder (there is no such folder in Cumulus 1).
    • I checked that I had a "[FTP site]" section (yes, mine was named correctly with second word all lowercase, but if your has [FTP Site] you will need to edit that section title to put second word entirely in lower-case)
  4. I now had to decide whether
    1. I would use the Extra web files settings page in the MX admin interface to make the changes, in the local file column, necessary to define which web templates I wanted MX to process
    2. Or I would make the changes myself by editing the appropriate lines in this [FTP site] section. (I decided on this option).
    • Although my web templates are stored in a folder "Templates for Cumulus to Process" outside the Cumulus 1 or Cumulus MX folder structure, I had to reference a new set of template files to cope with differences in the output parameters of MX web tags.
    • Next where I want a transfer done only at end of day, I added lines like "ExtraEOD19=1" (when you run MX it will add a ExtraEODnn for each of the 100 possible values of nn that you have not created) and changed the previous "ExtraRealtime19=1" to "ExtraRealtime19=0" (I previously used realtime as that was only way in Cumulus 1 to ensure a template file was processed so it held correct values as close to end of day as possible, but it inefficiently also made huge numbers of unwanted transfers during the day). I had 9 such files being copied far too often, so those 9 changes will cause a huge reduction in processing load! I know I could also do this later using the MX admin interface, but it makes sense to me to do it as I am working through the file.
    • I have a few files that are PHP scripts written as Cumulus templates; each PHP script has a number of PHP variables being set equal to a Cumulus web tag. You can find out about these scripts at Php webtags.
    • I also have a few Cumulus templates that, like the standard ones I don't use, generate web pages and embed a lot of Cumulus web tags. I have had to edit these templates as in some cases the web tags have date/time output format parameters.
    • I mentioned some of my web pages are generated from my own Cumulus templates. Despite now having Cumulus 1 and Cumulus MX templates with different names, these still both generate remote web pages given the same names, so I don't need to alter any navigation between pages on my web server.
    • In the "[NOAA]" section I had MonthFileFormat="NOAAMO"MMMyyyy".txt" on a line, I checked at Webtags#The_format_used_for_naming that 'MMM' and 'yyyy' were valid in Cumulus MX as well as in Cumulus 1, they were, so no edit needed either to that line or to "YearFileFormat="NOAAYR"yyyy".txt" line.
  5. In the download, there is a file "\CumulusMX\Reports\.gitignore" provided. In this same MX folder, I copied in the 200 or so report files I currently have in "\Cumulus\Reports". Remember you don't need to rename these files, it is only how that naming is specified in the settings that might need changing.
  6. Next I see there is a "MXdiags" folder, so I don't copy across the Cumulus 1 "diags" folder. Equally I don't change anything in the new MX "webfiles" folder, but I do copy across to my web server the "cumuluscharts.js" and "logoSmall.png" files I see there that I have not seen before.
  7. So left to last is the "data" folder:
    • I have copied all files from "\Cumulus\data" to "\CumulusMX\data" (except log.xml as MX uses a different file and MX does not provide a way to read the XML file into its diary.db).
    • Some of my .ini contain date-time entries like "12/03/2019 14:50:45". I'm assured MX can read these, although it changes a date time like that to "2019-03-12T14:50:45", but I am waiting to see if that is true. I use the full stop character for all my decimal points, but if you use decimal commas, you might find you need to do some editing of your .ini files in this data folder before MX can read them.

Aside on .ini files in data folder

I find after running the CumulusMX engine, that it edits those .ini files it needs to, and the new versions contain date-time entries in the "2019-03-16T12:45:00" style, but despite what I worried about from reading on the forum, I found you don't need to edit beforehand these entries in log files like month.ini as Cumulus MX can read the old formats like "12/03/2019 14:50:45" as well as the new year first formats.

Creating the shortcut to run MX

I right clicked on the "CumulusMX.exe" entry in the top level folder and selected Send to ... desktop (create shortcut).

  • Ensure that your shortcut has a Start in: defined as the folder where your executable is stored. This is the most vital setting.
  • You can optionally change other shortcut properties. I selected to use different settings in the colours tab, so when I have that terminal/console window open I don't confuse it with any other command window I might open. I selected to change options in the layout tab to position the terminal/console window on my second (smaller) screen. I also selected the Start minimised option, as I don't need the window for this MX engine taking up screen space all the time.
  • I have renamed my shortcut to "MX_run" so I can recognise it as different to the folder name, as I have also created a shortcut for the folder.
  • On the same right click menu I also selected Pin to taskbar.
  • When I am happy with MX, I will copy the shortcut into C:\Users\Personal\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ and then MX will start automatically after I (or Windows Update) reboot my PC.

One-off extra installation steps

  1. I clicked on one of my new shortcuts. Windows Defender popped up, so I told it allow all for Cumulus MX.
  2. I opened my Internet Security premium package, in the "unrecognised files" section I selected CumulusMX.exe then right clicked and selected Change File Rating to Trusted
  3. In the "Firewall" section of the Internet Security package I added port 8998 as one that was permitted.
  4. I viewed my hub (router) to see the IPv4 address allocated to my Cumulus MX computer (192.168.1.64), that told me that I would find the user interface by typing "http://192.168.1.64:8998/" into my browser while the MX engine command window remains open (so MX is actually running), so I typed that and I saw the user interface and navigated around it.
  5. I right clicked on my desktop (you may need to right click on the windows symbol at bottom left), selected command prompt as administrator that opened a command window where I typed netsh http add urlacl url=http://http://192.168.1.64:8998/ user=\users

and I got the response "URL reservation successfully added", so I know it worked. This command is apparently to allow all users to bind to port 8998 (i.e. that used for the Cumulus interface). This also means you don't have to run the engine (CumulusMX.exe) in an administrator user, nor select "Run as administrator" from right click menu on the shortcut, nor set the properties for any shortcut to run in any special way.

IMPORTANT NOTE: I don't use "localhost:8998" for two reasons, first I already have a web server on my PC at IPv4 "127.0.0.1" using "localhost" as an alternative name (and port 81, selected because something called 'Skype' that I don't use had reserved port 80 that I had expected to use), and second using the IPv4 exact "http://192.168.1.64:8998/" address as a bookmark, I can view the Cumulus Admin Interface on my mobile phone which shares bookmarks with my PC and connects to my LAN via wifi.

End of my test of MX actions

When I am happy to stop using MX, I type Control + C into that MX command window on my PC and MX closes.

Testing MX while still using Cumulus 1

Obviously, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station.

If you (like I was to begin with) are just experimenting with MX you may sometimes run one flavour (say MX) and sometimes the other (Cumulus 1).

Each time you swap, you must copy all the updated log files from the just used data folder to the data folder you are about to use when you close one favour before you start the other flavour, or you must have both executables in same top level folder to force them to share the data folder.

Please note, today.ini is a special case, the time-stamp line has a different format in Cumulus 1 (C1) and MX; while MX can read the format that C1 uses, C1 cannot understand the format that MX uses. Remember today.ini determines which stored entries in the weather station console need to be read to "catch-up" and it also holds the various figures that will inform what gets stored in dayfile.txt at the end of the day. So to have this file being read and updated correctly is vital.

If you don't do ensure both flavours use the same log files (.txt and .ini), various derivatives (e.g. Chill Hours) will become wrong and you may have conflicting rows in dayfile.txt (because its content is generated from what that flavour saw when it was running the previous day) and generally this will be particularly evident in any weather parameter that varies a lot like the wind vector (speed and direction). It also affects what is stored for any derivatives that rely on averaging (temperature, wind run, rain rate) as these are calculated biased towards the actual times when that flavour of Cumulus was actually running, so you can have issues if you run the 2 flavours in different folders/devices as if the other does not exist.

I have some batch scripts that Cumulus initiates, and a number of Cumulus templates, and in my case I had to be happy these were working before I stopped using Cumulus 1, and got MX as the flavour that auto-started on switching on my PC.

I also use output modifiers on a lot of the web tags I use in my custom web pages and it took me a long time to work out the necessary changes to get these templates correctly edited so that MX could process them and produce the web page content I wanted. I am not going to explain all the problems nor give the solutions, because you probably don't have web pages as complex as mine. 2.4.8 My migration from Cumulus 1 to MX

My installation of Cumulus MX has succeeded, and as the experiment did help me find a mistake in one of my Cumulus templates where I had not defined input parameters for "Recent History", it has been useful. Initially, I am continuing to use Cumulus 1 for the moment, until I am absolutely sure MX can do everything I want.

I believe MX will do some tasks better, but there is a lot more to learn about how to use MX. MX does lack some features that I used in Cumulus 1. I found the View Period screen in Cumulus 1, where you could look at any day, week, month, season, or year in the past extremely useful. MX does not have such functionality yet.

While I was using Cumulus 1, I found with my Chas Olsen Fine Offset I had to define EWpressureoffset=x.y otherwise Cumulus 1 frequently failed to read the correct pressure. In implementing MX, I decided to try without that line in the new Cumulus.ini file; I have not had any problems either when I first ran MX or indeed 2 months later when it is more than a month since I last ran Cumulus 1. Consequently, if you used to have pressure reading problems, you might find you don't with MX.

Some days after I first started trying MX, I have tried out more MX features, been happy with those, and as MX is now doing all I want I have stopped using Cumulus 1.

I still use my own PHP script to update my database tables, I tried the custom SQL and it does not do all I want.

I have done a little editing of the user interface, partly to discover how easy it is to edit, partly to understand better how it works. For each file I have edited (HTML or CSS) I have kept copy of original and made a second copy of my edited version, so I cam easily go back to original and if I download a new release I won't lose the copies of my edited versions of files.

You can judge my progress with trying features, because elsewhere in this Wiki I have expanded the text for those features I have tried and therefore understand.

Retrieved from "https://www.cumuluswiki.org/index.php?title=Migrating_from_Cumulus_1_to_MX&oldid=7688"