If you are wondering what Cumulus software does, see this article.

Introduction

Before you read this article any further, read the article that introduces Cumulus first, as that will explain what Cumulus software can do for you, then you will be linked back to this page.

This Wiki article was originally exactly what Steve Loft said in the support forum when he first started experimenting with Cumulus MX and access was restricted to those willing to experiment with his tests.

At that stage, Cumulus 1 was still recommended for most users, because MX was experimental and it had limited functionality. Now that further development is adding lots more functionality into MX, this is the Cumulus flavour that most users will select to install and run. However, whether you have used Cumulus 1 in the past, or are new to Cumulus, there are no instructions built into the MX package, so it is hoped that the update of this article will help people to understand MX sufficiently to use it both more easily and to maximum capability.

Restrictions on who can use MX

Message from Steve Loft

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

Message from Steve Loft

There's quite a lot to read before you start - please do read all of 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 Frequently Asked Questions for Cumulus 1, Frequently asked questions for MX, and articles elsewhere in this 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.

Update

The update made to this page draws on what has been said spread over lots of posts on the support forum and attempts to make it more accessible by repeating it on this page. In writing this update, I have drawn on my own experience of moving from Cumulus 1 to MX, but saved you the pain of where I went wrong, just telling you what is correct.

If this page, and those other Wiki pages it links to (e.g. a new Cumulus FAQ), do not answer all your questions then see the support forum for current Cumulus MX as that will let you see what other people have asked about, any posts I have not yet incorporated into this page, and there you get the opportunity to post your own query.

Comparing Cumulus 1 and MX

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

• 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) from the user interface (displays basic information, allows you to vary settings, contains editors for highs and lows and for log files).
• Like Cumulus 2, MX runs on Linux and OS X as well as (like Cumulus 1) Windows.

Features and functionality

Initially MX, as written by Steve Loft, lacked a lot of features that were available in Cumulus 1, but subsequent 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. All quotes are from the release notes issued by Steve or Mark. Only changes to functionality are noted below (for fixes see support forum for full release announcements). There is some version information here from MX build 350 onwards.

• 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 station
  • Improved console messages at start up to indicate whether station has been connected successfully
  • Make sure dayfile.txt entry is always logged to diags in case of problems writing file
  • 'Stop second instance' option now implemented
  • 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.

Accessing user interface

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 '192.168.y.z' (where y and z are numbers that vary between implementations) if the browser is on a different machine OR if "localhost" is already in use for another web server. For security reasons, the user interface should not be accessible via the public internet.

Operating Systems

MX runs on:

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

Configuration and Log 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. Look up the Log Files index page or the individual file pages just referenced 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 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) that were not part of Cumulus 1.

Installing and Running Cumulus MX

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

When running Cumulus MX, you either have a package that runs it for you, or you type CumulusMX.exe in your command type interface (or click a shortcut). You can however add parameters to the run instruction e.g. CumulusMX.exe -lang en-GB (to select the GB locale), CumulusMX.exe Current culture: English (United States), CumulusMX.exe -lang de-DE, CumulusMX.exe -lang el-GR (this is one of the locales that reads numbers with integer,decimal format), CumulusMX.exe -lang nl-NL, CumulusMX.exe -port 8002 (to change the port where the user interface runs), or CumulusMX.exe -debug (to have full debugging turned on as MX starts), CumulusMX.exe -Logging=1 (for the Davis specific logging). Try start /min C:\Cumulus\CumulusMX.exe to run MX as a minimised package.

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. The .Net download for version 4.8 should be here https://dotnet.microsoft.com/download/dotnet-framework/net48 .

You can run MX as administrator, but you don't need to if you run this MSDOS command in a Command Prompt window opened with Administrator rights that will grant all users the right to bind to port 8998 -

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

After you have done this you can run CumulusMX.exe normally without Administrator rights and therefore you can create a short-cut to run MX when your PC starts (put your user name where I have put ...), the shortcut should point to T:\CumulusMX\CumulusMX.exe (where T denotes the drive on which you have installed MX as it does not need to be the same as where your operating system is):

C:\Users\...\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\CumulusMX.exe

With this you might want to right click on that shortcut, select properties, then you can set the starting position for the command window, the colours and font it will use, and even choose to start minimised, amongst many other selections.

