Category:Cumulus MX: Difference between revisions

I have used Cumulus 1 for a decade or so, and been very happy with it, but I wanted to give MX a go without affecting my Cumulus 1 installation. Here is exactly what I did on my ex NHS Windows 10 Pro PC, step by step; I am hoping this list might help some readers.  Can I just stress I downloaded version 3.4.5 (build 3069), there may be some changes that affect what I record below in more recent versions, I just noted what I had to do at that moment in time (March 2020). For example from version 3.5.0 the obsolete Highstocks I mention below is no longer included in the MX package, instead MX uses the online latest version.

#I downloaded the '''CumulusMXDist3069''' zip from [[Software#Current_Release|the Current Release section]]  on the downloads page. N.B. 3069 is no longer latest distribution, but the same link will always give you latest available.

#I unzipped the contents (on my Windows PC) into a partition I use just for software downloads. You don't have to have somewhere separate to the installation, but it is useful if you want to download on a separate device to the device where you will install your MX, or if you do any customisation of particular files and wish to keep copies of originals.

#I am not intending to use the web pages that come with MX, so I selected to exclude some download files: the ones from the "'''\CumulusMX\webfiles\*.*'''" folder, and its sub-folders in the download.

#* If you intend to use these web pages, then you will need to:

#*#You will also need to FTP all files and sub-folders '''within''' the webfiles folder and sub-folders to whatever folder on your web server you specify as the directory in the '''Web/FTP site''' part of the settings for MX.

The locale I used for Cumulus 1 is going to be the same I will use for MX (same PC!) so my copying across of my existing files should be fairly easy:

#Next, I copied my existing Cumulus 1 alarm sounds in "\Cumulus" across to MX folder "\CumulusMX\interface\sounds" as these were referenced in my main Cumulus.ini file.

# I copy '''\Cumulus\Cumulus1.ini''' to ''\CumulusMX'' folder as "Cumulus.ini". I then edit the MX "Cumulus.ini" file:

#*In the "'''[FTP site]'''" section (yes, mine was named correctly with second word all lowercase), I had a number of edits to make:

#*# I change any references to any web pages within "Cumulus" folder to say within "CumulusMX" folder. The approach I am taking is to continue to use my customised web pages, but I am editing the template files as required to cope with differences in the output parameters of [[Webtags#Output_.28format_modifier.29_parameters_for_times_and_dates|MX web tags]].

#*# Next where I want a transfer done only at end of day, I added lines like "ExtraEOD19=1" (when you run MX it will add a ExtraEODnn for each of the 100 possible values of nn that you have not created) and changed the previous "ExtraRealtime19=1" to "ExtraRealtime19=0" (I previously used realtime as that was only way in Cumulus 1 to ensure a template file was processed so it held correct values as close to end of day as possible, but it inefficiently also made huge numbers of unwanted transfers during the day). I had 9 such files being copied far too often, so those 9 changes will cause a huge reduction in processing load!  ''I know I could do this later using the MX admin interface, but it makes sense to me to do it as I am working through the file.''

#*# 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.

#*# 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.

#*In some cases the web tags have date/time output format parameters.

#*Now I had to do lots more editing of these web tags. I created a new version of each PHP script that used "nn", changed it in each new script to "mm" and changed each reference in the MX '''Cumulus.ini''' to the old files to refer to the new files. While in Cumulus 1 you can use tags like 'H' and 'M' on their own, in MX a single modifier on its own often means something different to when that modifier appears with other modifiers. Consequently, I edited any  "h" or "H" on its own into "%h", any "hh" into "%H". Next all my "am/pm" references had to be changed to "tt". There were other changes I had to make and there was quite a lot of work here, despite being able to use the Search ... Replace option in Notepad++. As a result I have done some edits to [[Webtags#List_of_allowed_modifiers|this table]] hopefully making life simpler for the next person faced with this.

#* I mentioned some of my web pages are generated from my own Cumulus templates. Despite now having Cumulus 1 and Cumulus MX templates with different names, these still both generate web pages given the same names, so I don't need to alter any navigation between pages on my web server.

#*In the "'''[NOAA]'''" section I had '''MonthFileFormat="NOAAMO"MMMyyyy".txt"''' on a line, I checked at [[Webtags#List_of_allowed_modifiers|List of allowed date/time modifiers]] that 'MMM' and 'yyyy' were valid in Cumulus MX as well as in Cumulus 1, they were so no edit needed either to that line or to "YearFileFormat="NOAAYR"yyyy".txt" line.

#The file "\CumulusMX\Reports\.gitignore" provided in the mX package at download, is joined in the '''\CumulusMX\Reports''' folder by copying in the 200 or so report files I currently have in "\Cumulus\Reports". These are another "Cumulus.ini" (''I am certain this is not used'', but I am playing safe by coping it in) and the existing monthly and annual NOAA reports. I don't need to change those file names as I will continue to use the same format (see change to main Cumulus.ini mentioned above).

#Obviously "\Cumulus\web" and "\CumulusMX\web" have different content, so there are not any Cumulus 1 files to copy across to MX (not that I am using the standard web files).

