Cumulus Wiki - User contributions [en]

Updating MX to new version

2023-03-16T09:32:11Z

Relleray: /* Upgrading if you run MX as a service */

=Who this article is for=

Please be aware that if you want to move from Cumulus 1 to MX, you should read [[Migrating_from_Cumulus_1_to_MX]] article instead.

This article is for those who already use MX, and so are comfortable with basic MX installation and running.

=Who is not intended reader=

Cumulus MX has been updated so frequently in 2020, that you may be used to upgrading to a new build, and for you this article is not useful.

=Where to download a release distribution=

==Latest release==

Download release distribution zip from [[Software|the Software article in this Wiki]] for latest version.

Be aware that the developer needs to remember to update this link each time there is a new release.

An image that contains a '''Raspberry Pi lite operating system''' and a recent CumulusMX release already included, can be downloaded from the same wiki article. Not every CumulusMX release is provided as a Raspberry Pi image, so you may need to perform an update to get the latest release. The Raspberry Pi image places CumulusMX in /opt/CumulusMX.

==Any release developed by Mark Crossley==

Download release distribution zip from https://github.com/cumulusmx/CumulusMX/releases for earlier versions.

=Introduction to upgrading MX=

<div style="background: LemonChiffon;padding:5px; margin:2px;">
[[File:Crystal Clear info.png|40px]] This document is 'Work In Progress' so content may not be complete or accurate!
</div>
[[Category:Cumulus MX]]

You can download and unzip in advance, but cannot replace existing files while they are being used, so how you stop MX is in next two sub-sections.

My preference, after download, and unzip into a holding area, is to copy (it would be file transfer if you download on another device) over my existing installation all files except:
*CumulusMX.exe
*CumulusMX.exe.config
while MX is still running. I then stop MX for minimal time needed to replace just those two files before I restart MX. That way I minimise downtime, especially useful for a patch release when few files have changed, as it takes some time to replace all the files in the installation.

For simplicity, in guidance below, MX is stopped before any files are replaced.

==Upgrading on a Raspberry Pi (RPi) computer by commands from a Microsoft Windows computer (PC)==

I recommend you download WinSCP (this and PuTTy share some settings). This will allow you to connect your PC to your rPi and copy files back and forth. You can use it to copy the MX distribution, you download and unzip on your PC, onto the RPi. You can also use it to take a back-up of your RPI files onto your PC, and to pick certain files off your RPi. e.g. copy log files from [[MXdiags folder]] to your PC to read diagnostics etc.

You can download PuTTy (shares some settings with WinSCP) to enable you to open a terminal session and send commands to your RPi computer.

If you have Cumulus MX setup to run as a service then you will need to do one of these, should you wish to add debugging when the upgraded MX begins...
# Edit the CumulusMX service file (see [[MX_on_Linux#Running_as_a_service]]) to add the -debug parameter (do this if always want debugging on, not usually needed)
# Just set it from Program Settings | Logging Options (easiest for turning debug on when you need it and off when you don't need it)
# Edit the Cumulus.ini file and enable it in there (no longer recommended)

==Upgrading if you run MX as a service==

Don't forget to stop the service, before you do the upgrade.

For a Linux Operating system: <code>sudo systemctl stop cumulusmx</code>.

For Microsoft Windows Operating System: <br>

Open Windows Administration Tools from Windows Task Bar, select Component Services, click on Services (local)
In middle window select CumulusMX service from the list; click on Stop the service option. (click on Start the service after upgrade)

==Upgrading if you run MX interactively==

If you do NOT run as a service, you will want to use '''Control and C''' in the terminal (or command) window running MX to make the software close tidily.

== Updating to the next MX release if you have not upgraded before ==

The simplest upgrade is from the immediate preceding build, and the steps required are summarised as follows:
# Download the release distribution zip for the next build (see later for where from)
#* My advice is to have a separate download location away from the location where you are installing/running the software; it can retain older releases to make regression simple if the new release proves to have a bug.
# Use '''Control-C''' to stop Cumulus MX (see later if running as a service)
# Take a backup of your complete existing MX installation (as it is not running, no files will be locked)
# Unzip the new distribution, overwriting the previous installation (the release announcement might ask you to delete obsolete files)
# Run any one-off batch scripts needed to prepare for upgrade
#* These might be needed if log files in the new release contain fields that were not in earlier release
#* These might be needed if you use optional database functionality (see later for examples)
# Do any actions that require you to use [[MX Administrative Interface|Admin Interface]] to change settings
# Do any one-off actions in relation to any files provided by MX for you to run a web site with the default pages
# Restart your Cumulus MX (consider running with '''-debug''' parameter if you are not sure the new build is bug free)

The remainder of this article explains all options for updating, and is thus less simple than above.

==Installer Option==