Look at your hub or router (this should have come with instructions on how to do this in your browser) and on one screen it should show what devices are connected to your LAN and wifi. Look for the IPv4 address (w.x.y.z) of the device you have installed MX on, for example 192.168.1.64. Then give your Computer a fixed address for MX user interface by finding the network card via Network and Sharing Centre (Control Panel), click on Change Adapter Settings, then Right click on Ethernet or WiFi Adapter, select Properties and in the window that opens right click on Internet Protocol Version 4 (TCP/IP 4), and select properties and on that pop up screen tell the computer to "use the following IP address and fill it out with a subnet mask of 255.255.255.0 and gateway address between 192.168.1.1 and 192.168.1.254 (depending on the address of your hub/router).

Requirements for running on Linux and OS X

You will need to install the Mono runtime (the latest version of Mono should work with latest MX in all locales).

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

Notes by Steve Loft

please note these notes may now be obsolete, library routines have changed a lot since this was written in 2014

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

You need to specify something like /dev/ttyUSB0 for the connection for your weather station. This is set in the "station settings" and stored in the ComportName attribute in Cumulus.ini configuration file.

In some builds of MX you have to run as "root", there are ways of giving "root" like permissions when running MX as another user, see forum for details until this section has been updated.

Completely new MX installation

Create a new directory (recommended name CumulusMX) and unzip the contents of the download package into it. See notes above for extras required in various operating systems.

The package contains everything else you need to read from your weather station (if it is a supported model), to load up the user interface (for settings and some simple web pages to see on a device connected to your home network), and to even have some web pages (if you have a web site to run them on). You might want to read topics on the MX support forum to discover about other people's experiences.

Changing from Cumulus 1 to 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 (used on Cumulus 1 trends page). Cumulus MX does not upload any images (prior to Release 3.5.0, from then on it uploads a moon phase image), instead it uploads a series of .json files that hold time and value pairs that can be used to draw graphs. 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.

Remember, that depending on the operating system, MX may require you to install extra components, see above for details.

You may be installing MX on a different device to the Windows PC that Cumulus 1 ran on, in that case follow first alternative below.

1. If you are installing MX on a PC that has been running Cumulus 1, then there are actually 2 alternatives to choose between:
   1. 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). In this case you will need to edit that copied across "Cumulus.ini" so any lines that referenced the old folder are changed to reference the new folder, and you may need to edit a few other items either now, or via the settings functionality in MX user interface. 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).
   2. 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. This saves you from the need to edit any reference to folders, but stops you going back easily to Cumulus 1 if you have an issue.
2. If your "Cumulus.ini" was actually called "cumulus.ini" you should rename it to start with a capital letter. There are some differences in how the contents of 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 MX uses that to find the first log file to start reading from, whilst Cumulus 1 just looks at all log files it finds in the data folder. There are several other differences, but you can address those later through the MX settings screens.
3. See individual log file pages already referenced (access from Log Files index page) where there is more information for how to edit your .ini files to work with MX.

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). For example from version 3.5.0 the obsolete Highstocks I mention below is no longer included in the MX package, instead MX uses the online latest version.

Download and unzip