#* I have copied all files from "\Cumulus\data" to "\CumulusMX\data" (except '''log.xml''' as MX uses a different file), and will see what edits I need to make later. Some of my '''.ini''' contain date-time entries like "12/03/2019 14:50:45". I'm assured MX can read these, although it changes a date time like that to "2019-03-12T14:50:45", but I am waiting to see if that is true.

=== Almost "Ready to run" ===

# I find after running the CumulusMX engine, that it edits those '''.ini''' files it needs to, and the new versions contain date-time entries in the "2019-03-16T12:45:00" style, but despite what I picked up from reading on the forum, you '''don't''' need to edit beforehand these entries in log files like '''month.ini''' as Cumulus MX can read the old ones.

# I right clicked on the "CumulusMX.exe" entry in the top level folder and selected '''Send to ... desktop (create shortcut) '''. I have renamed my shortcut to "MX_run" so I can recognise it as different to the folder name, as I have also created a shortcut for the folder. On the same right click menu I also selected '''Pin to taskbar'''. [When I am happy with MX, I can copy the shortcut into '''C:\Users\Personal\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\''' and then MX will start automatically after I (or Windows Update) reboot my PC].

# I clicked on one of my new shortcuts. '''Windows Defender''' popped up, so I told it '''allow all''' for Cumulus MX. For the shortcut in the "Startup" folder, I righ-clicked and set up on the layout tab the necessary parameters to place the window that opened on the smaller of the 2 monitors I have connected to my PC, so when it is not minimised (another setting on the shortcut tab) it does not interfere with whatever I am doing on my larger main monitor.

# I opened my Internet Security premium package, in the "unrecognised files" section I selected CumulusMX.exe then right clicked and selected '''Change File Rating to Trusted''' (I will need to repeat this every time a new version is installed) and in the "Firewall" section of the Internet Security package I added port '''8998''' as one that was permitted.

Obviously, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station. 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 either of those alternatives, various derivatives (e.g. Chill Hours) will become wrong and you may have conflicting rows in dayfile.txt (because its content is generated from what that flavour saw when it was running the previous day) and generally this will be particularly evident in any weather parameter that varies a lot like wind vector. It also affects 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 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.

My installation of Cumulus MX has succeeded, and as the experiment did help me find a mistake in one of my Cumulus templates where I had not defined input parameters for "Recent History", it has been useful. I am continuing to use Cumulus 1 for the moment, until I am absolutely sure MX can do everything I want. I believe it will do some tasks better, but there is a lot more to learn about how to use it. While I was using Cumulus 1, I found with my Chas Olsen Fine Offset I had to define [[Cumulus.ini#Introduced_for_problems_with_Fine_Offset_family:|EWpressureoffset=x.y ]] otherwise Cumulus 1 frequently failed to read the correct pressure. In implementing MX, I decided to try without that line in the new Cumulus.ini file; I have not had any problems either when I first ran MX or indeed 2 months later when it is more than a month since I last ran Cumulus 1. Consequently, if you used to have pressure reading problems, you might find you don't with MX.

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 I have expanded the text for those features in this article.

You don't need to read this, '''it is not part of the migration from Cumulus 1 (C1) to MX for those using standard C1'''. However, this is a bit of a warning if you already use some of the library packages that MX uses because your web site is not based on standard C1 web pages.  

#The latest MX package does NOT include Highstock in the distribution, so MX will automatically use the latest version, and you can miss out this first updating step I had to do.

#*However, the MX 3.4.5 (this was latest at time I wrote these notes) package I downloaded contained obsolete vintage version 2.1.4 (2015-03-10) of Highstocks and Highcharts within both the interface folder "'''\CumulusMX\interface\lib\highstock'''" and the webfiles folder '''T:\CumulusMX\webfiles\lib\highstock'''. I am already using version 8.04 released 10 March 2020 on my web server because I have additional charts on my web pages, and I was worried this clash of versions might cause a problem.

#**I created a new folder '''obsolete''', I moved the various highstock and highchart files from existing folder "\CumulusMX\interface\lib\highstock\js", and the folders "modules" and "themes" that were in the existing folder into my new folder.

#**I had downloaded the 8.04 versions from [https://www.highcharts.com/blog/download/ the Highstock link] and saved that on my partition I just use for software downloads.  So I copied the files and folders from that download to "\CumulusMX\interface\lib\highstock\js" to replace the ones I moved out. So now (in March 2020) my admin interface is also using Highstock version 8.04 released 10 March 2020 to match the version I use with my own web pages on my web server.

#**With my own web pages, the only ones that use jQuery are those generated from Cumulus templates using web tags, and I include "jQuery" in the name of all those templates to remind me which files to edit (and I use a batch editor that edits all the files with one instruction) when I want them to use a new jQuery version.

#The MX package also included "alpaca" old version 1.1.3 which predates 29 July 2014 in "\CumulusMX\interface\lib\alpaca", looking at  ['''http://www.alpacajs.org''' is the alpaca home page] the latest version is 1.5.27 released on 14 May 2019, again there is no guarantee that the MX user interface will work fully with these new versions, so I stayed with what MX provides.