Cumulus MX

Cumulus MX is offered on the same terms as Cumulus 1 - if you use it, please make a donation according to what you think it is worth and what you can afford.

Introduction

This Wiki article was created by Mark Crossley based on what Steve Loft said when he first started experimenting with Cumulus MX and access was restricted to those willing to experiment with his tests.

It has now been updated to reflect that Mark Crossley has continued its development, it is now out of beta, and a fully working package.

Restrictions on who can use MX

Note: The graphs used in Cumulus MX are drawn using Highcharts and they are free for non-commercial use only, i.e. you may not use them on a company web site, see http://shop.highsoft.com/faq/non-commercial for clarification. For this reason, and others, use of Cumulus MX in a commercial environment is expressly forbidden. Please include a link to the Highcharts web site (as the supplied web page does) if you use the charts under the terms of the non-commercial licence.

Documentation for MX

There's quite a lot to read before you start - please do read both this page and all the references it mentions, most of it is very important.

Note that most of the Cumulus 1 documentation also applies to Cumulus MX. MX specific documentation is currently in very early stages and some settings may not be obvious. Looking at the FAQ and the wiki will help, as will looking at the Cumulus 1 help file, it is available on the Software downloads page. If you already use Cumulus 1, the help is part of the standard installation.

If MX is your first encounter with Cumulus, you will be at a disadvantage regarding documentation of many of the features, while those who have previously been familiar with Cumulus 1 will find most aspects of MX easier to pick up.

Comparing Cumulus 1 and MX

Cumulus MX aims to be as compatible with Cumulus 1 as possible. Initially MX, as developed by Steve Loft, lacked a lot of features that were available in Cumulus 1, but the developments headed by Mark Crossley have now added the majority of the missing features. There are also many features that have been added to MX that were either on the now lost list of enhancements for Cumulus 1 that never got implemented, or they are extra functionality to reflect recent changes in weather station features.

• build 30146 -added weather diary database (see below).
• build 3047 - Web token parser updated to cope with html tag characters "<>" in the format string (see below).
• build 3049 - This build enables to 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

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. 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/console application which has no user interface. The separate user interface is provided by virtue of the engine acting as a web server. Once the engine is running, you can view the user 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/ - substitute the machine's IP address for 'localhost' if the browser is on a different machine. For security reasons, the user interface should not be accessible via the public internet.

Cumulus 1 only runs on Microsoft Windows operating system, MX is different as that in addition to running on Windows, it also runs on Linux and Mac OS X. To run MX on Windows, you need .NET 4.5 installed. To run MX on the additional platforms, it requires a suitable version (see support forum for advice) of the Mono runtime, and you will need to install this, as described below.

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.

Look up the Log Files index page or the individual file pages just referenced to see the differences between file content, and what you need to edit to use Cumulus 1 files with MX. However, there are files that Cumulus 1 uses (most of the image files) that are not used by MX and also files that MX creates that were not part of Cumulus 1.

Installing Cumulus MX

There is no automatic installer (this may change). Cumulus MX is supplied as a zipped package on a link from download page.

Requirements for running on Windows

To run MX on Windows, you need .Net version of at least 4.5.2 installed. This is only available for Vista SP2, Windows 7 SP1, Windows 8, Windows 8.1. For Windows 10 you need version 4.8 or later, this should already be installed by your windows update feature. I could not find anywhere to download this from official Microsoft sites, either they were blocked by my virus checker, by my internet supplier or they reported page not found. So I found you can download it from https://www.filehorse.com/. Decline any unwanted software offered by the downloader if you do need to use it.

Requirements for running on Linux and OS X

You will need to install the Mono runtime.

• For OS X, you can download this here - http://www.mono-project.com/download/.
• How you install on Linux depends on the flavour of Linux you are running. There are download links for Linux at the same URL, but it is often easier to use a package manager, which will download and install it automatically.
  • For example, in 'Raspbian' on the Raspberry Pi, you can install mono with these commands:

sudo apt-get update
sudo apt-get install mono-complete

Make sure that you have the mono-complete package installed.

• • If you have a Raspberry Pi 2, there is a later version of Mono available, which you may find works better that the one in the standard distribution, particularly if you use decimal commas. Mono 3.2.8 (which is the default in some Linux distributions) will not work if you use commas for decimals, as in some countries.