1. I downloaded the CumulusMXDist3069 zip from the Current Release section on the downloads page. N.B. 3069 is no longer latest distribution, but the same link will always give you latest available.
2. I unzipped the contents (on my Windows PC) into a partition I use just for software downloads. You don't have to have somewhere separate to the installation, but it is useful if you want to download on a separate device to the device where you will install your MX, or if you do any customisation of particular files and wish to keep copies of originals.
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:
   • As downloaded, the MX 3.4.5 package contained obsolete vintage version 2.1.4 (2015-03-10) of Highstocks and Highcharts within the interface folder "\CumulusMX\interface\lib\highstock", so I downloaded latest versions from the Highstock link and saved that on my partition I just use for software downloads. I then created a new folder obsolete within existing folder "\CumulusMX\interface\lib\highstock\js", moved the folders "modules" and "themes" that were in the existing folder into my new folder, and next I moved the various highstock and highchart files that were in this same existing folder into the obsolete folder. Now I navigated to the code folder within my new 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 replace the ones I moved out. So now (in March 2020) everything is related to Highstock version 8.04 released 10 March 2020. This matches the version I use with my own web pages on my web server.
   • As downloaded, "\CumulusMX\webfiles\lib\jquery" contained jQuery version 1.9.1, that is 2014 vintage and very obsolete, 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. If you do want to use a newer version of jQuery on your web site, you can download latest compressed production version from jQuery web site. I prefixed the version in the MX package with the word OBSOLETE (OBSOLETEjquery-latest.min.js), you will find the latest version you download is called jquery-3.4.1.min.js. If you are using MX web pages, rename that new jQuery to "jquery-latest.min.js" to match the name that MX uses.
   • Other parts of the interface also had old versions of library software, but (because the interface uses json files to drive content of the various screens) I had no guarantee that its screens would work with later versions of the following libraries:
     • "\CumulusMX\interface\lib\jquery" contained the same old jQuery version 1.9.1, that is 2014 vintage and very obsolete, whether you update that or not is your choice, but there is no guarantee that the MX user interface will work fully with latest jQuery version.
   • "\CumulusMX\interface\lib\alpaca" included "alpaca" old version 1.1.3 which predates 29 July 2014, the latest I found [http://www.alpacajs.org is the alpaca home page] was version: 1.5.27 released on 14 May 2019, again there is no guarantee that the MX user interface will work fully with these new versions, so I use what MX provides.

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 should be fairly easy:

1. First, I copied my \Cumulus\strings.ini to \CumulusMX\strings.ini. This preserves any tailoring I have done of terminology.
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.
3. I copy \Cumulus\Cumulus1.ini 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).
   • In the "[FTP site]" section (yes, mine was named correctly with second word all lowercase), I had a number of edits to make:
     1. I change any references to any web pages within "Cumulus" folder to say within "CumulusMX" folder. The approach I am taking is to continue to use my customised web pages, but I am editing the template files as required to cope with differences in the output parameters of MX web tags.
     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! I know I could do this later using the MX interface, but it makes sense to me to do it as I am working through the file.
     3. I have a few files that are PHP scripts, or web pages, listed in this section, all written as Cumulus templates; each PHP script has a number of PHP variables being set equal to a Cumulus web tag while the web page templates embed a lot of Cumulus web tags. In some cases the web tags have date/time output format 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 that I had some years ago typed into this table for Cumulus 1. That left "nn" for minutes in Cumulus 1 where I could only change it to a MX equivalent "mm" in those cases where Cumulus 1 would have not taken it as month, I was too lazy to check every individual cases (I prefer to use global edits across all my files). So now I created a new version of each PHP script that used "nn", changed it in each new script to "mm" and changed each reference in the MX Cumulus.ini to the old files to refer to the new files. Subsequently I realised all my "am/pm" references had to be changed to "tt" so I edited my new files again. There were other changes I had to make, in Cumulus 1 you can use tags like 'H' and 'M' on their own, in MX a single modifier on its own often means something different to when that modifier appears with other modifers. Yes quite a lot of work here, despite being able to use the Search ... Replace option in Notepad++. As a result I have done some edits to this table hopefully making life simpler for the next person faced with this.
     4. 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 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 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.
4. The file "\CumulusMX\Reports\.gitignore" is joined in the \CumulusMX\Reports folder by copying in what I currently have in "\Cumulus\Reports". These are another "Cumulus.ini" (I am certain this is not used, but I am playing safe by coping it in) 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).
5. 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 weather time-series 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.
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 will see what edits I need to make later. Some of my .ini contain date-time entries like "12/03/2019 14:50:45".

Almost "Ready to run"

1. 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 picked up from reading on the forum, you don't need to edit beforehand these entries in log files like month.ini as Cumulus MX can read the old ones.
2. I right clicked on the "CumulusMX.exe" entry in the top level folder and selected Send to ... desktop (create shortcut) . 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 can 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].
3. I clicked on one of my new shortcuts. Windows Defender popped up, so I told it allow all for Cumulus MX. For the shortcut in the "Startup" folder, I righ-clicked and set up on the layout tab the necessary parameters to place the window that opened on the smaller of the 2 monitors I have connected to my PC, so when it is not minimised (another setting on the shortcut tab) it does not interfere with whatever I am doing on my larger main monitor.
4. 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 (I will need to repeat this every time a new version is installed) and in the "Firewall" section of the Internet Security package I added port 8998 as one that was permitted.
5. 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.
6. 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 user interface on my mobile phone which shares bookmarks with my PC and connects to my LAN via wifi.

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

