mirror of
https://github.com/weewx/weewx.git
synced 2026-04-19 09:06:58 -04:00
4e7fee3e55
Constants "albedo", "cn", and "cd" were formerly hardwired into the code that calculates ET. They can now be specified in the configuration file. ET was formerly calculated in XTypes class WXXTypes, but now has its own class ETXType. Certain parameters were removed from WXXTypes and moved to ETXType. Resolves issue #730.
2037 lines
87 KiB
HTML
2037 lines
87 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<title>weewx: Upgrade Guide</title>
|
|
<meta charset="UTF-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
|
|
<link rel="icon" href="images/favicon.png" type="image/png"/>
|
|
<link rel="stylesheet" href="css/tocbot-4.12.0.css">
|
|
<link rel="stylesheet" href="css/weewx_ui.css"/>
|
|
<script src="js/cash.min.js"></script>
|
|
<script src="js/tocbot-4.12.0.min.js"></script>
|
|
<script src="js/weewx.js"></script>
|
|
<script>
|
|
$(function () {
|
|
make_ids('#technical_content');
|
|
let level = get_level_from_cookie();
|
|
create_toc_level_control(level);
|
|
create_toc(level);
|
|
})
|
|
</script>
|
|
<style>
|
|
#toc_parent {
|
|
overflow-y: hidden;
|
|
}
|
|
|
|
#legend {
|
|
padding-top: 30px;
|
|
}
|
|
|
|
#legend p {
|
|
font-size: 80%;
|
|
border: 1px solid #888888;
|
|
padding-left: 5px;
|
|
padding-right: 5px;
|
|
margin-left: 20px;
|
|
margin-right: 20px;
|
|
margin-bottom: 1px;
|
|
}
|
|
|
|
.removed {
|
|
background: #ffdddd;
|
|
}
|
|
|
|
.changed {
|
|
background: #ffe0b0;
|
|
}
|
|
|
|
.added {
|
|
background: #ccffcc;
|
|
}
|
|
</style>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="sidebar">
|
|
<div class="doclist">
|
|
<a href="usersguide.htm">User's Guide</a><br/> <a href="customizing.htm">Customization Guide</a><br/> <a
|
|
href="hardware.htm">Hardware Guide</a><br/> <a href="utilities.htm">Utilities Guide</a><br/> <a
|
|
href="upgrading.htm">Upgrade Guide</a><br/> <a href="devnotes.htm">Notes for Developers</a>
|
|
</div>
|
|
<div id="toc_controls">
|
|
<!-- The TOC select list will be injected here -->
|
|
</div>
|
|
<div id="toc_parent">
|
|
<div id="toc-location" class="toc">
|
|
<!-- The table of contents will be injected here -->
|
|
</div>
|
|
</div>
|
|
<div id='legend'>
|
|
<p class='removed'>removed</p>
|
|
<p class='changed' style='text-align: center'>changed</p>
|
|
<p class='added' style='text-align: right'>added</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="main">
|
|
|
|
<div class="header">
|
|
<div class="logoref">
|
|
<a href='https://weewx.com'> <img src='images/logo-weewx.png' class='logo' style="float:right"
|
|
alt="weewx logo"/> </a><br/> <span class='version'>
|
|
Version: 4.9
|
|
</span>
|
|
</div>
|
|
<div class="title">WeeWX Upgrade Guide</div>
|
|
</div>
|
|
|
|
<div id="technical_content" class="content">
|
|
|
|
<p>This document explains the three methods of upgrading:</p>
|
|
<ul>
|
|
<li><a href="#Upgrading_using_setup.py">Upgrading using <span class='code'>setup.py</span></a></li>
|
|
<li><a href="#Upgrading_using_DEB_package">Upgrading using DEB package</a></li>
|
|
<li><a href="#Upgrading_using_RPM_package">Upgrading using RPM package</a></li>
|
|
</ul>
|
|
<p>The section <em><a href="#Instructions_for_specific_versions">Instructions for Specific Versions</a></em>
|
|
describes changes required from one version to the next. These changes apply to every upgrade method.
|
|
</p>
|
|
|
|
<p class="warning"><strong>Warning!</strong><br/> You must use the same upgrade technique as your initial
|
|
install! For example, if you used <span class="code">setup.py</span> to install WeeWX, then you should use
|
|
<span class="code">setup.py</span> to upgrade. If you used a DEB or RPM package to install, then you should
|
|
upgrade using the same package type.
|
|
</p>
|
|
|
|
<h1><a id="Upgrading_using_setup.py">Upgrading using <span class='code'>setup.py</span></a></h1>
|
|
|
|
<p>Before upgrading WeeWX, check the section <em> <a href="#Instructions_for_specific_versions">Instructions for
|
|
Specific Versions</a></em> to see if any specific actions are required.</p>
|
|
|
|
<p>If you are an old Python 2 version, and you plan on switching to Python 3, make sure you have installed
|
|
whatever pre-requisites are required. You can find them in the guide
|
|
<a href="setup.htm"><em>Installation using setup.py</em></a>.
|
|
</p>
|
|
|
|
<p>
|
|
Then follow the standard installation procedure:
|
|
</p>
|
|
<p>Unpack the archive:</p>
|
|
<pre class="tty cmd">tar xvfz weewx-X.Y.Z.tar.gz</pre>
|
|
<p>Change directory into it:</p>
|
|
<pre class="tty cmd">cd weewx-X.Y.Z </pre>
|
|
<p>Build the distribution, using whatever version of Python you plan to use. For example, for Python 3:</p>
|
|
<pre class="tty cmd">python3 ./setup.py build </pre>
|
|
|
|
<p class='warning'><strong>Warning!</strong><br/> Before doing the next step, be sure that <span class="code">home</span>
|
|
in the file <span class="code">setup.cfg</span> is set to the location of the previous WeeWX installation.
|
|
</p>
|
|
|
|
<p>
|
|
After checking <span class='code'>setup.cfg</span>, install your new version of WeeWX, again using
|
|
the version of Python you plan on using:
|
|
</p>
|
|
|
|
<pre class="tty cmd">sudo python3 ./setup.py install </pre>
|
|
|
|
<p>The install process will do the following:</p>
|
|
<ul>
|
|
<li>Install the new version in the <span class="code">bin</span> directory, while preserving any user
|
|
extensions in the <span class="code">bin/user</span> directory
|
|
</li>
|
|
<li>Save a copy of the old <span class="code">weewx.conf</span> as
|
|
<span class='code'>weewx.conf.YYYYMMDDHHMMSS</span>
|
|
</li>
|
|
<li>Update your copy of <span class="code">weewx.conf</span>, reflecting any changes required by the latest
|
|
version of WeeWX. This updated version is then installed.
|
|
</li>
|
|
<li>Install a <span class="code">skins</span> directory if one does not already exist.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Finally, restart WeeWX.</p>
|
|
|
|
<h1><a id="Upgrading_using_DEB_package">Upgrading using DEB package</a></h1>
|
|
|
|
<p>If you have specified the WeeWX apt repository in <span
|
|
class="code">/etc/apt/sources.list.d/weewx.list</span>, then upgrade to the latest version like this:
|
|
</p>
|
|
|
|
<pre class='tty cmd'>sudo apt-get update
|
|
sudo apt-get install weewx</pre>
|
|
|
|
<p>Otherwise, download the latest X.Y.Z DEB package from the <a href="https://weewx.com/downloads/">Download
|
|
page</a> on weewx.com, then upgrade like this:
|
|
</p>
|
|
|
|
<pre class='tty cmd'>sudo dpkg -i weewx_X.Y.Z-R.deb</pre>
|
|
|
|
<p>The upgrade process will not modify the WeeWX databases.</p>
|
|
|
|
<p>Unmodified files will be upgraded. If modifications have been made to the WeeWX configuration, you will be
|
|
prompted as to whether you want to keep the existing configuration or accept the new configuration. Either
|
|
way, a copy of the option you did not choose will be saved.
|
|
</p>
|
|
|
|
<p>For example, if <span class='code'>/etc/weewx/weewx.conf</span> was modified, you will see a message
|
|
something like this:
|
|
</p>
|
|
|
|
<pre class='tty'>Configuration file `/etc/weewx/weewx.conf'
|
|
==> Modified (by you or by a script) since installation.
|
|
==> Package distributor has shipped an updated version.
|
|
What would you like to do about it ? Your options are:
|
|
Y or I : install the package maintainer's version
|
|
N or O : keep your currently-installed version
|
|
D : show the differences between the versions
|
|
Z : start a shell to examine the situation
|
|
The default action is to keep your current version.
|
|
*** weewx.conf (Y/I/N/O/D/Z) [default=N] ?</pre>
|
|
|
|
<p>
|
|
Choosing <span class="code">Y</span> or <span class='code'>I</span> (install the new version) will place
|
|
your old configuration in <span class='code'>/etc/weewx/weewx.conf.dpkg-old</span>, where it can be compared
|
|
with the new version in <span class='code'>/etc/weewx/weewx.conf</span>.
|
|
</p>
|
|
|
|
<p>
|
|
Choosing <span class="code">N</span> or <span class='code'>O</span> (keep the current version) will place
|
|
the new configuration in <span class='code'>/etc/weewx/weewx.conf.X.Y.Z</span>, where <span class="code">X.Y.Z</span>
|
|
is the new version number. It can then be compared with your old version which will be in <span
|
|
class='code'>/etc/weewx/weewx.conf</span>.
|
|
</p>
|
|
|
|
<p class="note">
|
|
The vast majority of the time you will want to choose <span class="code">N</span> (the default).
|
|
</p>
|
|
|
|
<h1><a id="Upgrading_using_RPM_package">Upgrading using RPM package</a></h1>
|
|
|
|
<p>If you have specified the WeeWX yum repository in <span
|
|
class="code">/etc/yum.repos.d/weewx.repo</span>, then upgrade to the latest version like this:
|
|
</p>
|
|
|
|
<pre class='tty cmd'>sudo yum update weewx</pre>
|
|
|
|
<p>Otherwise, download the latest X.Y.Z RPM package from the <a href="https://weewx.com/downloads/">Download
|
|
page</a> on weewx.com, then upgrade like this:
|
|
</p>
|
|
|
|
<pre class='tty cmd'>sudo rpm -U weewx-X.Y.Z-R.rpm</pre>
|
|
|
|
<p>The upgrade process will not modify the WeeWX databases.</p>
|
|
|
|
<p>Unmodified files will be upgraded. If modifications have been made to the configuration, <span class='code'>rpm</span>
|
|
will display a message about any differences between the changes and the new configuration. Any new changes
|
|
from the upgrade will be noted as files with a <span class='code'>.rpmnew</span> extension and the modified
|
|
files will be left untouched.
|
|
</p>
|
|
|
|
<p>For example, if <span class='code'>/etc/weewx/weewx.conf</span> was modified, <span class='code'>rpm</span>
|
|
will present a message something like this:
|
|
</p>
|
|
|
|
<pre class='tty'>warning: /etc/weewx/weewx.conf created as /etc/weewx/weewx.conf.rpmnew</pre>
|
|
|
|
<h1>Upgrading the WeeWX configuration file</h1>
|
|
|
|
<p>
|
|
It does not happen very often, but occasionally a new release will <em>require</em> changes to the WeeWX configuration file. When this happens, the installer, whether it is <span class="code">setup.py</span>, or a package installer, takes care of upgrading the file and you do not need to worry about it.
|
|
</p>
|
|
<p>
|
|
However, there are some occasions when you may need to upgrade the file yourself. In particular, this happens when you run several instances of <span class="code">weewxd</span> on the same machine, each with its own configuration file. The configuration file named <span class="code">weewx.conf</span> will get upgraded, but what about the others?
|
|
</p>
|
|
<p>
|
|
Use <span class="code">wee_config</span> to upgrade each configuration file. See the section on <a href="utilities.htm#wee_config_utility_upgrade"><span class="code">wee_config --upgrade</span></a> in the Utilities Guide for how to do this.
|
|
</p>
|
|
|
|
|
|
<h1><a id="Instructions_for_specific_versions">Instructions for specific versions</a></h1>
|
|
|
|
<h2>Upgrading to V4.9</h2>
|
|
<h3><span class="code">wee_reports</span> may require <span class="code">--epoch</span> option.</h3>
|
|
<p>
|
|
In previous versions, the utility <span class="code">wee_reports</span> could take an optional
|
|
position argument that specified the reporting time in unix epoch time. For example,
|
|
</p>
|
|
<pre class="tty cmd">wee_reports /home/weewx/weewx.conf 1645131600</pre>
|
|
<p>
|
|
would specify that the reporting time should be 1645131600, or 17-Feb-2022 13:00 PST.
|
|
</p>
|
|
<p>
|
|
Starting with V4.9, the unix epoch time must be specified using the <span class="code">--epoch</span>
|
|
flag, so the command becomes
|
|
</p>
|
|
<pre class="tty cmd">wee_reports /home/weewx/weewx.conf --epoch=1645131600</pre>
|
|
<p>
|
|
Alternatively, the reporting time can be specified by using <span class="code">--date</span> and
|
|
<span class="code">--time</span> flags:
|
|
</p>
|
|
<pre class="tty cmd">wee_reports /home/weewx/weewx.conf --date=2022-02-17 --time=13:00</pre>
|
|
|
|
<h3>Init function of class <span class="code">WXXTypes</span> has changed</h3>
|
|
<p>
|
|
In earlier versions, ET was calculated in class <span class="code">WXXTypes</span>. Now it has its own
|
|
class, <span class="code">ETXType</span>. As a result, some initialization parameters are no longer needed
|
|
and have been removed.
|
|
</p>
|
|
<p>
|
|
Note also that the parameter <span class="code">heat_index_algo</span> was changed to
|
|
<span class="code">heatindex_algo</span> in keeping with the rest of the code.
|
|
</p>
|
|
<p>
|
|
Unless you have been writing specialized code that required direct access to <span
|
|
class="code">WXXTypes</span> you are very unlikely to be affected.
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>V4.8 and earlier</td>
|
|
<td>4.9</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>
|
|
def __init__(self, altitude_vt, latitude_f, longitude_f,
|
|
<span class="removed">et_period=3600,</span>
|
|
atc=0.8,
|
|
nfac=2,
|
|
<span class="removed">wind_height=2.0,</span>
|
|
force_null=True,
|
|
maxSolarRad_algo='rs',
|
|
<span class="changed">heat_index_algo</span>='new')
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>
|
|
def __init__(self, altitude_vt, latitude_f, longitude_f,
|
|
atc=0.8,
|
|
nfac=2,
|
|
force_null=True,
|
|
maxSolarRad_algo='rs',
|
|
<span class="changed">heatindex_algo</span>='new')
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h2>Upgrading to V4.6</h2>
|
|
<h3>Ordering of search list changed</h3>
|
|
<p>
|
|
In previous versions, user-supplied search list extensions were <em>appended</em> to the search list.
|
|
Starting with V4.6, they are now <em>prepended</em> to the list. This means that when Cheetah is evaluating
|
|
the list, looking for a tag, it will encounter user-supplied extensions first, allowing extensions to
|
|
override the built-in tags and change their behavior.
|
|
</p>
|
|
<h3>Tag <span class="code">$alltime</span></h3>
|
|
<p>
|
|
The tag <span class="code">$alltime</span>, formerly included as an example, is now a part of the core of
|
|
WeeWX. This means you may no longer need to include the "stats" example as a Cheetah search list extension,
|
|
although leaving it in will do no harm.
|
|
</p>
|
|
|
|
<h3>API changes</h3>
|
|
<h4>Elapsed time calls may have to be changed</h4>
|
|
<p>
|
|
If you use group <span class="code">group_deltatime</span> to display elapsed time, you may have to change
|
|
the call. For example,
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>V4.5 and earlier</td>
|
|
<td>4.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>
|
|
# Create an elapsed time of 1655 seconds
|
|
vt = ValueTuple(1655, 'second', 'group_deltatime')
|
|
vh = ValueHelper(vt,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter)
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>
|
|
# Create an elapsed time of 1655 seconds
|
|
vt = ValueTuple(1655, 'second', 'group_deltatime')
|
|
vh = ValueHelper(vt,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter,
|
|
<span class="added">context='short_delta'</span>)
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
In summary, you will need to indicate the "context". There are two choices, <span class="code">short_delta</span>
|
|
for elapsed times less than a day, and <span class="code">long_delta</span> for time spans more than
|
|
a day.
|
|
</p>
|
|
|
|
<h2>Upgrading to V4.5</h2>
|
|
<p>
|
|
Version 4.5 changes are unlikely to affect anyone, except extension writers who are deep in the internals of
|
|
WeeWX.
|
|
</p>
|
|
|
|
<h3>API changes</h3>
|
|
<p>
|
|
There have been a number of changes in the WeeWX API. None of them are likely to affect end users. Overall,
|
|
the biggest change is that the data held internally in class <span class="code">ValueHelper</span> is now
|
|
held in the target unit system, rather than being converted at time of use.
|
|
</p>
|
|
|
|
<h4>Defaults for <span class="code">ValueHelper</span> have changed</h4>
|
|
<p>
|
|
Before, when constructing a new <span class="code">ValueHelper</span>, if no converter was included in the
|
|
constructor, a default converter, which converts to US Units, was supplied. Now, if no converter is included
|
|
in the constructor, no default converter at all is supplied, and the data remain in the original units. This
|
|
is unlikely to affect most extension writers because the usual case is to supply a converter to the <span
|
|
class="code">ValueHelper</span> constructor.
|
|
</p>
|
|
|
|
<h4>Function <span class="code">as_value_tuple()</span> may raise <span class="code">KeyError</span></h4>
|
|
<p>
|
|
Previously, if the function <span class="code">as_value_tuple()</span> was asked to return a
|
|
<span class="code">ValueTuple</span> of a non-existent type, it returned a <span class="code">ValueTuple</span>
|
|
with values <span class="code">(None, None, None)</span>. Now it raises a <span class="code">KeyError</span>
|
|
exception.
|
|
</p>
|
|
|
|
<h2>Upgrading to V4.4</h2>
|
|
|
|
<h3>Auto patch of daily summaries</h3>
|
|
|
|
<p>
|
|
The V4.2 daily summary patch inadvertently introduced a bug which caused the <span class="code">wind</span>
|
|
daily summary to be incorrectly weighted. See issue <a href="https://github.com/weewx/weewx/issues/642">#642</a>.
|
|
V4.4 includes a patch to automatically fix the defective daily summary. It is run only once on the first use
|
|
of a database (usually by <span class="code">weewxd</span>) and takes only a few seconds.
|
|
</p>
|
|
|
|
<h2>Upgrading to V4.3</h2>
|
|
|
|
<h3>Auto patch of daily summaries</h3>
|
|
|
|
<p>
|
|
Version 4.2 inadvertently introduced a bug, which prevented the sums that are kept in the daily summaries
|
|
from being weighted by the archive interval. See issue <a href="https://github.com/weewx/weewx/issues/623">#623</a>.
|
|
V4.3 includes a patch, which will fix any defective daily summaries automatically. It is run only once
|
|
on the first use of a database (usually by <span class="code">weewxd</span>) and takes only a few
|
|
seconds.
|
|
</p>
|
|
|
|
<h3>Option <span class="code">ignore_zero_wind</span> has been renamed and moved</h3>
|
|
|
|
<p>
|
|
Normally, WeeWX sets wind direction to undefined when wind speed is zero. While it was never documented,
|
|
some users used option <span class="code">ignore_zero_wind</span> to prevent this: if set to <span
|
|
class="code">False</span>, wind direction will not be set to undefined when wind speed is zero. However, the
|
|
option's location and name has changed. It is now called <span class="code">force_null</span>, and it is
|
|
now located under <span class="code">[StdWXCalculate] / [[WXXTypes]] / [[[windDir]]]</span>. The old name
|
|
and location has been deprecated, but still honored.
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>V4.2 and earlier</td>
|
|
<td>4.3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>
|
|
[StdWXCalculate]
|
|
<span class="removed">ignore_zero_wind = False</span>
|
|
[[Calculations]]
|
|
...
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>
|
|
[StdWXCalculate]
|
|
[[Calculations]]
|
|
...
|
|
[[WXXTypes]]
|
|
[[[windDir]]]
|
|
<span class="added">force_null = False</span>
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Option <span class="code">log_failure</span> set to <span class="code">True</span></h3>
|
|
<p>
|
|
The option <span class="code">log_failure</span> under <span class="code">[StdReport]</span> controls
|
|
whether to log failures into the system log. It was previously set to <span class="code">False</span>.
|
|
The upgrade process will set it to <span class="code">True</span>, so that users can better see failure
|
|
modes.
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>V4.2 and earlier</td>
|
|
<td>4.3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>
|
|
[StdReport]
|
|
...
|
|
<span class="changed">log_failure = False</span>
|
|
...
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>
|
|
[StdReport]
|
|
...
|
|
<span class="changed">log_failure = True</span>
|
|
...
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Upgrading to V4.2</h2>
|
|
|
|
<p>
|
|
For the most part, V4.2 is backwards compatible with previous versions. There is one small exception.
|
|
</p>
|
|
|
|
<h3>Type <span class="code">beaufort</span> deprecated</h3>
|
|
<p>
|
|
The type <span class="code">beaufort</span> has been deprecated, although there are no immediate plans
|
|
to remove it — using it will put a warning in the log. Instead, it has become a new unit, which can be
|
|
used as part of <span class="code">group_speed</span>. Here's an example:
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>V4.1 and earlier</td>
|
|
<td>4.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'><p>
|
|
The current wind speed is $current.windSpeed,
|
|
which is <span class="changed">$current.beaufort</span> on the beaufort scale.
|
|
</p>
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'><p>
|
|
The current wind speed is $current.windSpeed,
|
|
which is <span class="changed">$current.windSpeed.beaufort</span> on the beaufort scale.
|
|
</p>
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Upgrading to V4.0</h2>
|
|
|
|
<p>
|
|
For the most part, V4.0 is backwards compatible with previous versions.
|
|
</p>
|
|
<h3>Python 2.5 and 2.6</h3>
|
|
<p>
|
|
Support for Python 2.5 and 2.6 has been dropped. It has now been well over 10 years since these versions
|
|
were introduced, and 6+ years since they were supported by the Python Software Foundation. If you are
|
|
using Python 2.5 or 2.6, then you should either upgrade your copy of Python, or stay with your old
|
|
version of WeeWX.
|
|
</p>
|
|
<h3><span class="code">[StdWXCalculate]</span></h3>
|
|
<p>
|
|
In earlier versions of WeeWX, many derived types were calculated by default by the service <span
|
|
class="code">StdWXCalculate</span>. By contrast, in WeeWX V4, no derived types are calculated by default
|
|
— all desired types must be explicitly listed in <span class="code">weewx.conf</span>. For most users,
|
|
this will not cause a problem because most types were already listed in <span class="code">weewx.conf</span>.
|
|
However if you deleted one of the following types in the clause <span class="code">[StdWXCalculate]</span>,
|
|
and started to depend on the default calculations, then the type will no longer be calculated in V4.
|
|
</p>
|
|
<table class="tty" style="width:50%">
|
|
<tr>
|
|
<td>pressure</td>
|
|
<td>barometer</td>
|
|
<td>altimeter</td>
|
|
</tr>
|
|
<tr>
|
|
<td>windchill</td>
|
|
<td>heatindex</td>
|
|
<td>dewpoint</td>
|
|
</tr>
|
|
<tr>
|
|
<td>inDewpoint</td>
|
|
<td>rainRate</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
In this case, you should add the type to <span class="code">[StdWXCalculate]</span>. For example, if for
|
|
some reason you deleted <span class="code">dewpoint</span>, then you would need to add the following
|
|
</p>
|
|
<pre class="tty" style="width:50%">
|
|
[StdWXCalculate]
|
|
[[Calculations]]
|
|
...
|
|
<span class="highlight">dewpoint = prefer_hardware</span>
|
|
</pre>
|
|
|
|
<h2>Upgrading to V3.9</h2>
|
|
|
|
<h3>New skins</h3>
|
|
<p>
|
|
Version 3.9 introduces and installs a new skin, <em>Seasons</em>, and promotes two old skins,
|
|
<em>Mobile</em> and <em>Smartphone</em>, previously part of <em>Standard</em>, to first-class,
|
|
independent, skins.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
If you are installing fresh (not an upgrade), then all four skins, <em>Seasons</em>, <em>Standard</em>,
|
|
<em>Mobile</em>, and <em>Smartphone</em> will be installed, but only <em>Seasons</em> will be activated.
|
|
</li>
|
|
<li>
|
|
If you are upgrading, then the three new skins, <em>Seasons</em>, <em>Mobile</em>, and
|
|
<em>Smartphone</em> will be installed, but none will be activated. Your existing <em>Standard</em> will
|
|
be left untouched and activated. For most people, your website will continue to look as expected (the
|
|
exception is explained below in section
|
|
<a href="#v39_effects"><em>Do you need to change anything?</em></a>).
|
|
</li>
|
|
</ul>
|
|
|
|
<p class="note">
|
|
If you are upgrading, and you wish to try the new skin <em>Seasons</em>, then activate it, but <em>be sure
|
|
to deactivate Standard</em>. Otherwise, both will get generated, and they will compete with each other for
|
|
placement in your HTML directory.
|
|
</p>
|
|
|
|
<h3>Skin defaults</h3>
|
|
<p>
|
|
Version 3.9 introduces a new section, <span class="code">[StdReport]/[[Defaults]]</span> in <span
|
|
class="code">weewx.conf</span>. Options in this section apply to <em>all</em> reports. For example, if you
|
|
set a unit group here, it will be applied everywhere. This makes it easy to set the units across all
|
|
reports, or to ensure that the labels for observations are the same in every report.
|
|
</p>
|
|
<p>
|
|
It also adds a file <span class="code">defaults.py</span>, in which the fallback values for every report
|
|
parameter are specified. Although the defaults file is currently useful only to developers, in
|
|
the future it may be extended to facilitate translations and localization.
|
|
</p>
|
|
|
|
<h3 id="v39_effects">Do you need to change anything?</h3>
|
|
<p>
|
|
The introduction of the new section, <span class="code">[StdReport]/[[Defaults]]</span> in <span
|
|
class="code">weewx.conf</span>, can change which units are applied to reports because it has a higher
|
|
precedence than what is in <span class="code">skin.conf</span>. See the section <a
|
|
href="customizing.htm#How_options_work"><em>How options work</em></a> for details of the ordering
|
|
in which an option is considered.
|
|
</p>
|
|
|
|
<p>
|
|
Most users will be unaffected by these changes because they depend on specific report overrides. There is,
|
|
however, one exception:
|
|
</p>
|
|
|
|
<p class="note">
|
|
If your installation does not use overrides, and you changed to metric units in your <span class="code">skin.conf</span>
|
|
file, you will be affected.
|
|
</p>
|
|
<p>
|
|
Your reports will start appearing in U.S. Customary units. The reason is that the new section, <span
|
|
class="code">[StdReport]/[[Defaults]]</span> has higher priority than options in <span class="code">skin.conf</span>,
|
|
and thus will start asserting themselves.
|
|
</p>
|
|
<p>
|
|
The fix is simple: modify the <span class="code">[StdReport]/[[Defaults]]</span> to suit your preferences.
|
|
</p>
|
|
|
|
<p>
|
|
However, users who specified what unit system to use as part of the automated install using a
|
|
package installer or <span class="code">setup.py</span>, will have an override section, and therefore
|
|
will be unaffected. This is because the override section has the highest priority.
|
|
</p>
|
|
|
|
<h2>Upgrading to V3.7</h2>
|
|
|
|
|
|
<h3 id="change_to_daily_summaries">Changes to daily summaries</h3>
|
|
<p>Perhaps the most significant change in V3.7 is a fix for how daily summary values are calculated and stored.
|
|
</p>
|
|
|
|
<p>Daily summaries were introduced in V3.0 (December, 2014), to speed up certain kinds of aggregation
|
|
calculations. They were designed to "weight" values depending on the time length of the archive record that
|
|
contributed them. For example, shorter intervals contributed less than longer intervals. This was intended
|
|
to enable changes to the length of the archive interval.
|
|
</p>
|
|
|
|
<p>Unfortunately, a bug caused the weightings to all be one (1), regardless of what the actual archive interval
|
|
length might be. This means all archive records, long and short, contribute the same amount, instead of
|
|
being weighted by their length. So, if the archive interval were to change, averages would be calculated
|
|
incorrectly.
|
|
</p>
|
|
|
|
<p>
|
|
This bug will only affect you if you have changed the length of your archive interval, or if you plan to. If
|
|
you have not changed your archive interval length, and have no plans to do so, then there is nothing you
|
|
need to do.
|
|
</p>
|
|
|
|
<p class="note">
|
|
Your archive may have interval values of different sizes if...<br/> <br/> ... you have imported data using
|
|
<span class="code">wee_import</span>.<br/> <br/> ... your hardware has a data logger, your configuration
|
|
uses <span class="code">record_generation=software</span>, and the <span
|
|
class="code">archive_interval</span> is different from that in the hardware.<br/> <br/> ... your archive
|
|
contains data from more than one type of hardware.
|
|
</p>
|
|
|
|
<p>The <a href="utilities.htm#wee_database_utility"><span class="code">wee_database</span></a> utility, with
|
|
option <a href="utilities.htm#wee_database_utility_update"><span class="code">--update</span></a>, can fix
|
|
this problem by recalculating the weights in the daily summary, on the basis of the actual archive interval
|
|
lengths. On a Raspberry Pi 1, model B, it takes about 10 minutes to fix a database with 10 years of data. On
|
|
faster machines, it takes much less time.
|
|
</p>
|
|
|
|
<pre class="tty cmd">wee_database /etc/weewx/weewx.conf --update</pre>
|
|
|
|
<p>
|
|
If you have multiple databases, consider recalculating the weights in each database. Interval weighting will
|
|
only need to be applied to databases that have daily summaries, i.e., the binding uses
|
|
</p>
|
|
<pre class="tty">manager = weewx.wxmanager.WXDaySummaryManager</pre>
|
|
<p>
|
|
To apply interval weighting to a database other than the default <span class="code">wx_binding</span>, use
|
|
the <span class="code">--binding=BINDING_NAME</span> option in conjunction with the <span class="code">--update</span>
|
|
action.
|
|
</p>
|
|
<pre class="tty cmd">wee_database /etc/weewx/weewx.conf --update --binding=cmon_binding</pre>
|
|
|
|
<h3 id="recalculation_of_windspeed">Recalculation of <span class="code">windSpeed</span> maximum values</h3>
|
|
|
|
<p>Version 3.7 changes how maximum <span class="code">windSpeed</span> is calculated for aggregations of a day
|
|
or more. Previously, if option <span class="code">use_hilo</span> was set to <span class="code">True</span>
|
|
(the usual case), maximum <span class="code">windSpeed</span> for a day was set to the maximum value seen in
|
|
the LOOP packets for the day. In practice this is the same value as <span class="code">windGust</span>. That
|
|
is, these two tags would supply the same value:
|
|
</p>
|
|
|
|
<pre class="tty">$day.windSpeed.max
|
|
$day.windGust.max</pre>
|
|
|
|
<p>In Version 3.7, this has been changed so the maximum <span class="code">windSpeed</span> is now set to the
|
|
maximum <em>archive</em> value seen during the day — usually a slightly smaller number. However, older
|
|
daily max values will still contain the max LOOP packet values. If you wish to update your older values and
|
|
have them use the max archive record value, use the utility <a
|
|
href="utilities.htm#wee_database_utility"><span class="code">wee_database</span></a>, with option <a
|
|
href="utilities.htm#wee_database_utility_update"><span class="code">--update</span></a>.
|
|
</p>
|
|
|
|
<h3>Changes to <span class="code">wee_database</span></h3>
|
|
<p>
|
|
The <span class="code">wee_database</span> utility has been revised. Whilst the v3.6 functionality has been
|
|
retained, a number of the <span class="code">wee_database</span> actions have been renamed and new options
|
|
have been added to support the weighting of daily summaries and the recalculation of portions of the
|
|
windSpeed daily summary table. The rebuilding of the daily summaries (formerly backfilling the daily
|
|
summaries) now supports selective rebuilding. Full details on the revised <span
|
|
class="code">wee_database</span> utility can be found in the <a
|
|
href="utilities.htm#wee_database_utility"><i><span class="code">wee_database</span></i></a> section in the
|
|
<i>Utilities Guide</i>.
|
|
</p>
|
|
|
|
|
|
<h3>Change in the name and locations of examples</h3>
|
|
<p>
|
|
In earlier versions, examples were located with the WeeWX code base, and packaged as a Python module. This
|
|
is categorically and semantically incorrect.
|
|
</p>
|
|
<p>
|
|
The examples now live in their own directory, <a href="usersguide.htm#Where_to_find_things">whose location
|
|
is dependent on the installation method</a>. If you use an example, you should copy it to the <span
|
|
class="code">user</span> subdirectory, modify it if necessary, then use it there. Your copy will be retained
|
|
across version upgrades.
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.6</td>
|
|
<td>3.7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'><span class="changed">examples.alarm.MyAlarm
|
|
examples.lowBattery.MyAlarm
|
|
examples.xsearch.MyXSearch</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'><span class="changed">user.alarm.MyAlarm
|
|
user.lowBattery.BatteryAlarm
|
|
user.stats.MyStats</span></pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Finally, note that the name of one example has been changed:</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.6</td>
|
|
<td>3.7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'><span class="changed">xsearch.py</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'><span class="changed">stats.py</span></pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h3>Changes to sensor mapping</h3>
|
|
<p>
|
|
The mapping of sensors to database fields was formalized in Version 3.7, resulting in changes to the
|
|
configuration for some of the drivers, including <span class="code">cc3000</span>, <span
|
|
class="code">te923</span>, <span class="code">wmr100</span>, <span class="code">wmr200</span>, <span
|
|
class="code">wmr300</span>, and <span class="code">wmr9x8</span>.
|
|
</p>
|
|
<p>
|
|
For the <span class="code">wmr200</span> driver, until Version 3.6, the fields extraTemp1 and extraHumid1
|
|
were not usable. Version 3.6.1 shifted the extraTemp and extraHumid mappings down one channel, so that
|
|
extraTemp1 corresponded to channel 2, extraTemp2 corresponded to channel 3, and so on. The mappings can now
|
|
be modified by a change to the configuration file, and the default mappings are as follows:
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.6</td>
|
|
<td>3.7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>** hard-coded in the driver **
|
|
|
|
outTemp = temperature_1
|
|
# extraTemp1 is not usable
|
|
extraTemp2 = temperature_2
|
|
extraTemp3 = temperature_3
|
|
extraTemp4 = temperature_4
|
|
extraTemp5 = temperature_5
|
|
extraTemp6 = temperature_6
|
|
extraTemp7 = temperature_7
|
|
extraTemp8 = temperature_8
|
|
outHumidity = humidity_1
|
|
# extraHumid1 is not usable
|
|
extraHumid2 = humidity_2
|
|
extraHumid3 = humidity_3
|
|
extraHumid4 = humidity_4
|
|
extraHumid5 = humidity_5
|
|
extraHumid6 = humidity_6
|
|
extraHumid7 = humidity_7
|
|
extraHumid8 = humidity_8</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[WMR200]
|
|
<span class="added">[[sensor_map]]
|
|
altimeter = altimeter
|
|
pressure = pressure
|
|
windSpeed = wind_speed
|
|
windDir = wind_dir
|
|
windGust = wind_gust
|
|
windBatteryStatus = battery_status_wind
|
|
inTemp = temperature_0
|
|
outTemp = temperature_1
|
|
extraTemp1 = temperature_2
|
|
extraTemp2 = temperature_3
|
|
extraTemp3 = temperature_4
|
|
extraTemp4 = temperature_5
|
|
extraTemp5 = temperature_6
|
|
extraTemp6 = temperature_7
|
|
extraTemp7 = temperature_8
|
|
inHumidity = humidity_0
|
|
outHumidity = humidity_1
|
|
extraHumid1 = humidity_2
|
|
extraHumid2 = humidity_3
|
|
extraHumid3 = humidity_4
|
|
extraHumid4 = humidity_5
|
|
extraHumid5 = humidity_6
|
|
extraHumid6 = humidity_7
|
|
extraHumid7 = humidity_8
|
|
outTempBatteryStatus = battery_status_out
|
|
rain = rain
|
|
rainTotal = rain_total
|
|
rainRate = rain_rate
|
|
hourRain = rain_hour
|
|
rain24 = rain_24
|
|
rainBatteryStatus = battery_status_rain
|
|
UV = uv
|
|
uvBatteryStatus = battery_status_uv
|
|
windchill = windchill
|
|
heatindex = heatindex
|
|
forecastIcon = forecast_icon
|
|
outTempFault = out_fault
|
|
windFault = wind_fault
|
|
uvFault = uv_fault
|
|
rainFault = rain_fault
|
|
clockUnsynchronized = clock_unsynchronized
|
|
</span></pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
For the <span class="code">te923</span> driver:
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.6</td>
|
|
<td>3.7</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[TE923]
|
|
<span class="changed">[[map]]
|
|
link_wind = windLinkStatus
|
|
bat_wind = windBatteryStatus
|
|
link_rain = rainLinkStatus
|
|
bat_rain = rainBatteryStatus
|
|
link_uv = uvLinkStatus
|
|
bat_uv = uvBatteryStatus
|
|
uv = UV
|
|
t_in = inTemp
|
|
h_in = inHumidity
|
|
t_1 = outTemp
|
|
h_1 = outHumidity
|
|
bat_1 = outBatteryStatus
|
|
link_1 = outLinkStatus
|
|
t_2 = extraTemp1
|
|
h_2 = extraHumid1
|
|
bat_2 = extraBatteryStatus1
|
|
link_2 = extraLinkStatus1
|
|
t_3 = extraTemp2
|
|
h_3 = extraHumid3
|
|
bat_3 = extraBatteryStatus2
|
|
link_3 = extraLinkStatus2
|
|
t_4 = extraTemp3
|
|
h_4 = extraHumid3
|
|
bat_4 = extraBatteryStatus3
|
|
link_4 = extraLinkStatus3
|
|
t_5 = extraTemp4
|
|
h_5 = extraHumid4
|
|
bat_5 = extraBatteryStatus4
|
|
link_5 = extraLinkStatus4</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[TE923]
|
|
<span class="changed">[[sensor_map]]
|
|
windLinkStatus = link_wind
|
|
windBatteryStatus = bat_wind
|
|
rainLinkStatus = link_rain
|
|
rainBatteryStatus = bat_rain
|
|
uvLinkStatus = link_uv
|
|
uvBatteryStatus = bat_uv
|
|
inTemp = t_in
|
|
inHumidity = h_in
|
|
outTemp = t_1
|
|
outHumidity = h_1
|
|
outTempBatteryStatus = bat_1
|
|
outLinkStatus = link_1
|
|
extraTemp1 = t_2
|
|
extraHumid1 = h_2
|
|
extraBatteryStatus1 = bat_2
|
|
extraLinkStatus1 = link_2
|
|
extraTemp2 = t_3
|
|
extraHumid2 = h_3
|
|
extraBatteryStatus2 = bat_3
|
|
extraLinkStatus2 = link_3
|
|
extraTemp3 = t_4
|
|
extraHumid3 = h_4
|
|
extraBatteryStatus3 = bat_4
|
|
extraLinkStatus3 = link_4
|
|
extraTemp4 = t_5
|
|
extraHumid4 = h_5
|
|
extraBatteryStatus4 = bat_5
|
|
extraLinkStatus4 = link_5
|
|
|
|
</span></pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h2>Upgrading to V3.6</h2>
|
|
|
|
<h3>Changes to <span class="code">weewx.conf</span></h3>
|
|
<p>
|
|
In Version 3.6, the list of options that describe how derived variables are to be calculated have been moved
|
|
to a new subsection called <span class="code">[[Calculations]]</span>. The upgrade process will
|
|
automatically make this change for you.
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.5</td>
|
|
<td>3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[StdWXCalculate]
|
|
pressure = prefer_hardware
|
|
barometer = prefer_hardware
|
|
altimeter = prefer_hardware
|
|
windchill = prefer_hardware
|
|
heatindex = prefer_hardware
|
|
dewpoint = prefer_hardware
|
|
inDewpoint = prefer_hardware
|
|
rainRate = prefer_hardware
|
|
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[StdWXCalculate]
|
|
<span class="changed">[[Calculations]]</span>
|
|
pressure = prefer_hardware
|
|
barometer = prefer_hardware
|
|
altimeter = prefer_hardware
|
|
windchill = prefer_hardware
|
|
heatindex = prefer_hardware
|
|
dewpoint = prefer_hardware
|
|
inDewpoint = prefer_hardware
|
|
rainRate = prefer_hardware</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h2>Upgrading to V3.2</h2>
|
|
|
|
<h3>New utilities</h3>
|
|
|
|
<p>
|
|
Version 3.2 includes new utilities to facilitate configuration.
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:30%'>3.2</td>
|
|
<td style='width:30%'>3.1 and earlier</td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>wee_config</span></td>
|
|
<td></td>
|
|
<td>Change driver or other station parameters</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>wee_extension</span></td>
|
|
<td><span class='code'>setup.py</span> or <span class='code'>wee_setup</span></td>
|
|
<td>Install, list, and remove extensions</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>wee_database</span></td>
|
|
<td><span class='code'>wee_config_database</span></td>
|
|
<td>Manipulate the database</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>wee_device</span></td>
|
|
<td><span class='code'>wee_config_device</span></td>
|
|
<td>Get and set parameters on the hardware</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>wee_reports</span></td>
|
|
<td><span class='code'>wee_reports</span></td>
|
|
<td>Run reports</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Changes to weewx.conf</h3>
|
|
|
|
<p>Release 3.2 introduces a new section <span class='code'>[DatabaseTypes]</span>. This section defines the
|
|
default settings for each type of database. For example, the host, user, and password for MySQL databases
|
|
can be specified once in the <span class='code'>DatabaseTypes</span> section instead of repeating in each
|
|
<span class='code'>Database</span> section. The defaults in <span class='code'>DatabaseTypes</span> can be
|
|
overridden in each <span class='code'>Database</span> section as needed.
|
|
</p>
|
|
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>3.1</td>
|
|
<td>3.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[DataBindings]
|
|
[[wx_binding]]
|
|
database = archive_sqlite
|
|
manager = weewx.wxmanager.WXDaySummaryManager
|
|
table_name = archive
|
|
schema = schemas.wview.schema
|
|
[Databases]
|
|
[[archive_sqlite]]
|
|
<span class='changed'> root = %(WEEWX_ROOT)s
|
|
database = archive/weewx.sdb
|
|
driver = weedb.sqlite</span>
|
|
[[archive_mysql]]
|
|
<span class='changed'> host = localhost
|
|
user = weewx
|
|
password = weewx
|
|
database = weewx
|
|
driver = weedb.mysql</span>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[DataBindings]
|
|
[[wx_binding]]
|
|
database = archive_sqlite
|
|
manager = weewx.wxmanager.WXDaySummaryManager
|
|
table_name = archive
|
|
schema = schemas.wview.schema
|
|
[Databases]
|
|
[[archive_sqlite]]
|
|
<span class='changed'> database_name = weewx.sdb
|
|
database_type = SQLite</span>
|
|
|
|
[[archive_mysql]]
|
|
<span class='changed'> database_name = weewx
|
|
database_type = MySQL</span>
|
|
|
|
|
|
|
|
<span class='added'>[DatabaseTypes]
|
|
[[SQLite]]
|
|
driver = weedb.sqlite
|
|
SQLITE_ROOT = %(WEEWX_ROOT)s/archive
|
|
[[MySQL]]
|
|
driver = weedb.mysql
|
|
host = localhost
|
|
user = weewx
|
|
password = weewx</span></pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Upgrading to V3.0</h2>
|
|
|
|
<h3>Overview</h3>
|
|
|
|
<p>While a lot has changed with Version 3, the upgrade process should take care of most changes for most users.
|
|
However, if you have installed an extension or, especially, if you have written a custom service, search
|
|
list extension, or uploader, you will have to make some changes.
|
|
</p>
|
|
|
|
<h3>Database contents</h3>
|
|
|
|
<p>
|
|
With Version 3, there is no longer a separate "stats" database. Instead, "daily summaries" have been
|
|
included in the same database as the archive data — everything is under one name. For example, if you
|
|
are using sqlite, both the archive data and the daily summaries will be inside file <span class="code">weewx.sdb</span>.
|
|
With MySQL, everything is inside the database <span class="code">weewx</span>.
|
|
This makes it easier to keep all data together when working with multiple databases.
|
|
</p>
|
|
|
|
<p>This change in database structure should be transparent to you. On startup, WeeWX will automatically backfill
|
|
the new internal daily summaries from the archive data. Your old "stats" database will no longer be used and
|
|
may safely set aside or even deleted.
|
|
</p>
|
|
|
|
<h3>Pressure calibration</h3>
|
|
|
|
<p>
|
|
Since the new <span class="code">StdWXCalculate</span> service is applied after the <span class="code">StdCalibrate</span>
|
|
services, the <span class='code'>pressure_offset</span> parameter is no longer necessary; pressure
|
|
calibration can be applied just like any other calibration. If your pressure was calibrated using the <span
|
|
class='code'>pressure_offset</span> parameter, move the calibration to the <span
|
|
class="code">[StdCalibrate]</span> section. This applies only to CC3000, FineOffsetUSB, Ultimeter, WS1,
|
|
WS23xx, and WS28xx hardware.
|
|
</p>
|
|
|
|
<h3><span class="code">weewx.conf</span></h3>
|
|
|
|
<p>
|
|
A version 2.X <span class="code">weewx.conf</span> file is not compatible with Version 3.X. However, the
|
|
upgrade process should automatically update the file. Nevertheless, the changes are documented below:
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td></td>
|
|
<td>
|
|
<pre class='tty'>[StdReport]
|
|
<span class='added'> data_binding = wx_binding</span></pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[StdArchive]
|
|
<span class='removed'> archive_database = archive_sqlite
|
|
stats_database = stats_sqlite
|
|
archive_schema = user.schemas.defaultArchiveSchema
|
|
stats_schema = user.schemas.defaultStatsSchema</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[StdArchive]
|
|
<span class='added'> data_binding = wx_binding</span></pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td></td>
|
|
<td>
|
|
<pre class='tty'><span class='added'>[DataBindings]
|
|
[[wx_binding]]
|
|
database = archive_sqlite
|
|
manager = weewx.wxmanager.WXDaySummaryManager
|
|
table_name = archive
|
|
schema = schemas.wview.schema</span></pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[Databases]
|
|
[[archive_sqlite]]
|
|
root = %(WEEWX_ROOT)s
|
|
<span class='changed'>database</span> = archive/weewx.sdb
|
|
driver = weedb.sqlite
|
|
<span class='removed'> [[stats_sqlite]]
|
|
root = %(WEEWX_ROOT)s
|
|
database = archive/stats.sdb
|
|
driver = weedb.sqlite</span>
|
|
[[archive_mysql]]
|
|
host = localhost
|
|
user = weewx
|
|
password = weewx
|
|
<span class='changed'>database</span> = weewx
|
|
driver = weedb.mysql
|
|
<span class='removed'> [[stats_mysql]]
|
|
host = localhost
|
|
user = weewx
|
|
password = weewx
|
|
database = stats
|
|
driver = weedb.mysql</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[Databases]
|
|
[[archive_sqlite]]
|
|
root = %(WEEWX_ROOT)s
|
|
<span class='changed'>database_name</span> = archive/weewx.sdb
|
|
driver = weedb.sqlite
|
|
|
|
|
|
|
|
|
|
[[archive_mysql]]
|
|
host = localhost
|
|
user = weewx
|
|
password = weewx
|
|
<span class='changed'>database_name</span> = weewx
|
|
driver = weedb.mysql
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[<span class='changed'>Engines</span>]
|
|
[[<span class='changed'>WxEngine</span>]]
|
|
prep_services = \
|
|
weewx.<span class='changed'>wxengine</span>.StdTimeSynch
|
|
process_services = \
|
|
weewx.<span class='changed'>wxengine</span>.StdConvert, \
|
|
weewx.<span class='changed'>wxengine</span>.StdCalibrate, \
|
|
weewx.<span class='changed'>wxengine</span>.StdQC
|
|
|
|
archive_services = \
|
|
weewx.<span class='changed'>wxengine</span>.StdArchive
|
|
restful_services = \
|
|
weewx.restx.StdStationRegistry, \
|
|
weewx.restx.StdWunderground, \
|
|
weewx.restx.StdPWSweather, \
|
|
weewx.restx.StdCWOP, \
|
|
weewx.restx.StdWOW, \
|
|
weewx.restx.StdAWEKAS
|
|
report_services = \
|
|
weewx.<span class='changed'>wxengine</span>.StdPrint, \
|
|
weewx.<span class='changed'>wxengine</span>.StdReport</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[<span class='changed'>Engine</span>]
|
|
[[<span class='changed'>Services</span>]]
|
|
prep_services = \
|
|
weewx.<span class='changed'>engine</span>.StdTimeSynch
|
|
process_services = \
|
|
weewx.<span class='changed'>engine</span>.StdConvert, \
|
|
weewx.<span class='changed'>engine</span>.StdCalibrate, \
|
|
weewx.<span class='changed'>engine</span>.StdQC<span class='added'>, \
|
|
weewx.wxservices.StdWXCalculate</span>
|
|
archive_services = \
|
|
weewx.<span class='changed'>engine</span>.StdArchive
|
|
restful_services = \
|
|
weewx.restx.StdStationRegistry, \
|
|
weewx.restx.StdWunderground, \
|
|
weewx.restx.StdPWSweather, \
|
|
weewx.restx.StdCWOP, \
|
|
weewx.restx.StdWOW, \
|
|
weewx.restx.StdAWEKAS
|
|
report_services = \
|
|
weewx.<span class='changed'>engine</span>.StdPrint, \
|
|
weewx.<span class='changed'>engine</span>.StdReport</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Custom data sources in skins</h3>
|
|
|
|
<p>The mechanism for specifying non-default data sources in skins has changed. If you modified the Standard
|
|
skin, or created or used other skins that draw data from a database other than the weather database, you
|
|
must change how the other sources are specified.
|
|
</p>
|
|
|
|
<p>For example, in the <span class='code'>cmon</span> extension:</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[ImageGenerator]
|
|
...
|
|
[[day_images]]
|
|
...
|
|
[[[daycpu]]]
|
|
<span class='changed'>archive_database = cmon_sqlite</span>
|
|
[[[cpu_user]]]
|
|
[[[cpu_idle]]]
|
|
[[[cpu_system]]]</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[ImageGenerator]
|
|
...
|
|
[[day_images]]
|
|
...
|
|
[[[daycpu]]]
|
|
<span class='changed'>data_binding = cmon_binding</span>
|
|
[[[cpu_user]]]
|
|
[[[cpu_idle]]]
|
|
[[[cpu_system]]]</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Extensions</h3>
|
|
|
|
<p>
|
|
Many skins will work in v3 with no modification required. However, every search list extension will have to
|
|
be upgraded, every restful extension must be upgraded, and some other services must be upgraded.
|
|
</p>
|
|
|
|
<p>
|
|
There is no automated upgrade system for extensions; if an extension must be upgraded, you must do it
|
|
manually. If the extension has any python code, this will mean replacing any v2-compatible code with
|
|
v3-compatible code. In some cases parts of the configuration file <span class='code'>weewx.conf</span> must
|
|
be modified.
|
|
</p>
|
|
|
|
<p>
|
|
For example, to update the <span class='code'>pmon</span> extension, replace <span class='code'>bin/user/pmon.py</span>
|
|
with the v3-compatible <span class='code'>pmon.py</span> and modify <span class='code'>weewx.conf</span> as
|
|
shown in this table:
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[ProcessMonitor]
|
|
<span class='changed'>database = pmon_sqlite</span></pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[ProcessMonitor]
|
|
<span class='changed'>data_binding = pmon_binding</span></pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td></td>
|
|
<td>
|
|
<pre class='tty'><span class='added'>[DataBindings]
|
|
[[pmon_binding]]
|
|
database = pmon_sqlite
|
|
manager = weewx.manager.DaySummaryManager
|
|
table_name = archive
|
|
schema = user.pmon.schema</span></pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>[Databases]
|
|
[[pmon_sqlite]]
|
|
root = %(WEEWX_ROOT)s
|
|
<span class='changed'>database</span> = archive/pmon.sdb
|
|
driver = weedb.sqlite</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>[Databases]
|
|
[[pmon_sqlite]]
|
|
root = %(WEEWX_ROOT)s
|
|
<span class='changed'>database_name</span> = archive/pmon.sdb
|
|
driver = weedb.sqlite</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
For other extensions, see the extension's documentation or contact the author of the extension.
|
|
</p>
|
|
|
|
<h3>Search list extensions</h3>
|
|
|
|
<p>
|
|
The introduction of <em>data bindings</em> has meant a change in the calling signature of <em>search list
|
|
extensions.</em> By way of example, here's the example from the section <a
|
|
href="customizing.htm#extending_the_list"><i>Extending the list</i></a> in the <i>Customizing Guide</i>,
|
|
with the differences highlighted.
|
|
</p>
|
|
<table>
|
|
<tbody>
|
|
<tr class="first_row">
|
|
<td>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><pre class="tty">def <span class="changed">get_extension</span>(self, timespan, <span
|
|
class="changed">archivedb, statsdb</span>):
|
|
|
|
all_stats = <span class="changed">TimeSpanStats</span>(
|
|
timespan,
|
|
<span class="changed">statsdb</span>,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter)
|
|
week_dt = datetime.date.fromtimestamp(timespan.stop) - \
|
|
datetime.timedelta(weeks=1)
|
|
week_ts = time.mktime(week_dt.timetuple())
|
|
seven_day_stats = <span class="changed">TimeSpanStats</span>(
|
|
TimeSpan(week_ts, timespan.stop),
|
|
<span class="changed">statsdb</span>,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter)
|
|
|
|
search_list_extension = {'alltime' : all_stats,
|
|
'seven_day' : seven_day_stats}
|
|
|
|
return search_list_extension</pre>
|
|
</td>
|
|
<td><pre class="tty">def <span class="changed">get_extension_list</span>(self, timespan, <span
|
|
class="changed">db_lookup</span>):
|
|
|
|
all_stats = <span class="changed">TimespanBinder</span>(
|
|
timespan,
|
|
<span class="changed">db_lookup</span>,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter)
|
|
week_dt = datetime.date.fromtimestamp(timespan.stop) - \
|
|
datetime.timedelta(weeks=1)
|
|
week_ts = time.mktime(week_dt.timetuple())
|
|
seven_day_stats = <span class="changed">TimespanBinder</span>(
|
|
TimeSpan(week_ts, timespan.stop),
|
|
<span class="changed">db_lookup</span>,
|
|
formatter=self.generator.formatter,
|
|
converter=self.generator.converter)
|
|
|
|
search_list_extension = {'alltime' : all_stats,
|
|
'seven_day' : seven_day_stats}
|
|
|
|
return <span class="added">[</span>search_list_extension<span class="added">]</span></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>A few things to note:</p>
|
|
<ul>
|
|
<li>The name of the extension function has changed from <span class="code">get_extension</span> to <span
|
|
class="code">get_extension_list</span>.
|
|
</li>
|
|
<li>The calling signature has changed. Instead of an archive database and a stats database being passed in,
|
|
a single <em>database lookup function</em> is passed in.
|
|
</li>
|
|
<li>The name of the top-level class in the tag chain has changed from <span
|
|
class="code">TimeSpanStats</span> to <span class="code">TimespanBinder</span>. See the <i>Customizing
|
|
Guide</i> for details.
|
|
</li>
|
|
<li>Instead of returning a single search list extension, the function should now return a Python <span
|
|
class="code">list</span> of extensions. The list will be searched in order.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>Derived quantities</h3>
|
|
|
|
<p>Some calculations that were done in drivers or in hardware are now done consistently by the new
|
|
StdWXCalculate service. Drivers should no longer calculate derived quantities such as windchill, heatindex,
|
|
dewpoint, or rain rate.
|
|
</p>
|
|
|
|
<h3>Driver APIs</h3>
|
|
|
|
<p>The base class for drivers has been renamed, and new, optional, methods have been defined to provide hooks
|
|
for configuring hardware and producing default and upgraded configuration stanzas.
|
|
</p>
|
|
|
|
<p>These changes affect only those who have written custom drivers.</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>import weewx.<span class="changed">abstractstation</span>
|
|
|
|
class ACME960(weewx.<span class="changed">abstractstation.AbstractStation</span>):
|
|
...</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>import weewx.<span class="changed">drivers</span>
|
|
|
|
class ACME960(weewx.<span class="changed">drivers.AbstractDevice</span>):
|
|
...</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Service APIs</h3>
|
|
|
|
<p>The base class for services has moved.</p>
|
|
|
|
<p>This affects only those who have written custom services.</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>import weewx.<span class="changed">wxengine</span>
|
|
|
|
class BetterMousetrapService(weewx.<span class="changed">wxengine</span>.StdService):
|
|
...</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>import weewx.<span class="changed">engine</span>
|
|
|
|
class BetterMousetrapService(weewx.<span class="changed">engine</span>.StdService):
|
|
...</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>RESTful APIs</h3>
|
|
|
|
<p>Some of the methods internal to RESTful services have changed, specifically those that relate to getting
|
|
configuration options from <span class='code'>weewx.conf</span> and configuring databases.
|
|
</p>
|
|
|
|
<p>This affects only those who have written custom RESTful services.</p>
|
|
|
|
<p>Here is an example of obtaining the database dictionary for use in the RESTful service thread.</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><pre class="tty">site_dict = weewx.restx.get_dict(config_dict, 'Uploader')
|
|
db_name = config_dict['StdArchive']['archive_database']
|
|
db_dict = config_dict['Databases'][db_name]
|
|
site_dict.setdefault('database_dict', db_dict)</pre>
|
|
</td>
|
|
<td><pre class="tty">site_dict = config_dict['StdRESTful']['Uploader']
|
|
site_dict = accumulateLeaves(site_dict, max_level=1)
|
|
manager_dict = weewx.manager.open_manager_with_config(
|
|
config_dict, 'wx_binding')</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Database APIs</h3>
|
|
|
|
<p>The methods for obtaining, opening, and querying databases have changed. This affects only those who have
|
|
written code that accesses databases.
|
|
</p>
|
|
|
|
<p>
|
|
The class <span class="code">Manager</span> and its subclasses have replaced the old <span class="code">Archive</span>
|
|
class. The table name is no longer hard-coded, so developers should use the table name from the database
|
|
binding. There is no longer a separate <span class="code">StatsDb</span> class, its functions having been
|
|
subsumed into the <span class="code">Manager</span> class and its subclasses.
|
|
</p>
|
|
|
|
<p>
|
|
A new class <span class="code">DBBinder</span> is the preferred way of getting a <span
|
|
class="code">Manager</span> class, as it will automatically take care of instantiating the right class, as
|
|
well as caching instances of <span class="code">Manager</span>. An instance of <span
|
|
class="code">DBBinder</span> is held by the engine as attribute <span class="code">db_binder</span>. Here's
|
|
an example of making a simple query.
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><pre class="tty">db = config_dict['StdArchive']['archive_database']
|
|
self.database_dict = config_dict['Databases'][db]
|
|
with weewx.archive.Archive.open(self.database_dict) as archive:
|
|
val = archive.getSql("SELECT AVG(windSpeed) FROM archive"
|
|
" WHERE dateTime>? AND dateTime<=?",
|
|
(start_ts, end_ts))</pre>
|
|
</td>
|
|
<td><pre class="tty">with self.engine.db_binder.get_manager('wx_binding') as mgr:
|
|
val = mgr.getSql("SELECT AVG(windSpeed) FROM %s"
|
|
" WHERE dateTime>? AND dateTime<=?" %
|
|
mgr.table_name, (start_ts, end_ts))</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Generator APIs</h3>
|
|
|
|
<p>
|
|
The base class for report generators has changed. The old class <span
|
|
class="code">CachedReportGenerator</span> no longer exists; its functionality has been replaced by an
|
|
instance of <span class="code">DBBinder</span>, held by the generator superclass. This affects only those
|
|
who have written customer generators.
|
|
</p>
|
|
|
|
<p>Here's an example:</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width: 50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><pre class="tty">class GaugeGenerator(weewx.reportengine.<span
|
|
class='changed'>CachedReportGenerator</span>)
|
|
def run(self):
|
|
archive_name = self.config_dict['GaugeGenerator']['archive_name']
|
|
archive = self._getArchive(archive_name)
|
|
results = archive.getSql(...)</pre>
|
|
</td>
|
|
<td><pre class="tty">class GaugeGenerator(weewx.reportengine.<span
|
|
class='changed'>ReportGenerator</span>)
|
|
def run(self):
|
|
mgr = self.generator.db_binder.get_manager()
|
|
results = mgr.getSql(...)</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>Extension installer</h3>
|
|
|
|
<p>The <span class='code'>setup.py</span> utility is now included in the installation; it is no longer necessary
|
|
to keep a copy of the WeeWX source tree just for the <span class='code'>setup.py</span> utility.
|
|
</p>
|
|
|
|
<p>For .deb and .rpm installations, the command <span class='code'>wee_setup</span> is a symlink to <span
|
|
class='code'>setup.py</span>.
|
|
</p>
|
|
|
|
<p>The options for installing extensions changed slightly to be more consistent with the rest of the options to
|
|
<span class='code'>setup.py</span>.
|
|
</p>
|
|
<table>
|
|
<tr class="first_row">
|
|
<td style='width:50%'>2.7</td>
|
|
<td>3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<pre class='tty'>setup.py --extension --install extensions/basic
|
|
setup.py --extension --install basic.tar.gz
|
|
setup.py --extension --uninstall basic
|
|
setup.py --extension --list
|
|
setup.py --extension --install basic.tar.gz --dryrun</pre>
|
|
</td>
|
|
<td>
|
|
<pre class='tty'>setup.py install --extension extensions/basic
|
|
setup.py install --extension basic.tar.gz
|
|
setup.py uninstall --extension basic
|
|
setup.py list-extensions
|
|
setup.py install --extension basic.tar.gz --dry-run</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Upgrading to V2.7</h2>
|
|
|
|
<p>Version 2.7 is backwards compatible with earlier versions with one minor exception.</p>
|
|
|
|
<p>
|
|
It now includes the ability to localize the WeeWX and server uptimes. Previously, the labels <span
|
|
class="code">days</span>, <span class="code">hours</span>, and <span class="code">minutes</span> were
|
|
hardcoded in a Python utility. There was no way of changing them. Now, like any other labels, they are taken
|
|
from the skin configuration file, <span class="code">skin.conf</span>, section <span
|
|
class="code">[[Labels]]</span>. Older configuration files had a definition for <span
|
|
class="code">hour</span>, but none for <span class="code">day</span>, and <span class="code">minute</span>.
|
|
Also, the old definition for <span class="code">hour</span> used an abbreviation <span
|
|
class="code">hrs</span> instead of <span class="code">hours</span>.
|
|
</p>
|
|
|
|
<p>If you do nothing, your WeeWX and station uptimes will look like:</p>
|
|
<pre class="tty">Weewx uptime: 1 day, 1 hrs, 41 minutes
|
|
Server uptime: 2 days, 10 hrs, 22 minutes</pre>
|
|
<p>
|
|
Note how the label for hours is abbreviated and always uses the plural. If you want the previous behavior,
|
|
or if you want to localize the labels, you should update your skin configuration file. Remove the old
|
|
entries for <span class="code">hour</span> and <span class="code">second</span> and replace them with:
|
|
</p>
|
|
<pre class="tty">day = " day", " days"
|
|
hour = " hour", " hours"
|
|
minute = " minute", " minutes"
|
|
second = " second", " seconds"</pre>
|
|
|
|
<p>The first item is the singular spelling, the second the plural. This will result in the desired</p>
|
|
<pre class="tty">Weewx uptime: 1 day, 1 hour, 41 minutes
|
|
Server uptime: 2 days, 10 hours, 22 minutes</pre>
|
|
|
|
<h2>Upgrading to V2.6</h2>
|
|
|
|
<p>Version 2.6 is backwards compatible with earlier versions, with a couple of small exceptions.</p>
|
|
<ul>
|
|
<li>If you have written a custom WeeWX service, the install routine will try to insert its name into an
|
|
appropriate place in one of the five new lists of services to be run. You should check section <span
|
|
class="code">[Engines][[WxEngine]]</span> to make sure it made a reasonable guess.
|
|
</li>
|
|
<li>If you have written a custom RESTful service, the architecture for these services has completely
|
|
changed. They are now first class services, and are treated like any other WeeWX service. There are some
|
|
guides to writing RESTful services using the new architecture at the top of the file <span class='code'>bin/weewx/restx.py</span>.
|
|
I can also help you with the transition.
|
|
</li>
|
|
<li>Option <span class='code'>interval</span> in the CWOP configuration section has become option <span
|
|
class='code'>post_interval</span>. This change should be done automatically by the install routine.
|
|
</li>
|
|
<li>The mechanism for specifying RESTful services has changed. To activate a RESTful service, put the driver
|
|
in the <span class="code">restful_services</span> list in <span
|
|
class="code">[Engines][[WxEngine]]</span>. The <span class="code">driver</span> parameter is no
|
|
longer necessary in the RESTful service's configuration stanza. These changes should be done
|
|
automatically by the install routine.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Upgrading to V2.4</h2>
|
|
|
|
<p>The option <span class="code">time_length</span> will now be the exact length of the resultant plot. Before,
|
|
a plot with <span class="code">time_length</span> equal to 24 hours would result in a plot of 27 hours, now
|
|
it's 24 hours. If you want the old behavior, set it equal to 27 hours. To do this, change your section in
|
|
<span class="code">skin.conf</span> from
|
|
</p>
|
|
|
|
<pre class="tty">[[day_images]]
|
|
x_label_format = %H:%M
|
|
bottom_label_format = %m/%d/%y %H:%M
|
|
time_length = 86400 # == 24 hours</pre>
|
|
|
|
<p>to</p>
|
|
|
|
<pre class="tty">[[day_images]]
|
|
x_label_format = %H:%M
|
|
bottom_label_format = %m/%d/%y %H:%M
|
|
<span class="highlight">time_length = 97200 # == 27 hours</span></pre>
|
|
|
|
<p>The service <span class="code">StdTimeSync</span> now synchronizes the console's onboard clock on startup.
|
|
This is nice because if the clock failed, perhaps because the battery was taken out, the time is corrected
|
|
first <em>before</em> data is downloaded from the logger's memory. To take advantage of this, you can move
|
|
service <span class="code">StdTimeSync</span> to the front of the list of services to be run. For example:
|
|
</p>
|
|
|
|
<pre class="tty">[[WxEngine]]
|
|
# The list of services the main weewx engine should run:
|
|
service_list = <span class="highlight">weewx.wxengine.StdTimeSynch</span>, weewx.wxengine.StdConvert,
|
|
weewx.wxengine.StdCalibrate, weewx.wxengine.StdQC, weewx.wxengine.StdArchive, weewx.wxengine.StdPrint,
|
|
weewx.wxengine.StdRESTful, weewx.wxengine.StdReport</pre>
|
|
|
|
<h2>Upgrading to V2.3</h2>
|
|
|
|
<p>The signature of the function "<span class="code">loader</span>", used to return an instance of the station
|
|
device driver, has changed slightly. It has changed from
|
|
</p>
|
|
|
|
<pre class="tty">loader(config_dict)</pre>
|
|
|
|
<p>to</p>
|
|
|
|
<pre class="tty">loader(config_dict, engine)</pre>
|
|
|
|
<p>That is, a second parameter, <span class="code">engine</span>, has been added. This is a reference to the
|
|
WeeWX engine.
|
|
</p>
|
|
|
|
<p>This change will affect only those who have written their own device driver.</p>
|
|
|
|
<h2>Upgrading to V2.2</h2>
|
|
|
|
<p>Version 2.2 introduces a schema, found in <span class="code">
|
|
bin/user/schemas.py</span>, for the stats database. This schema is used only when initially creating the
|
|
database. If you have a specialized stats database, that is, one that saves types other than the default
|
|
that comes with WeeWX, you should edit this file to reflect your changes before attempting to rebuild the
|
|
database.
|
|
</p>
|
|
|
|
<h2>Upgrading to V2.0</h2>
|
|
|
|
<p>Version 2.0 introduces many new features, including a revamped internal engine. There are two changes that
|
|
are not backwards compatible:
|
|
</p>
|
|
<ul>
|
|
<li>The configuration file, <span class="code">weewx.conf</span>. When upgrading from V1.X, the setup
|
|
utility will install a new, fresh copy of <span class="code">weewx.conf</span>, which you will then have
|
|
to edit by hand. Thereafter, V2.X upgrades should be automatic.
|
|
</li>
|
|
<li>Custom services. If you have written a custom service, it will have to be updated to use the new engine.
|
|
The overall architecture is very similar, except that functions must be <em>bound</em> to events, rather
|
|
than get called implicitly. See the sections <a href="customizing.htm#Customizing_a_service">Customizing
|
|
a Service</a> and <a href="customizing.htm#Adding_a_service">Adding a Service</a> in the <a
|
|
href="customizing.htm">Customizing Guide</a> for details on how to do this.
|
|
</li>
|
|
</ul>
|
|
<p>All skins should be completely backwards compatible, so you should not have to change your templates or skin
|
|
configuration file, <span class="code">skin.conf</span>.
|
|
</p>
|
|
|
|
<p>If you have written a custom report generator it should also be backwards compatible.</p>
|
|
|
|
<h2>Upgrading to V1.14</h2>
|
|
|
|
<p>Version 1.14 introduces some new webpages that have been expressly formatted for the smartphone by using <a
|
|
href="http://jquery.com/">jQuery</a>.
|
|
</p>
|
|
|
|
<p>The skins shipped with the distribution take advantage of these features. If you do nothing, your old skins
|
|
will continue to work, but you will not be taking advantage of these new webpages.
|
|
</p>
|
|
|
|
<p>If you want them, then you have two choices:</p>
|
|
<ol>
|
|
<li>Rename your old skin directory (call it "<span class="code">skins.old</span>") then do the
|
|
install. This will install the new skin distribution. You can then modify it to reflect any changes you
|
|
have made, referring to <span class="code">
|
|
skins.old</span> for guidance. If you have not changed many things, this approach will be the easiest.
|
|
</li>
|
|
<li>Alternatively, change the contents of your existing skin directory to include the new webpages. If you
|
|
take this approach, you will need to copy over the contents of the subdirectory <span class="code">
|
|
skins/Standard/smartphone</span> from the distribution into your <span class="code">skins/Standard</span>
|
|
directory. You will then need to modify your <span class="code">skin.conf</span>.
|
|
<p>After the section that looks like</p>
|
|
|
|
<pre class='tty'>[[[Mobile]]]
|
|
template = mobile.html.tmpl</pre>
|
|
|
|
<p>add the following directives:</p>
|
|
|
|
<pre class='tty'>[[[MobileSmartphone]]]
|
|
template = smartphone/index.html.tmpl
|
|
[[[MobileTempOutside]]]
|
|
template = smartphone/temp_outside.html.tmpl
|
|
[[[MobileRain]]]
|
|
template = smartphone/rain.html.tmpl
|
|
[[[MobileBarometer]]]
|
|
template = smartphone/barometer.html.tmpl
|
|
[[[MobileWind]]]
|
|
template = smartphone/wind.html.tmpl
|
|
[[[MobileRadar]]]
|
|
template = smartphone/radar.html.tmpl</pre>
|
|
|
|
<p>Then modify section <span class="code">[CopyGenerator]</span> to add the <span class="highlight">highlighted</span>
|
|
files:
|
|
</p>
|
|
|
|
<pre class='tty'>[CopyGenerator]
|
|
#
|
|
# This section is used by the generator CopyGenerator
|
|
#
|
|
|
|
# List of files that are to be copied at the first invocation of the generator only
|
|
copy_once = backgrounds/*, weewx.css, mobile.css, favicon.ico, <span class="highlight">smartphone/icons/*, smartphone/custom.js</span></pre>
|
|
</li>
|
|
</ol>
|
|
<p>Whichever approach you chose, the generated files will appear in <span
|
|
class="code">public_html/smartphone</span>. The start of the document root will be at <span class="code">public_html/smartphone/index.html</span>.
|
|
You may want to add a link to this in the template for your main index page <span class="code">skins/Standard/index.html.tmpl</span>.
|
|
</p>
|
|
|
|
<h2>Upgrading to V1.13</h2>
|
|
|
|
<p>Version 1.13 changed the way binding happens to the databases used in reports so that it happens much later.
|
|
The upshot is that the signature of a few functions changed. Most you are unlikely to encounter. The
|
|
exception is if you have written custom template <em>search lists</em>, as described in the <a
|
|
href="customizing.htm">Customizing weewx guide</a>. This section has been updated to reflect the new
|
|
function signatures. As a side effect, the illustrated example actually has become much simpler!
|
|
</p>
|
|
|
|
<p>No changes to skins.</p>
|
|
|
|
<h2>Upgrading to V1.10</h2>
|
|
|
|
<p>Version 1.10 introduced several new features.</p>
|
|
|
|
<h3>New almanac features, icon, and mobile template</h3>
|
|
|
|
<p>Version 1.10 introduces some extra almanac features, such as the azimuth and elevation of the sun and moon,
|
|
or when the next solstice will be. It also includes a template formatted for smartphones, as well as an icon
|
|
("<span class="code">favicon.ico</span>") that displays in your browser toolbar. The skins shipped
|
|
with the distribution take advantage of these features. If you do nothing, your old skins will continue to
|
|
work, but you will not take advantage of these new features.
|
|
</p>
|
|
|
|
<p>If you want these new features then you have two choices:</p>
|
|
<ol>
|
|
<li>Rename your old skin directory (call it "<span class="code">skin.old</span>") then do the
|
|
install. This will install the new skin distribution. You can modify it to reflect any changes you have
|
|
made, referring to <span class="code">
|
|
skin.old</span> for guidance.
|
|
</li>
|
|
<li>Alternatively, change the contents of your existing skin directory to take advantage of the new
|
|
features. If you take this approach, you will need to copy over files <span class="code">favicon.ico, mobile.css</span>,
|
|
and <span class="code">mobile.html.tmpl</span> from the distribution into your <span class="code">skin/Standard</span>
|
|
directory. Modify <span class="code">skins/Standard/index.html.tmpl</span> to take advantage of the new
|
|
almanac features, using the version shipped with the distribution for guidance. You will then need to
|
|
modify your <span class="code">skin.conf</span>.
|
|
<p>Add a new <span class="code">[[[Mobile]]]</span> section:</p>
|
|
|
|
<pre class="tty">[FileGenerator]
|
|
...
|
|
[[ToDate]]
|
|
...
|
|
[[[Mobile]]]
|
|
template = mobile.html.tmpl</pre>
|
|
|
|
<p>Then add <span class="code">mobile.css</span> and <span class="code">
|
|
favicon.ico</span> to the list of files to be copied on report generation:
|
|
</p>
|
|
|
|
<pre class="tty">[CopyGenerator]
|
|
copy_once = backgrounds/*, weewx.css, mobile.css, favicon.ico</pre>
|
|
</li>
|
|
</ol>
|
|
<p>Which approach you should take will depend on how extensively you have modified the stock skin distribution.
|
|
If the modifications are slight, approach #1 will be easier, otherwise use approach #2.
|
|
</p>
|
|
|
|
<h3>Backwards compatibility</h3>
|
|
|
|
<p>With the introduction of explicit control of output units in the templates such as</p>
|
|
|
|
<pre class="tty">$day.outTemp.max.degree_C</pre>
|
|
|
|
<p>the calling signature of the following two Python classes was changed</p>
|
|
<ul>
|
|
<li><span class="code">weewx.stats.TaggedStats</span></li>
|
|
<li><span class="code">weewx.stats.TimeSpanStats</span></li>
|
|
</ul>
|
|
<p>The example of writing a custom generator <span class="code">MyFileGenerator</span> (which produced "all
|
|
time" statistics) has been changed to reflect the new signatures.
|
|
</p>
|
|
|
|
<p>This will only affect you if you have written a custom generator.</p>
|
|
|
|
<h2>Upgrading to V1.8</h2>
|
|
|
|
<p>With the introduction of a standard archiving service, <span class="code">
|
|
StdArchive</span>, the names of some events have changed. This will not affect you unless you have written a
|
|
custom service.
|
|
</p>
|
|
|
|
<h2>Upgrading to V1.7</h2>
|
|
|
|
<p>V1.7 introduces <em>skins</em>. The skins live in subdirectory <span class="code">skins</span>. They are <em>not</em>
|
|
compatible with the old <span class="code">template</span> subdirectory --- you can't simply rename
|
|
<span class="code">templates</span> to <span class="code">skins</span>.
|
|
</p>
|
|
|
|
<p>The part of the configuration file dealing with the presentation layer has been split off into a separate
|
|
file <span class="code">skin.conf</span>. Hence, once again, the installation script <span class="code">setup.py</span>
|
|
will NOT merge your old <span class="code">
|
|
weewx.conf</span> configuration file into the new one. You will have to re-edit <span class="code">weewx.conf</span>
|
|
to put in your customizations. You may also have to edit <span class="code">
|
|
skin.conf</span> for whatever skin you choose (right now, only one skin, <em>Standard</em>, comes with the
|
|
distribution).
|
|
</p>
|
|
|
|
<p>However, a reinstall of V1.7 <em>will</em> merge your changes for <span class="code">weewx.conf</span>. It
|
|
will also merge any changes you have made to <span class="code">skin.conf</span> as well.
|
|
</p>
|
|
|
|
<p>Please check the following:</p>
|
|
<ul>
|
|
<li>Option "<span class="code">altitude</span>" in section <span class="code">[Station]</span> now
|
|
takes a unit. Hence, it should look something like:
|
|
<pre class='tty'>altitude = 120, meter</pre>
|
|
|
|
</li>
|
|
<li>In a similar manner, options <span class="code">heating_base</span> and <span
|
|
class="code">cooling_base</span> in <span class="code">skin.conf</span> also take units:
|
|
<pre class='tty'>heating_base = 65, degree_F
|
|
cooling_base = 65, degree_F</pre>
|
|
</li>
|
|
</ul>
|
|
<p>The directory '<span class="code">templates</span>' is no longer used; it has been replaced with
|
|
directory '<span class="code">skins</span>'. You may delete it if you wish:
|
|
</p>
|
|
|
|
<pre class="tty cmd">rm -r templates</pre>
|
|
|
|
<h2>Upgrading to V1.5</h2>
|
|
|
|
<p>Because the configuration file <span class="code">weewx.conf</span> changed significantly going from V1.4 to
|
|
V1.5, the installation script <span class="code">setup.py</span> will NOT merge your old configuration file
|
|
into the new one. You will have to re-edit <span class="code">weewx.conf</span> to put in your
|
|
customizations.
|
|
</p>
|
|
|
|
<h2>Upgrading to V1.4</h2>
|
|
|
|
<p>Option <span class="code">clock_check</span>, previously found in the <span class="code">[VantagePro]</span>
|
|
section, is now found in the <span class="code">[Station]</span> section. The install program will put a
|
|
default value in the new place, but it will not delete nor move your old value over. If you have changed
|
|
this value or if you cannot stand the thought of <span class="code">clock_check</span> appearing in two
|
|
different places, you should delete the old one found under <span class="code">[VantagePro]</span> and make
|
|
sure the new value, found under <span class="code">[Station]</span> is correct.
|
|
</p>
|
|
|
|
<p>Two Python files are no longer used, so they may be deleted from your installation if you wish:</p>
|
|
|
|
<pre class="tty cmd">rm bin/weewx/processdata.py
|
|
rm bin/weewx/mainloop.py</pre>
|
|
|
|
<p>In addition, file <span class="code">readme.htm</span> has been moved to subdirectory <span
|
|
class='code'>docs</span>, so the old one can be deleted:
|
|
</p>
|
|
|
|
<pre class="tty cmd">rm readme.htm</pre>
|
|
|
|
</div>
|
|
|
|
<div class="footer">
|
|
<p class="copyright"> © <a href="copyright.htm">Copyright</a> Tom Keffer</p>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</body>
|
|
|
|
</html>
|