5,838
edits
Updating MX to new version: Difference between revisions
From Cumulus Wiki
Jump to navigationJump to search
Updating MX to new version (view source)
Revision as of 16:25, 21 January 2021
, 16:25, 21 January 2021PASTE
m (→The rename old approach: added 2nd point about disadvantage stopping it being recommended) |
m (PASTE) |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 18: | Line 18: | ||
You might want to read galfert's post on the support forum [https://cumulus.hosiene.co.uk/viewtopic.php?p=148851#p148851 here] for the relevant Linux instructions in a concise format. | You might want to read galfert's post on the support forum [https://cumulus.hosiene.co.uk/viewtopic.php?p=148851#p148851 here] for the relevant Linux instructions in a concise format. | ||
== Updating if you use the start/stop management script == | |||
This section contributed by ''Jank'' on support forum. Note the version on the forum might have been updated from the original included here. | |||
1. look on [[Software|Software download page]], find the link to latest version, and fill out the '...' below appropriately as you run these 2 commands on your device where you do downloads: | |||
<pre>cd /tmp | |||
wget https://github.com/cumulusmx/CumulusMX/ ... .zip</pre> | |||
2. Once that download is complete, start cumulusmx.sh with option -u | |||
<pre>/home/pi/CumulusMX/cumulusmx.sh -u</pre> | |||
3.When asked for the zip file, enter | |||
<pre>/tmp/CumulusMXDist</pre> and hit the TAB Button | |||
4.Choose the zip file with the CumulusMX update and hit return. | |||
5. Follow the on screen instructions | |||
6. With each update component .....you can choose: [y]es, [n]o, [A]ll, [N]one, [r]ename | |||
I would recommend select '''A''' as that will simply replace all files without further action. | |||
CumulusMX will be restarted after update completes. | |||
You can check if the update was successful by using option -s: | |||
<pre> /home/pi/CumulusMX/cumulusmx.sh -s</pre> | |||
== Updating to the next MX release if you have not updated before == | == Updating to the next MX release if you have not updated before == | ||
| Line 113: | Line 141: | ||
** 1 - MX is running an earlier build than the latest public release | ** 1 - MX is running an earlier build than the latest public release | ||
* <#NewBuildNumber> Displays the latest public release build number | * <#NewBuildNumber> Displays the latest public release build number | ||
=Where to download a release distribution= | |||
==Latest release== | |||
Download release distribution zip from [[Software|the Software article in this Wiki]] for latest version. | |||
Be aware that the developer needs to remember to update this link each time there is a new release. | |||
An image that contains a '''Rapberry Pi lite operating system''' and the latest Cumulus MX release already included, may be downloaded from the same wiki article. | |||
==Any release developed by Mark Crossley== | |||
Download release distribution zip from https://github.com/cumulusmx/CumulusMX/releases for earlier versions. | |||
= What to read (and when) before updating = | = What to read (and when) before updating = | ||
| Line 223: | Line 265: | ||
====If using either 3.1.x, 3.2.y, 3.3.z, or 3.4.w releases==== | ====If using either 3.1.x, 3.2.y, 3.3.z, or 3.4.w releases==== | ||
As above, update to 3.5.1 by downloading it at [[https://github.com/cumulusmx/CumulusMX/releases/tag/b3072]]. | As above, update to 3.5.1 by downloading it at [[https://github.com/cumulusmx/CumulusMX/releases/tag/b3072 Mark's Github respository]]. The actual installation is done using the instructions above for simple next build upgrades. You can safely skip reading the intermediate release announcements, as there are no special one-off actions. | ||
When you are happy running 3.5.1, then you should continue to upgrade, initially follow instructions in next sub-section. | |||
====If using a 3.5.x release ==== | ====If using a 3.5.x release ==== | ||
| Line 241: | Line 286: | ||
*'''If you have your own customised web pages''', then there are changes to web tags that might lead to you needing to edit your web pages. | *'''If you have your own customised web pages''', then there are changes to web tags that might lead to you needing to edit your web pages. | ||
*'''If you use commas to separate integer and decimal parts of real numbers''', then various releases from 3.6.0 to 3.7.0 add "rc=y" to various web tags, that option will replace the decimal commas you use by decimal points that are required for some script languages (like the JavaScript used by HighCharts), and that makes it easier if you want to customise your web site. | *'''If you use commas to separate integer and decimal parts of real numbers''', then various releases from 3.6.0 to 3.7.0 add "rc=y" to various web tags, that option will replace the decimal commas you use by decimal points that are required for some script languages (like the JavaScript used by HighCharts), and that makes it easier if you want to customise your web site. | ||
When you are happy with running 3.7.0, then you should continue to upgrade, and the next sub-section describes what to do next. | |||
====if using a 3.7.y release ==== | ====if using a 3.7.y release ==== | ||
Only 3.7.0 was ever released, it introduced a lot of changes, so that is why staged upgrades recommend that this version is implemented and run | If you are using 3.7.0 (there were no other builds in 3.7.y series), then you should upgrade directly to version 3.9.6 - build 3101. | ||
Only 3.7.0 was ever released, it introduced a lot of changes, so that is why staged upgrades recommend that this version is implemented, and run for a while, before continuing to upgrade. | |||
Version 3.8.0 was a major release, as it introduced the ability to run Cumulus MX as a service. However, there were bugs in the builds in all 3.8.z versions, and in some 3.9.x versions, so that is why you need to skip through intermediate builds below 3101. | |||
'''IMPORTANT''' one-off actions needed: | |||
* There is a one-off change described in [https://cumulus.hosiene.co.uk/viewtopic.php?p=146957#p146957 v3.9.0 - b3095 release announcement] for those using RG-11 rain sensor. | |||
* There is a further on-off change described in [https://cumulus.hosiene.co.uk/viewtopic.php?p=147329#p147329 release announcement for Patch release 3.9.1 - b3096] for those who use '''Mono''' to enable the executables to run. | |||
When you are happy with running version 3.9.6 build 3101, you can continue to upgrade, and that will be covered in subsequent sub-sections (assuming someone is bothered to keep this article up to date). | |||
====if using either 3.8.x or 3.9.y release==== | ====if using either 3.8.x or 3.9.y release==== | ||
| Line 262: | Line 317: | ||
Contributors to this section are named in text. | Contributors to this section are named in text. | ||
Some people upgrade by just copying in the files that the release announcement says have changed, others copy in all files from the downloaded zip. The first should only be used with caution, files like '''CumulusMX.exe.config''' can change between versions, but not be mentioned in a release announcement, and the developer will have been making edits to files since the previous release, and might forget exactly which files have been edited between releases. Also you may be upgrading from an earlier version and therefore be skipping several intermediate releases. You may be able to see the dates when files were changed within the zip and therefore be able to decide for yourself if you compare those dates with the previous release you were using if you have kept the download for the version you were using. | Some people upgrade by just copying in the files that the release announcement says have changed, others copy in all files from the downloaded zip. The first should only be used with caution, files like '''CumulusMX.exe.config''' can change between versions, but not be mentioned in a release announcement, and the developer will have been making edits to files since the previous release, and might forget exactly which files have been edited between releases. Also you may be upgrading from an earlier version and therefore be skipping several intermediate releases. | ||
You may be able to see the dates when files were changed within the zip and therefore be able to decide for yourself if you compare those dates with the previous release you were using if you have kept the download for the version you were using. However, do not assume that only files with later date are needed; in some releases the new build regresses one or more files and so a file with an older date is the correct one to retain. | |||
===The rename old approach=== | ===The rename old approach=== | ||
#The popular approach recommended by many forum contributors in many different posts (including at [https://cumulus.hosiene.co.uk/viewtopic.php?p=141763#p141763 this post by Mark Crossley for example] is to rename your current install directory, then unzip the new release, letting it create a new '''CumulusMX''' folder (or whatever name you prefer and specify in unzip options). | #The popular approach, recommended by many forum contributors, in many different posts (including at [https://cumulus.hosiene.co.uk/viewtopic.php?p=141763#p141763 this post by Mark Crossley for example] is to rename your current install directory, then unzip the new release, letting it create a new '''CumulusMX''' folder (or whatever name you prefer and specify in unzip options). | ||
#However, you will find that this option is not being recommended any more, because it relies on you knowing which files (see | #However, you will find that this option is not being recommended any more, because it relies on you knowing which files (see next 2 points) you need to copy back. | ||
#Copy across '''Cumulus.ini''' and (if you use it) '''string.ini''' into that new directory, and then copy the contents of the '''data''' and '''Reports''' directories from your ''current install'' to the new install. | #Copy across '''Cumulus.ini''' and (if you use it) '''string.ini''' into that new directory, and then copy the contents of the '''data''' and '''Reports''' directories from your ''current install'' to the new install. | ||
#Don't forget to copy any other set-up files across too. | #Don't forget to copy any other set-up files across too. | ||
| Line 278: | Line 335: | ||
===The overwrite approach=== | ===The overwrite approach=== | ||
#* if you have a lot of set-up files, or other custom files, (i.e. files not part of release), | The general advice is that if you want custom pages for the administrative interface, or custom templates to process to produce your web pages, then these custom files should be given different names (and ideally be placed in different folders) to the standard files included in the release distributions. If you follow this advice, the approach described in this sub-section is the best for you, if you don't follow this advice, see later section on dealing with customised files. | ||
#*if you are downloading on a different | |||
# | #* if you have a lot of set-up files, or other custom files, (i.e. files with names that are not part of release), these won't be overwritten by files in the release distribution, but you do want to keep them; | ||
#''' | #*or if you are downloading on a different computer, or on a different disc, to where you are running MX, it is easiest to keep your MX installation in the same place | ||
#*The updated files can be tracked by their modification date, | #Note the forum administrator, David, [https://cumulus.hosiene.co.uk/viewtopic.php?p=140355#p140355 (see this post)] recommends this particular approach. | ||
#*In general, especially if updating a major release, it is best to overwrite with all files in zip, whether they are listed as changed or not. This ensures you have a consistent set of files. | #After downloading a new release unzip it on the device/disc where you down load it. Next stop your existing Cumulus MX software and take a backup of your existing installation. After that, simply copy the files (optionally only those that have newer dates because they have changed) into the existing MX directory on the device where you run MX. Then you know all your existing files are there, and your MX can be run as before. | ||
#The great advantage of this approach, and the reason that it is widely recommended as best, is that you can't lose any data or configuration files (i.e. files that are not part of the release distribution). | |||
#Provided you did the backup, '''the only problem with this approach is that in some releases files are removed from the distribution''', yet unless you check carefully, this approach may ''leave files that are no longer required'' in your installation, and it is just possible you might continue to use the obsolete file instead of the intended alternative. Such a non-standard installation is difficult for others to support. So do check through file by file to ensure you only have files in the distribution you have just installed, not any from earlier distributions. The only files that you still want (that are not in distribution) will be those that either configure your system or contain your data in log files. | |||
#*The updated files can be tracked by their modification date, some will be specified in the release notes (find them on [https://cumulus.hosiene.co.uk/viewtopic.php?f=40&t=17887 this forum]). There is a list indicating what files vary in [[Cumulus_MX_formal_release_versions|this Wiki article]]. | |||
#*In general, especially if updating a major release, it is best to overwrite with all files in zip, whether they are listed as changed or not. This ensures you have a consistent set of files, and avoids any issues when the developer does not correctly list all the files that have changed, or a file might be regressed to an earlier version and not have a newer date than the file in your previous installation. | |||
====Example downloading on PC and installing on pi ==== | ====Example: downloading on PC and installing on pi ==== | ||
#On your pc: Download zip either from [[Software]] for latest version or from https://github.com/cumulusmx/CumulusMX/releases for earlier versions. | #On your pc: Download zip either from [[Software]] for latest version or from https://github.com/cumulusmx/CumulusMX/releases for earlier versions. | ||
#On your pc: Use Filezilla (or similar file transfer program, or it might even be a copy over network depending on way set up) to transfer zip to pi e.g. <tt>FileZilla CumulusMXDist3089.zip to /home/pi</tt> | #On your pc: Use Filezilla (or similar file transfer program, or it might even be a copy over network depending on way set up) to transfer zip to pi (e.g. <tt>FileZilla CumulusMXDist3089.zip to /home/pi</tt>), but remember you might want to install to a different location (perhaps on an external USB drive, or SSD) | ||
#Control C on pi to stop MX | #Control C on pi to stop MX | ||
#On pi go to directory where zip now is | #On pi go to directory where zip now is, for example it might be <tt>cd /home/pi</tt> | ||
# Unzip the installation over your existing installation <tt>unzip -o CumulusMXDist3089.zip</tt> | # Unzip the installation over your existing installation, by running on your Raspberry Pi this instruction: <tt>unzip -o CumulusMXDist3089.zip</tt> | ||
# Restart MX | # Restart MX | ||
# Remove any files that were needed by earlier releases but release announcement says are not needed by the release you are installing | # Remove any files that were needed by earlier releases but release announcement says are not needed by the release you are installing | ||
===The customised approach=== | |||
If you edit a file that is included in the release distribution, you should give it a different name (e.g. I have placed an underline in front of original file name for some of the files I edited in the admin interface), and/or place it in a different folder (e.g. I place all the cumulus templates I have created in a folder called '''cumulus_Templates'''). If you follow this advice, then you won't lose your files by following the advice above, regardless of whether you overwrite or not. | |||
If you won't listen to best practice advice, and have decided to for example modify the provided Cumulus web templates without allocating new names, then installing the whole release distribution will overwrite your edited file(s) with the standard file content provided by the developer. Therefore you need to do a customised approach where you select which files from the distribution to copy into your installation. If you have changed one or more web templates, you might think it safe just to omit the relevant files in the zip within folder '''web''', but some builds change the files in the '''webfiles''' folder too, and you need to retain consistency. | |||
==== Updating when files within release might overwrite your own edits ==== | |||
To further explain the customised approach, here are some more examples. | |||
===== web site files ===== | |||
If you have edited any files that sit on your '''web site''', then these can remain on your web site. However, if those web pages are generated from templates that you expect MX to process and upload for you, you do need to take special action. Maybe you edited a template to give the look you desire, or the content you want (e.g. adding rain this month to this month page, or combining this month and this year page). | |||
The first step is to see if the release notice says that file has been revised, if it has not then it is easy to keep your edited file by not copying in the replacement file from within the zip. If the release revises any file you previously edited, take a backup of your edited file, before you copy the new file into your folder. You can then use a file comparing tool to see what has changed in the release and what you changed and hopefully manage to merge to a new file that keeps any functionality change in a new release and keeps your customisation. Do think about changing name of the template file, or placing it in a different folder, and using the '''Extra Files''' settings. That will make it easier for you next time you do an upgrade to a new MX build. | |||
If you have done major customisation to the standard website then you probably have followed the guidance and stored your new web page templates in a different directory and you use '''Extra Files''' to specify where they are, so they cannot be overwritten, and the new MX will still find them. It might be that new web tags have been added since whatever build you were running before, and that you decide to edit your customised template file, but that can be done any time after you install the new MX build. | |||
===== admin interface files ===== | |||
If you have done any customisation to the '''interface''' (perhaps you don't like seeing solar in the tables when you don't measure that) then again you can skip over these files when copying. Hopefully you will have copies of the files that you have customised of the ''interface folder'' so you have ability to copy them back into installation if you do overwrite with the release version. | |||
'''You do have to be careful''', as many releases change the interface in some way, even if the change is not in the file you have customised, it might be in an asociated file, and all the various components of the interface have to work together as a coherent unit. For instance when feels like was added to MX, the api used for sending data from the MX engine to the admin interface was updated. In some releases, a new web page is added to the admin interface, with the consequence that all the navigation menus were adjusted in all web pages. Any HTML page in the admin interface may be edited to refer to a different styling page (so it, and the .css file, must be updated together) or to a different script (so the .HTML, and the .js file, must be updated together). The settings pages in the admin interface are dependent on the correct pair of json files to define the options or values that appear on that web page, so again all must be consistent. | |||
To sum up, admin interface files are interdependent, and you cannot always update some, but not all, of the admin interface pages. | |||
Be prepared to go back to the standard file for whatever you customised if something it depends upon has changed, after all you must not lose any vital functionality. | |||
On my site, my own versions of interface files have a "_" (underline character) added to the start of the standard MX file name. This applies to both HTML pages, and JavaScript files that I have edited. I edit the menu items within my edited pages so those all go to my versions where I have a HTML customised page, leaving unchanged the menu items that can still go to a standard MX web page where I don't have my own version of the .HTML page. This makes it easy for me to navigate between my pages, as all of them link to my other pages. If I am on a standard MX page and want to go to one of my customised pages, I select the equivalent standard page, then edit the URL to add the underline and get easily to my page. This naming means I can always use a standard page instead of my customised page when I need to, and I never miss out on any new features. | |||
== After an update if you use the standard web template files == | == After an update if you use the standard web template files == | ||
| Line 317: | Line 408: | ||
**'''jquery''' - this folder is needed for "trends,htm" to work, but it has not been updated since 2014. Both the files included are obsolete packages, no longer officially available, and there are no plans to replace them. | **'''jquery''' - this folder is needed for "trends,htm" to work, but it has not been updated since 2014. Both the files included are obsolete packages, no longer officially available, and there are no plans to replace them. | ||
**'''steelseries''' - this folder has 3 sub-folders, and I can only think of 2 MX releases when anything was changed here, and I don't anticipate any further changes. | **'''steelseries''' - this folder has 3 sub-folders, and I can only think of 2 MX releases when anything was changed here, and I don't anticipate any further changes. | ||
== After update - checking for bugs in MX or mistakes in your installation == | == After update - checking for bugs in MX or mistakes in your installation == | ||
| Line 343: | Line 417: | ||
== Updating if you use a virus Checker == | == Updating if you use a virus Checker == | ||
You may find that virus checkers such as Windows Defender reject your new version of MX. They need to be told it is safe. | You may find that virus checkers such as Windows Defender reject your new version of MX. They need to be told it is safe. | ||