One more lesson, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station. If you sometimes run one flavour (say MX) and sometimes the other (Cumulus 1), 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. If you don't do either of those alternatives, 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 wind vector. It also affects any 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.

Success

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. I am continuing to use Cumulus 1 for the moment, until I am absolutely sure MX can do everything I want. I believe it will do some tasks better, but there is a lot more to learn about how to use it.

Some days later, 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.

Editing the User Interface

The general advice is do not change any files that are part of the MX package, they are a package and therefore there are interdependencies. Also updating to a newer release is more complicated if you have edited any files. The files as provided in the MX package are a compromise, for example they include reporting on solar measurements but not all weather stations include such measurements. Given that the user interface is not shared with anyone else, it could be argued its look and content is not that important. In particular this interface is the only way to change settings, so do not change anything that stops those setting screens from working!

Remember, if you decide to download a new release to not overwrite any file(s) that you have edited, or your edit will be lost. It is less likely that a new release will change the interface files than other files, but some releases do change these files. Remember, each release zip contains all MX files, even those not changed since previous release. The release notice will usually give some idea of whether interface files have changed, but it may not list which interface files have been added, modified, or removed.

If you do decide to change any file, I suggest you maintain a back-up copy of the original elsewhere (so it can be gone back to) and you save the edited file under a new name (so you can't lose my edited file by installing a new release).

Changing the look

You need some understanding of Cascading Style Sheets (CSS) to do this, but all you need to do is to edit the relevant style sheet either in \CumulusMX\interface\css or in the relevant folder within the lib folder. You may feel that the default look of grey, black, and white, is either boring or does not offer sufficient contrast for you, perhaps you feel certain font sizes are too small, or you want to change the page background. Well, you can change the look, it is all defined in .css files. However, because MX makes use of standard libraries (bootstrap, datatables, alcapa etc.) there are a multitude of .css files used and it might not be easy to work out which one to edit. Each HTML page has links to a number of css files. You will probably make use of developer functions in your browser to inspect any element whose look you wish to change to see where its different properties are defined. It is better to make any such edits at a high level, rather than on any CSS just for that particular element. As always when editing, keep a copy of original so you can go back to it; keep a copy of your edited file, so installing a new release does not lose you edited file.

Removing Solar Figures

If your weather station does not have solar instrumentation you might wish to remove some of the display elements that relate to that. You need some understanding of Hyper-Text Markup Language to do this correctly, but here are simple examples.

1. Navigate to \CumulusMX\interface folder.
2. Open the file now.html in an editor designed for code (e.g. Notepad++ for Windows, Notetab Lite)
3. Near the bottom of the file edit it by inserting HTML comment delimiters (opening after </thead>, closing before </table>) so it looks like this:

<table id="SolarTable" style="width:100%">
      <thead>
          <tr>
               <th> Solar</th>
               <th></th>
               <th></th>
         </tr>
      </thead>
  <!--
         <tr>
               <td>Solar Radiation</td>
               <td><span id="SolarRad">--</span></td>
               <td>W/m<sup>2</sup></td>
         </tr>
         <tr>
               <td>Sunshine Today</td>
               <td><span id="SunshineHours">--</span></td>
               <td>hrs</td>
         </tr>
         <tr>
                <td>UV</td>
                <td><span id="UVindex">--</span></td>
                <td></td>
         </tr>
   -->
</table> 

IMPORTANT NOTES:

1. The above approach works on "now.html", but it does not work on other pages where table rows are dynamically created by an external script, so the existing rows in the table body are dummies whose content is ignored.

• An alternative technique is to delete the whole table and any "<div> .. </div>" that surrounds only that table, that will work on all the HTML pages.

Adding derivatives not shown on the existing interface page

It is a JavaScript file \CumulusMX\interface\js\dashboard.js that reads the real-time file and inserts particular content into position indicated by values of the HTML attribute "id" on the interface screens. The standard \CumulusMX\interface\now.html does not include temperature trend for example, but because there is a temptrend: inp.TempTrend.toString() defined in the JavaScript file, you can easily add it to the "now" page by a simple insert of the middle row here:

<tr>
          <td>Outdoor Temperature</td>
          <td><span id="OutdoorTemp">--</span></td>
          <td><span class="TempUnit">--</span></td>
</tr>
<tr>
           <td>Trend</td>
           <td><span id="TempTrend">--</span></td>
           <td><span class="TempUnit">--</span> hour<sup>-1</sup></td>
</tr>
<tr>
           <td>Dew Point</td>
           <td><span id="OutdoorDewpoint">--</span></td>
           <td><span class="TempUnit">--</span></td>
</tr>

You can't add any derivatives into any table unless the value (for the derivative you want to add) is already defined in the related files.

There is a section of the support forum devoted to Cumulus MX interface customisation, so you can see what other people are doing. There is also another sub-forum for making suggestions on what you would like added to MX.

Changing Settings

This is done using the MX "user interface", you will see that Settings is the penultimate option in the navigation bar, and it has a drop down for the various settings screens that are now described.

Most settings are best made using these screens rather than in the file that stores them, as each setting screen uses tick boxes, radio buttons, and drop down selection boxes, wherever possible, so the choices available are clearly laid out. There are however some settings that can not be found in any of the setting screens, for these you need to edit the Cumulus.ini file directly, and the referenced Wiki page gives details of which settings can only be adjusted by adding parameters in the file, and tells you what values are accepted for those attributes.

Station Settings

Each setting has a hint beside it (with a small 'i' for information before each hint). If you have used Cumulus 1, the layout and section headings will be familiar. Like all the settings pages, the headings are collapsed and need to be clicked to see the items under them. The table here will explain how MX stores the selections you make here, and give a bit more detail about each item and the values it can take.

Internet Settings

This has a lot of similarities with the Cumulus 1 settings, except that this screen only covers what was on the main tab in Cumulus 1. Again there are hints, MX has more options than Cumulus 1 had, and some defaults are different in the two flavours. Windy has been added to the external web sites that can be automatically updated.

The main new feature within this settings page is a Custom Http section. Within here you can define commands to be executed at some multiple of seconds interval, at one of 1 specified intervals in minutes and at end of day (before external programs, and that is before EOD for Extra Files). In each of these you can use web tags to supply values for parameters to the command. You need to turn on enhanced debug logging to see confirmation that the http has run:

2018-07-21 16:05:00.821 Custom HTTP Minutes update
2018-07-21 16:05:01.037 Custom HTTP Minutes response: OK: ok! (24.2)

Extra Web Files

This is an extension of the Cumulus 1 facility on the "Files" tab of its Internet Settings. How to use these settings is explained for both Cumulus flavours on another Wiki page here, MX has an extra "end of day" option (leave "realtime" and normal updating columns blank if you tick the new column), but otherwise you fill it out exactly the same way. If you have moved from Cumulus 1, you might need to:

1. change some paths in local column, as you may be referencing some files moved when you installed MX
2. untick one column, and tick another, now that EOD is an option for the timing as well as real-time and normal logging/ftp interval.
3. edit some templates where the process column is ticked because of Web tags differences meaning that some output modifiers are interpreted differently.

Calibration settings

This is identical to Cumulus 1 screen functionality, already explained in Cumulus 1 FAQ here and "Dealing with rogue measurements" in this wiki.

NOAA report settings

This is identical to Cumulus 1 functionality, the various settings available on this screen are already explained elsewhere in this wiki.

MySQL settings

Cumulus MX includes functionality not in Cumulus 1, and this is one example of a new feature. It was developed from this script for Cumulus 1. If you want to insert historic data (i.e. from before you first use this feature in MX), the script just referenced can be used, or you can write your own SQL.

Mandatory section

• Server Details - expand this drop down as it is used for essential information for any access to database
  1. Enter your host name or a IPv4 address for your web server. If you host your own server, it might be something like 127.0.0.1. It is the same as you enter for host in the "internet settings" screen.
  2. Enter the port for communicating with database server e.g. 33106.
  3. Enter the User Name for updating your database.
  4. Enter the password for updating your database.
  5. Enter the name of the database that holds the tables you wish to update

Optional Sections

The remaining 6 drop-down sections are optional, you choose which you want to use, they appear on the screen in a different order to how I explain them below.

• Dayfile.txt upload
  • This feature is to upload the line added to this log file at the end of the day, into a new row in a database table
  • Before you enable this option there is a separate option lower down on the settings page to create this database table Create Dayfile. First choose the table name here, and hit Save, then you can click Create Dayfile and with the default table name, it will create the table using the following SQL:

CREATE TABLE Dayfile (LogDate date NOT NULL ,HighWindGust decimal(4,1) NOT NULL,HWindGBear varchar(3) NOT NULL,THWindG varchar(5) NOT NULL,MinTemp decimal(5,1) NOT NULL,TMinTemp varchar(5) NOT NULL,MaxTemp decimal(5,1) NOT NULL,TMaxTemp varchar(5) NOT NULL,MinPress decimal(6,1) NOT NULL,TMinPress varchar(5) NOT NULL,MaxPress decimal(6,1) NOT NULL,TMaxPress varchar(5) NOT NULL,MaxRainRate decimal(4,1) NOT NULL,TMaxRR varchar(5) NOT NULL,TotRainFall decimal(6,1) NOT NULL,AvgTemp decimal(4,1) NOT NULL,TotWindRun decimal(5,1) NOT NULL,HighAvgWSpeed decimal(3,1),THAvgWSpeed varchar(5),LowHum decimal(4,0),TLowHum varchar(5),HighHum decimal(4,0),THighHum varchar(5),TotalEvap decimal(5,1),HoursSun decimal(3,1),HighHeatInd decimal(4,1),THighHeatInd varchar(5),HighAppTemp decimal(4,1),THighAppTemp varchar(5),LowAppTemp decimal(4,1),TLowAppTemp varchar(5),HighHourRain decimal(4,1),THighHourRain varchar(5),LowWindChill decimal(4,1),TLowWindChill varchar(5),HighDewPoint decimal(4,1),THighDewPoint varchar(5),LowDewPoint decimal(4,1),TLowDewPoint varchar(5),DomWindDir varchar(3),HeatDegDays decimal(4,1),CoolDegDays decimal(4,1),HighSolarRad decimal(5,1),THighSolarRad varchar(5),HighUV decimal(3,1),THighUV varchar(5),HWindGBearSym varchar(3),DomWindDirSym varchar(3),PRIMARY KEY(LogDate)) COMMENT = "Dayfile from Cumulus"

• There are just 2 items on the settings menu:
  1. A tick box that you tick if you want the schema shown above to be used to store lines from dayfile.txt in a database table
  2. A text box where you can change the default table name to one that suits you better. Do not leave this blank, SQL requires a table name.

• Custom upload - at rollover
  • In the previous option, you have no ability to vary the schema, it will update a column for Total Evaporation even if your weather station cannot calculate that. It will update columns for total hours of sunshine, highest solar radiation level, and the maximum UV in the day even if you cannot measure these. It will not record whether snow was falling or lying, or the depth of snow even if you are recording those.
  • MX provides this alternative option, again doing an upload as part of roll over to next day, but here you can specify the schema, and say which columns are to be updated with two options:
  1. A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
  2. The SQL you want to run, it should include INSERT IGNORE (or REPLACE or UPDATE) to insert a row, the name of the table, the columns to be updated and the values you include in your SQL are expressed as web tags.
     • Here is an example of a suitable query that MX can process for you (note I have had to include some yesterday tags e.g. for primary key):

INSERT IGNORE INTO `test_daily_summary` (`MaxRainRate`, `TMaxRainRate`, `HighHourRain`, `THighHourRain`, `TotRainFall`, `SnowFalling`, `SnowLying`, `SnowDepth`,  `CumChillHours`, `LogDate`, `RollOver`,  `MinTemp`, `TMinTemp`, `HeatDegDays`, `AvgTemp`, `MaxTemp`, `TMaxTemp`, `CoolDegDays`, `LowDewPoint`, `TLowDewPoint`, `LowHum`, `TLowHum`, `HighHum`, `THighHum`, `HighDewPoint`, `THighDewPoint`, `GreatWindChill`, `TGreatWindChill`, `LowAppTemp`, `TLowAppTemp`, `HighAppTemp`, `THighAppTemp`, `HighHeatInd`, `THighHeatInd`, `MinPress`, `TMinPress`, `MaxPress`, `TMaxPress`, `HighAvgWSpeed`, `THighAvgWSpeed`, `StrongestWindGust`, `TStrongestWindGust`, `BearStrongestWindGust`,  `BearDomWind`, `BearDomWindSym`,  `TotWindRun`) VALUES ('<#rrateTM>', '<#TrrateTM>', '<#hourlyrainTH>', '<#ThourlyrainTH>', '<#rfall> ', '<#snowfalling>', '<#snowlying>', '<#snowdepth>', '<#chillhours> ', '<#metdateyesterday format=yyyy-MM-dd>',  '<#rollovertime>', '<#tempYL>', '<#TtempYL> ', '<#heatdegdays> ', '<#avgtemp>', '<#tempTH>', '<#TtempTH> ', '<#cooldegdays> ', '<#dewpointTL>', '<#TdewpointTL>', '<#humTL>', '<#ThumTL>', '<#humTH>', '<#ThumTH>', '<#dewpointTH>', '<#TdewpointTH>', '<#wchillTL>', '<#TwchillTL>', '<#apptempTL>', '<#TapptempTL>', '<#apptempTH>', '<#TapptempTH>', '<#heatindexTH>', '<#TheatindexTH>', '<#pressTL>', '<#TpressTL>', '<#pressTH>', '<#TpressTH>', '<#windTM>', '<#TwindTM>', '<#wgustTM>', '<#TwgustTM>', '<#bearingTM>', '<#domwindbearing>', '<#domwinddir>', '<#windrun>')

• • Again before you enable this option, there is a facility lower down this setting page (under the heading Create database table) where you can type some SQL to be run immediately, that can create the table you want this option to update, (although it could even populate any table with historic data, it is only intended for a small query). I am using a table that already exists as I have used it for testing changes to my PHP scripts, so I did not need to create a table.

• Monthly log file upload
  • Before you enable this option, there is a separate option, lower down this settings page, to create this table (you must save the settings here to tell Cumulus what table name you want), then click Create Monthly.
  • This feature allows you to upload the file that Cumulus creates each month to log measurements on a regular basis, it has just two items:
  1. A tick box, where you tick if you want a standard table structure to be used to reflect the fields in the detailed log file
  2. A text box where you can change the default table name to one that suits you better. Do not leave this blank, SQL requires a table name.
  • If the table does not exist it will be created, before the new row is added
  • If the table already has rows, the upload just creates a new row

• Custom upload - minutes interval
  • This feature allows you to specify your own SQL for an upload to be repeated every NN minutes. There are 3 items:
  1. A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
  2. The SQL you want to run, it should include INSERT IGNORE (or REPLACE or UPDATE) to insert a row, the name of the table, the columns to be updated and the values you include in your SQL are expressed as web tags.
  3. A drop down for the number of minutes between runs, the default is 10, but if your weather station updates less frequently, maybe you will choose 15, 20, 30, or 60 as the interval out of the 11 available in drop down.
  • One way you could use this option, is to replace the monthly log file upload if you wanted to change the schema, by leaving out some columns if your weather station is not able to measure all the derivatives included in the standard schema.

• Realtime.txt upload
  • This feature allows you to upload the file that Cumulus recreates on the most frequent basis.
  • There are 3 items for this option:
  1. A tick box to enable this very frequent upload
  2. A text box where you can change the default table name
  3. A text box where you enter a retention string in format retainVal=NNN retainUnit=XXXX where NNN is a number from 1 to 3 digits long, and XXX is a time unit like "days"
  • Because the updates are so frequent this database table grows very quickly, and you need to say when it should delete the older rows so the table never has too many rows. If you think about it, after a few days, you probably do not need to look at this very detailed level of values information within a day. In that case set retention to delete after a few days.

• Custom upload - seconds interval
  • This feature allows you to specify your own SQL for an upload to be repeated every NN seconds. There are 3 items:
  1. A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
  2. The SQL you want to run, it should include INSERT IGNORE (or REPLACE or UPDATE) to insert a row, the name of the table, the columns to be updated and the values you include in your SQL are expressed as web tags. You can have more than one SQL statement in this box (end each with semi-colon) so you might want to add a delete "DELETE FROM YourTableName WHERE LogDateTime < DATE_SUB(NOW(), INTERVAL 7 DAY);" after your update/insert command to replicate the retention option of the previous feature, in this case deleting rows over a week old.
  3. The number of seconds between runs, the default is 10, but if your weather station updates less frequently, maybe you will choose 40 or 60 as the interval.

Alarms

This is identical to Cumulus 1 functionality, apart from using a new default location for the files "\CumulusMX\interface\sounds", the alarms available are already explained elsewhere in this wiki.

The alarms are shown at the bottom of the Dashboard page of the user interface. They also feed a set of Webtags.

FTP Now

This is similar to the option in the file menu of Cumulus 1 to do an update now. Depending on which build of MX you are using, the functionality varies. On latest build it does whatever updates are set up to happen at normal updating interval whether these are by FTP to your web site, or by copying files between local and remote filenames with path (although both could be on same device).

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.

Best way is to rename your current install directory, then unzip the new release, letting it create a new CumulusMX folder. Copy across Cumulus.ini into that new directory, and then copy the contents of the data and Reports directories from your current install to the new install.

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 replacement 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 that keeps any functionality change in a new release and keeps your customisation. 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). If you have done major customisation to the standard website then you probably have your equivalents to the standard web page in a different directory and use Extra Files to specify where they are, so the new MX will still find them. If you have done any customisation to the interface then copy across just the files that you have customised of the interface folder from the current installation to the new installation - but be careful with this one, as many releases change the interface in some way and you must not lose any vital functionality.

