Category:Cumulus MX: Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
3,302 bytes added ,  21:53, 26 March 2020
m
m (→‎Running Cumulus MX: add cross ref to "cumulus.ini" page)
(4 intermediate revisions by the same user not shown)
Line 117: Line 117:
#I unzipped the contents (on my Windows PC) into a partition I use just for software downloads
#I unzipped the contents (on my Windows PC) into a partition I use just for software downloads
#I used a package that verifies the files it copies to duplicate the folder '''CumuluxMX''' onto the drive where I run Cumulus. I then noticed that the package contained some very obsolete copies of some external packages:
#I used a package that verifies the files it copies to duplicate the folder '''CumuluxMX''' onto the drive where I run Cumulus. I then noticed that the package contained some very obsolete copies of some external packages:
#*As downloaded, the MX package contained obsolete vintage version 2.1.4 (2015-03-10) of Highstocks and Highcharts, so I downloaded latest versions from [https://www.highcharts.com/blog/download/ the Highstock link] on this page.  I then created a new folder obsolete at "\CumulusMX\interface\lib\highstock\js", moved the folders "modules" and "themes" that were there in my new folder, and the various highstock and highchart files that were there were moved into the obsolete folder. Now I navigated to the code folder within that download, copied the files within it to "\CumulusMX\interface\lib\highstock\js" and then copied the folders  "modules" and "themes" from that code download folder into the same location. So now (in March 2020) everything is related to version 8.04 released 10 March 2020.
#*As downloaded, the MX package contained obsolete vintage version 2.1.4 (2015-03-10) of Highstocks and Highcharts, so I downloaded latest versions from [https://www.highcharts.com/blog/download/ the Highstock link] on this page.  I then created a new folder obsolete at "\CumulusMX\interface\lib\highstock\js", moved the folders "modules" and "themes" that were there in my new folder, and the various highstock and highchart files that were there were moved into the obsolete folder. Now I navigated to the code folder within that download, copied the files within it to "\CumulusMX\interface\lib\highstock\js" and then copied the folders  "modules" and "themes" from that code download folder into the same location. So now (in March 2020) everything is related to version 8.04 released 10 March 2020. This matches the version I use with my web pages on my web server.
#*As downloaded, "\CumulusMX\webfiles\lib\jquery" contained jQuery version 1.9.1, that is 2014 vintage and very obsolete, I already have the latest jQuery on my web server, so I did not need to put that new version into this webfiles\lib location, I just noted that this new path meant I ''may'' have to make some change on my web server later. If you do want to use a newer version of jQuery on your web site, you can download latest compressed production version from [https://jquery.com/download/ jQuery web site]. I prefixed the version in the MX package with the word OBSOLETE (OBSOLETEjquery-latest.min.js), you will find the latest version you download is called '''jquery-3.4.1.min.js'''. If necessary, rename that to "jquery-latest.min.js" to match the name that MX uses.
#*As downloaded, "\CumulusMX\webfiles\lib\jquery" contained jQuery version 1.9.1, that is 2014 vintage and very obsolete, I already have the latest jQuery on my web server, so I did not need to put that new version into this webfiles\lib location, I just noted that this new path meant I ''may'' have to make some change on my web server later. If you do want to use a newer version of jQuery on your web site, you can download latest compressed production version from [https://jquery.com/download/ jQuery web site]. I prefixed the version in the MX package with the word OBSOLETE (OBSOLETEjquery-latest.min.js), you will find the latest version you download is called '''jquery-3.4.1.min.js'''. If you are using MX web pages, rename the new jQuery to "jquery-latest.min.js" to match the name that MX uses.
#*I also noted "\CumulusMX\interface\lib\jquery" also contained the same jQuery version 1.9.1, that is 2014 vintage and very obsolete, whether you update that or not is your choice, but there is no guarantee that the MX user interface will work fully with latest jQuery version.
#* Other parts of the interface also had old versions of library software, but (because the interface uses json files to drive content of the various screens) I had no guarantee that its screens would work with later versions of the following libraries:
#** "\CumulusMX\interface\lib\jquery" contained the same old jQuery version 1.9.1, that is 2014 vintage and very obsolete, whether you update that or not is your choice, but there is no guarantee that the MX user interface will work fully with latest jQuery version.
#* "\CumulusMX\interface\lib\alpaca" included "alpaca" old version 1.1.3, the latest I found  [http://www.alpacajs.org on the alpaca home page] was version: 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.


