Cumulus Wiki

Category:Cumulus MX: Difference between revisions

Category:Cumulus MX (view source)

Revision as of 10:27, 21 June 2020

15,643 bytes removed ,  10:27, 21 June 2020
m
no edit summary
mNo edit summary
mNo edit summary
Line 574: Line 574:
You may find [[PHP|this wiki page]] useful for understanding more about the different script languages.
You may find [[PHP|this wiki page]] useful for understanding more about the different script languages.


== 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 the latest version probably has some changes to folders and files included in the package.
=== Download and unzip ===
#I downloaded the '''CumulusMXDist3069''' zip from [[Software#Current_Release|the Current Release section]]  on the downloads page. Although 3069 is no longer the latest distribution, still use the same link as it will always give you latest available.
#I unzipped the contents into a partition I use just for software downloads.
#*You don't have to have somewhere separate to the installation, but many people will want to download on a separate device to the device where they will install  MX
#*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 was not intending to use the web pages that come with MX, so I selected to exclude in this verified copying everything from the "'''\CumulusMX\webfiles\*.*'''" folder, and its sub-folders in the download.
#* If you intend to use the standard MX web pages, then you will need to:
#*#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 (not the actual folder itself), to whatever folder on your web server you specify as the directory in the '''Web/FTP site''' part of the settings for MX.
=== 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 was easy:
#First, I copied my '''\Cumulus\strings.ini''' to '''\CumulusMX\strings.ini'''.  This preserves any tailoring I have done of terminology.
#Remember, "\Cumulus\web" and "\CumulusMX\web" have different content, so don't do any copying between these.
#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 will edit that file next to reference the new location of these files).
#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 checked that I had a "'''[FTP site]'''" section (yes, mine was named correctly with second word all lowercase, but if your has '''[FTP Site]''' you will need to edit that section title to put second word entirely in lower-case)
#*I now had to decide whether
#** 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
#**Or I would make the changes myself by editing the appropriate lines in this [FTP site] section. (I decided on this option).
#*Although my web templates are stored in a folder "Templates for Cumulus to Process" outside the Cumulus 1 or Cumulus MX folder structure, I had to reference a new set of template files 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 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#The_format_used_for_naming]] 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.
#In the download, there is a file "\CumulusMX\Reports\.gitignore" provided. In this same MX folder, I copied in the 200 or so report files I currently have in "\Cumulus\Reports". Remember you don't need to rename these files, it is only how that naming is specified in the settings that might need changing.
# 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 and MX does not provide a way to read the XML file into its '''diary.db''').
#**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.
=== 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 can read the old formats like "12/03/2019 14:50:45" as well as the new year first formats.
=== 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.
=== 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
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.
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.
=== 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.
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.
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 =
= Updating to a new MX release =
Sfws
5,838

edits

Retrieved from "https://www.cumuluswiki.org/a/Special:MobileDiff/6314"