• • On Linux you will need library libudev.so.0 which may not be installed by default. Installing package libudev0 may resolve this. There may be issues if you are using a 64-bit version of Linux. I'm not sure what the resolution is at the moment, if this is the case.

Completely new MX installation

Create a new directory (recommended name CumulusMX) and unzip the contents of the download package into it.

Changing from Cumulus 1 to MX

1. Two alternatives
   • Just create a new directory (recommended name CumulusMX) and unzip the contents into it. Then copy over your existing data files and your Cumulus.ini file, and any other configuration files that you may have created (e.g. strings.ini, twitter.txt etc).
   • Alternatively, to run Cumulus MX with your existing Cumulus data, take a back up copy of your existing Cumulus directory, and then unzip Cumulus MX into the original Cumulus folder.
2. If your "Cumulus.ini" was actually called "cumulus.ini" you should rename it to start with a capital letter.
3. See pages already referenced for how to edit your .ini files to work with MX.

What I did

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 it might help some readers.

1. I downloaded the CumulusMXDist3069 zip from the Current Release section on the downloads page.
2. I unzipped the contents (on my Windows PC) into a partition I use just for software downloads
3. I used a package that verifies the files it copies to duplicate the folder CumuluxMX onto the drive where I run Cumulus. I then noticed that the package contained some very obsolete copies of some external packages:
   • In "\CumulusMX\interface\lib\jquery" it contained jQuery version 1.9.1, that is 2014 vintage and very obsolete, so I downloaded latest compressed production version from jQuery web site. I prefixed the version in the MX package with the word OBSOLETE (OBSOLETEjquery-latest.min.js) and renamed the version I had downloaded (jquery-3.4.1.min.js) to the old name in the correct path (on my Windows PC) "\CumulusMX\interface\lib\jquery\jquery-latest.min.js". I later noticed the old jQuery version 1.9.1, that is 2014 vintage and very obsolete was also in "\CumulusMX\webfiles\lib\jquery" so I renamed that with the word obsolete (OBSOLETEjquery-latest.min.js) just to remind me that despite its file name it was not latest. I already have the latest jQuery on my web server, so I did not need to put that new version into this webfiles\lib location, I just noted that this new path meant I may have to make some change on my web server later.
   • Similarly, the MX package contained obsolete vintage version 2.1.4 (2015-03-10) of Highstocks and Highcharts, so I downloaded latest versions from the Highstock link on this page. I then created a new folder obsolete at "\CumulusMX\interface\lib\highstock\js", moved the folders "modules" and "themes" that were there in my new folder, and the various highstock and highchart files that were there were moved into the obsolete folder. Now I navigated to the code folder within that download, copied the files within it to "\CumulusMX\interface\lib\highstock\js" and then copied the folders "modules" and "themes" from that code download folder into the same location. So now (in March 2020) everything is related to version 8.04 released 10 March 2020.
