MX on Windows OS
Request to Readers
When everyone used Cumulus 1, the Cumulus Wiki was highly rated as being comprehensive (partly because there were multiple contributors).
MX development has been so rapid, with MX now having so much functionality the documentation has not caught up (partly because of lack of contributors).
Can you contribute? Will you make this page more useful by bringing content up-to-date?
- 1 Introduction
- 2 Download MX release
- 3 Where to store the download zip
- 4 Where to unzip distribution files
- 5 Other executables
- 6 Requirements for running MX on Windows
- 7 How to run MX
- 8 Access to admin interface
- 9 One-off essential settings
- 10 Upgrade to a new MX release
- 11 One-off optional uploads
- 12 Operating a web site with uploads from MX engine
- 13 Optional parameters to add to the instruction to run the MX engine
This page is a simple summary for installing and running (non-beta) releases of MX on any computer running the Microsoft Windows Operating System.
If you are not running MX using the Microsoft Windows Operating System, then please see MX on Linux page instead.
There are various related pages to get more information:
- Go to Category:Terminology for links to pages that explain terminology used by Cumulus (some of these need updating for MX)
- Go to Category:Cumulus MX for links to all pages in this Cumulus Wiki that relate specifically to MX
- Admin interface provides information on configuration and web pages for viewing your weather data locally
- Go to Category:Cumulus Files for links to all pages describing the sub-folders and files used by MX
- If you encounter a problem when running MX, see What to do when I have a problem with MX
- The Cumulus MX FAQ page was created with snippets from the forum, but nobody has yet sorted this out into a useful page or updated it for recent releases
- If you were using the original (now legacy) Cumulus software, please read Migrating_from_Cumulus_1_to_MX, although that was written for an obsolete MX release, it will help you understand configuration differences.
Download MX release
Decide whether you want latest release, by looking in the support forum to see if any bugs are reported with it.
Read the relevant release announcement at Cumulus MX Announcements and Download - PLEASE READ FIRST, because that may describe one-off tasks associated with that release.
Latest MX release
- To find the link to latest release distribution zip in the Cumulus Wiki, open the Software page and navigate to the Current_Release section.
- Download the MX distribution from the link that appears there, Mark will update it for each release he makes.
Earlier MX releases
'If the latest release has bugs (it is impossible for the developer to check all the ways in which versatile MX can be used), you can download, whatever older version of MX you have decided is sufficiently bug-free to install, from CumulusMX/releases.
Where to store the download zip
- It is up to you, where you store the download, but it is a good idea to store it on a separate disc, or partition, if you have a choice.
- Whether this location is the default, or you are asked to select location will depend on whether your browser's default settings have been changed.
- When download completes, use the mouse to click on the download file name, this should ask if you want to extract (unzip) it.
- Decide where you want the full distribution to be stored, again you might have somewhere where you backup files.
Where to unzip distribution files
The only rule about where you put the MX files is "avoid the 'Program File' hierarchy".
Best practice is to place MX files in the root directory of any disc or partition where you have frequent updating.
MX uses a number of different computer languages and multiple components. It is best to keep the path short, to remove any possibility of path name being truncated as it is passed between components.
As well as CumulusMX.exe, you will find CreateMissing.exe and ExportToMySQL.exe zips to download from the Software page. These should be unzipped so their executables are added to same folder as CumulusMX.exe. Both have been written in C# by Mark Crossley to work with MX. You need to ensure that you use the right version of these utilities for the MX release you are running, so if you are using an old MX release, you might need to go directly to the Cumulus MX github page, and navigate to the utility of interest, to download an older version of these utilities.
Although you might not need them immediately, these utilities may be useful in future. Simple Instructions for using these executables are on the github page where they are found, again links exist on Software page in this Wiki. Note that for Windows, you don't quote the ".exe" when running them.
Using CreateMissing.exe is fully documented at Calculate_Missing_Values#CreateMissing.exe in this Wiki.
ExportToMySQL.exe is not (at the time this was written) documented in this Wiki although MX_Administrative_Interface#MySQL_settings does describe a similar utility (written by Steve Loft) that was actually included in early MX release downloads.
Requirements for running MX on Windows
To run MX on Windows, you need .Net version of at least 4.5.2 installed. This is only available for the Vista SP2, Windows 7 SP1, Windows 8, and Windows 8.1 operating systems.
For Windows 10 you use .NET version 5 (or its updates), as installed by your windows update feature. (MX will also run on version 4.8; the .Net download for version 4.8 should be here https://dotnet.microsoft.com/download/dotnet-framework/net48).
Microsoft originally created .NET for all operating systems, but Microsoft then decided to restrict it to just Windows (and that was the position while MX was being developed, and was still true in early 2020), mostly to encourage greater dominance by Microsoft software and hardware.
Mono was then born based on .NET to work with all operating systems, Mono subsequently changed independently from .NET (although Microsoft still has a leading role).
Later, Microsoft launched an alternative called .NET Core that took out of .NET the parts that were Windows specific, and it ceased work on further development of .NET beyond version 4.x.x.
The most recent change, in November 2020, involved a change around of names, and the multi-operating system .NET Core product took over the .NET name as version 5
Are you using elevated administrative rights?
For those who downloaded the first MX Beta in January 2015, the code was only experimental and that version had to be run by a Windows Administrative User, but Steve Loft soon improved the code and now none of the code requires any elevated rights and it can be run by a normal user (or a user with administrative rights) without needing to be started by Run as administrator.
However, Cumulus MX initiates a web server, which is what runs the Admin Interface. To access that, all users need to be given elevated rights to the port on which the web server runs. By default this is port 8998, so that is used in the example below of the one-off command needed to give all users access to the port. You can use a -port=nnnn parameter when starting MX to make it use another port, if you use that then the command below needs revising accordingly.
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 is dependent on some settings which determine what appears when you right click:
- the normal default on Windows 10 is Windows PowerShell (admin),
- the normal default on earlier versions of Windows is Command Prompt (Administrator)
- an alternative is Windows Terminal
Whichever of these you can use, the result is it opens a new window on your monitor with a prompt for typing. In that window type the command:
netsh http add urlacl url=http://*:8998/ user=\users
You only need to do that once. If you do not issue this command, administrative rights are needed every time to access the port so you can use the admin interface.
Talking about command windows, if you want to check that the port is open for listening (i.e. able to access the admin interface) type
netstat -an | findstr 8998 into the command window.
How to run MX
We need to run MX in order for it to generate a web server that will enable us to see the admin interface where we can change settings, view our weather data, or edit various Cumulus files (extreme records or log files).
There are two ways to run MX:
- either Interactively
- or As Service
It is recommended that you run MX interactively to begin with, as this means you will see any messages it outputs, and can respond to those. Once you are happy that MX is running smoothly, then run it as a service, as that will run in background, and you don't need to watch for messages.
|Setting up||To run Cumulus MX, Windows needs to know
Therefore it is best to always start MX using what Windows calls a shortcut, because when creating the shortcut you can enter all the required information into the properties.
There are 3 ways on Windows to create a shortcut to run MX:
|# Navigate to the folder with your MX installation.
The service will stop itself if it detects that the computer is going into standby:
|(Re-)Starting MX||# First start the MX engine using your shortcut (created in one of the 3 ways as above), if it has not started when you started your computer
Try start /min C:\Cumulus\CumulusMX.exe to run MX as a minimised package (although in Windows you can change the properties of the shortcut you use to start minimised).
|There are two ways to start MX service:
|Checking MX is still running||Simply look in the Command window or Powershell window or Terminal window you used to start MX and left open.||You can use |
|Deleting shortcut/service||If you have set up your short-cut in the Startup folder, you need to delete that short-cut (or move it to a sub-folder), to stop MX automatically starting when you restart your computer||To remove the Cumulus system service run |
|Stopping MX||The recommended way is to click into the command window in which MX is running, hold down Control key and press C. It is normal for there to be a short wait, then a message "Cumulus Terminating" and then after another short wait, it will say "Cumulus Stopped" and immediately after that the command window will be closed by MX.
Some people, click in the task bar and select close, or click the X button on top right of command window. Although these are not official advice, they do seem to work.
There are packages that can be programmed to send a control C to a running task, and to not continue until the task window has closed. Remember to also program in a subsequent delay in that package, to make sure the package waits for MX to close, or do a check that MX has released all the files it might need to update.
You should not issue a TASKKILL instruction, as that will prevent MX correctly writing out to all the files it should update on exit. Consequently, it will not restart correctly and may actually lose settings and data.
|There are two ways to stop MX service:
Access to admin interface
The admin interface URL http://*:8998/ needs to have that wildcard "*" replaced by a precise location if we are to access the admin interface to change settings, view our weather data, or edit various Cumulus files (extreme records or log files).
The missing part of the URL depends on how your local network is set up.
- If you are accessing the admin interface on the same device as that running MX then the "*" can be replaced by "localhost", i.e. http://localhost:8998/ will be used to load the admin interface into your browser.
- In the more general case when you want to access the admin interface from anywhere on your local wired and wireless interface, then the "*" needs to be replaced by a string of 4 numbers representing what is called a IPv4 address (w.x.y.z) of the device you have installed MX on.
How to find out which Internet Protocol address to use
- Look at your hub or router (this should have come with instructions on how to access its settings in your browser) and on one screen it should show what devices are connected to your LAN and wifi.
- Look for the IPv4 address, for example 192.168.1.64, it has assigned to the device where MX is running. That is what should replace the "*".
However, there is one more complication, either the Windows networking settings may change, or else your hub or router may reconfigure, both can happen at any time, and both can assign a different IPv4 address to the device running MX.
To give your Computer a fixed address for the MX admin interface,
- first find the network card via Network and Sharing Centre (Control Panel),
- then click on Change Adapter Settings,
- then Right click on Ethernet or WiFi Adapter,
- next select Properties
- In the window that opens, right click on Internet Protocol Version 4 (TCP/IP 4),
- Next select properties
- Onn that pop up screen tell the computer to "use the following IP address"
- Fill out the form 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).
One-off essential settings
So 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. The settings you see may vary, depending on which MX release you have installed, so are not described here. It is best to work through all the settings listed, as although some have defaults, you might want to vary them from default.
Upgrade to a new MX release
If at any time, you need to upgrade to a newer release of MX, it is basically a case of installing the new release over the existing one, but more guidance at upgrade MX.
One-off optional uploads
If you have a web server, then navigate to the CumulusMX\webfiles sub-folder, and upload everything in that folder onto your web server.
You don't create a folder called webfiles on your web server, but you put the files and sub-folders into position at the root for your weather pages.
To do this, you will must invoke a FTP process outside of Cumulus, MX does not include any functionality to do this one-off upload for you. The filezilla client is a popular choice as it has a very friendly graphical user interface, although other software to do this is also available. You may prefer a tool that lets you do the uploads from a command line without requiring working with a graphical interface.
The contents of that sub-folder may change when you upgrade MX, so this task might need to be repeated.
webfiles sub-folder in releases from 3.10.1 onwards
I'm not going to list all the files and sub-folders within CumulusMX\webfiles as the contents may change.
- However, it can be said that you will find some .htm files (basic web pages) in the main folder,
- and some sub-folders for
- .css files (styling) in \css
- .js files (scripts) in \js
- .png and .jpg files in \images
- two further sub-folders in \lib
- jquery (makes scripts independent of browser selection)
webfiles subfolder in releases 3.0.x to 3.9.y
- The static files to be uploaded include the standard styling file \CumulusMX\webfiles\weatherstyle.css which you place in the directory specified for the uploads.
- Next you have three sub-folders, each of those sub-folders need to be replicated within the directory specified for the uploads.
- For example \CumulusMX\webfiles\images\picture.jpg will be stored in a "images" sub-directory of the upload directory and is used as the background image for web pages.
- There is nothing to stop you creating your own "picture.jpg" (instead of uploading the supplied one) and then Cumulus web pages will use that for the background image on each page.
- Similarly \CumulusMX\webfiles\js\cumuluscharts.js needs to be stored in a "js" sub-directory of your upload directory (this is the script that allows you to change the chart shown on the trends page and uses the appropriate json file to populate it with data).
- For example \CumulusMX\webfiles\images\picture.jpg will be stored in a "images" sub-directory of the upload directory and is used as the background image for web pages.
- The "lib" sub-folder contains further levels of sub-folders all to be replicated on your web site.
Operating a web site with uploads from MX engine
The standard web pages
From release 3.10.1
Please read this page for more information about styling options and other details.
Until release 3.9.7
As mentioned above, the styling and library files are a one-off upload from CumulusMX\webfiles. These release use template files, these are processed by MX to add the variable data, and this will create web pages that are uploaded to your web site.
Please read Customised_templates for further information about the various pages provided, and how you can customise them to suit you.
Comparison with legacy Cumulus 1 web pages
- Note that the MX web files are not the same as the ones for Cumulus 1,
- so if moving from Cumulus 1 to MX, delete all your Cumulus 1 files from the "web" and "webfiles" sub-folders, and all files from your web server; then upload files from the new "webfiles" folder.
- The standard gauges are now the SteelSeries gauges. The default gauges page does not display a graph when you hover over a gauge (as happened when you added the stand-alone Steel Series gauges to Cumulus 1).
- The trends web page in Cumulus 1 relied on that software generating graphs as images.
- In MX, the software generates files with time and value pairs, these are stored in json format, the trends page then uses a library package (Highstocks) to draw graphs from those data pairs.
Alternative ways to obtain web pages
You can choose to use some of the alternative web pages available from third parties and described on User Contributions page.
Using your own web pages
- Of course you can use your own web pages, instead of the standard ones. Assuming they need to include figures that are available as web tags, there are three alternative ways to implement this:
- MX can process template files with a HTML structure and those web tags in the structure where values are required just as it does with the standard templates, and MX can upload the resulting web pages at either the real-time interval, the standard interval, or after end of day. All of this is covered on the Customised templates page in this Wiki.
You may find this wiki page useful for understanding more about the different script languages.
Optional parameters to add to the instruction to run the MX engine
Beta builds of MX
Beta builds in MX version 3.0.0 had an optional parameter
CumulusMX -wsport nnnn that determined which port (represented by a 4 digit number nnnn) was used for Web Sockets.
That parameter is now deprecated as Web Sockets in all builds since 3045 uses the same port as the rest of the Admin Interface, see Port parameter below.
Debugging of data flow between station and MX
Use CumulusMX -Logging=1 (for the station to MX transfers to have increased debugging logging).
Although this is not mentioned in any release announcements, it appears that use of this parameter is now deprecated as it appears that on all recent MX releases this effect is incorporated into the -debug parameter. Perhaps someone could confirm whether this is true.
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:
CumulusMX -port 9999
Parameter for adding debugging
MX has a default level of logging that stores in the MXdiags_folder folder a log file that shows some of the interaction with the weather station and some of the output actions done as MX runs. A new log is started each time MX is restarted.
If there is a problem, then there is a great benefit in actually increasing the level of detail in these logs; and that is done either within the settings (on recent MX releases this is on Program Settings page of admin interface - please see MXdiags_folder page for details) or by adding a parameter:
Obviously this log file continues to grow, the longer MX is left running, and if debugging is switched on the file will grow in size must faster. Consequently, the default is not to add the extra debugging information and the settings can be used to switch it off again if you do have it switched on. Since this parameter is applied when you start MX, it applies while MX continues to run. Obviously, it must be applied every time you start MX if you want this increased level of logging to continue every time you restart MX.