Start the new installation of MX and watch out for any errors - If the device you run MX on has a monitor, then look in the terminal/command window. In all cases look at the latest file in the MXdiags folder to see if any errors are reported.

Finally, don't delete your old installation for a week or so as you may notice something from the older version that you haven't copied across!

Running Cumulus MX

1. Make sure your station is connected to the device on which you have installed Cumulus MX, before you try to run Cumulus MX.
2. Start Cumulus MX engine (command to do this varies between operating systems, so see sub-heading for you device below
3. Start user interface

If you are running MX for the first time, without a configuration file (none is included in download package), see here for screen shots and instructions.

Windows

Cumulus MX initiates a web server, to do this it may need administrative access, consequently to avoid having to run it as an administrator you can issue a command that 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. To enter the command, first open a command window as administrator. One way to do this is to right click the windows symbol at the start of the windows task bar. The option to choose there (on windows 10) is Windows PowerShell (admin), but an option called Command Prompt (Administrator) will also work. Once that opens a new window type:

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

You only need to do that once.

1. Each time you want to run Cumulus:
   • Open the folder where you installed MX and click on the CumulusMX.exe to run it. (There are some optional parameters that can be used)
   • OR create a shortcut on your desktop (and/or the taskbar) for that executable and click the shortcut to start the engine.
   • OR place the shortcut in the start up folder for the user account so MX automatically starts when you connect/log in.
2. Start the user interface, when you need it (when you first use MX you will need it to access the settings where you tell MX what type of station you have and what units you want to use, and set various timing options), it normally runs on port 8998 (to vary that there is a -port parameter that is followed by required port and has to be entered every time you start MX).

Linux and OS X

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

sudo mono CumulusMX.exe

Parameter for changing Port

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

Parameter for changing Locale

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. Note that you may need to supply your administrator password after typing the 'sudo ...' command line. The system will prompt you for this if it is needed.

User Interface

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 may 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. Follow that link to see what you can add in that file, and (if you are swapping from Cumulus 1 to MX) how that file varies between Cumulus flavours.

Operating a web site

• 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 web files 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.

SPECIAL CONSIDERATIONS - Text by Steve Loft

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. A new FAQ for MX has been started at another page.

MX specific questions, such as those related to installation are now covered by the updated text on this "Cumulus MX" page.

Cumulus MX Known Issues

See Steve Loft's post