4. 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 should be fairly easy:
   • I copy \Cumulus\Cumulus1.ini to \CumulusMX folder as "Cumulus.ini". I then edit the MX "Cumulus.ini" file:
     • In the "[FTP site]" (yes, mine was named correctly with second word all lowercase), I had a number of edits to make:
       1. I change any references to web pages within "Cumulus" folder to say within "CumulusMX" folder.
       2. Next where I want a transfer done only at end of day, I have added lines like "ExtraEOD19=1" 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!
       3. I have a few files that are PHP scripts listed in this section written as Cumulus templates; each has a number of PHP variables being set equal to a Cumulus web tag. In some cases the web tags have date/time parameters, for these I had previously edited any ""hh" into "HH", any "mm" into "MM", any "mmm" into "MMM" and any "mmmm" into "MMMM" in line with the recommendations I had some years ago put in this table for Cumulus 1. That left "nn" for minutes in Cumulus 1 where I could not change it to a MX equivalent "mm" which Cumulus 1 would have taken as month. So now I created a new version of the one PHP script that used "nn", changed it in the new script to "mm" and changed the reference in the MX Cumulus.ini to the old file to refer to the new file. Subsequently I realised all my "am/pm" references had to be changed to "t" so I edited my new file again. Then another edit as I had a number of Recent History tags defined all with Cumulus 1 time specifiers having to be changed to MX equivalents. Yes quite a lot of work here, despite being able to use the Search ... Replace option in Notepad++.
       4. I also have some of my web pages generated from my own Cumulus templates. All the web tags in these that use date-time specifiers had to be edited, because I want to still use Cumulus 1 until MX is doing all I want, all these templates were given new names and I had to adjust the entries in "Cumulus.ini" to use these new names.
     • In the "[NOAA]" section I had MonthFileFormat="NOAAMO"MMMyyyy".txt" on a line, I checked at List of allowed date/time modifiers 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. Next, I copied my existing Cumulus 1 alarm sounds in "\Cumulus" across to MX folder "\CumulusMX\interface\sounds" as these were refenced in my main Cumulus.ini file.
   • The file "\CumulusMX\Reports\.gitignore" is joined in the Reports folder by copying in what I currently have in "\Cumulus\Reports". These are another "Cumulus.ini" and the existing monthly and annual NOAA reports. I don't need to change those file names as I will continue to use the same format (see change to main Cumulus.ini mentioned above).
   • Next I compare "\Cumulus\web" with "\CumulusMX\web", I notice the subfolder "images" has gone, I expected that from what I already know about MX and its use of Highcharts instead of uploading graphs (and the moon image). Also "realtimegaugesT.txt" is only in MX, I expected that knowing the gauges pages supplied with Cumulus 1 and MX are different. I mostly use my own web pages, so I don't worry about the template files.
   • 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.
   • So left to last is the "data" folder:
     • I have copied all files from "\Cumulus\data" to "\CumulusMX\data", and will see what edits I need to make later.
6. I tried typing "http://192.168.1.64.8998/" into my browser after starting the MX engine, but it gave a message "Server not found".
7. I opened my Internet Security premium package and in the firewall section set port 8998 as one that was permitted.

Updating to a new MX release

It is always best to take a backup of your existing MX installation before you do an update, this allows you to regress back to the earlier version if you mess up installing the new version.

Follow the instructions for installing, you download the zip, and copy it over the existing components in your MX folder.

If you have edited any files, see if the release notice says that file has been revised, if it has not then keep your edited file by not copying in the file within the zip. If the release revises a file you previously edited, take a backup of your edited file, before you copy the new file into your folder. You can then use a file comparing tool to see what has changed in the release and what you changed and hopefully manage to merge to a new file. This includes any web pages you might have edited to give the look you desire, or the content you want (e.g. adding rain this month to this month page, or combining this month and this year page).

Running Cumulus MX

Cumulus MX needs to run as an administrator on Windows and under Superuser (root) on Linux and OS X. Make sure your station is connected to the device on which you have installed Cumulus MX, before you try to run Cumulus MX.

Windows

Either right click on CumulusMX.exe and click 'Run as administrator', or open an administrator command prompt (right click on Command Prompt and click 'Run as administrator'), change to the Cumulus MX directory, and then type CumulusMX and enter. You will probably need to accept a security prompt the first time you run it, to allow it act as a web server. You can avoid having to run it as an administrator by running the following command once from an administrator command window:

netsh http add urlacl url=http://*:8998/ user=\users

This command allows all users to bind to port 8998 (used for the Cumulus interface). Note that if you change the interface port as described below, you should change the 8998 to whatever port you are using. Note that while this allows Cumulus MX to run and act as a web server, there may be other operations which require it to run as an administrator.

Linux and OS X

Open a terminal window, change to the Cumulus MX directory, and then type:

sudo mono CumulusMX.exe

When Cumulus starts, it will display the URL of the user interface. It runs on port 8998 by default; if this is not suitable for some reason you can over-ride it using the '-port' parameter on the command line, e.g. to use port 9999 instead:

sudo mono CumulusMX.exe -port 9999

Note that you may need to supply your administrator password after typing the 'sudo ...' command line. The system will prompt you for this.

Type the URL which is displayed (when MX starts running) into your browser (replace the * with the IP address, or use localhost) and the interface should appear. If this is a 'clean' installation, the first thing you will need to do is to go to the settings and set the station type and units, and any other configuration settings you want to make. Having set the station type, you will need stop Cumulus MX and start it again. Note that this also applies to some other settings - you will need to restart Cumulus MX to get the new setting picked up.