[https://cumulus.hosiene.co.uk/memberlist.php?mode=viewprofile&u=9016 HansR] on support forum has developed an multi-platform installer, see [https://cumulus.hosiene.co.uk/viewtopic.php?f=44&t=18916 Multiplatform Installer for CumulusMX] which makes life a lot easier if you do not wish to dive into the (file level contents) internals of CumulusMX.

#Copy the '''InstallCMX.exe''' to any directory you want, on the drive where you wish to install (or have previously installed) MX.
#Copy the CumulusMX release distribution zip(s) to that same directory, if you have not already done so. You may have more than one distribution in the same directory.
#*The install procedure gives you the possibility to select, or define, the Archive to install, and the location where to install.
#Stop CumulusMX
#Run '''InstallCMX''' and confirm / fill in (on the console) where you wish to install (or update) CMX. The default for Windows is C:\CumulusMX\ and for Linux it is : /home/CumulusMX. The Installation directory can be modified.
#* You can give the '''build number''', for the release distribution zip, to install as command line '''argument'''.
#Start CumulusMX

'''NOTE:''' On Windows you run the installer as any other command line executable and it is best to open a command window in which you start the installer. On Linux you run it on the command line as "mono ./InstallCMX.exe", the mono command can be omitted if mono is already active (e.g. if you run CumulusMX as a service, and stop it, mono remains active).
'''NOTE:''' In an existing installation with modified files, make sure those are in a different, either filename or folder (a safe place). If they have the same name as files in the distribution, they will be overwritten.
'''NOTE:''' Check in the <code>webfiles</code> directory to see if any files there have been modified, since your last upload to your web server. If so, move those new files to the website.

After the installation, there is a '''log file'''. Check the log file to see everything has gone well.
There is an '''ini file''' where you can control:
* NormalMessageToConsole=true or (default) NormalMessageToConsole=false
* TraceInfoLevel=Warning (out of: Error, Warning, Info, Verbose, None)

Any reactions (thank you, issues and questions) please post in the [https://cumulus.hosiene.co.uk/viewtopic.php?f=44&t=18916 download thread of the installer].

Modifications and additions on user request can be discussed (e.g. think about automated start/stop, upload of webfiles to the directory etc....), use the talk for this page.

==Upgrading if you are running MX on a Linux computer==

You might want to read galfert's post on the support forum [https://cumulus.hosiene.co.uk/viewtopic.php?p=148851#p148851 here] for the relevant Linux instructions in a concise format.

If you want more detailed information, on any Linux (including Raspberry Pi operating system) aspects of the upgrade instructions on this page, see [[MX on Linux]] page.

== Updating if you use the start/stop management script ==

This section contributed by ''Jank'' on support forum. Note the version on the forum might have been updated from the original included here.

1. look on [[Software|Software download page]], find the link to latest version, and fill out the '...' below appropriately as you run these 2 commands on your device where you do downloads:
<pre>cd /tmp
wget https://github.com/cumulusmx/CumulusMX/ ... .zip</pre>

2. Once that download is complete, start cumulusmx.sh with option -u
<pre>/home/pi/CumulusMX/cumulusmx.sh -u</pre>

3.When asked for the zip file, enter
<pre>/tmp/CumulusMXDist</pre> and hit the TAB Button

4.Choose the zip file with the CumulusMX upgrade and hit return.

5. Follow the on screen instructions

6. With each update component .....you can choose: [y]es, [n]o, [A]ll, [N]one, [r]ename

I would recommend select '''A''' as that will simply replace all files without further action.

CumulusMX will be restarted after upgrade completes.

You can check if the upgrade was successful by using option -s:
<pre> /home/pi/CumulusMX/cumulusmx.sh -s</pre>

=Considerations that determine when to upgrade=

Cumulus MX will nag you, in various places, to make you aware if you are not running the latest build. Some people will choose to upgrade as soon after a new release as they can. However, each upgrade does involve a period when MX is not running, and that causes some loss of data:
*for some weather station types readings taken every minute, or more frequently, are replaced by whatever period you station data logger records at;
*for other stations, without their own logging, all data is lost for the period when MX is not running.

Other, more cautious, people (like the present writer) will not upgrade each time a new release becomes available (and there are a lot of new releases in 2020), here are some of the reasons:
* you will see in the Cumulus Support Forum that many builds have bugs, and so you realise that it is better to stick with your fully working release, than install one with bugs;
* you may wish to avoid the loss of data mentioned above, by minimising the number of times that you stop MX;
* you may run MX on a computer that you rarely visit, perhaps even in a remote location not often visited, so you prefer to leave it untouched, rather than risk possibility of being unable to restart remotely;
* you may just have more important ways to use your time than updating your MX software, and some new builds might not give you any benefits that make it worthwhile to change your priorities.

It is perfectly possible to '''upgrade from rather old versions of MX, to the latest''', skipping intermediate versions, '''but there are some key versions that you should not skip over'''. This page, in subsequent sections, includes suggestions for which releases to install (and get running) before moving onto newer releases. This will be especially useful for those people who do not immediately upgrade to new releases, as per above suggestions.

===Advice about skipping versions===

Please see [[Updating_MX_to_new_version#Updating_from_a_very_old_version]] sub-section later on this page (and preceding sub-sections where relevant)

The important point to make here is that when you do an upgrade, you should copy in '''ALL''' files from the release distribution you want to run next. This is because there are dependencies between files within a distribution, so missing out any particular file may stop other files from working. However, if you are skipping versions, read the in-between release announcements to see if there are any one-off actions.

= What to read (and when) before upgrading =

== Upgrading from immediately preceding build ==

=== The release announcement ===

The release announcement is found in [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 Cumulus MX Announcements and Download - PLEASE READ FIRST] topic of the support forum.

*Generally, a release announcement WILL contain
*#An overall purpose for that particular release (e.g. fixing bugs or adding functionality)
*#Details of what functionality has been added
*#Details of what bugs have been fixed, or where the processing has been improved
*# (For older releases only) A list of the main files that have been added or amended in the release (excluding "updates.txt" which is amended in each release)
*#* (Publishing a list of changed files has been discontinued, because people were updating selected files, and often missed crucial ones, like '''CumulusMX.cfg''')
*Sometimes, a release announcement MAY contain
**Descriptions of one-off actions (like changing the schema if you use a database, or editing your web pages to take advantage of new web tags).
**Actual scripts to download and run to perform the necessary one-off actions.
*Be aware that it is worth while checking back on the release announcement for a few days after a release.
**It may have been edited because the original announcement forgot to mention something.
** It may have been edited to mention that some bugs have now been found
***That may mean you are advised to regress to an earlier version and use that
***It might mean that some supporting files in current version are wrong, and you only need to regress those named files
***There might be an emergency release to fix the bugs, and you need to upgrade to that emergency release
***Finally you might be given advice to avoid using certain parts of the functionality or take some other action until the next release is available.

===Other places where you can find information about release content ===

Although it is not always kept in step, a concise summary of all formal MX releases is available at [[Cumulus_MX_formal_release_versions]].

You can also view the latest [https://github.com/cumulusmx/CumulusMX/blob/master/Updates.txt Updates.txt].

===Deciding whether to upgrade to new release ===

This has been covered earlier in this article, but I repeat here 2 critical considerations:
*Any new development or change in a new version of MX might cause problems for some users. You might want to stick with the version you are already using unless you really need any new functionality or the fixes gained by upgrading.
*Also remember that there are bugs in (almost) all versions of MX, this is a large and complicated package, and the current developer has not been able to test all the code with all possible settings and all possible weather stations.

==Updating to a new minor build, skipping in-between minor builds==

For a minor version build either the associated version number does not change or only the final section changes (3.x.y to 3.x.z).

===Reading multiple release announcements===

If you are skipping some intermediate builds, then you will need to read each of the formal release announcements for builds after the build you currently use.

The other sources of release information mentioned above may be consulted as an alternative and may highlight something useful, but the formal release announcement contains what the developer wants you to know.

===Action to take when skipping minor intermediate builds===

You need to apply the cumulative actions recommended (i.e. apply any actions in sequence as listed for each intermediate build). Unfortunately, for Cumulus MX, one cannot assume that minor builds have no one-off actions associated with them. Luckily, most of the advice above for updating from immediately preceding build still applies.

==Updating to a new major version==

Generally, if the developer decides a new build warrants classification as a major version (i.e. 3.w.0) then the change being implemented is significant enough that updating might be more complex.

=== Examples of what might be classified as a major change===

*Additions to fields in log files (whilst older lines can continue to be read, you might want to consider [https://cumulus.hosiene.co.uk/viewtopic.php?f=18&t=18096 amending your standard data log] by populating the additional derivatives for older lines)
*Schema changes for database tables (if you don't use the standard tables, this might be irrelevant to you), the standard insert operations by MX can cope with extra columns in a table, but will fail if any column they try to update is missing
*Additions, changes, or removals, in configuration file (in general MX will ignore unrecognised parameters, but it does need correct values for those attributes it does recognise), see release announcements to discover if new lines in configuration file need you to add them manually or you need to use the admin interface to select the right setting for you
*New pages in Administrative Interface (additional pages require menu on every other page to be amended)
*Changes to existing pages in admin interface that involve changes to associated files (it is vital that all associated files are from same build)
*Catering for new weather station sensors, or new ways of communicating (this might not seem relevant to you)
*Any interface functionality changes (it may look the same, but what it does has changed)
*Additions to files being generated for web server (i.e. changes to template files, or additions to ''web'' or ''webfiles'' folders), even if you use your own versions of such files you may want to check the revisions

=== What you need to read ===

*Basically, check the corresponding release announcements for every version since the one you have been using before planning your upgrade.
**Make a note of any one-off actions required at particular in-between versions, remember these actions are only in forum release announcements.
**Although one-off actions will not be described in the Wiki (whether on the [[Software]] page or the [[Cumulus_MX_formal_release_versions]] page), the Wiki can give you an idea of what functionality has been improved to help you decide whether to upgrade.
*It is still worth reading all the points made above for updating from immediately preceding build.

=== Doing the upgrade===

# Download the release distribution
# Use '''control-c''' (or equivalent for MX running as service) to stop your existing MX software
# Backup your existing installation
# Do the on-off actions identified (e.g. changing schema of database tables, adding new configuration
# Unzip the distribution over existing one (alternative installation options listed later)
# Restart MX, considering whether to use '''-debug''' parameter in case the new release does not work for you
# Check the latest file in the MXDiags folder after an hour, to see if there have been any problems with reading from station, real-time uploads, standard uploads, or hourly uploads. (You may wish to recheck after an End of Day action has been done).

==Updating from a very old version==

Many people believe if it works, it don't need fixing. So they install whatever MX version is available when they start using MX and ignore all the bug fixing and new functionality being added, and stick with their existing installation.

Suddenly they realise that perhaps their version does lack functionality that would be useful to them. Maybe their version does not have an editor for correcting rogue extreme records and they realise correcting log files is something that is hard for them to do.

This section is therefore included to give advice on why you should not jump from an old version to the latest directly, but how it can be safely done in stages.

===Recommendations for staged updating===

<big>'''This section will need to be updated, new contributors are needed to keep this advice current.'''</big>

Do read all release announcements, to see if the developer has made a major change since those described below that means you need to stage your updates if you are currently running an old release.

====If using a release up to 3.11.4 and want to use any later release====

Upgrade exactly to release 3.12.0 (no later) by using zip at [https://github.com/cumulusmx/CumulusMX/releases/download/b3141/CumulusMXDist3141.zip download/b3141/CumulusMXDist3141.zip].

Run that release, it will rename your [[Cumulus.ini]] file, and create a new file with same name, but different settings.

You need to work through all the settings pages in the interface, and ensure all settings are correct, then close MX so it writes away the new settings according to your preferences.

Now [[Software#Latest_build_distribution_download|download the latest release]], and copy in all the files from the zip, before restarting MX at the release that is supported by developer.

====Currently running 3.10.x or 3.11.y====

Treat like any other major version upgrade as described above.

The changes between any 3.10.x release and any 3.11.y release were minor, but ''you can't go from 3.10.x to the latest release'', because you must use 3.12.0 to convert [[Cumulus.ini]].

====Currently using one of the 3.9.y releases ====

If you are using any release in the 3.9.y series (note release announcement 3.9.1 warning about Mono if you use that), and you are using web pages that were provided by MX...

Then you need to be aware that 3.10.1 (3.10.0 was withdrawn) got rid of the HTML templates that you have been using, and introduced a lot of new settings.

The good news is that you can now jump straight to 3.12.0 as that release will rename your existing [[Cumulus.ini]] and create a new file with all the new settings:
* Changes to settings
** You need to open the [[MX Administrative Interface]] and work through all pages in the '''Settings''' menu.
*Changes to web files included in two folders in distribution: <code>[[Web folder|CumulusMX/web]]</code>, <code>[[Webfiles folder|CumulusMX/webfiles]]</code>
**If you used the provided templates to produce web pages in earlier releases, or you had directly customised provided [[Customised templates|web templates]], these will no longer work
**Please see [[New Default Web Site Information|New Default Web Site Information page]] for further advice

Note: The folder <code>CumulusMX/webfiles-legacy</code> mentioned in the new default web site information page, with some alternative web pages that have no ongoing support, is only available from a 3.10.0 or 3.10.1 download (find from [https://github.com/cumulusmx/CumulusMX/releases this Github page]).

====if using 3.7.0 release, any 3.8.x release, or 3.9.y release====

See sub-section directly above, that describes similar process,
* EITHER '''upgrade directly to 3.9.6, or any later build, within 3.9.x, without any major change,'''
* or to 3.12.0 with major change
* (find either release from [https://github.com/cumulusmx/CumulusMX/releases this Github page]).

If you are using a release earlier that 3.7.0, you can note 3.7.0 was only build in 3.7.y series, but because 3.7.0 introduced a lot of changes these staged upgrades recommend that 3.7.0 is implemented, and run for a while, before continuing to upgrade.

Be aware that 3.8.0 was a major release, as it introduced the ability to run Cumulus MX as a service, but there is no reason to install it as the ability to run either interactively, or as a service, continues to be available in all subsequent releases.

It is optional to install release 3.9.6 build 3101, because that is a safe release to use while there were bugs in the builds in all 3.8.z versions, and in other 3.9.x releases, however please action the one-off changes noted as IMPORTANT here:

'''IMPORTANT''' one-off actions needed:
* There is a one-off change described in [https://cumulus.hosiene.co.uk/viewtopic.php?p=146957#p146957 v3.9.0 - b3095 release announcement] for those using RG-11 rain sensor.
* There is a further on-off change described in [https://cumulus.hosiene.co.uk/viewtopic.php?p=147329#p147329 release announcement for Patch release 3.9.1 - b3096] for those who use '''Mono''' to enable the executables to run.

Be aware that 3.10.0 was withdrawn, but it was a major release that totally changed the files in [[Web folder]] and [[Webfiles folder]] within the release download. However, you can skip directly from 3.9.6 (if you have implemented that) to 3.12.0 as soon as you are happy to change your web server contents (if you are using web pages that MX provides), see sub-section above for further advice re web pages. You should continue in stages because it is mandatory to install 3.12.0 as only that release can rewrite your [[Cumulus.ini]] file ready for subsequent release, so ensure that 3.12.0 is working before installing current release as instructed in sub-sections for those using subsequent releases.

====If using a 3.5.x release ====

My advice is to upgrade directly to 3.7.0 available at [https://github.com/cumulusmx/CumulusMX/releases Mark's Github repository].

''You should skip the intermediate releases because several 3.6.y releases have bugs in them'', and you want to avoid those problems (the bugs vary in severity between mistakes in calculations done by MX to particular functionality not working).

But there may be additional actions you need to do when moving from 3.5.x to 3.7.y, depending on what features you use in MX:
*there are no additional actions if '''you use standard web pages and you do not use database tables''', just enjoy the bug fixes and extra features after your update!
*'''If you use database tables''', be aware that the <big>schema (Column names that must be in a table) varies</big> between 3.5.x versions and 3.7.y versions.
**The '''updating database table features in MX will only work''' if all the columns named in each such upload update ''already exist'' in the database table it is trying to update.
**Look at individual release announcements for both 3.6.0 and 3.7.0, to see the SQL provided for adding the columns added at particular versions.
***At 3.6.0 the SQL was provided as a separate attachment to the release announcement (read [https://cumulus.hosiene.co.uk/viewtopic.php?p=142085#p142085 UpdateMYSQL-b3076.zip])
***At 3.7.0 the SQL was provided as part of the main zip (read [https://cumulus.hosiene.co.uk/viewtopic.php?p=145048#p145048 AlterSQLTables3098.sql])
***In both cases, the SQL provided assumes you are using the default names for database tables, it does not read [[Cumulus.ini]] to see whether you have selected different names for the tables (unlike ExportMySQL.exe which used to be provided in the MX release zip with standard CumulusMX.exe; both of those (at MX release 3.7.0) check what tables names you have selected for updates).
*'''If you have your own customised web pages''', then there are changes to web tags that might lead to you needing to edit your web pages.
*'''If you use commas to separate integer and decimal parts of real numbers''', then various releases from 3.6.0 to 3.7.0 add "rc=y" to various web tags, that option will replace the decimal commas you use by decimal points that are required for some script languages (like the JavaScript used by HighCharts), and that makes it easier if you want to customise your web site.

When you are happy with running 3.7.0, then you should continue to upgrade, but in steps (optionally try 3.9.6 because that will test some new features, then mandatory upgrade to exactly 3.12.0 which will rewrite your Cumulus.ini file, then you can continue your upgrade to latest) as described in earlier sub-sections for later releases.

====If using either 3.1.x, 3.2.y, 3.3.z, or 3.4.w releases====

First, upgrade to 3.5.1 by downloading it at [[https://github.com/cumulusmx/CumulusMX/releases/tag/b3072 Mark's Github respository]]. The actual installation is done using the instructions early in this Wiki page for simple next build upgrades. You can safely skip reading the intermediate release announcements, as there are no special one-off actions. There are one-off actions at 3.5.1, see release announcement. It does not involve any updates to the fields in the log files nor to the columns in any database tables you use.

When you are happy running 3.5.1, then you should continue to upgrade, initially follow instructions given for later releases

====If using 3.0.0 (the MX original beta)====

Upgrade from the beta directly to 3.5.1 by downloading it at https://github.com/cumulusmx/CumulusMX/releases/tag/b3072. There are one-off actions at 3.5.1, see release announcement. This skips you past the problems in 3.5.0. It gives you benefits introduced in 3.1.x, 3.2.y, 3.3.z, and 3.4.w releases.

This gives you essential new functionality in the admin interface like editors for the log files and extreme records. But it also fixes multiple bugs in the beta you were using and adds some useful validation missing in the beta.

It does not involve any updates to the fields in the log files nor to the columns in any database tables you use.

Now follow instructions in other sub-sections, to upgrade in stages to where there are significant actions to do, until you reach latest release and get support from developer.

= Knowing when a new release is available =

== CREDIT ==

Thanks to ''Billy'' on support forum for suggesting text for this section.

== Using forum notifications ==

As new releases are announced in [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 Cumulus MX Announcements and Download - PLEASE READ FIRST] topic, you can use the spanner tool to '''subscribe''' to this topic to receive notifications of a new post announcing a new release (or any other release-related announcement).

== MX terminal message ==

If ...
#...you have a monitor to see the terminal output from the Cumulus MX engine (Windows calls this either a command window, powershell window, or a terminal window depending on how you invoke it, for Unix-based implementations this is the output window when using the terminal functionality), AND
#...your device running MX is connected to internet, AND
#...your MONO (if not Windows) is not obsolete (SSL certificate out of date), AND
#...you restart MX
... then you will see a prompt when a new version of MX is available.

It is worth stressing that if you leave MX running, then this feature will leave you blissfully unaware that an update is available; it only checks when MX is restarted.

== MXDiags ==

In addition ...
#...if you can view the MXdiags file for the current session of MX, AND
#... MX is running with connection to the internet, AND
#...you restart MX
... if a new version of MX is available, the MXDiags file will say so (the message is not easy to spot as there is a lot of output before it, and variation in what output appears before it). Anyway, here is one example, just one example as in my experience '''the message has appeared at different places for each of the recent upgrades'''):
<pre>
2020-05-27 04:18:48.326 Calculating sunrise and sunset times
2020-05-27 04:18:48.326 Sunrise: 04:58:11
2020-05-27 04:18:48.326 Sunset : 21:19:54
2020-05-27 04:18:48.326 Tomorrow sunrise: 04:57:08
2020-05-27 04:18:48.326 Tomorrow sunset : 21:21:11
2020-05-27 04:18:48.388 You are not running the latest version of CumulusMX, build 3080 is available.
2020-05-27 04:18:48.763 Station type:</pre>

There is no message in whatever place it can appear ...
*... if you are using latest version, OR
* ... if you are not connected to the internet, OR
*... if you keep MX running all the time!

== Start/Stop script ==

When the '''Status''' option of this script is used, whenever a new release of MX is available, it will output a message.

== Dashboard in MX Admin Interface ==

In recent releases, one of the alarm indicators shown at the bottom of the dashboard page of the administrative interface, will flash red when you are not running latest build, and glow green when there is no newer release compared to the one you are running.

== Web Tags ==

Since 3.7.0 release of MX, two relevant web tags have become available:
* <#NewBuildAvailable> Returns a boolean value
** 0 - MX running the latest build available
** 1 - MX is running an earlier build than the latest public release
* <#NewBuildNumber> Displays the latest public release build number

= Recommended Actions when Updating =

== Back-ups ==

It is always best to take a backup of your existing MX installation before you do an upgrade, this allows you to regress back to the earlier version if either you mess up installing the new version, or the new version has a issue that prevents it working with the versions of other software (like MONO) that your installation uses.

== The two approaches ==

Contributors to this section are named in text.

Some people upgrade by just copying in the files that the release announcement says have changed, others copy in all files from the downloaded zip. The first should only be used with caution, files like '''CumulusMX.exe.config''' can change between versions, but not be mentioned in a release announcement, and the developer will have been making edits to files since the previous release, and might forget exactly which files have been edited between releases. Also you may be upgrading from an earlier version and therefore be skipping several intermediate releases.

You may be able to see the dates when files were changed within the zip and therefore be able to decide for yourself if you compare those dates with the previous release you were using if you have kept the download for the version you were using. However, do not assume that only files with later date are needed; in some releases the new build regresses one or more files and so a file with an older date is the correct one to retain.

===The rename old approach===

#The popular approach, recommended by many forum contributors, in many different posts (including at [https://cumulus.hosiene.co.uk/viewtopic.php?p=141763#p141763 this post by Mark Crossley for example] is to rename your current install directory, then unzip the new release, letting it create a new '''CumulusMX''' folder (or whatever name you prefer and specify in unzip options).
#However, you will find that this option is not being recommended any more, because it relies on you knowing which files (see next 2 points) you need to copy back.
#Copy across '''Cumulus.ini''' and (if you use it) '''string.ini''' into that new directory, and then copy the contents of the '''data''' and '''Reports''' directories from your ''current install'' to the new install.
#Don't forget to copy any other set-up files across too.
#*The advantage (as Mark says) is that you ensure you do use all the files in the new release, and don't miss out any he may have forgotten to mention in his release announcement.
#* A key advantage is that you don't retain files that an old release migt have needed but the new release does not use.
#*Another advantage (as PaulMy says [https://cumulus.hosiene.co.uk/viewtopic.php?p=140262#p140262 here for example]) is that you retain your old set-up intact and can easily restore it should you have a problem with new release.
#Various people advise that you 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!
#Check again that you copied across (you may not have all of these files, but if you have them in old installation then you need them in new installation) '''strings.ini''', '''twitter.txt''', '''Cumulus.ini''', and similar files in the same folder level as CumulusMX.exe, as well as all the files in the '''data''' and '''Reports''' sub-folders. Then, provided you are happy, you can delete the old release when you want to reduce clutter on your storage discs.

===The overwrite approach===

The general advice is that if you want custom pages for the administrative interface, or custom templates to process to produce your web pages, then these custom files should be given different names (and ideally be placed in different folders) to the standard files included in the release distributions. If you follow this advice, the approach described in this sub-section is the best for you, if you don't follow this advice, see later section on dealing with customised files.

#* if you have a lot of set-up files, or other custom files, (i.e. files with names that are not part of release), these won't be overwritten by files in the release distribution, but you do want to keep them;
#*or if you are downloading on a different computer, or on a different disc, to where you are running MX, it is easiest to keep your MX installation in the same place
#Note the forum administrator, David, [https://cumulus.hosiene.co.uk/viewtopic.php?p=140355#p140355 (see this post)] recommends this particular approach.
#After downloading a new release unzip it on the device/disc where you down load it. Next stop your existing Cumulus MX software and take a backup of your existing installation. After that, simply copy the files (optionally only those that have newer dates because they have changed) into the existing MX directory on the device where you run MX. Then you know all your existing files are there, and your MX can be run as before.
#The great advantage of this approach, and the reason that it is widely recommended as best, is that you can't lose any data or configuration files (i.e. files that are not part of the release distribution).
#Provided you did the backup, '''the only problem with this approach is that in some releases files are removed from the distribution''', yet unless you check carefully, this approach may ''leave files that are no longer required'' in your installation, and it is just possible you might continue to use the obsolete file instead of the intended alternative. Such a non-standard installation is difficult for others to support. So do check through file by file to ensure you only have files in the distribution you have just installed, not any from earlier distributions. The only files that you still want (that are not in distribution) will be those that either configure your system or contain your data in log files.
#*The updated files can be tracked by their modification date, some will be specified in the release notes (find them on [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 this forum]). There is a list indicating what files vary in [[Cumulus_MX_formal_release_versions|this Wiki article]].
#*In general, especially if updating a major release, it is best to overwrite with all files in zip, whether they are listed as changed or not. This ensures you have a consistent set of files, and avoids any issues when the developer does not correctly list all the files that have changed, or a file might be regressed to an earlier version and not have a newer date than the file in your previous installation.

====Example: downloading on PC and installing on pi ====

#On your pc: Download zip either from [[Software]] for latest version or from https://github.com/cumulusmx/CumulusMX/releases for earlier versions.
#On your pc: Use Filezilla (or similar file transfer program, or it might even be a copy over network depending on way set up) to transfer zip to pi (e.g. <tt>FileZilla CumulusMXDist3089.zip to /home/pi</tt>), but remember you might want to install to a different location (perhaps on an external USB drive, or SSD)
#Control C on pi to stop MX
#On pi go to directory where zip now is, for example it might be <tt>cd /home/pi</tt>
# Unzip the installation over your existing installation, by running on your Raspberry Pi this instruction: <tt>unzip -o CumulusMXDist3089.zip</tt>
# Restart MX
# Remove any files that were needed by earlier releases but release announcement says are not needed by the release you are installing

===The customised approach===

If you edit a file that is included in the release distribution, you should give it a different name (e.g. I have placed an underline in front of original file name for some of the files I edited in the admin interface), and/or place it in a different folder (e.g. I place all the cumulus templates I have created in a folder called '''cumulus_Templates'''). If you follow this advice, then you won't lose your files by following the advice above, regardless of whether you overwrite or not.

If you won't listen to best practice advice, and have decided to for example modify the provided Cumulus web templates without allocating new names, then installing the whole release distribution will overwrite your edited file(s) with the standard file content provided by the developer. Therefore you need to do a customised approach where you select which files from the distribution to copy into your installation. If you have changed one or more web templates, you might think it safe just to omit the relevant files in the zip within folder '''web''', but some builds change the files in the '''webfiles''' folder too, and you need to retain consistency.

==== Updating when files within release might overwrite your own edits ====

To further explain the customised approach, here are some more examples.

===== web site files =====

If you have edited any files that sit on your '''web site''', then these can remain on your web site. However, if those web pages are generated from templates that you expect MX to process and upload for you, you do need to take special action. Maybe you edited a template 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).

The first step is to see if the release notice says that file has been revised, if it has not then it is easy to keep your edited file by not copying in the replacement file from within the zip. If the release revises any 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. Do think about changing name of the template file, or placing it in a different folder, and using the '''Extra Files''' settings. That will make it easier for you next time you do an upgrade to a new MX build.

If you have done major customisation to the standard website then you probably have followed the guidance and stored your new web page templates in a different directory and you use '''Extra Files''' to specify where they are, so they cannot be overwritten, and the new MX will still find them. It might be that new web tags have been added since whatever build you were running before, and that you decide to edit your customised template file, but that can be done any time after you install the new MX build.

===== admin interface files =====

If you have done any customisation to the '''interface''' (perhaps you don't like seeing solar in the tables when you don't measure that) then again you can skip over these files when copying. Hopefully you will have copies of the files that you have customised of the ''interface folder'' so you have ability to copy them back into installation if you do overwrite with the release version.

'''You do have to be careful''', as many releases change the interface in some way, even if the change is not in the file you have customised, it might be in an asociated file, and all the various components of the interface have to work together as a coherent unit. For instance when feels like was added to MX, the api used for sending data from the MX engine to the admin interface was updated. In some releases, a new web page is added to the admin interface, with the consequence that all the navigation menus were adjusted in all web pages. Any HTML page in the admin interface may be edited to refer to a different styling page (so it, and the .css file, must be updated together) or to a different script (so the .HTML, and the .js file, must be updated together). The settings pages in the admin interface are dependent on the correct pair of json files to define the options or values that appear on that web page, so again all must be consistent.

To sum up, admin interface files are interdependent, and you cannot always update some, but not all, of the admin interface pages.

Be prepared to go back to the standard file for whatever you customised if something it depends upon has changed, after all you must not lose any vital functionality.

On my site, my own versions of interface files have a "_" (underline character) added to the start of the standard MX file name. This applies to both HTML pages, and JavaScript files that I have edited. I edit the menu items within my edited pages so those all go to my versions where I have a HTML customised page, leaving unchanged the menu items that can still go to a standard MX web page where I don't have my own version of the .HTML page. This makes it easy for me to navigate between my pages, as all of them link to my other pages. If I am on a standard MX page and want to go to one of my customised pages, I select the equivalent standard page, then edit the URL to add the underline and get easily to my page. This naming means I can always use a standard page instead of my customised page when I need to, and I never miss out on any new features.

== After an upgrade if you use the standard web template files ==

If you do not use the example web template files, provided as standard, with a MX release, the remainder of this section can be ignored.

If you use the third party [[CumulusMX and Cumulus1 UI style Multilingual Websites]] web pages, as maintained by BCJKiwi, follow any instructions in his package as to which of the files in this section are required and any announcements in his forum topic about when such files need to be upgraded.

=== web folder from zip ===

If you do use the example web templates to produce web pages for your web server, and you have copied all files from the release distribution ....

....MX will find any new web template files in your '''web''' folder, MX will process those template files, and upload the web pages produced, ''as before with no further action by you''.

=== webfiles folder from zip ===

<br/>
<big>PLEASE COULD SOMEONE USING LATEST MX RELEASE ENSURE THIS IS KEPT UP TO DATE</big>

<br/>

You do need a further action, if any files in this folder have been updated. The updated files must be uploaded to your web site.

This may be easy to forget if you use the standard web templates, because you thought that upload was a one-off and maybe you cannot remember what you did.

Certain third-party web-pages still use files from that folder, if one of the files they use has been updated, then ensure you have a backup of your web site before you upload the updated file, it should work, but it might not, and you might need to regress.

Let me go through the files currently in webfiles folder:
*'''weatherstyle.css''' has not been updated since its last update by Steve Loft in 2009.
*subfolder '''images''' contains 2 pictures that have stayed same since MX launch
*subfolder '''js''' contains one file or two files (depending on which MX release you are using:
**The standard web page '''trends.htm''' will only work if the correct version of any file here has been uploaded to your web site, and placed in a sub-folder "js" of where "trends.htm" is installed. .
*** BCJKiwi's user interface '''charts.php''' also requires the same JavaScript file (or files?), so upload the file(s0 anytime there is a change in a MX release.
** The file '''\CumulusMX\webfiles\js\cumuluscharts.js''' has changed in a lot of releases, it is updated whenever there is a change in the JSON files used for providing data to the charts, and you must use the right upgrade.
** The file '''historiccharts.js'' (it was introduced from release 3.8.7) is similar to previous script, but drives the historic chart functionality on your web server
*subfolder '''lib''' currently contains 3 folders:
**'''highstock''' - this folder is no longer needed on your web site (and the most recent MX releases have emptied it)
**'''jquery''' - this folder is needed for "trends,htm" to work, but it has not been updated since 2014. Both the files included are obsolete packages, no longer officially available, and there are no plans to replace them.
**'''steelseries''' - this folder has 3 sub-folders, I can only think of 2 MX releases when anything was changed here, and I don't anticipate any further changes.

= After upgrade - checking for bugs in MX or mistakes in your installation =

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|MXdiags folder]] to see if any errors are reported.

In newer releases of MX, also see [[ServiceConsoleLog.txt]]

Also keep an eye on the support forum for first few days, some releases do have bugs, as developer cannot test all possible configurations.

== Updating if you use a virus Checker ==
You may find that virus checkers such as Windows Defender reject your new version of MX. They need to be told it is safe.

MX on Windows OS

2023-02-03T15:49:39Z

Relleray: removed extraneous space after - on service creation

{{Template:WorkInProgressBanner}}{{Template:Version badge Mx}}

The banner above has been included as, at the time of typing this, everything on this Wiki page has been typed by a single contributor, who no longer uses Microsoft Windows to run MX. Cumulus MX is evolving rapidly, and any documentation in any page of this Wiki tends to quickly become outdated. It is therefore essential that at least one other contributor takes over updating this Wiki page.

=Introduction=

This page is a simple summary for installing and running (non-beta) releases of MX on any computer running the Microsoft Windows Operating System (e.g. personal computer, notebook computer, laptop computer, Raspberry Pi with Windows instead of Linux, etc.).

If you are not running MX using the Microsoft Windows Operating System, then please read [[MX on Linux]] page in this Wiki 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
*[[MX Administrative Interface|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 want to use a script language, you might want to read [[PHP|PHP Hypertext Preprocessor and JavaScript]] page

= Requirements for running MX on Windows =

MX can be run on most computers with a modern version of the Microsoft operating system, but this Wiki page is trying not to get too technical, so it will focus on just two aspects, the locale and .NET.

==Locale==

Cumulus MX is much more fussy than the legacy Cumulus 1 about items like [[Amending_dayfile#Correcting_date_separator_errors|date separators like hyphen or slash]] and [[:Category:Ini_Files#File_content_differences_between_Cumulus_1_and_MX|decimal separators like comma or point]]. For example, Microsoft computers usually default to USA locale, that specifies date format as month, day of month, year. Cumulus may default to GB format (day of month, month, year) or to ISO 8601 format of "yyyy-MM-ddTHH:mm:ss". Note that as of 2020, there are plans for MX to standardise on slash for date separator,and decimal points, and increasingly MX is using UTC, so check release announcements.

There is also the character set and [[Reports_folder#Encoding| File Encoding]], MX defaults to UTF-8 and it does not use "Byte Order Mark" that Microsoft traditionally has used by default. Microsoft used to actively pursue an approach of being non-standard in everything to keep people from using rival products, so there may be other issues if you have previously used a different computer.

Anyway it is vital that your Microsoft computer is set up correctly, if you have used Cumulus (1 or MX) before and wish to have access to existing data, reports and extreme records. You can choose a locale within the '''Settings''' app (cogwheel icon) on your computer, but you will get on better working through individual settings using ''Control Panel -->> Region''. There you can choose between 24-hour clock, am/pm, or AM/PM, as well as between different date formats, and between different field separators (both decimal commas and field separator set to comma must be avoided!).

Ask in support forum if you need more advice, the evidence in there is that MX on Windows raises lots of queries!

==.NET==

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

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

==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 [[MX_Administrative_Interface|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:
:<code>netsh http add urlacl url=http://*:8998/ user=\users</code>

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 <code>netstat -an | findstr 8998</code> into the command window.

=Cumulus Software=

Note use of plural in section name above, the following subsections will install various packages produced by Developer Mark Crossley.

==Packages to install==

<big>We shall install the Cumulus software listed on [[Software]] page</big>:
# '''CumulusMX''':
#* '''CumulusMX.exe''' is written in C#, that has been developed by Mark Crossley, some code is contributed by other developers, some is library code used when it can be, and there remains some code by Steve Loft
#* Download '''CumulusMX zip file’’’ from the link at[[Software#Latest_build_distribution_download]]
# [[Software#Create_Missing|'''Create Missing''']]:
#* '''CreateMissing.exe''' is also written in C#, created, and developed, by Mark Crossley
#* Download '''Create Missing zip file''' from the link at [[Software#Create_Missing]]
#** This takes you to a github page with a "ReadMe" providing minimal instructions
#* Using '''CreateMissing.exe''' is fully documented at [[Calculate_Missing_Values#CreateMissing.exe]] in this Wiki
#* (it will populate missing fields in [[standard log files]] and/or missing lines in [[dayfile.txt]]).
# '''ExportToMySQL'''
#* '''ExportToMySQL.exe''' is also written in C# by Mark Crossley
#* Download '''Export To My SQL zip file''' from the link at [[Software#ExportToMySQL]]
#** This takes you to a github page with a "ReadMe" providing minimal instructions
#* '''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 within early CumulusMX zip downloads.

As at 9 March 2020, another utility, '''CreateRecord''', has been initialised in the Github areas managed by the developer where Cumulus is worked on, although it appears to be just a concept (any code on the developer's computer has not yet been included) on github. This will, if my understanding is correct, read [[dayfile.txt]] and use that to update the various [[:Category:Ini Files|extreme record files]].

== Where to store download ==

There are no firm rules.
* Most browsers, if you don't change any options, will download to a sub-folder that is called "Download" within the Current User's folder (or a location elsewhere that is associated with a link of that name)
** Some people change the default, so they can place all downloads onto a separate partition, or a separate disc, mostly because it helps to keep downloads safe in case your main computer disc fails.
* A beginner may find it easier to create a new folder specifically for storing MX download zips, so it is easy to find if your standard download location is used a lot.
* It probably is not sensible for a beginner to store the download zip in a "temp" folder, although that is sometimes suggested for downloads that do not need to be kept.

== Earlier MX releases ==

Check if posts in the [https://cumulus.hosiene.co.uk/viewforum.php?f=40 Cumulus Support Forum] tell you that the current release of MX has one or more bug(s) that affects one or more aspect(s) of MX functionality that you intend to use.

Remember, it is impossible for the developer to check all the ways in which versatile MX can be used:
* Different weather station types (the developer only has a Davis),
* Different computer types (development is mostly on Microsoft Windows),
* Plus a whole host of optional features, and different external upload sites, (typically each of these optional features are only used by a sub-set of Cumulus users).

Anyway, '''you can download any earlier build, without the bug''', from [https://github.com/cumulusmx/CumulusMX/releases CumulusMX/releases].

You need to ensure that you use the right version of "CreateMissing.exe" and "ExportToMySQL.exe" utilities for the MX release you do install, as some modules are shared. Therefore if you are using an old MX release, you will need to go directly to the [https://github.com/cumulusmx Cumulus MX github] page, and navigate to the utility of interest, to see if you need to download an older version of these utilities that matches to your older MX.

=Unzip the package, and install MX=

Please note there are rules governing where you can install MX.

==Have you already got Cumulus MX?==

# It is good practice to backup your existing MX installation, (i.e. make a copy that is placed somewhere else, so it is easy to check what you had before; and if you find a bug in new release, or you make a mistake during the new installation, it is easy to regress to the earlier version)
# Now install the new MX over where the old MX was
#* This makes life simpler, as you know you will retain all files needed that are not included inthe new release

If you already have MX installed, you should be following the [[Updating MX to new version|Upgrade]] page advice:
* It is not a good idea to skip too many in-between releases
* Read the relevant release announcement at [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 Cumulus MX Announcements and Download - PLEASE READ FIRST], for all in-between releases just in case particular releases have one-off tasks associated with that release.

==Where should you install MX if you have not used MX before?==

# When download completes, use the mouse (those unable to use the mouse should do the equivalent keyboard action) to click on the download file name, this should ask if you want to extract (unzip) it.
# If there is an option as to whether to preserve folder structure, then select to preserve it, and be aware that this extracts into a folder with a name '''CumulusMX3xyz''' where the digits represented there by "xyz" identifies the build
# You should therefore extract to the download location (see earlier), and then copy, or file transfer all the files in sub-folder of that into appropriate place, following hierarchy in final location
# The final location has a small number of important rules, although there is some flexibility if you have multiple drives.
#* MX uses a number of different computer languages and multiple components. It is best to keep the path to where you install it short, to remove any possibility of path name being truncated as it is passed between components.
#* Best practice is to place MX files in the root directory of any disc or partition where you can have frequent updating, i.e. '''G:\CumulusMX''' (where G is the chosen drive, might be ''C:'' and '''CumulusMX''' is a short informative folder name that matches the top folder under the name '''CumulusMX3xyz''' in the release download after extraction from zip.
#* There is one place, where you must not store MX, and that is "avoid the 'Program File' hierarchy".
#*# Let me explain that:
#*# Microsoft tell developers to put code in '''C:\Program Files''' or ''c:\Program Files (x86)'' as these are read only folders except when software is being installed, and Microsoft tells developers to put data files for that software in '''c:\ProgramData'''
#*# Cumulus MX has not been developed in accordance with those Microsoft specific rules
#*# Consequently, if you did wrongly install MX in the above hierarchy, the read-only rule would mean that Microsoft stores any files that MX updates in another place and MX would not find them, here are two examples:
#*#* When you use the Settings pages in MX, instead of creating/updating a [[Cumulus.ini]] file in the same folder as "CumulusMX.exe", Microsoft would create/update the file in ''C:\Users\user_name\AppData\Local\VirtualStore\Program Files\CumulusMX\Cumulus.ini''
#*#* As MX runs, instead of creating files in say the [[Data folder|data sub-folder]], Microsoft redirects any file changes, after the software installation, into ''C:\Users\user_name\AppData\Local\VirtualStore\Program Files\CumulusMX\data'' (and similar redirection for other sub-folders)
#*# The problem then is that your Microsoft Windows computer now has two "data" (and other) sub-folders, but MX cannot know which sub-folder to look in, (as any file not updated is in installation sub-folder, while any file that has been updated is in the redirection sub-folder).

=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 [[MX_Administrative_Interface|admin interface]] where we can change [[Cumulus.ini|settings]], view our weather data, or edit various [[:Category:Cumulus_Files|Cumulus files]] (extreme records or log files).

If this is your first run of MX, please see [[First_Run_of_MX|First Run of MX page]].

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.

{| class="wikitable" border="1"
|-
!style="width:30px" | Step
!style="width:600px" | Interactively
!style="width:400px" | As Service
|- style="vertical-align:top;"
! scope="row" |Setting up
| To run Cumulus MX, Windows needs to know
# which '''.exe''' you want to run (ExportToMySQL.exe, CalculateMissing.exe, or CumulusMX.exe)
# the path where all the required '''.dll''' files are located

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 the CumulusMX executable:
#Create a shortcut on your desktop (and/or the taskbar) for the '''CumulusMX.exe''' executable <code>cmd.exe /C start CumulusMX C:\CumulusMX\CumulusMX.exe -debug</code>, the "-debug" is ''optional'', it starts the logging in debugging mode so the log created in MXDiags folder has more information. There are other optional parameters all listed later.
#*In that shortcut define the path where the executable is located as the path to start in.
#* '''Remember, if you have not done the <code>''netsh http add urlacl url=http://*:8998/ user=\users''</code> command mentioned above, you must run as administrator.'''
#* Add any of the parameters that can be used with the executable, as listed later, such as specifying a different port for the admin interface , or starting with debugging.
#* Choose whether to start as minimised or as a command window
#* You can also choose text colour (foreground) and background colour, you can choose where the window appears (so if you have two monitors you can choose which one it appears on), and how big that window is. There is a forum post by water01 about this.
#* Now you can click the shortcut to start the engine, it will open a Command window or Powershell window or Terminal window (default depends on release of Windows OS, but you can change which is used in Settings)
#* Please note: '''This window must be left open''', closing it will stop MX.
# OR place the shortcut as defined here in the start up folder for the user account so MX automatically starts when you connect/log in (see a later section for how to find that start up folder).
#* If you want MX to automatically start whenever you log into your PC, then the place to store your shortcut is <code>C:\Users\...\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Run_CumulusMX</code>. Don't forget to put your Microsoft username where I have put ...
#* 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.
# OR declare a task in the scheduler to start MX;
#* in the '''Actions''' tab fill in fields as follows (the other tabs should be obvious):
#** '''Action''' <code>Start a program</code> from drop-down
#** '''Program/script''' <code>cmd.exe</code> (this is standard Windows environment to run something)
#** '''Add arguments''' <code>/C start Start_MX \CumulusMX\CumulusMX.exe -debug -port=nnnn</code> (the "/C" means this task will close once it has started the task, the "Start_MX" is how the task will be labelled as it is running, the next argument "\CumulusMX\CumulusMX.exe" actually starts the executable and it does not need a drive prefix as that is in next box.
#** Note in this example I have included next two optional parameters that can be used after the .exe call in that same box, here '''-debug''' (only include if you want full debugging logging) and '''-port=nnnn''' where nnnn is the port to be used for admin interface (only include if want to change from default 8998),
#** all optional parameters are listed later
#**'''Start in''' <code>\CumulusMX</code> (include a drive specifier if necessary)
|
# '''Navigate to the folder with your MX installation'''.
# '''Install MX service''' (as an administrative user) using <code>CumulusMX.exe -install</code>
# '''MX is now set up as a service'''.
# There are other optional parameters (e.g. -port, -debug, -locale) you can add by editing registry
#* To add parameters to the service when it starts automatically you will have to edit the registry
#*# Right click the Windows button at left hand edge of taskbar (often at bottom of your screen)
#*# Choose '''Run'''
#*# Type '''regedit''' (and press ENTER)
#*# Navigate to '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CumulusMX'''
#*#* Hint, you can expand at any level by clicking the '''>''' in the navigation panel
#*#* Similarly, contract by clicking on '''&or;''' in the navigation panel
#*# Right Click on '''ImagePath'''
#*# Select '''Modify'''
#*# You should see '''"C:\CumulusMX\CumulusMX.exe"'''
#*#* This assumes that you have installed your MX in that system partition path, adjust the '''C:''' if you have installed your MX in another partition, in above and in examples below
#*# Now you can add parameters as per [[#Optional_parameters_to_add_to_the_instruction_to_run_the_MX_engine]]
#*#* For example modify to ''' "C:\CumulusMX\CumulusMX.exe" -port 9000''' to add port
#*#* For example modify to ''' "C:\CumulusMX\CumulusMX.exe" -debug''' to add full debugging
# The service will stop itself if it detects that the computer is going into standby:
# In your MX release distribution, navigate to '''CumulusMX\MXutils\windows'''.
# Find file '''CreateCmxResumeFromStandbyTask.ps1''' for resuming MX after Microsoft Windows has gone into standby.
# The script MUST be run with Administrator privileges.
# Type <code>CreateCmxResumeFromStandbyTask</code>, and press '''Enter''', this will create a Scheduled Task.
#* The scheduled task will exist from now on, and will automatically restart the service (on resume from standby/hibernate).
|- style="vertical-align:top;"
! scope="row" | (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
# Next '''start the admin interface''', it does not need to run all the time, but only when you need it , it normally runs on port 8998 (to vary that there is a '''-port''' parameter that is followed by required port and that port parameter has to be entered every time you start MX if you are not using the default port). More information on admin interface [[MX Administrative Interface|in separate article]].

Try '''start /min C:\Cumulus\CumulusMX''' to run MX as a minimised package (although in Windows you can change the properties of the shortcut you use to start minimised).

Note that you may sometimes want to use one or more of the optional parameters when starting MX.
| There are two ways to start MX service:
* Either, use the Services applet:- services.msc (You can pass parameters using this tool, but they are not saved for future use)
* Or, use the service command line tool:- <code>sc start CumulusMX</code> using Command window or Powershell window or Terminal window (one of these will be offered when you right click the Windows/Start symbol) and type '''exit''' to leave that window.

Note that you may sometimes want to use one or more of the optional parameters when starting MX, as per previous row.
|-
! scope="row"| 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 <code>sc query CumulusMX</code> at any time to check that the service is running.
|-
! scope="row"| 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:
* Either run <code>CumulusMX.exe - uninstall</code> as an Administrator using Command window or Powershell window or Terminal window (one of these will be offered when you right click the Windows/Start symbol) and type '''exit''' to leave that window.
* Or select '''Services''' from "Start", as an administrator, in the ''services applet'' that loads navigate to the one labelled Cumulus, and delete that.
|- style="vertical-align:top;"
! scope="row"| 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:
* Either, use the Services applet:- services.msc
* Or, use the service command line tool:- <code>sc stop CumulusMX</code>
|}

= Optional parameters to add to the instruction to run the MX engine =

As seen above, in Microsoft Windows, we leave off the file extension when we want to run one of the Cumulus executables, but we might need to add a parameter (starts with a minus symbol), and that parameter might need to be followed with a value.

== -install parameter for installing as Windows Service==

Use '''CumulusMX -install''' to install MX as a Windows service.

By default, MX's Microsoft Windows service is installed to run under the System account.

System does not have permissions for network access, that it turn means that any batch file that MX initiates as an external program will be restricted to actions that a System account can do, that excludes actions that a network access account can do.

== -uninstall parameter for uninstalling the Windows Service==

Use '''CumulusMX -uninstall''' to uninstall the service that runs MX.

== -Port parameter for changing HTTP 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:
:<code>CumulusMX -port 9999</code>

== -debug parameter for adding debugging ==

This is only available for [https://cumulus.hosiene.co.uk/viewtopic.php?p=138839#p138839 release 3.4.4 - Build 3068] onwards. This switches on debug and data logging from the start-up of Cumulus MX by adding a parameter:
:<code>CumulusMX -debug</code>

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 [[:Category:Diagnostics]] page for details) or the above command.

== Beta builds of MX ==

The following two parameters are not available since MX came out of 3.0.0 beta.

=== -wsport parameter for web sockets ===

Beta builds in MX version 3.0.0 had an optional parameter <code>CumulusMX -wsport nnnn</code> that determined which port (represented by a 4 digit number ''nnnn'') was used for '''Web Sockets'''.

Note use of this parameter is now deprecated, as it has been incorporated into '''-port''' parameter described earlier. The reason is that [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887&p=138815&hilit=sockets#p138815 Web Sockets in all builds since 3045] use the same port for web sockets as for the HTTP port of the [[MX_Administrative_Interface#The_API_interface|Admin Interface]].

=== -Logging parameter for debugging of data flow between station and MX===

Use '''CumulusMX -Logging=1''' (for the station to MX transfers to have increased debugging logging).

Note use of this parameter is now deprecated, as it has been incorporated into '''-debug''', see above.

=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 [[MX_Administrative_Interface|admin interface]] to change [[Cumulus.ini|settings]], view our weather data, or edit various [[:Category:Cumulus_Files|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.
** (Note "localhost" will work even if you host your own database server or own web server, each of these uses a different port number to ensure the correct server is loaded)
*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=

If this is your first time using MX, the release distribution does not contain a [[Cumulus.ini|configuration file]], and you need to [[MX_Administrative_Interface#Changing_Settings| set various settings]] to create this file.

If you are running MX interactively (explained above), you will see [[File:MX first start.PNG]].

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.

=One-off optional uploads=

If you have a web server, then navigate to the [[Webfiles_folder|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
**# steelseries
**# 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).
# The "lib" sub-folder contains further levels of sub-folders all to be replicated on your web site.
# The '''trends.htm''' web page also loads some library software from an internet Content Delivery Network (cdn) to invoke the JavaScript based Highstocks library.

=Already have Cumulus?=

== Report and data files to copy across from any previous Cumulus location ==

All the (optional) files in the [[Reports folder]] can be copied across from a previous installation. It should not matter which MX release created past files, although ideally you need to ensure that the report naming and encoding described on that linked page remain the same. If you previously used the legacy Cumulus 1, on the same computer, the same requirement for settings compatibility applies. If however you previously used the legacy Cumulus 1 on a different computer, then you may have some difficulty in accessing the old files because of differences in the default settings, please see [[Migrating from Cumulus 1 to MX]] page and read about why it is often more complex.

<br>

Whilst you should copy ''nearly'' ALL the files in the [[data folder]], from any old installation into the new installation, there are several extra considerations:
* MX cannot understand the Cumulus 1 [[Log.xml|log file]] (aka [[Weather Diary]]), so there is no point in copying that from the legacy Cumulus to a MX folder
* If your previous Cumulus installation was of the legacy software, version 1.9.4, or earlier, then you need to do a lot of reading:
** [[Amending dayfile]] tells you about how MX is far more fussy about the content in [[dayfile.txt]]
** [[:Category:Ini Files|.ini files]] explains how time-stamps are formatted differently in the extreme tracking files
** [[Migrating from Cumulus 1 to MX]] gives some advice about differences in settings, but be aware that the way MX handles settings varies by release, and information on the linked page may be out of date
* When copying [[Standard log files|MMMYYlog.txt]] files and [[Extra Sensor Files|ExtraLogyyyymm.txt]] files, be aware that '''your new MX installation will ignore any entries prior to the MX Start Date''' when it reads those files:
** See [[Cumulus.ini#Data_Logging|'''StartDate=xxxxx''']] parameter, edit using ''Station Settings → Common Options → Advanced Options → Records Began date''
* Some releases of MX are very fussy, some are less fussy, about all lines in all [[:Category:Files_with_Comma_Separated_Values]] being totally consistent in all "locale" settings.
* If your old MX installation, is on a different operating system to the Microsoft Windows for your new installation, remember that Microsoft Windows uses different line terminators to all other operating systems, although MX should cope with mixed line terminators, any third party routines reading your data files will probably not accept a line terminator change.

==Configuration Files to copy across from any previous Cumulus installation==

There are two configuration files that are not included in any MX release:
*[[strings.ini]] – optional file to customise output (MX content significantly different to legacy Cumulus content)
*[[Cumulus.ini]] – main configuration file (Substantial changes to content at release 3.12.0, some changes at other releases)

Just copy the existing files from old to new installation, if
# Your locale (Language settings in the Settings app, Regional Settings in the Windows Control Panel (use that not "Settings" even on Windows 10/11) is still the same
# All files on your new install are in same paths as on your old install (some settings involve specifying paths)
# Your old installation has a relatively recent MX release (compare the "y" in 3.y.z,between old and new installation, a difference of more than 1 means you do not have a recent release)
# Your old installation was on computer running Microsoft Windows Operating System, (not a Linux computer)

If you are upgrading from an older release, please read the table for advice.

{| class="wikitable"
|-
! scope="col" style="width:450px; color:blue" | Cumulus.ini !! scope="col" style="width:450px; color:navy" | strings.ini
|-
| Your old installation will have this file. In general, ''if your old installation was any release before 3.8.0'', the advice is give the old file a different name when you copy it across to the new installation, and let MX create the file as you work through all the settings.
| '''This is an optional file'''. Its [[strings.ini|purpose]] is to allow customisation of some of the outputs from Cumulus. You might want to use customisation to abbreviate (or extend) some outputs, or to change those outputs into another language.
|-
| When you work through the Settings pages, MX will create this file if it does not exist.
* If your old installation was of the legacy software then do consult [[Migrating from Cumulus 1 to MX]]
* As MX evolves, the former "read-only" settings in this file are becoming "advanced" settings in the interface.
| You create a “strings.ini” file by '''selecting some of the parameter'''s from the [[Samplestring.ini]] file that is included in each MX release, and ''modifying the value for the listed attributes'' as you type just those you selected (under the same group titles - these are enclosed in [ ] as before).

The sections that appear in '''samplestring.ini''', and the parameters that appear within a section, depend upon which release you are using. So be cautious if you try to reuse a "strings.ini" file originally created by the legacy software, you may find you need to specify your customisation using different parameters in the latest "samplestring.ini".
|-
| The content of "Cumulus.ini" is changing as MX is developed, the [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 Release Announcements] normally list any new parameters as they appear in the file, without always mentioning those that have become redundant. The announcements tend to avoid any detail, so you have to guess ''from the attribute'' what values it might take, and generally have no idea of where to make any change.

To remove any parameters no longer used in this file, see [[Cumulus.ini#How_to_Remove_Redundant_parameters_from_file|remove redundant parameters]]

If your old file contains any [[Cumulus.ini (Cumulus 1)|legacy read-only]] parameters not yet converted into advanced settings, or any [[Cumulus.ini (MX 3.0.0 to 3.7.0)|MX read-only parameters not yet converted into advanced settings]], you may need to manually add such missing parameters back into new file by stopping MX (after finishing all the settings you can configure in the interface), doing an external file edit, and then restarting MX
| The content of "samplestring.ini" is changing as MX is developed:
* Therefore, your existing “strings.ini” might need to be modified.
* There is no automatic way to check your “strings.ini” file, if MX does not understand any parameter in this file, it ignores it.
* Instead, you need to manually check each parameter you have in your “strings.ini” file to see if that parameter is still in the “samplestring.ini” included in the release you have installed.
* You may also find new parameters in “samplestring.ini” that you wish to add to your “strings.ini” file to tailor new functionality to your preferences.
|}

If you previously used an older release of Cumulus, but in this new installation will be using the latest release (latest is what is normally best, unless it has bugs), you may want to read up on all the changes between your old release and the current release, not just changes that affect the configuration file.

= Operating a web site with uploads from MX engine =

== The standard web pages ==

=== From release 3.10.1 ===

As mentioned above, the web pages are a one-off upload from '''CumulusMX\webfiles'''. The data to be shown on these web pages are uploaded from [[:Category:JSON_Files|.json]] files in the [[web_folder]].

Please read [[New_Default_Web_Site_Information|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 [[Cumulus_template_file|template files]], these are [[Customised_templates#What_is_meant_by_.27Cumulus_processes_templates.27|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 [[:Category:User Contributions|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|Customised templates]] page in this Wiki.
*# MX can process a file with a string of web tags mirroring the realtime.txt option in MX, and upload the resulting file so your web pages can use JavaScript for a one-off insert of the values or an Ajax routine to update the web page at a fixed interval.
*# Alternatively, you can use template scripts processed locally by MX that don't create web pages, but are uploaded by MX at either the real-time interval, the standard interval, or after end of day. These scripts simply initialise script variables with values obtained from web tags. You then independently have a set of web pages resident only on your web server (they don't exist where you run MX) using a combination of HTML and script content that bring in the script(s) with the variables by the appropriate syntax. All of this is covered on the [[Php_webtags|PHP web tags]] page in this wiki. As it suggests there, you might therefore have several files processed by Cumulus MX at these different intervals, converting the web tags into script variables, and then use AJAX (JavaScript that may use json format to bring in the variables) or PHP (using <tt>'require_once 'filename';</tt> syntax) to put those variables into a web page.

You may find [[PHP|this wiki page]] useful for understanding more about the different script languages.