5,838
edits
Category:Cumulus MX: Difference between revisions
m
→What I did to Install MX
|
== What I did to Install MX ==
I have used Cumulus 1 for a decade or so, and been very happy with it, but I wanted to give MX a go without affecting my Cumulus 1 installation. Here is exactly what I did on my ex NHS Windows 10 Pro PC, step by step; I am hoping this list might help some readers. Can I just stress I downloaded version 3.4.5 (build 3069), there may be some changes that affect what I record below in more recent versions, I just noted what I had to do at that moment in time (March 2020). For example
=== Download and unzip ===
#I downloaded the '''CumulusMXDist3069''' zip from [[Software#Current_Release|the Current Release section]] on the downloads page.
#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 unzipped the contents into a partition I use just for software downloads.
▲#
#*Downloading to somewhere other than where you will install it, also makes it easier if you do any customisation of particular files and wish to keep copies of originals.
#I used a package that '''verifies the files it copies''' to duplicate the folder '''CumuluxMX''' within the zip onto the drive where I wanted to run Cumulus MX.
#As I
#* If you intend to use
#*#Ensure you do copy these files from download into where you are installing MX.
#*#You will also need to FTP all files and sub-folders '''within''' the webfiles folder
=== Copying Cumulus 1 files into MX folder ===
The locale I used for Cumulus 1 is going to be the same I will use for MX (same PC!) so my copying across of my existing files
#First, I copied my '''\Cumulus\strings.ini''' to '''\CumulusMX\strings.ini'''. This preserves any tailoring I have done of terminology.
#
#Next, I
#Now, I copy my '''\Cumulus\Cumulus1.ini''' (don't worry why my file had a "1" in its name, just remember that yours probably won't) to ''\CumulusMX'' folder as "Cumulus.ini". I then edit the MX "Cumulus.ini" file:
#* In the '''[Alarms]''' section (your Cumulus.ini may have sections in a different order to mine) I edit all the parameter lines where the attribute ends in "File" to reflect their MX location in the sounds folder (there is no such folder in Cumulus 1).
#*
#*I now had to decide whether
#*# 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]].▼
#** I would use the '''Extra web files''' settings page in the MX admin interface to make the changes, in the local file column, necessary to define which web templates I wanted MX to process
#*# 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.''▼
#**Or I would make the changes myself by editing the appropriate lines in this [FTP site] section. (I decided on this option).
#*# 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.▼
▲#*# 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 also 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. 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.
#* 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 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, I checked at [[Webtags#
#
▲#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).
# Next I see there is a "MXdiags" folder, so I don't copy across the Cumulus 1 "diags" folder. Equally I don't change anything in the new MX "webfiles" folder, but I do copy across to my web server the "cumuluscharts.js" and "logoSmall.png" files I see there that I have not seen before.
# So left to last is the "data" folder:
#* I have copied all files from "\Cumulus\data" to "\CumulusMX\data" (except '''log.xml''' as MX uses a different file
#**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. I use the full stop character for all my decimal points, but if you use decimal commas, you might find you need to do some editing of your .ini files in this data folder before MX can read them.
===
# 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
=== Creating the shortcut to run MX ===
# 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.▼
# 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.
=== One-off extra installation steps ===
# I clicked on one of my new shortcuts. '''Windows Defender''' popped up, so I told it '''allow all''' for Cumulus MX.
▲# 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'''
#In the "Firewall" section of the Internet Security package I added port '''8998''' as one that was permitted.
# I viewed my hub (router) to see the IPv4 address allocated to my Cumulus MX computer (192.168.1.64), that told me that I would find the user interface by typing "http://192.168.1.64:8998/" into my browser while the MX engine command window remains open (so MX is actually running), so I typed that and I saw the user interface and navigated around it.
# 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
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. 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.▼
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.
▲
If you don't do
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.
=== My migration from Cumulus 1 to MX ===
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. Initially, I am continuing to use Cumulus 1 for the moment, until I am absolutely sure MX can do everything I want.
▲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 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.
▲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 elsewhere in this article I have expanded the text for those features I have tried and therefore understand.
= Updating to a new MX release =
| |||