As with Cumulus 1, if there are any settings which are not currently available via the user interface, you can change them by stopping Cumulus and editing Cumulus.ini. A description of the settings in this file is in the wiki, and most of what is in there also applies to MX.

If you want to operate the 'standard' web site, then just the same as with Cumulus 1, you will need to upload the contents of the webfiles folder from the zip file (don't upload the containing webfiles folder itself). Note that the MX webfiles are not the same as the ones for Cumulus 1, so make sure you upload the MX files if moving from Cumulus 1 to MX. The standard gauges are now the SteelSeries gauges.

Important note about locales

On Linux and (in particular) OS X, Cumulus MX may not be given the correct locale to use, and you may get the default US locale even if that is not your locale. It will output the local it is using when it starts; if it is not correct, close it down and start it again, this time specifying your locale on the command line, using the -lang parameter . For example, in the UK, type:

sudo mono CumulusMX.exe -lang en-GB

If you are not sure what value you need to supply for the -lang parameter, there is a list here - http://msdn.microsoft.com/en-gb/library/ee825488%28v=cs.20%29.aspx. You need to supply the code in the first column ("Language Culture Name"). Note that this does not affect the language used by Cumulus MX (although it may in the future), it affects the decimal separator and the list separator.

Restrictions in MX for decimal separators

On the subject of decimal and list separators, there are a couple of issues which users of decimal commas may encounter.

1. The first is that there may be an issue with some of the user interface not working correctly. Please report these issues and I will fix them. There may be aspects of the displays that I cannot change (because the package used does not support decimal commas) but it should be possible to at least get it working.
2. The second issue with decimal separators only affects the Raspberry Pi (as far as I am aware). There is apparently an issue with the current version (3.2.8) of the Mono package on Raspbian 'hard float' where it cannot parse values using decimal commas. If this does turn out to be an issue, there are a number of possible workarounds until the Raspbian package gets updated. One workaround is to use the 'soft float' version of Debian instead. Obviously, this will have performance issues, but is probably the easiest. The second workaround is to build Mono from the latest sources, see http://www.mono-project.com/docs/compiling-mono/linux/. I am told that this fixes the problem. Another possible workaround would be to find an already fixed binary package, but I don't know if one currently exists.

If you want to use your Cumulus 1 data with MX

If you use decimal commas in your Cumulus 1 data, you will need to edit the .ini files to change the decimal commas into periods/full stops, because Cumulus MX always expects periods/full stops in .ini files regardless of the locale in use. The other data files will be OK - assuming you are using the same decimal and list separators in MX as you used in Cumulus 1 (i.e. the same locale). If you try to switch to a different locale, then your data log files will of course no longer be in the correct format, so you would need to edit all of your files.

A note to Davis owners

I am experimenting with the use of the LOOP2 packet. The current code uses this for two purposes. First, it uses the 'peak 10-minute gust' value, to avoid the problem where a gust might be missed (although hopefully this will not be such an issue with Cumulus MX as it does not use the Davis DLL), and secondly it uses the 'absolute pressure' value to make calculation of 'altimeter pressure' easier and more accurate. This is mainly used if you upload to CWOP.

The LOOP2 packet is supported on the VP2 with firmware version 1.90 or later, and on the Vue. If you have a Vantage Pro (i.e. the original 'VP1'), or a VP2 with pre-1.90 firmware, or if you are using Virtual VP, none of these support the LOOP2 packet. In these cases, you should edit cumulus.ini and add a line to the [Station] section:

UseDavisLoop2=0

With this setting, Cumulus will revert to calculating the 10-minute gust value itself from the individual wind speed readings, but it will not currently attempt to calculate altimeter pressure correctly, it will simply use the sea-level pressure instead. This is likely to be an issue if you are at high altitude and you upload to CWOP using Cumulus MX.

Also for Davis stations, I have assumed that people using millimetres in Cumulus have a metric rain gauge (0.2 mm per tip), and those using inches have a 0.01" rain gauge. This can be over-ridden by adding a line to the [Station] section of Cumulus.ini:

VPrainGaugeType=0

or

VPrainGaugeType=1

Where 0 is a 0.2mm gauge and 1 is a 0.01" gauge. Note that changing this after MX has already read some data may cause your rainfall reading for today etc to change considerably, so you will need to correct that.

Web Tags and related features

Almost all of the web tags from Cumulus 1 are supported in Cumulus MX.

Beta builds of MX

The following web tags were not available or worked differently:

• The individual 'record set' tags such as <#TempRecordSet> etc did not work (because the interface then had no indicators for new records).
• The <#newrecord> tag does work, but works differently, it turns itself off automatically after 24 hours.
• Some of the 'system status' web tags do not work: <#CpuName>, <#MemoryStatus>, <#DisplayMode>, <#DiskSize> and <#DiskFree>
• The <#txbattery> web tag has no content currently. Using it with a 'channel' parameter causes a 'token error'.
• The snow tags were not available as there was no Weather Diary

Current builds of MX

The web tags you have depend on which build you are using:

From Build 3046

• added <#snowdepth> tag processing
• added diary.db file

From build 3047

• Web token parser updated to cope with html tag characters "<>" in the format string e.g. <#TapptempH format="dd' 'MMM' 'yyyy' at 'HH:mm''">
• All record Value tags should now return '---' and Date tags '----' until they are first set.
• <#MoonAge>, <#MoonPercent>, <#MoonPercentAbs> - all given new 'dp' and 'rc' parameters.

From Version 3.1.1 - b3054

• Adds new web tags <#snowlying>, <#snowfalling>, both provide 1|0 responses

From build 3056 of version 3.2.0 (19 November 2019):

• Enables alarms as per Cumulus 1
  • New Alarm page under Settings
  • Alarms are shown visually on the dashboard
  • Due to browser restrictions, alarm sounds on the browser page may require you to click a button on the first alarm in order to hear it.
    • You can add the MX admin site to your browsers list of sites allowed to play sound automatically. Your browser should "learn" that you want to allow sounds to play automatically.
    • Alarm sound files should be placed in the /interface/sounds folder, they must be a browser compatible format (mp3 are good). The alarm settings for the sound file should be just the filename without any path
• Lots of new web tags not available in Cumulus 1, see release announcement for details

From Version 3.2.2 - build 3058

• Implements the missing <#txbattery> web tag

All builds of MX

The 'format' parameter on the date/time web tags is unfortunately different, because many of the characters used are different.

Note that this also applies to the NOAA report file formats.

For full details see the web tags article.

Cumulus MX FAQ

The FAQ page that was originally written for Cumulus 1 has now had some MX differences highlighted.

MX specific questions, such as those related to installation are now covered by the updated text above.

There is a third party offering for helping you start and stop Cumulus MX on a Raspberry Pi. There are two other related threads initiated by same author (Jank).

One problem various people have had is swapping from a Windows environment to a Linux environment. There are lots of new commands to learn, and specifying the interface is different so getting MX to connect to your weather station has been a problem for some.

For setting up your web site see this page first.

There is no guide yet to the MX setting pages. Generally any edit you make to a setting takes effect as soon as you move to next setting, but some only take effect when you next restart Cumulus MX. Most settings have a friendlier interface than the settings for the similar feature in Cumulus 1.

Cumulus MX supports updating to secure web sites, this feature is not yet properly documented.

The use of decimal comma gives rise to various problems mentioned in the forum, as the guidance above says Cumulus MX uses procedures that depend on full stops being used for the decimal point in many log files.

There is confusion between Cumulus 1 symbols for minutes (nn) and the Cumulus MX symbol for minutes (mm) which Cumulus 1 uses to represent months (mm or MM allowed). This is seen in NOAA report names and any web tags that have had a date-time modifier added.

On Cumulus 1, some people used '.' to separate the hours and minutes (HH.nn), this causes problems in MX that only accepts a colon separator (HH:mm). Thus files like the alltime.ini might have a mix of times in different formats.

Another issue raised from time to time in the forum is that if you swap from Cumulus 1 to MX it does not access the old NOAA reports (because the settings in MX were not set to generate same file naming as previously used in Cumulus 1).

Certain versions of Mono give problems, for example the Mono version 5 release has thrown up an issue with some locales and the short month names having an extra decimal point that Cumulus MX cannot cope with. Most of these problems are raised in the forum.

Cumulus MX Known Issues

See Steve Loft's post