=== Copying Cumulus 1 files into MX folder ===
=== Copying Cumulus 1 files into MX folder ===
Line 150: Line 152:
Finally, 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.
Finally, 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.


IMPORTANT NOTE: I don't use "localhost" for two reasons, first I already have a web server on my PC using "localhost", and second using the IPv4 exact address as a bookmark, I can view the Cumulus user interface on my mobile phone which shares bookmarks with my PC and connects to my LAN via wifi.
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), and second using the IPv4 exact "http://192.168.1.64:8998/" address as a bookmark, I can view the Cumulus user interface on my mobile phone which shares bookmarks with my PC and connects to my LAN via wifi.


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


One more lesson, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station. If you sometimes run one flavour (say MX) and sometimes the other (Cumulus 1), 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 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. 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.
One more lesson, you cannot have Cumulus 1 and Cumulus MX running at same time, accessing same weather station. If you sometimes run one flavour (say MX) and sometimes the other (Cumulus 1), 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 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 any 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.


=== Success ===
=== Success ===
Line 220: Line 225:
=== Changing Look ===
=== Changing Look ===
You need some understanding of Cascading Style Sheets (CSS) to do this, but all you need to do is to edit the relevant style sheet in '''\CumulusMX\interface\css'''.
You need some understanding of Cascading Style Sheets (CSS) to do this, but all you need to do is to edit the relevant style sheet in '''\CumulusMX\interface\css'''.
== Changing Settings ==
This is done using the MX "user interface", you will see that '''Settings''' is the penultimate option in the navigation bar, and it has a drop down for the various settings screens that are now described.
=== Station Settings ===
Each setting has a hint beside it (with a small 'i' for information before each hint). If you have used [[Cumulus_Screenshots#Station|Cumulus 1]], the layout and section headings will be familiar. Like all the settings pages, the headings are collapsed and need to be clicked to see the items under them. The table [[Cumulus.ini#Section:_Station|here]] will explain how MX stores the selections you make here, and give a bit more detail about each item and the values it can take.
=== Internet Settings ===
This has a lot of similarities with the [[Cumulus_Screenshots#Sites.2FOptions_Tab|Cumulus 1 settings]]. Again there are hints, MX has more options than Cumulus 1 had, and some defaults are different in the two flavours.
=== Extra Web Files ===
This is an extension of the Cumulus 1 facility, that is explained for both Cumulus flavours [[Customised_templates#What_to_select_on_the_.27Files.27_tab_of_the_Internet_Settings_screen_within_the_.27Configuration.27_menu|here]], it has an extra "end of day" option (leave "realtime" column blank if you tick the new column), but otherwise you fill it out exactly the same way.  If you have moved from Cumulus 1, you might need to:
# change some paths in local column
# edit some templates where the process column is ticked because of [[Webtags|Web tags differences]].
=== Calibration settings ===
This is identical to [[Cumulus_Screenshots#Calibration|Cumulus 1]] functionality, already explained elsewhere in this wiki.
=== NOAA report settings ===
This is identical to Cumulus 1 functionality, already explained [[Cumulus.ini#Section:_NOAA|elsewhere]] in this wiki.
=== MySQL settings ===
This is new.  <big>THIS SECTION NEEDS TO BE WRITTEN - WILL YOU VOLUNTEER ???</big>
=== Alarms  ===
This is identical to Cumulus 1 functionality, apart from using a new default location for the files "\CumulusMX\interface\sounds", already explained [[Cumulus.ini#Section:_Alarms|elsewhere]] in this wiki.
=== FTP Now ===
This is similar to the option in Cumulus 1 to do an update now.


= Updating to a new MX release =
= Updating to a new MX release =
5,838

edits

Navigation menu