Cumulus Wiki

My migration from C1 to MX

Revision as of 10:25, 25 March 2021 by Sfws (talk | contribs) (Created page with "'''What I did to Migrate from the original Cumulus software to MX'''{{TOCright}} I was happy using the original Cumulus software for more than a decade. When I saw that Mark...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

What I did to Migrate from the original Cumulus software to MX

I was happy using the original Cumulus software for more than a decade. When I saw that Mark Crossley's development work on MX had made the functionality similar in that flavour, I decided to give MX a try without affecting my Cumulus 1 installation.

Here is exactly what I did on my ex NHS Windows 10 Pro PC, step by step; I am hoping this list might help some readers who choose to stay with a Windows PC. Once I was happy with MX, I moved to using a Raspberry Pi computer, and what I did then is on the Setting up Raspberry Pi page.

Warning

The following notes relate to release version 3.4.5 (build 3069). This was the latest in March 2020, when I did my experiment.

The MX package has changed massively since then, functionality has been increased, but also the folders and files included are not the same as they were in March 2020 when this article was originally created (on a different page, so that is why the page history for this page does not show this).

Download and unzip

  1. I downloaded the CumulusMXDist3069 zip from the Current Release section on the Software page. Please note this link will always give you latest available.
  2. I unzipped the contents into a disk partition, on my PC, I use just for software downloads.
    • I have designed my own web pages, so I did not require any files from the "\CumulusMX\webfiles\*.*" folder, and its sub-folders, or from the "\CumulusMX\web" folder.
  3. However, I did copy the rest of the folders within the folder CumuluxMXfrom the package, as well as the files in the top level folder, onto the drive where I wanted to run Cumulus MX.
  4. I used a package (TeraCopy) that verifies the files it copies to be sure every file was correctly copied across.

Copying Cumulus 1 files into MX folder

  1. First, I copied my \Cumulus\strings.ini to \CumulusMX\strings.ini. This preserves any tailoring I have done of terminology.
  2. Next, I copied my existing Cumulus 1 alarm sounds in "\Cumulus" across to MX folder "\CumulusMX\interface\sounds" as these were referenced in my main Cumulus.ini_(Cumulus_1) file (I will edit that file next to reference the new location of these files).
  3. Now, I edit my \Cumulus\cumulus1.ini (don't worry why my file had a "1" in its name, just remember that yours probably won't) into \CumulusMX\Cumulus.ini making the following changes:
    • In the [Station] section, I deleted the parameter I had that looked like EWpressureoffset=x.y. (There is an error in the legacy Cumulus - it reads a byte that has nothing to do with pressure, as well as the byte that does relate to pressure, consequently you can get strange pressure readings reported).
    • In the [Alarms] section I edit all the parameter lines where the attribute ends in "File" to reflect their MX location in the sounds folder (there is no such folder in Cumulus 1).
    • I replaced [FTP Site] with [FTP site] (second word entirely in lower-case)
    • I amended all the parameters relating to the extra template files I had defined, to reference a new set of template files to cope with differences in the output parameters of MX web tags.
    • I have a few files that are PHP scripts written as Cumulus templates; each PHP script has a number of PHP variables being set equal to a Cumulus web tag. You can find out about these scripts at Php webtags.
    • I also have a few Cumulus templates that, like the standard ones I don't use, generate web pages and embed a lot of Cumulus web tags. I have had to edit these templates as in some cases the web tags have date/time output format parameters. Despite now having Cumulus 1 and Cumulus MX templates with different names, these still both generate remote web pages given the same names, so I don't need to alter any navigation between pages on my web server.
    • In the "[NOAA]" section I had MonthFileFormat="NOAAMO"MMMyyyy".txt" on a line, so it was already in the right format for MX.
  4. In the download, there is a file "\CumulusMX\Reports\.gitignore" provided. I copied into that folder over 200 report files from "\Cumulus\Reports".
  5. The download also has a file "\CumulusMX\data\.gitignore" provided. I copied into "\CumulusMX\data" most of the files from "\Cumulus\data" (except log.xml as MX uses a different file)
    • As MX does not provide a way to read the XML file into its diary.db, I manually copy across the weather diary entries I want to keep.

Aside on .ini files in data folder

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

Aside on .txt files in data foilder

All the lines in my dayfile.txt used the same format for dates (with "/" as separator), all used period (.) as decimal point, and all used colon (:) in the time-stamps. Because the locale I used with MX was the same, the existing file worked with MX, despite earlier lines having significantly fewer fields than later lines.

Creating the shortcut to run MX

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

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

Please note, later releases of MX can be run as a service, the above details relate to a release that could not be run as a service.

One-off extra installation steps

  1. I clicked on one of my new shortcuts. Windows Defender popped up, so I told it allow all for Cumulus MX.
  2. I opened my Internet Security premium package, in the "unrecognised files" section I selected CumulusMX.exe then right clicked and selected Change File Rating to Trusted
  3. In the "Firewall" section of the Internet Security package I added port 8998 as one that was permitted.
  4. I viewed my hub (router) to see the IPv4 address allocated to my Cumulus MX computer (192.168.1.64), that told me that I would find the admin interface by typing "http://192.168.1.64:8998/" into my browser while the MX engine command window remains open (so MX is actually running), so I typed that and I saw the user interface and navigated around it.
  5. I right clicked on my desktop (you may need to right click on the windows symbol at bottom left), selected command prompt as administrator that opened a command window where I typed netsh http add urlacl url=http://http://192.168.1.64:8998/ user=\users and I got the response "URL reservation successfully added", so I know it worked. This command is apparently to allow all users to bind to port 8998 (i.e. that used for the Cumulus interface). This also means you don't have to run the engine (CumulusMX.exe) in an administrator user, nor select "Run as administrator" from right click menu on the shortcut, nor set the properties for any shortcut to run in any special way.

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

End of my test of MX actions

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

Testing MX while still using Cumulus 1

Obviously, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station. As already noted, MX changes some files making it impossible for the legacy Cumulus to understand them. Depending on the locale you use, the notes here that applied to me, might not fully cover all the file changes you need to do.

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

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

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

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

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

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

Final notes

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

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

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

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

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

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

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