mirror of
https://github.com/weewx/weewx.git
synced 2026-04-18 16:46:56 -04:00
5879 lines
253 KiB
HTML
5879 lines
253 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta content="en-us" http-equiv="Content-Language"/>
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
|
|
<title>weewx: User's Guide</title>
|
|
<link href="css/ui-lightness/jquery-ui-1.10.4.custom.min.css" rel="stylesheet"/>
|
|
<link href="css/jquery.tocify.css" rel="stylesheet"/>
|
|
<link href="css/weewx_docs.css" rel="stylesheet"/>
|
|
</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="upgrading.htm">Upgrade Guide</a>
|
|
</div>
|
|
<div id="toc_controls"></div>
|
|
<div id="toc_parent">
|
|
<div id="toc">
|
|
<!-- The table of contents will be injected here -->
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="main">
|
|
|
|
<div class="header">
|
|
<div class="logoref">
|
|
<a href='http://weewx.com'>
|
|
<img src='images/logo-weewx.png' class='logo' align='right' alt="weewx logo"/>
|
|
</a><br/>
|
|
<span class='version'>
|
|
Version: 3.5.0
|
|
</span>
|
|
</div>
|
|
<div class="title">
|
|
User's Guide to the <span class="code">weewx</span> Weather System
|
|
</div>
|
|
</div>
|
|
|
|
<div id="technical_content" class="content">
|
|
|
|
<p>
|
|
This is the complete guide to installing, configuring, and
|
|
troubleshooting <span class="code">weewx</span>.
|
|
</p>
|
|
|
|
<h1 id="about">About <span class="code">weewx</span></h1>
|
|
|
|
<p><span class="code"><a href="http://www.weewx.com">weewx</a></span> is
|
|
software, written in <a href="http://www.python.org">Python</a>, that
|
|
interacts with a weather station to produce plots, reports, and HTML
|
|
pages. It can optionally upload the reports to a remote Web server as
|
|
well as publish to weather services such as
|
|
<a href="http://www.wunderground.com">WeatherUnderground</a>,
|
|
<a href="http://wxqa.com">CWOP</a>, or
|
|
<a href="http://www.pwsweather.com/">PWSweather.com</a>.</p>
|
|
|
|
<p>Initial development began in the winter of 2008-2009, with the first
|
|
release in 2009.</p>
|
|
|
|
<p>The source code is hosted on <a href="https://github.com/weewx/weewx">GitHub</a>, while
|
|
downloads are available at
|
|
<a href="http://weewx.com/downloads"><span class="code">weewx.com/downloads</span></a>.</p>
|
|
|
|
<p><span class="code">weewx</span> is about 8,000 lines of code, plus
|
|
another 11,000 for the many drivers used by the supported hardware. </p>
|
|
|
|
<h1 id="hardware">Supported hardware</h1>
|
|
|
|
<p>
|
|
Many types of station hardware are supported. In addition to hardware
|
|
support, <span class="code">weewx</span> comes with a software
|
|
simulator, useful for testing and evaluation.
|
|
</p>
|
|
|
|
<p>The following table enumerates many of the weather stations that
|
|
are known to work with <span class='code'>weewx</span>. If your
|
|
station is not in the table, check the pictures at the
|
|
<a href="http://weewx.com/hardware.html">supported hardware page</a> —
|
|
it could be a variation of one of the supported models. You can also
|
|
check the <a href="http://weewx.com/hwcmp.html">station comparison</a>
|
|
table — sometimes new models use the same communication protocols
|
|
as older hardware.
|
|
</p>
|
|
|
|
<p>The maturity column indicates the degree of confidence in the
|
|
driver. For stations marked <span class="code">Tested</span>,
|
|
the station is routinely tested as part of the release process
|
|
and should work as documented. For stations not marked at all,
|
|
they are "known to work" using the indicated driver, but are not
|
|
routinely tested. For stations marked
|
|
<span class="code">Experimental</span>, we are still working
|
|
on the driver. There can be problems.
|
|
</p>
|
|
|
|
<table class="indent">
|
|
<caption>Weather hardware supported by <span class='code'>weewx</span></caption>
|
|
<tr class="first_row">
|
|
<td>Vendor</td>
|
|
<td>Model</td>
|
|
<td>Hardware<br/>Interface</td>
|
|
<td>Required<br/>Package</td>
|
|
<td>Station<br/>Driver</td>
|
|
<td>Maturity</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="6">AcuRite</td>
|
|
<td>01025</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>01035</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>01036</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>01525</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>02032</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>02064</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>AcuRite<sup><a href='#acurite'>13</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">Argent Data Systems</td>
|
|
<td>WS1</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WS1<sup><a href='#ads'>10</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Aercus</td>
|
|
<td>WS2083</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS3083</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="5">Ambient Weather</td>
|
|
<td>WS1090</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS2080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS2080A</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS2090</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS2095</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Cresta</td>
|
|
<td>WRX815</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>PWS720</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="3">DAZA</td>
|
|
<td>DZ-WH1080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>DZ-WS3101</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>DZ-WS3104</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="3">Davis</td>
|
|
<td>VantagePro2</td>
|
|
<td>Serial or USB</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Vantage<sup><a href='#vantage'>1</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VantagePro2</td>
|
|
<td>WeatherLink IP</td>
|
|
<td class="code"> </td>
|
|
<td>Vantage<sup><a href='#vantage'>1</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VantageVue</td>
|
|
<td>Serial or USB</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Vantage<sup><a href='#vantage'>1</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Elecsa</td>
|
|
<td>6975</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>6976</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="11">Fine Offset</td>
|
|
<td>WH1080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH1081</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH1091</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH1090</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS1080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WA2080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WA2081</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH2080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH2081</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH3080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WH3081</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="1">General Tools</td>
|
|
<td>WS831DL</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="6">Hideki</td>
|
|
<td>DV928</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE821</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE827</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE831</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE838</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE923</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">Huger</td>
|
|
<td>WM918</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>WMR9x8<sup><a href='#wmr9x8'>5</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">IROX</td>
|
|
<td>Pro X</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="4">La Crosse</td>
|
|
<td>C86234</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WS28xx<sup><a href='#ws28xx'>8</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS-1640</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS-23XX</td>
|
|
<td>Serial</td>
|
|
<td class="code">fcntl/select</td>
|
|
<td>WS23xx<sup><a href='#ws23xx'>7</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS-28XX</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WS28xx<sup><a href='#ws28xx'>8</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Maplin</td>
|
|
<td>N96GY</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>N96FY</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="3">Meade</td>
|
|
<td>TE923W</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE923W-M</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TE924W</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">Mebus</td>
|
|
<td>TE923</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">National Geographic</td>
|
|
<td>265</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="14">Oregon Scientific</td>
|
|
<td>WMR88</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR88A</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR100</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR100N</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR180</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR180A</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMRS200</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR200</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR200<sup><a href="#wmr200">3</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR200A</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR200<sup><a href="#wmr200">3</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR300</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR300<sup><a href="#wmr300">4</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR300A</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR300<sup><a href="#wmr300">4</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR918</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>WMR9x8<sup><a href='#wmr9x8'>5</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR928N</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>WMR9x8<sup><a href='#wmr9x8'>5</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WMR968</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>WMR9x8<sup><a href='#wmr9x8'>5</a></sup></td>
|
|
<td>Tested</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="4">PeetBros</td>
|
|
<td>Ultimeter 100</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Ultimeter<sup><a href='#peetbros'>11</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Ultimeter 800</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Ultimeter<sup><a href='#peetbros'>11</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Ultimeter 2000</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Ultimeter<sup><a href='#peetbros'>11</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Ultimeter 2100</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>Ultimeter<sup><a href='#peetbros'>11</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">RainWise</td>
|
|
<td>Mark III</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>CC3000<sup><a href='#rainwise'>12</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>CC3000</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>CC3000<sup><a href="#rainwise">12</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="3">Radio Shack</td>
|
|
<td>63-256</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR100<sup><a href='#wmr100'>2</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WX200</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WMR200<sup><a href="#wmr200">3</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>63-1016</td>
|
|
<td>Serial</td>
|
|
<td class="code">pyserial</td>
|
|
<td>WMR9x8<sup><a href='#wmr9x8'>5</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Sinometer</td>
|
|
<td>WS1080 / WS1081</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS3100 / WS3101</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan='2'>TechnoLine</td>
|
|
<td>WS-2300</td>
|
|
<td>Serial</td>
|
|
<td class="code">fcntl/select</td>
|
|
<td>WS23xx<sup><a href='#ws23xx'>7</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>WS-2350</td>
|
|
<td>Serial</td>
|
|
<td class="code">fcntl/select</td>
|
|
<td>WS23xx<sup><a href='#ws23xx'>7</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan='5'>TFA</td>
|
|
<td>Matrix</td>
|
|
<td>Serial</td>
|
|
<td class="code">fcntl/select</td>
|
|
<td>WS23xx<sup><a href='#ws23xx'>7</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Nexus</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Opus</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WS28xx<sup><a href='#ws28xx'>8</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Primus</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>WS28xx<sup><a href='#ws28xx'>8</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Sinus</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">Tycon</td>
|
|
<td>TP1080WC</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Watson</td>
|
|
<td>W-8681</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>WX-2008</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">Velleman</td>
|
|
<td>WS3080</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>FineOffsetUSB<sup><a href='#fousb'>6</a></sup></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan="2">Ventus</td>
|
|
<td>W831</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
<tr>
|
|
<td>W928</td>
|
|
<td>USB</td>
|
|
<td class="code">pyusb</td>
|
|
<td>TE923<sup><a href='#te923'>9</a></sup></td>
|
|
<td>Experimental</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<ol>
|
|
<li><a id="vantage">Davis "Vantage" series</a> of weather
|
|
stations, including the
|
|
<a href="http://www.davisnet.com/weather/products/vantage-pro-professional-weather-stations.asp">VantagePro2</a>™
|
|
and
|
|
<a href="http://www.vantagevue.com/">VantageVue</a>™,
|
|
using serial, USB, or
|
|
<a href="http://www.davisnet.com/weather/products/weather_product.asp?pnum=06555">WeatherLinkIP</a>™
|
|
connections. Both the "Rev A" (firmware dated before
|
|
22 April 2002) and "Rev B" versions are supported.
|
|
</li>
|
|
<li><a id="wmr100">Oregon Scientific WMR-100 stations.</a> Tested on the
|
|
<a href="http://us.oregonscientific.com/cat-Weather-sub-Professional-Weather-Stations-prod-Pro-Wireless-Weather-Station.html">Oregon
|
|
Scientific WMR100N</a>.
|
|
</li>
|
|
<li><a id="wmr200">Oregon Scientific WMR-200 stations.</a> Tested on the
|
|
<a href="http://www.oregonscientificstore.com/Oregon-Scientific-WMR200-Bundle-Complete-Weather-Bundle.data">Oregon
|
|
Scientific WMR200</a>.
|
|
</li>
|
|
<li><a id="wmr200">Oregon Scientific WMR-300 stations.</a> Tested on the
|
|
<a href="http://www.oregonscientificstore.com/p-358-oregon-scientific-wmr300-ultra-precision-professional-weather-system.aspx">Oregon
|
|
Scientific WMR300A</a>.
|
|
</li>
|
|
<li><a id="wmr9x8">Oregon Scientific WMR-9x8 stations.</a> Tested on the
|
|
<a href="http://www.oregonscientificstore.com/oregon_scientific/product.asp?itmky=659831">Oregon Scientific
|
|
WMR968</a>.
|
|
</li>
|
|
<li><a id="fousb">Fine Offset 10xx, 20xx, and 30xx stations.</a>
|
|
Tested on the
|
|
<a href="http://www.ambientweather.com/amws2080.html">Ambient Weather WS2080</a>.
|
|
</li>
|
|
<li><a id="ws23xx">La Crosse WS-23xx stations.</a> Tested on the
|
|
<a href="http://lacrossetechnologies.com/2317/">La Crosse 2317</a>.
|
|
</li>
|
|
<li><a id="ws28xx">La Crosse WS-28xx stations.</a> Tested on the
|
|
<a href="http://lacrossetechnologies.com/2814/">La Crosse C86234</a>.
|
|
</li>
|
|
<li><a id="te923">Hideki Professional Weather Stations.</a> Tested on the
|
|
<a href="http://www.ambientweather.com/hotewiwest.html">Meade TE923</a>.
|
|
</li>
|
|
<li><a id="ads">ADS WS1 Stations.</a> Tested on the
|
|
<a href="http://www.argentdata.com/catalog/product_info.php?products_id=135">WS1</a>.
|
|
</li>
|
|
<li><a id="peetbros">PeetBros Ultimeter Stations.</a> Tested on the
|
|
<a href="http://www.peetbros.com/">Ultimeter 2000</a>.
|
|
</li>
|
|
<li><a id="rainwise">RainWise Mark III Stations.</a> Tested on the
|
|
<a href="http://www.rainwise.com/">CC3000</a>.
|
|
</li>
|
|
<li><a id="acurite">AcuRite Weather Stations.</a> Tested on the
|
|
<a href="http://www.acurite.com/8-pro-digital-weather-station-with-pc-connect-01036.html">01036RX</a>.
|
|
</li>
|
|
</ol>
|
|
|
|
<h1 id="prerequisites">System requirements</h1>
|
|
|
|
<h2>Hardware</h2>
|
|
|
|
<p>Weewx is written in Python, so it has the overhead associated with that
|
|
language. Nevertheless, it is "fast enough" on just about any hardware. It
|
|
has been run on everything from an early MacBook to a router!</p>
|
|
|
|
<p>I run <span class="code">weewx</span> on a Fit-PC with a 500 MHz AMD
|
|
Geode processor and 512 MB of memory. Configured this way, it
|
|
consumes about 5% of the CPU, 100 MB of virtual memory,
|
|
and 20 MB of real memory. </p>
|
|
|
|
<p>Weewx also runs great on a Raspberry Pi, although report generation will take longer.
|
|
For example, the 12 "To Date" templates take about 5.1 seconds on the RPi,
|
|
compared to 3.0 seconds on my Fit-PC, and a mere 0.9 seconds on my vintage
|
|
Dell Optiplex 745.</p>
|
|
|
|
<h2>Time</h2>
|
|
|
|
<p> You should run a <a href="http://www.ntp.org/">NTP</a> daemon on your
|
|
server to ensure that it is synchronized with the correct time. Doing so
|
|
will greatly reduce errors, especially if you send data to services such
|
|
as the Weather Underground. </p>
|
|
|
|
<p>The time on some stations is automatically synchronized with the
|
|
<span class="code">weewx</span> server nominally every four hours.
|
|
The synchronization frequency can be adjusted in the
|
|
<span class='code'>weewx</span> configuration.</p>
|
|
|
|
<h2>Python</h2>
|
|
|
|
<p>Python 2.5, 2.6, or 2.7 is required. Python 3 will not work. For Python 2.5, see
|
|
<a href="#python2_5">the special instructions below</a>.</p>
|
|
|
|
<h1 id="installing">Installing <span class="code">weewx</span></h1>
|
|
|
|
<h2>Required skills</h2>
|
|
|
|
<p>
|
|
In the world of open-source hobbyist software,
|
|
<span class="code"> weewx</span> is pretty easy to install and
|
|
configure. There are not many package dependencies, the
|
|
configuration is simple, and this guide includes extensive
|
|
instructions.
|
|
There are thousands of people who have successfully done an
|
|
install. However, there is no "point-and-click" interface, so
|
|
you will have to do some manual configuring.
|
|
</p>
|
|
|
|
<p>You should have the following skills:</p>
|
|
<ul>
|
|
<li>The patience to read and follow this guide;</li>
|
|
<li>Willingness and ability to edit a configuration file;</li>
|
|
<li>Some familiarity with Linux or other Unix derivatives;</li>
|
|
<li>Ability to do simple Unix tasks such as changing file
|
|
permissions and running commands;
|
|
</li>
|
|
<li>No programming experience is necessary unless you wish
|
|
to extend weewx. In this case, you should have some
|
|
familiarity with Python.
|
|
</li>
|
|
</ul>
|
|
<p>If you get stuck, there is a very active
|
|
<a href="https://groups.google.com/forum/#!forum/weewx-user">User's Group</a> to
|
|
help, but, please, try to solve the problem yourself before posting.
|
|
</p>
|
|
|
|
<h2>Installation methods</h2>
|
|
|
|
<p>
|
|
<span class='code'>Weewx</span> can be installed from a DEB (Debian) or RPM
|
|
(Redhat, SUSE) package, or it can be installed using the standard Python utility
|
|
<span class='code'>setup.py</span>.
|
|
</p>
|
|
|
|
<p>
|
|
The DEB or RPM package approach is simpler and is the recommended method for
|
|
beginners. However, it requires root privileges, and will install the
|
|
bits and pieces of <span class="code">weewx</span> in standard
|
|
operating system locations across the file system instead of in a
|
|
single directory. The net effect is that configuration files,
|
|
templates, and code will all be installed in separate locations, most
|
|
of which will require root privileges to modify.
|
|
</p>
|
|
|
|
<p>
|
|
Installation using <span class="code">setup.py</span> is the
|
|
recommended method for those who plan to write custom services and
|
|
reports for <span class='code'>weewx</span>. It will put everything
|
|
in a single directory, specified by the parameter <span class='code'>home</span>
|
|
in the <span class='code'>setup.cfg</span> file, making it
|
|
easier to modify <span class="code">weewx</span>. This file is not
|
|
used by the other installation methods. If the user installing <span
|
|
class='code'>weewx</span> has permission to write to the directory,
|
|
root privileges will not be required to install, run, or modify <span
|
|
class='code'>weewx</span>.
|
|
</p>
|
|
|
|
<h2><a href='debian.htm'>Installing from DEB package</a></h2>
|
|
|
|
<p>For Debian, Ubuntu, Mint, and Raspian operating systems, follow the
|
|
<a href='debian.htm'>instructions for Debian-based systems</a>.</p>
|
|
|
|
<h2><a href='redhat.htm'>Installing from Redhat RPM package</a></h2>
|
|
|
|
<p>For Redhat, CentOS, Fedora operating systems, follow the
|
|
the <a href='redhat.htm'>instructions for Redhat-based systems</a>.</p>
|
|
|
|
<h2><a href='suse.htm'>Installing from SuSE RPM package</a></h2>
|
|
|
|
<p>For SuSE and OpenSUSE, follow the
|
|
<a href='suse.htm'>instructions for SuSE-based systems</a>.</p>
|
|
|
|
<h2><a href='setup.htm'>Installing using the Python tool setup.py</a></h2>
|
|
|
|
<p>For all other operating systems, follow the
|
|
<a href='setup.htm'><span class="code">setup.py</span> instructions</a>. This method
|
|
can also be used on Debian-, Redhat-, and SUSE-based operating systems as well,
|
|
and may be a better choice if you intend to heavily customize Weewx.
|
|
</p>
|
|
|
|
<h2>Where to find things</h2>
|
|
|
|
<p>
|
|
Here is a summary of the layout for the different install methods, along
|
|
with the symbolic names used for each role. These names are used
|
|
throughout the documentation. </p>
|
|
|
|
<div id='dir-layout-table' class='tabs' style='padding-top:1em'>
|
|
<div id='layout-tab-deb' class='tab selected' onclick="showtab('layout','deb')">
|
|
Debian
|
|
<img src='images/logo-debian.png' class='thumbnail' alt="Debian logo"/>
|
|
<img src='images/logo-ubuntu.png' class='thumbnail' alt="Ubuntu logo"/>
|
|
<img src='images/logo-mint.png' class='thumbnail' alt="Mint logo"/>
|
|
</div>
|
|
<div id='layout-tab-rpm' class='tab' onclick="showtab('layout','rpm')">
|
|
Redhat/SUSE
|
|
<img src='images/logo-redhat.png' class='thumbnail' alt="Redhat logo"/>
|
|
<img src='images/logo-centos.png' class='thumbnail' alt="Centos logo"/>
|
|
<img src='images/logo-fedora.png' class='thumbnail' alt="Fedora logo"/>
|
|
<img src='images/logo-suse.png' class='thumbnail' alt="SUSE logo"/>
|
|
</div>
|
|
<div id='layout-tab-setup' class='tab' onclick="showtab('layout','setup')">setup.py</div>
|
|
</div>
|
|
|
|
<div id='layout' style='clear:both; width: 80%;'>
|
|
<div id='layout-deb'>
|
|
<table class='locations' width='100%'>
|
|
<tr class='selected'>
|
|
<td colspan='3' class='locations_banner'>Application layout for install using DEB package</td>
|
|
</tr>
|
|
<tr class="first_row" style="background-color: inherit">
|
|
<td>Role</td>
|
|
<td>Symbolic Name</td>
|
|
<td>Nominal Location</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Executables</td>
|
|
<td class="symcode">BIN_ROOT</td>
|
|
<td class='tty'>/usr/share/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Configuration directory</td>
|
|
<td class="symcode">CONFIG_ROOT</td>
|
|
<td class='tty'>/etc/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Skins and templates</td>
|
|
<td class="symcode">SKIN_ROOT</td>
|
|
<td class='tty'>/etc/weewx/skins/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>SQLite databases</td>
|
|
<td class="symcode">SQLITE_ROOT</td>
|
|
<td class='tty'>/var/lib/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Web pages and images</td>
|
|
<td class="symcode">HTML_ROOT</td>
|
|
<td class='tty'>/var/www/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Documentation</td>
|
|
<td class="symcode">DOC_ROOT</td>
|
|
<td class='tty'>/usr/share/doc/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>PID file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/run/weewx.pid</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Log file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/log/syslog</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div id='layout-rpm' style='display:none'>
|
|
<table class='locations' width='100%'>
|
|
<tr class='selected'>
|
|
<td colspan='3' class='locations_banner'>Application layout for install using RPM package</td>
|
|
</tr>
|
|
<tr class="first_row" style="background-color: inherit">
|
|
<td>Role</td>
|
|
<td>Symbolic Name</td>
|
|
<td>Nominal Location</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Executables</td>
|
|
<td class="symcode">BIN_ROOT</td>
|
|
<td class='tty'>/usr/share/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Configuration directory</td>
|
|
<td class="symcode">CONFIG_ROOT</td>
|
|
<td class='tty'>/etc/weewx</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Skins and templates</td>
|
|
<td class="symcode">SKIN_ROOT</td>
|
|
<td class='tty'>/etc/weewx/skins/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>SQLite databases</td>
|
|
<td class="symcode">SQLITE_ROOT</td>
|
|
<td class='tty'>/var/lib/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Web pages and images</td>
|
|
<td class="symcode">HTML_ROOT</td>
|
|
<td class='tty'>/var/www/html/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Documentation</td>
|
|
<td class="symcode">DOC_ROOT</td>
|
|
<td class='tty'>/usr/share/doc/weewx-x.y.z/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>PID file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/run/weewx.pid</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Log file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/log/messages</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div id='layout-setup' style='display:none'>
|
|
<table class='locations' width='100%'>
|
|
<tr class='selected'>
|
|
<td colspan='3' class='locations_banner'>Application layout for install using <span class='code'>setup.py</span>
|
|
</td>
|
|
</tr>
|
|
<tr class="first_row" style="background-color: inherit">
|
|
<td>Role</td>
|
|
<td>Symbolic Name</td>
|
|
<td>Nominal Location</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class='code'>weewx</span> root directory</td>
|
|
<td class="symcode">WEEWX_ROOT</td>
|
|
<td class="tty">/home/weewx</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Executables</td>
|
|
<td class="symcode">BIN_ROOT</td>
|
|
<td class='tty'>/home/weewx/bin/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Configuration directory</td>
|
|
<td class="symcode">CONFIG_ROOT</td>
|
|
<td class='tty'>/home/weewx/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Skins and templates</td>
|
|
<td class="symcode">SKIN_ROOT</td>
|
|
<td class='tty'>/home/weewx/skins/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>SQLite databases</td>
|
|
<td class="symcode">SQLITE_ROOT</td>
|
|
<td class='tty'>/home/weewx/archive</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Web pages and images</td>
|
|
<td class="symcode">HTML_ROOT</td>
|
|
<td class='tty'>/home/weewx/public_html/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Documentation</td>
|
|
<td class="symcode">DOC_ROOT</td>
|
|
<td class='tty'>/home/weewx/docs/</td>
|
|
</tr>
|
|
<tr>
|
|
<td>PID file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/run/weewx.pid</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Log file</td>
|
|
<td class="symcode"></td>
|
|
<td class='tty'>/var/log/syslog</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<h1 id="wee_config_utility">The utility <span class="code">wee_config</span></h1>
|
|
|
|
<p>
|
|
When you install <span class="code">weewx</span> for the first time,
|
|
the installation process will prompt you for the most essential
|
|
options, such as the type of hardware you are using, latitude,
|
|
longitude, or altitude. But, what if you want to change these later?
|
|
In particular, what if you want to change device drivers? You could
|
|
edit the definitive configuration file, <span class="code">weewx.conf</span>,
|
|
by hand — described in detail in the <a href="#weewxconf">next section</a>
|
|
— but it's a big file with lots of nuances. Alternatively, if
|
|
you're just changing something simple, you may be able to use the
|
|
utility <span class="code">wee_config</span>.
|
|
</p>
|
|
|
|
<p>
|
|
Before starting, it's worth running it with the <span
|
|
class="code">--help</span> option to see how it is used:
|
|
</p>
|
|
<pre class="tty cmd">wee_config --help</pre>
|
|
<p>This results in:</p>
|
|
<pre class="tty">Usage: wee_config --help
|
|
wee_config --version
|
|
wee_config --list-drivers
|
|
wee_config --install --dist-config=DIST_CONFIG --output=OUT_CONFIG
|
|
[--driver=DRIVER] [--units=(us|metric)]
|
|
[--latitude=yy.y] [--longitude=xx.x] [--altitude=zz.z,(foot|meter)]
|
|
[--location="Home Sweet Home"]
|
|
[--no-prompt] [--no-backup]
|
|
wee_config --upgrade CONFIG_FILE|--config=CONFIG_FILE
|
|
--dist-config=DIST_CONFIG
|
|
[--output=OUT_CONFIG] [--no-prompt] [--no-backup] [--warn-on-error]
|
|
wee_config --reconfigure CONFIG_FILE|--config=CONFIG_FILE
|
|
[--driver=DRIVER] [--units=(us|metric)]
|
|
[--latitude=yy.y] [--longitude=xx.x] [--altitude=zz.z,(foot|meter)]
|
|
[--location="Home Sweet Home"]
|
|
[--output=OUT_CONFIG] [--no-prompt] [--no-backup]
|
|
|
|
Commands:
|
|
|
|
--list-drivers List the available weewx device drivers, then exit.
|
|
--install Install a new configuration file starting with the contents of
|
|
DIST_CONFIG, prompting for station parameters.
|
|
--upgrade Update the contents of configuration file CONFIG_FILE to the
|
|
installed version, then merge the result with the contents of
|
|
configuration file DIST_CONFIG.
|
|
--reconfigure Modify an existing configuration file CONFIG_FILE with any
|
|
specified station parameters. Use this command with the
|
|
driver option to change the device driver.
|
|
|
|
Station parameters:
|
|
|
|
--driver --units
|
|
--latitude --longitude
|
|
--altitude --location
|
|
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--version Show the weewx version then exit.
|
|
--list-drivers List the available device drivers.
|
|
--install Install a new configuration file.
|
|
--upgrade Update an existing configuration file, then merge with
|
|
contents of DIST_CONFIG.
|
|
--reconfigure Reconfigure an existing configuration file.
|
|
--config=CONFIG_FILE Use configuration file CONFIG_FILE.
|
|
--dist-config=DIST_CONFIG
|
|
Use template configuration file DIST_CONFIG.
|
|
--output=OUT_CONFIG Save to configuration file OUT_CONFIG. If not
|
|
specified then replace existing configuration file.
|
|
--driver=DRIVER Use the driver DRIVER. For example,
|
|
weewx.driver.vantage
|
|
--latitude=yy.y The station latitude in decimal degrees.
|
|
--longitude=xx.x The station longitude in decimal degrees.
|
|
--altitude=zz,(foot|meter)
|
|
The station altitude in either feet or meters. For
|
|
example, '750,foot' or '320,meter'
|
|
--location=LOCATION A text description of the station. For example,
|
|
"Santa's workshop, North Pole"
|
|
--units=(metric|us) Set display units to 'metric' or 'us'.
|
|
--no-prompt Do not prompt. Use default or specified values.
|
|
--no-backup When replacing an existing configuration file, do not
|
|
create a backup copy.
|
|
--warn-on-error Only warn if an update is not possible. Default
|
|
behavior is to warn then exit.
|
|
--debug Show diagnostic information while running.
|
|
</pre>
|
|
|
|
<p>
|
|
The utility is pretty good about "guessing" where your configuration
|
|
file <span class="code">weewx.conf</span> is, but if you've done an
|
|
unusual install, you may have to tell it explicitly. You can do this by
|
|
either putting the location directly in the command line:
|
|
</p>
|
|
|
|
<pre class="tty cmd">wee_config /home/weewx/weewx.conf</pre>
|
|
|
|
<p>
|
|
or by using option <span class="code">--config</span>:
|
|
</p>
|
|
|
|
<pre class="tty cmd">wee_config --config=/home/weewx/weewx.conf</pre>
|
|
|
|
<h2>Changing device drivers</h2>
|
|
|
|
<p>
|
|
The most common use for <span class="code">wee_config</span> is to
|
|
change device drivers. Say that you originally installed
|
|
<span class="code">weewx</span> with the Simulator. Now you've bought a
|
|
Davis Vantage and you want to switch to that. Here's how you do it.
|
|
First, if you don't know the name of the driver, you can list all the
|
|
drivers available in your weewx install:
|
|
</p>
|
|
|
|
<pre class="tty cmd">wee_config --list-drivers</pre>
|
|
|
|
<p>This will result in something like:</p>
|
|
|
|
<pre class="tty">
|
|
Module name Driver name Version Status
|
|
weewx.drivers.acurite AcuRite 0.19 No module named usb
|
|
weewx.drivers.cc3000 CC3000 0.8
|
|
weewx.drivers.fousb FineOffsetUSB 1.7 No module named usb
|
|
weewx.drivers.simulator Simulator 3.0
|
|
weewx.drivers.te923 TE923 0.14 No module named usb
|
|
weewx.drivers.ultimeter Ultimeter 0.13
|
|
weewx.drivers.vantage Vantage 3.0
|
|
weewx.drivers.wmr100 WMR100 3.0 No module named usb
|
|
weewx.drivers.wmr200 WMR200 3.0 No module named usb
|
|
weewx.drivers.wmr9x8 WMR9x8 3.0
|
|
weewx.drivers.ws1 WS1 0.19
|
|
weewx.drivers.ws23xx WS23xx 0.24
|
|
weewx.drivers.ws28xx WS28xx 0.34 No module named usb </pre>
|
|
|
|
<p>The column <span class="code">Status</span> can give you some indication of whether you are missing
|
|
any modules to use this driver. It's not completely accurate, but works for most drivers.</p>
|
|
<p>
|
|
From this list, we can see that the name of the driver for the Vantage is
|
|
<span class="code">weewx.drivers.vantage</span>. Now run
|
|
<span class="code">wee_config</span>, with the
|
|
<span class="code">--reconfigure</span>
|
|
command, specifying that driver:
|
|
</p>
|
|
<pre class="tty cmd">wee_config --reconfigure --driver=weewx.drivers.vantage</pre>
|
|
|
|
<p>
|
|
The utility will go through your previously selected options, such as
|
|
station description, latitude, longitude, altitude, <i>etc.</i>. Your
|
|
previously selected values, <em>including</em> the specified device driver,
|
|
will all be the defaults. So, all you have to do is keep hitting
|
|
enter. This is what it looked like when I switched from the simulator
|
|
to the Vantage driver:
|
|
</p>
|
|
<pre class="tty">Using configuration file /home/weewx/weewx.conf
|
|
Enter a brief description of the station, such as its location. For example:
|
|
Santa's Workshop, North Pole
|
|
description [Hood River, Oregon]:
|
|
Specify altitude, with units 'foot' or 'meter'. For example:
|
|
35, foot
|
|
12, meter
|
|
altitude [700, foot]:
|
|
Specify latitude in decimal degrees, negative for south.
|
|
latitude [45]:
|
|
Specify longitude in decimal degrees, negative for west.
|
|
longitude [-125]:
|
|
Indicate the preferred units for display: 'metric' or 'us'
|
|
units [metricwx]:
|
|
Installed drivers include:
|
|
0) AcuRite (weewx.drivers.acurite)
|
|
1) CC3000 (weewx.drivers.cc3000)
|
|
2) FineOffsetUSB (weewx.drivers.fousb)
|
|
3) Simulator (weewx.drivers.simulator)
|
|
4) TE923 (weewx.drivers.te923)
|
|
5) Ultimeter (weewx.drivers.ultimeter)
|
|
6) Vantage (weewx.drivers.vantage)
|
|
7) WMR100 (weewx.drivers.wmr100)
|
|
8) WMR200 (weewx.drivers.wmr200)
|
|
9) WMR9x8 (weewx.drivers.wmr9x8)
|
|
10) WS1 (weewx.drivers.ws1)
|
|
11) WS23xx (weewx.drivers.ws23xx)
|
|
12) WS28xx (weewx.drivers.ws28xx)
|
|
choose a driver [6]:
|
|
Specify the hardware interface, either 'serial' or 'ethernet'.
|
|
If the station is connected by serial, USB, or serial-to-USB
|
|
adapter, specify serial. Specify ethernet for stations with
|
|
WeatherLinkIP interface.
|
|
type [serial]:
|
|
Specify a port for stations with a serial interface, for
|
|
example /dev/ttyUSB0 or /dev/ttyS0.
|
|
port [/dev/ttyUSB0]:
|
|
Saved backup to /home/weewx/weewx.conf.20150430084525
|
|
Saved configuration to /home/weewx/weewx.conf
|
|
</pre>
|
|
|
|
<p>
|
|
If this is too much trouble, you can specify the <span class="code">--no-prompt</span>
|
|
option:
|
|
</p>
|
|
|
|
<pre class="tty cmd">wee_config --reconfigure --driver=weewx.drivers.vantage --no-prompt</pre>
|
|
|
|
<p>This will accept all the defaults, including your new device
|
|
driver, without asking for any input.</p>
|
|
|
|
<h2>Other <span class="code">wee_config</span> commands.</h2>
|
|
|
|
<p>The other commands offered by <span class="code">wee_config</span>,
|
|
such as <span class="code">--install</span> and
|
|
<span class="code">--upgrade</span>, are used by the various <span class="code">weewx</span>
|
|
installers and are not generally intended for the end user.</p>
|
|
|
|
<h1 id="weewxconf">The configuration file <span class="code">weewx.conf</span></h1>
|
|
|
|
<p>The configuration file <span class="code">weewx.conf</span> is a big
|
|
text file that holds the configuration information about your
|
|
installation of <span class="code">weewx.</span> This includes things
|
|
such as:</p>
|
|
<ul>
|
|
<li>The type of hardware you have;</li>
|
|
<li>The name of your station;</li>
|
|
<li>What kind of database to use and where is it located;</li>
|
|
<li>How to recognize out-of-range observations, <i>etc</i>.</li>
|
|
</ul>
|
|
|
|
<p class='note'>The location of <span class="code">weewx.conf</span>
|
|
will depend on your installation method and operating
|
|
system. For example, if you used the
|
|
<span class='code'>setup.py</span> method, then the nominal location is
|
|
<span class='code'>/home/weewx</span>, and so your
|
|
configuration file will be
|
|
<span class='code'>/home/weewx/weewx.conf</span>. For other
|
|
configurations, consult the
|
|
<a href="#dir-layout-table">application layout table</a> in the
|
|
'Installation methods' section.</p>
|
|
|
|
<p class='note'>There is another configuration file, <span class="code">skin.conf</span>,
|
|
for presentation-specific options. It is described in the
|
|
<a href="customizing.htm">Customizing Guide</a>, under section <em>
|
|
<a href="customizing.htm#standard_skin">The Standard <span class="code">skin.conf</span></a></em>.</p>
|
|
|
|
<p>The following sections are the definitive guide to the many configuration options
|
|
available in <span class='code'>weewx.conf</span>. <em>They contain many
|
|
more options than you are likely to need!</em> —
|
|
you can safely ignore most of them. The truly important ones, the ones
|
|
you are likely to have to customize for your station, are
|
|
<span class="config_important">highlighted</span>.</p>
|
|
|
|
<p>Default values are provided for many options, meaning that if they are
|
|
not listed in the configuration file <em>at all</em>,
|
|
<span class="code">weewx</span> will pick sensible values. When the
|
|
documentation below gives a "default value" this is what it
|
|
means.</p>
|
|
|
|
<p>What follows is organized by the different sections of the
|
|
configuration file. </p>
|
|
|
|
<h2>General</h2>
|
|
|
|
<p>The options declared at the top are not actually part of any section.</p>
|
|
|
|
<p class="config_option">debug </p>
|
|
|
|
<p>Set to 1 to have the program perform extra debug checks, as well as
|
|
emit extra information in the log file. This is strongly recommended
|
|
if you are having trouble. Otherwise, set to 0. Default
|
|
is 0 (no debug).
|
|
</p>
|
|
|
|
<p class="config_option">WEEWX_ROOT </p>
|
|
|
|
<p>Set to the root directory of the <span class="code">weewx</span> file
|
|
hierarchy for this station. Normally, this is set automatically by the
|
|
installation process. Required. No default.
|
|
</p>
|
|
|
|
<p class="config_option">socket_timeout </p>
|
|
|
|
<p>Set to how long to wait before declaring a socket time out. This is
|
|
used when using FTP to send data to a web server or when sending data
|
|
to the Weather Underground. Twenty (20) seconds is reasonable. Default
|
|
is 20. </p>
|
|
|
|
<p class='config_option'>gc_interval</p>
|
|
|
|
<p>Set to how often garbage collection should be performed by the Python
|
|
runtime engine. Default is every 10,800 seconds (3 hours).</p>
|
|
|
|
<h2 class="config_section">[Station]</h2>
|
|
|
|
<p>This section covers options relating to your weather station setup. </p>
|
|
|
|
<p class="config_important">location </p>
|
|
|
|
<p>The station location should be a UTF-8 string that describes the
|
|
geography of where your weather station is located. Required.
|
|
No default.</p>
|
|
<pre class="tty">location = "A small ranch in Kentucky"</pre>
|
|
<p class="config_important">latitude <br/>
|
|
longitude </p>
|
|
|
|
<p>The lat/lon should be set in decimal degrees, negative for southern and
|
|
western hemispheres, respectively. Required. No default. </p>
|
|
<pre class="tty">latitude = 38.8977
|
|
longitude = -77.0366</pre>
|
|
<p class="config_option"><span class="config_important">altitude</span></p>
|
|
|
|
<p>Normally the station altitude is downloaded from your hardware, but not
|
|
all stations support this. Set to the altitude of the station and the
|
|
unit used for the altitude. Example: </p>
|
|
<pre class="tty">altitude = 700, foot</pre>
|
|
<p>An example in meters:</p>
|
|
<pre class="tty">altitude = 220, meter</pre>
|
|
<p class="config_important">station_type </p>
|
|
|
|
<p>Set to the type of hardware you are using.</p>
|
|
<pre class="tty">station_type = Simulator</pre>
|
|
<p>Valid options include:</p>
|
|
<table class="indent">
|
|
<tr class="first_row">
|
|
<td>Option</td>
|
|
<td>Description</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">Simulator</td>
|
|
<td>A software weather station simulator. Useful for testing and
|
|
debugging.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">AcuRite</td>
|
|
<td>AcuRite 5-in-1 stations with USB interface</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">CC3000</td>
|
|
<td>RainWise CC3000 data logger</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">FineOffsetUSB</td>
|
|
<td>Fine Offset 10xx, 20xx, and 30xx stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">TE923</td>
|
|
<td>Hideki TE923 stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">Ultimeter</td>
|
|
<td>PeetBros Ultimeter stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">Vantage</td>
|
|
<td>Davis Vantage weather stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WMR100</td>
|
|
<td>Oregon Scientific WMR100 series stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WMR200</td>
|
|
<td>Oregon Scientific WMR200 series stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WMR300</td>
|
|
<td>Oregon Scientific WMR300 series stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WMR9x8</td>
|
|
<td>Oregon Scientific WMR-918/968 series stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WS1</td>
|
|
<td>Argent Data Systems WS1 stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WS23xx</td>
|
|
<td>La Crosse 23xx stations</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code first_col">WS28xx</td>
|
|
<td>La Crosse 28xx stations</td>
|
|
</tr>
|
|
</table>
|
|
<p id="station_url" class="config_option"><span class="config_important">station_url</span></p>
|
|
|
|
<p>If you have a website, you may optionally specify an URL for
|
|
its HTML server. It will be included in the RSS file generated
|
|
by weewx and, if you choose to opt into the <a href="#station_registry">station
|
|
registry</a>, it will also be included in the
|
|
<a href="http://weewx.com/stations.html">map of weewx stations</a>.</p>
|
|
|
|
<p>Example:</p>
|
|
<pre class="tty">station_url = http://www.mywebsite.com</pre>
|
|
<p class="config_option" id="rain_year_start">rain_year_start
|
|
</p>
|
|
|
|
<p>Normally the start of the rain year is downloaded from your hardware,
|
|
but not all stations support this. Set to the start of your rain year,
|
|
for example, 10, if your rain year starts in October (as mine does).
|
|
Default is 1. </p>
|
|
<pre class="tty">rain_year_start = 1</pre>
|
|
<p class="config_option" id="week_start">week_start </p>
|
|
|
|
<p>Start of the week. 0=Monday, 1= Tuesday, ... , 6 = Sunday. Default is 6 (Sunday)
|
|
</p>
|
|
<pre class="tty">week_start = 0</pre>
|
|
|
|
<h3 class="config_section">[Simulator]</h3>
|
|
|
|
<p>This section is for options relating to the software weather station simulator
|
|
that comes with <span class="code">weewx</span>.</p>
|
|
|
|
<p class="config_option">loop_interval</p>
|
|
|
|
<p>The time (in seconds) between emitting loop packets. Default is 2.5</p>
|
|
|
|
<p class="config_option">mode</p>
|
|
|
|
<p>One of either <span class='code'>simulator</span> or <span class='code'>generator</span>. Default is <span
|
|
class='code'>simulator</span>.</p>
|
|
<table class="indent">
|
|
<tr>
|
|
<td class="code">simulator</td>
|
|
<td>Real-time simulator. It will sleep between emitting packets.</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code">generator</td>
|
|
<td>Emit packets as fast as it can. Useful for testing.</td>
|
|
</tr>
|
|
</table>
|
|
<p class="config_option">start</p>
|
|
|
|
<p>The start time for the generator in the format <span class="code">YYYY-MM-DD
|
|
hh:mm</span>. Optional. Default is the present time.</p>
|
|
|
|
<h3 class="config_section">[AcuRite]</h3>
|
|
|
|
<p>This section is for options relating to the AcuRite 5-in-1 series of
|
|
weather stations with USB connectors.</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, "AcuRite 01035", "AcuRite 01036",
|
|
or "02032C"</p>
|
|
|
|
<p class="config_option">use_constants</p>
|
|
|
|
<p>Some stations (01035, 01036) use the HP038 sensor, which contains
|
|
constants that define how the pressure and temperature should be
|
|
interpreted. Other stations (02032, 02064) use the MS5607 sensor,
|
|
which requires a different calculation to determine the pressure
|
|
and temperature from the sensor. When
|
|
<span class='code'>use_constants</span> is
|
|
<span class='code'>True</span>, the driver will use the constants to
|
|
determine which type of sensor is in the station and will adjust the
|
|
calculation accordingly. A value of False causes the driver to use
|
|
a linear approximation, regardless of the type of sensors.
|
|
The default is True.
|
|
</p>
|
|
|
|
<h3 class="config_section">[CC3000]</h3>
|
|
|
|
<p>This section is for options relating to the RainWise Mark III weather
|
|
stations and CC3000 data logger.</p>
|
|
|
|
<p class="config_important">port</p>
|
|
|
|
<p>The serial port, e.g., <span class='code'>/dev/ttyS0</span>. When using
|
|
a USB-Serial converter, the port will be something like
|
|
<span class='code'>/dev/ttyUSB0</span>. Default is
|
|
<span class='code'>/dev/ttyUSB0</span></p>
|
|
|
|
<p class='config_option'>polling_interval</p>
|
|
|
|
<p>The <span class="code">polling_interval</span> determines how often
|
|
<span class="code">weewx</span> will query the station for data. The
|
|
default is 1 second.
|
|
</p>
|
|
|
|
<h3 class="config_section">[FineOffsetUSB]</h3>
|
|
|
|
<p>This section is for options relating to the Fine Offset series of
|
|
weather stations with USB connectors.</p>
|
|
|
|
<p class="warning">The following settings are <strong>highly</strong>
|
|
recommended for Fine Offset stations. Using hardware record generation
|
|
or adaptive polling is more likely to cause USB communication failure.
|
|
Using hardware record generation will cause delays in report
|
|
generation.</p>
|
|
<pre class='tty'>
|
|
[FineOffsetUSB]
|
|
polling_mode = PERIODIC
|
|
polling_interval = 60
|
|
[StdArchive]
|
|
record_generation = software</pre>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WH1080, WS2080, WH3081, etc. </p>
|
|
|
|
<p class='config_option'>polling_mode</p>
|
|
|
|
<p>One of <span class='code'>PERIODIC</span> or
|
|
<span class='code'>ADAPTIVE</span>. In
|
|
<span class='code'>PERIODIC</span> mode,
|
|
<span class='code'>weewx</span> queries the console at regular intervals
|
|
determined by the <span class='code'>polling_interval</span>.
|
|
In <span class='code'>ADAPTIVE</span> mode,
|
|
<span class='code'>weewx</span> attempts to query the
|
|
console at times when it is not reading data from the sensors or writing
|
|
data to memory. See the section <a href="#polling_mode_and_the_polling_interval">
|
|
Polling Mode and the Polling Interval</a>
|
|
for details. The default is <span class='code'>PERIODIC</span>.</p>
|
|
|
|
<p class='config_option'>polling_interval</p>
|
|
|
|
<p>The frequency, in seconds, at which <span class='code'>weewx</span> will
|
|
poll the console for data. Default is 60. This setting applies only
|
|
when the <span class='code'>polling_mode</span> is
|
|
<span class='code'>PERIODIC</span>.</p>
|
|
|
|
<h3 class="config_section">[TE923]</h3>
|
|
|
|
<p>This section is for options relating to the Hideki TE923 series of
|
|
weather stations.</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, Meade TE923W or TFA Nexus.
|
|
Default is "TE923".</p>
|
|
|
|
<p class="config_option">map</p>
|
|
|
|
<p>This option defines the mapping between temperature/humidity values in
|
|
the database and the remote sensors. Up to 5 remote sensors are
|
|
supported. A switch on each sensor determines which of 5 channels that
|
|
sensor will use. For example, if the switch on the sensor is set to 3,
|
|
the temperature from that sensor will be t_3 and the humidity from that
|
|
sensor will be h_3.
|
|
</p>
|
|
|
|
<p>The default mapping is:
|
|
</p>
|
|
<pre class="tty">[[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</pre>
|
|
|
|
<h3 class="config_section">[Ultimeter]</h3>
|
|
|
|
<p>This section is for options relating to the PeetBros Ultimeter weather
|
|
stations.</p>
|
|
|
|
<p class="config_important">port</p>
|
|
|
|
<p>The serial port, e.g., <span class='code'>/dev/ttyS0</span>. When using
|
|
a USB-Serial converter, the port will be something like
|
|
<span class='code'>/dev/ttyUSB0</span>. Default is
|
|
<span class='code'>/dev/ttyUSB0</span></p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, Ultimeter 2000 or Ultimeter 800.
|
|
Default is "Ultimeter".</p>
|
|
|
|
<h3 class="config_section">[Vantage]</h3>
|
|
|
|
<p>This section is for options relating to the Davis Vantage series of hardware
|
|
(<em>VantagePro, VantagePro2</em> or <em>VantageVue</em>).</p>
|
|
|
|
<p class="config_important">type </p>
|
|
|
|
<p>Set to either <span class="code">serial</span>, for a serial or USB
|
|
connection to the VantagePro (by far the most common), or to
|
|
<span class="code">ethernet</span> for the WeatherLinkIP. No default.</p>
|
|
|
|
<p class="config_important">port </p>
|
|
|
|
<p>If you chose <span class="code">serial</span>, for <span class='code'>type</span>,
|
|
then set to the serial port name used by the station. For example,
|
|
<span class="code">/dev/ttyUSB0</span> is a common location for USB
|
|
ports, <span class="code">/dev/ttyS0</span> for serial ports. Otherwise,
|
|
not required. No default. </p>
|
|
|
|
<p class="config_important">host </p>
|
|
|
|
<p>If you chose <span class="code">ethernet</span>, then specify either
|
|
the IP address (<em>e.g.</em>, <span class="code">192.168.0.1</span>)
|
|
or hostname (<em>e.g.</em>, <span class="code">console.mydomain.com</span>)
|
|
to the console. Otherwise, not required. No default. </p>
|
|
|
|
<p class="config_option">baudrate </p>
|
|
|
|
<p>Set to the baudrate of the station. The default is 19200. </p>
|
|
|
|
<p class="config_option">tcp_port </p>
|
|
|
|
<p>The port where WeatherLinkIP will be listening. Default is 22222.
|
|
</p>
|
|
|
|
<p class="config_option">tcp_send_delay </p>
|
|
|
|
<p>How long to block after sending a socket packet to the WeatherLinkIP.
|
|
Default is 1 second. </p>
|
|
|
|
<p class="config_option">iss_id </p>
|
|
|
|
<p>Set to the ID number of the Integrated Sensor Suite (ISS). This is used
|
|
in the formula to calculate reception quality for wireless stations.
|
|
Default is 1. </p>
|
|
|
|
<p class="config_option">timeout </p>
|
|
|
|
<p>How many seconds to wait for a response from the station before giving
|
|
up. Default is 5 seconds. </p>
|
|
|
|
<p class="config_option">wait_before_retry </p>
|
|
|
|
<p>How many seconds to wait before retrying. Unless you have a good reason
|
|
to change it, this value should be left at the default, as it is long
|
|
enough for the station to offer new data, but not so long as to go into
|
|
a new loop packet (which arrive every 2 seconds). Default is 1.2
|
|
seconds. </p>
|
|
|
|
<p class="config_option">max_tries </p>
|
|
|
|
<p>How many times to try again before giving up. Default is 4. </p>
|
|
|
|
<h3 class="config_section">[WMR100]</h3>
|
|
|
|
<p>This section is for options relating to the Oregon Scientific WMR100
|
|
series of weather stations with USB connectors.</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WMR100 or WMRS200.</p>
|
|
|
|
<p class="config_option">stale_wind</p>
|
|
|
|
<p>How long a wind record can be used to calculate wind chill (in seconds).
|
|
Default is 30.</p>
|
|
|
|
<h3 class="config_section">[WMR200]</h3>
|
|
|
|
<p>This section is for options relating to the Oregon Scientific WMR200
|
|
series of weather stations with USB connectors.</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WMR200 or WMR200A.</p>
|
|
|
|
<p class="config_option">use_pc_time</p>
|
|
|
|
<p>If True, use the computer time, otherwise use the station time. Default
|
|
is True.</p>
|
|
|
|
<p class="config_option">archive_interval</p>
|
|
|
|
<p>Set the wmr200 archive interval in seconds. Default is 60 seconds.</p>
|
|
|
|
<p>The wmr200 hardware records archive data at an immutable rate of 60
|
|
seconds. This field may be set to a higher value enabling the weewx
|
|
engine to coalesce live data packets. However, when the wmr200 is not
|
|
connected to a system via USB or if the weewx software is not running,
|
|
the wmr200 console will continue to store weather data in onboard
|
|
console memory at a fixed rate of 60 seconds.</p>
|
|
|
|
<p class="config_option">erase_archive</p>
|
|
|
|
<p>If True, erase onboard console memory archive on startup. Default is
|
|
False.</p>
|
|
|
|
<p class="config_option">archive_startup</p>
|
|
|
|
<p>When retrieving archive data packets from the wmr200 onboard console
|
|
memory, there is no explicit indication that all the data has been
|
|
drained. This field specifies when to transition from archive mode to
|
|
live mode. This transition occurs when no archive packets are detected
|
|
within this time interval. Default is 120 seconds.</p>
|
|
|
|
<p class="config_option">archive_threshold</p>
|
|
|
|
<p>Occasionally when retrieving archive packets from the wmr200 onboard
|
|
memory a stale data packet will be detected. The archive packets are
|
|
presented in sequential order typically timestamped 60 seconds apart.
|
|
However, there is no guarantee the archive packets are exactly 60
|
|
seconds apart. Should an incoming archive data packet timestamp exceed
|
|
the previous archive data packet one by the amount in this field it will
|
|
be dropped. Default is 1512000 seconds (1 week).</p>
|
|
|
|
<p class="config_option">sensor_status</p>
|
|
|
|
<p>If True, emit sensor faults and failures to log. Default is True.</p>
|
|
|
|
<h3 class="config_section">[WMR300]</h3>
|
|
|
|
<p>This section is for options relating to the Oregon Scientific WMR300
|
|
series of weather stations with USB connectors.</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WMR300 or WMR300A.</p>
|
|
|
|
<h3 class="config_section">[WMR9x8]</h3>
|
|
|
|
<p>This section is for options relating to the Oregon Scientific WMR-918/968
|
|
series of weather stations with serial connectors.</p>
|
|
|
|
<p class="config_important">type</p>
|
|
|
|
<p>For the moment, only <span class="code">serial</span> is supported.</p>
|
|
|
|
<p class="config_important">port </p>
|
|
|
|
<p>Along with the <span class="code">serial</span> option above, you
|
|
must set the serial port name used by the station. For example,
|
|
<span class="code">/dev/ttyUSB0</span> is a common location for USB
|
|
ports, <span class="code">/dev/ttyS0</span> for serial ports.
|
|
No default. </p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WMR968 or WMR918.</p>
|
|
|
|
<h3 class="config_section">[WS1]</h3>
|
|
|
|
<p>This section is for options relating to the Argent Data Systems WS1
|
|
weather stations.</p>
|
|
|
|
<p class="config_important">port</p>
|
|
|
|
<p>The serial port, e.g., <span class='code'>/dev/ttyS0</span>. When using
|
|
a USB-Serial converter, the port will be something like
|
|
<span class='code'>/dev/ttyUSB0</span>. Default is
|
|
<span class='code'>/dev/ttyUSB0</span></p>
|
|
|
|
<p class='config_option'>polling_interval</p>
|
|
|
|
<p>The <span class="code">polling_interval</span> determines how often
|
|
<span class="code">weewx</span> will query the station for data. The
|
|
default is 1 second.
|
|
</p>
|
|
|
|
<h3 class="config_section">[WS23xx]</h3>
|
|
|
|
<p>This section is for options relating to the La Crosse WS-23xx series of
|
|
weather stations.</p>
|
|
|
|
<p class="config_important">port</p>
|
|
|
|
<p>The serial port, e.g., <span class='code'>/dev/ttyS0</span>. When using
|
|
a USB-Serial converter, the port will be something like
|
|
<span class='code'>/dev/ttyUSB0</span>. Default is
|
|
<span class='code'>/dev/ttyUSB0</span></p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, WS-2315, LaCrosse WS2317,
|
|
etc. Default is "LaCrosse WS23xx".</p>
|
|
|
|
<p class='config_option'>polling_interval</p>
|
|
|
|
<p>The <span class="code">polling_interval</span> determines how often
|
|
<span class="code">weewx</span> will query the station for data. If no
|
|
<span class="code">polling_interval</span> is specified (the default),
|
|
<span class="code">weewx</span> will automatically use a polling interval
|
|
based on the type of connection between the station and the sensors
|
|
(wired or wireless). When connected with a wire, the console updates
|
|
sensor data every 8 seconds. When connected wirelessly, the console
|
|
updates from 16 to 128 seconds, depending on sensor activity.
|
|
</p>
|
|
|
|
<h3 class='config_section'>[WS28xx]</h3>
|
|
|
|
<p>This section is for options relating to the La Crosse WS-28xx series of
|
|
weather stations.</p>
|
|
|
|
<p class="config_important">transceiver_frequency</p>
|
|
|
|
<p>Radio frequency to use between USB transceiver and console. Specify
|
|
either US or EU. US uses 915 MHz, EU uses 868.3 MHz. Default is US.
|
|
</p>
|
|
|
|
<p class="config_important">model</p>
|
|
|
|
<p>Set to the station model. For example, LaCrosse WS2810, TFA Primus,
|
|
etc. Default is "LaCrosse WS28xx".</p>
|
|
|
|
<h2 class="config_section">[StdRESTful]</h2>
|
|
|
|
<p>This section is for configuring the <span class="code">StdRESTful</span>
|
|
services, which upload to simple
|
|
<a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">RESTful</a>
|
|
servers such as the <a href="http://www.wunderground.com/">Weather Underground</a>,
|
|
<a href="http://www.pwsweather.com/">PWSweather.com</a>, or
|
|
<a href="http://www.wxqa.com/">CWOP</a>. </p>
|
|
|
|
<h3 class="config_section" id="station_registry">[[StationRegistry]]</h3>
|
|
|
|
<p> A registry of <span class="code">weewx</span> weather stations
|
|
is maintained at <span class="code">weewx.com</span>. Stations are
|
|
displayed on a map and a list at
|
|
<a href="http://weewx.com/stations.html">http://weewx.com/stations.html</a>
|
|
</p>
|
|
|
|
<p>How does the registry work? Individual weather stations
|
|
periodically contact the registry. Each station provides a URL to
|
|
identify itself, plus other information such as the station type and
|
|
<span class="code">weewx</span> version. No personal information, nor
|
|
any meteorological data, is sent.</p>
|
|
|
|
<p>To add your station to this list, you must do two things:</p>
|
|
<ol>
|
|
<li>Enable the StationRegistry in <span class="code">weewx.conf</span>
|
|
by setting the option <span class="code">register_this_station</span>
|
|
to <span class="code">True</span>. Your station will contact the
|
|
registry once per week. If your station does not contact the
|
|
registry for about a month, it will be removed from the list.
|
|
</li>
|
|
<li>Provide a <span class="code">station_url</span>, either in section
|
|
<a href="#station_url"><span class='code'>[Station]</span></a>, or
|
|
in the <span class='code'>[[StationRegistry]]</span> section.
|
|
</li>
|
|
</ol>
|
|
<p>The <span class='code'>station_url</span> is used to uniquely identify
|
|
each station, so choose it carefully before you set
|
|
<span class='code'>register_this_station</span> to
|
|
<span class='code'>True</span>.</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[StationRegistry]]
|
|
register_this_station = True</pre>
|
|
<p class="config_important">register_this_station</p>
|
|
|
|
<p>Set this to <span class="code">True</span> to register the weather station.</p>
|
|
|
|
<p class="config_option">description</p>
|
|
|
|
<p>
|
|
A description of the station. If no description is specified, the
|
|
<span class="config_option">location</span> from the <span
|
|
class="code">[Station]</span> section will be used.
|
|
</p>
|
|
|
|
<p class="config_option">station_url</p>
|
|
|
|
<p>
|
|
The URL to the weather station. If no URL is specified, the <span
|
|
class="config_option">station_url</span> from the <span
|
|
class="code">[Station]</span> section will be used.
|
|
</p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<h3 class="config_section">[[AWEKAS]]</h3>
|
|
|
|
<p class="config_section"><span class="code">Weewx</span> can send your
|
|
current data to the <a href="http://www.awekas.at/">Automatisches
|
|
Wetterkarten System</a> (AWEKAS). If you wish
|
|
to do this, set the option <span class='code'>enable</span> to
|
|
<span class="code">true</span>, then set options <span class='code'>username</span>
|
|
and <span class='code'>password</span> appropriately. When you are done, it will
|
|
look something like</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[AWEKAS]]
|
|
enable = true
|
|
username = joeuser
|
|
password = XXX </pre>
|
|
<p class="config_important">enable</p>
|
|
|
|
<p>
|
|
Set to <span class="code">true</span> to enable posting to
|
|
AWEKAS. Optional. Default is <span class="code">false</span>.
|
|
</p>
|
|
|
|
<p class="config_important">username</p>
|
|
|
|
<p>Set to your AWEKAS username (<i>e.g.</i>, <span class="code">joeuser</span>). Required.</p>
|
|
|
|
<p class="config_important">password</p>
|
|
|
|
<p>Set to your AWEKAS password. Required.</p>
|
|
|
|
<p class="config_option">language</p>
|
|
|
|
<p>Set to your preferred language. Default is <span class='code'>en</span>.</p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<h3 class="config_section">[[CWOP]]</h3>
|
|
|
|
<p><span class="code">Weewx</span> can send your current data to the
|
|
<a href="http://www.wxqa.com/">Citizen Weather Observer Program</a>. If you
|
|
wish to do this, set the option
|
|
<span class='code'>enable</span> to <span class='code'>true</span>,
|
|
then set the option <span class='code'>station</span> to your
|
|
CWOP station code. If your station is an amateur radio APRS station,
|
|
you will have to set <span class="code">passcode</span> as well.
|
|
When you are done, it will look something like</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[CWOP]]
|
|
enable = true
|
|
station = CW1234
|
|
passcode = XXX # Replace with your passcode (APRS stations only)
|
|
post_interval = 600</pre>
|
|
<p class="config_important">enable</p>
|
|
|
|
<p>
|
|
Set to <span class="code">true</span> to enable posting to the
|
|
CWOP. Optional. Default is <span class="code">false</span>.
|
|
</p>
|
|
|
|
<p class="config_important">station</p>
|
|
|
|
<p>Set to your CWOP station ID (<em>e.g.</em>, <span class="code">CW1234</span>)
|
|
or amateur radio callsign (APRS). Required.
|
|
</p>
|
|
|
|
<p class="config_important">passcode</p>
|
|
|
|
<p>This is used for APRS (amateur radio) stations only. Set to the
|
|
passcode given to you by the CWOP operators. Required for APRS stations,
|
|
ignored for others.</p>
|
|
|
|
<p class="config_option">post_interval </p>
|
|
|
|
<p>The interval in seconds between posts. Because CWOP is heavily used, the
|
|
operators discourage very frequent posts. Every 5 minutes (300 seconds)
|
|
is fine, but they prefer every 10 minutes (600 s) or even longer. Setting
|
|
this value to zero will cause every archive record to be posted.
|
|
Optional. Default is 600 seconds.</p>
|
|
|
|
<p class="config_option">stale</p>
|
|
|
|
<p>How old a record can be before it will not be used for a catch up. CWOP
|
|
does not use the timestamp on a posted record. Instead, they use the wall
|
|
clock time that it came in. This means that if your station is off the
|
|
air for a long period of time, then when <span class="code">weewx</span>
|
|
attempts a catch up, old data could be interpreted as the current
|
|
conditions. Optional. Default is 1800 seconds.</p>
|
|
|
|
<p class="config_option">server_list</p>
|
|
|
|
<p>A comma-delimited list of the servers that should be tried for
|
|
uploading data.
|
|
Optional. Default is: <span class="code">cwop.aprs.net:14580, cwop.aprs.net:23</span></p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<h3 class="config_section">[[PWSweather]]</h3>
|
|
|
|
<p><span class="code">Weewx </span>can send your current data to the
|
|
<a href="http://www.pwsweather.com/">PWSweather.com</a> service. If you
|
|
wish to do this, set the option
|
|
<span class='code'>enable</span> to <span class='code'>true</span>,
|
|
then set the options <span class='code'>station</span> and
|
|
<span class='code'>password</span> appropriately. When you are done,
|
|
it will look something like</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[PWSweather]]
|
|
enable = true
|
|
station = BOISE
|
|
password = XXX</pre>
|
|
<p class="config_important">enable</p>
|
|
|
|
<p>
|
|
Set to <span class="code">true</span> to enable posting to the
|
|
PWSweather. Optional. Default is <span class="code">false</span>.
|
|
</p>
|
|
|
|
<p class="config_important">station </p>
|
|
|
|
<p>Set to your PWSweather station ID (<i>e.g.</i>, <span class='code'>BOISE</span>). Required. </p>
|
|
|
|
<p class="config_important">password </p>
|
|
|
|
<p>Set to your PWSweather password. Required. </p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
|
|
<h3 class="config_section">[[WOW]]</h3>
|
|
|
|
<p class="config_section"><span class="code">Weewx</span> can send your
|
|
current data to the <a href="http://wow.metoffice.gov.uk/">British
|
|
Weather Observations Website (WOW)</a> service. If you wish
|
|
to do this, set the option <span class='code'>enable</span> to
|
|
<span class="code">true</span>, then set options <span class="code">station</span>
|
|
and <span class="code">password</span> appropriately. When you are done,
|
|
it will look something like</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[WOW]]
|
|
enable = true
|
|
station = 12345678
|
|
password = XXX</pre>
|
|
<p class="config_important">enable</p>
|
|
|
|
<p>
|
|
Set to <span class="code">true</span> to enable posting to
|
|
WOW. Optional. Default is <span class="code">false</span>.
|
|
</p>
|
|
|
|
<p class="config_important">station</p>
|
|
|
|
<p>Set to your WOW station ID (<i>e.g.</i>, <span class="code">12345678</span>). Required.</p>
|
|
|
|
<p class="config_important">password</p>
|
|
|
|
<p>Set to your WOW password. Required.</p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is <span class='code'>True</span>.</p>
|
|
|
|
<h3 class="config_section">[[Wunderground]]</h3>
|
|
|
|
<p>
|
|
<span class="code">Weewx</span> can send your current data to the
|
|
<a href="http://www.wunderground.com/">Weather Underground</a>. If
|
|
you wish to do this, set the option <span class="code">enable</span> to
|
|
<span class="code">true</span>, then set the options
|
|
<span class='code'>station</span> and <span class="code">password</span> appropriately.
|
|
When you are done, it will look something like
|
|
</p>
|
|
<pre class="tty">[StdRestful]
|
|
[[Wunderground]]
|
|
enable = true
|
|
station = KCASANFRA11
|
|
password = XXX
|
|
rapidfire = False</pre>
|
|
<p class="config_important">enable</p>
|
|
|
|
<p>
|
|
Set to <span class="code">true</span> to enable posting to the
|
|
Weather Underground. Optional. Default is <span class="code">false</span>.
|
|
</p>
|
|
|
|
<p class="config_important">station</p>
|
|
|
|
<p>
|
|
Set to your Weather Underground station ID (<em>e.g.</em>, <span
|
|
class="code">KCASANFRA11</span>). Required.
|
|
</p>
|
|
|
|
<p class="config_important">password</p>
|
|
|
|
<p>Set to your Weather Underground password. Required.</p>
|
|
|
|
<p class="config_option">rapidfire</p>
|
|
|
|
<p>
|
|
Set to <span class="code">True</span> to have <span class="code">weewx</span>
|
|
post using the <a href="http://www.wunderground.com/weatherstation/rapidfirehelp.asp">Weather Underground's
|
|
"Rapidfire" protocol</a>.
|
|
This will send a post to the
|
|
WU site with every LOOP packet, which can be as often as every 2.5
|
|
seconds in the case of the Vantage instruments. Not all instruments
|
|
support this. Optional. Default is <span class="code">False</span>.
|
|
</p>
|
|
|
|
<p class="config_option">archive_post</p>
|
|
|
|
<p>
|
|
This option tells <span class="code">weewx</span> to post on every
|
|
archive record, which is the normal "PWS" mode for the Weather
|
|
Underground. Because they prefer that you either use their
|
|
"Rapidfire" protocol, or their PWS mode, but not both, the default
|
|
for this option is the opposite for whatever you choose above for
|
|
option <span class="code">rapidfire</span>. However, if for some
|
|
reason you want to do both, then you may set both options to <span
|
|
class="code">True</span>.
|
|
</p>
|
|
|
|
<p class='config_option'>log_success</p>
|
|
|
|
<p>In case of success, make a note in the system log. The default is
|
|
<span class='code'>False</span> for Rapidfire mode,
|
|
<span class='code'>True</span> for PWS mode.</p>
|
|
|
|
<p class='config_option'>log_failure</p>
|
|
|
|
<p>In case of failure, make a note in the system log. The default is
|
|
<span class='code'>False</span> for Rapidfire mode,
|
|
<span class='code'>True</span> for PWS mode.</p>
|
|
|
|
|
|
<h2 class="config_section">[StdReport]</h2>
|
|
|
|
<p>This section is for configuring the <span class="code">StdReport</span> service,
|
|
which controls which reports are to be generated. While it can be highly customized
|
|
for your individual situation, this documentation describes the section as shipped
|
|
in the standard distribution. </p>
|
|
|
|
<p>Each report is represented by a sub-section, marked with double brackets
|
|
(<em>e.g.</em>, <span class="code">[[MyReport]]</span>). Any options for the
|
|
report should be placed under it. The standard report service will go through
|
|
the sections, running each report in order. Hence, normally the report
|
|
<span class="code">[[StandardReport]]</span> will be run first, then report
|
|
<span class="code">[[FTP]]</span> (which actually optionally uploads the results
|
|
to a remote web server). Details for how to customize reports are in the section
|
|
<em><a href="customizing.htm#customizing_reports">Customizing reports</a></em>, in the
|
|
<a href="customizing.htm">Customizing Guide</a>.
|
|
</p>
|
|
|
|
<p class="config_option">SKIN_ROOT </p>
|
|
|
|
<p>The directory where the skins live. A relative path is relative to
|
|
<span class="symcode">WEEWX_ROOT</span>.</p>
|
|
|
|
<p class="config_option">HTML_ROOT </p>
|
|
|
|
<p>The target directory for the generated files. A relative path is
|
|
relative to <span class="symcode">WEEWX_ROOT</span>. Generated
|
|
files and images will be put here. </p>
|
|
|
|
<p class="config_option">data_binding</p>
|
|
|
|
<p>
|
|
The data source to be used for the reports. It should match a
|
|
binding given in section <a href="#DataBindings"><span
|
|
class="code">[DataBindings]</span></a> below. The binding can be overridden in
|
|
individual reports. Optional. Default is <span class="code">wx_binding</span>.
|
|
</p>
|
|
|
|
<h3 class="config_section">[[StandardReport]]</h3>
|
|
|
|
<p>This is the standard report that will be run on every archiving interval.
|
|
It uses the skin "<span class="code">Standard</span>", which generates
|
|
four HTML pages ("day", "week", "month", and "year"
|
|
observations), plot graphs for same, an RSS feed, and NOAA monthly and yearly
|
|
reports. The default configuration uses US Customary Units and puts the results
|
|
in <span class="code">public_html</span> and subdirectory <span class="code">
|
|
public_html/NOAA</span>. </p>
|
|
|
|
<h3 class="config_section">[[FTP]]</h3>
|
|
|
|
<p>While this "report" does not actually generate anything, it
|
|
uses the report machinery to upload files from directory <span class="symcode">
|
|
HTML_ROOT</span> to a remote webserver. It does an incremental update,
|
|
that is, it only FTPs any files that have changed, saving the outgoing bandwidth
|
|
of your Internet connection. </p>
|
|
|
|
<p>If you do not use such a server, comment out the first four options below.
|
|
</p>
|
|
|
|
<p class="config_important">user </p>
|
|
|
|
<p>Set to the username you use for your FTP connection to your web server. Required.
|
|
No default. </p>
|
|
|
|
<p class="config_important">password </p>
|
|
|
|
<p>Set to the password you use for your FTP connection to your web server. Required.
|
|
No default. </p>
|
|
|
|
<p class="config_important">server </p>
|
|
|
|
<p>Set to the name of your web server (<em>e.g.</em>, <span class="code">www.threefools.org</span>,
|
|
in my case). Required. No default </p>
|
|
|
|
<p class="config_important">path </p>
|
|
|
|
<p>Set to the path where the weather data will be stored on your webserver (<em>e.g.</em>, <span class="code">/weather</span>).
|
|
NB: some FTP servers require a leading slash ('<span class="code">/</span>'),
|
|
some do not. Required. No default. </p>
|
|
|
|
<p class="config_important">secure_ftp</p>
|
|
|
|
<p>Set to <span class="code">True</span> to use a secure FTP (SFTP) connection. Not
|
|
all FTP servers support this. In particular, the Microsoft FTP server seems to do a poor
|
|
job of it. Requires Python V2.7. Will not work with older versions of Python.
|
|
Optional. Default is <span class="code">False</span></p>
|
|
|
|
<p class="config_option">port</p>
|
|
|
|
<p>Set to the port ID of your FTP server. Default is <span class="code">21</span>.</p>
|
|
|
|
<p class="config_option">passive</p>
|
|
|
|
<p>Set to 1 if you wish to use the more modern, FTP passive mode, 0 if you wish
|
|
to use active mode. Passive mode generally works better through firewalls, but
|
|
not all FTP servers do a good job of supporting it. See
|
|
<a href="http://slacksite.com/other/ftp.html">Active FTP vs. Passive FTP, a
|
|
Definitive Explanation</a> for a good explanation of the difference. Default
|
|
is 1 (passive mode). </p>
|
|
|
|
<p class="config_option">max_tries </p>
|
|
|
|
<p><span class="code">Weewx</span> will try up to this many times to FTP a file
|
|
up to your server before giving up. Default is 3. </p>
|
|
|
|
<h3 class="config_section">[[RSYNC]]</h3>
|
|
|
|
<p>While this "report" does not actually generate anything, it
|
|
uses the report machinery to upload files from directory <span class="symcode">
|
|
HTML_ROOT</span> to a remote webserver. It does an incremental update,
|
|
that is, it only synchronizes those files that have changed, saving the outgoing
|
|
bandwidth of your Internet connection. </p>
|
|
|
|
<p>If you do not use such a server, comment out the options below. </p>
|
|
|
|
<p class="config_important">server </p>
|
|
|
|
<p>Set to the name of your web server (<em>e.g.</em>,
|
|
<a href="http://www.threefools.org">www.threefools.org</a>, in my case). Required.
|
|
No default </p>
|
|
|
|
<p class="config_important">user </p>
|
|
|
|
<p>Set to the ssh username you use for your rsync connection to your web server.
|
|
The local user that <span class="code">weewx</span> runs as must have passwordless ssh configured for
|
|
user@server. Required. No default. </p>
|
|
|
|
<p class="config_important">path </p>
|
|
|
|
<p>Set to the path where the weather data will be stored on your webserver (<em>e.g.</em>, <span class="code">/weather</span>).
|
|
Required. No default. </p>
|
|
|
|
<p class="config_important">delete </p>
|
|
|
|
<p>Files that don't exist in the local report are removed from the remote location.
|
|
<em>USE WITH CAUTION:</em> If you make a mistake in setting the
|
|
<span class="code">path</span>, this can cause unexpected files to be deleted
|
|
on the remote server. Valid values are 1 to enable and 0 to disable. Required.
|
|
Default is 0.</p>
|
|
|
|
<h2 class="config_section" id="StdConvert">[StdConvert]</h2>
|
|
|
|
<p>This section is for configuring
|
|
the <span class="code">StdConvert</span> service. This service
|
|
acts as a filter, converting the unit system coming off your
|
|
hardware to a target output unit system. All downstream
|
|
services, including the archiving service, will then see this
|
|
unit system. Hence, your data will be stored in the database
|
|
using whatever unit system you specify here. </p>
|
|
|
|
<p><em>Once chosen, it cannot be changed!</em> Weewx does not allow you to
|
|
mix unit systems within the databases. You must chose a unit system
|
|
and then stick with it. This means that users coming from wview (which
|
|
uses US Customary) should not change the default setting. Having said
|
|
this, there is a way of reconfiguring the database to use another unit
|
|
system. See the section
|
|
<a href="customizing.htm#Changing_the_unit_system">Changing the unit system</a>
|
|
in the Customizing Guide.</p>
|
|
|
|
<p class='note'><strong>Note!</strong><br/> This service only
|
|
affects the units used in the <i>databases</i>. In particular,
|
|
it has nothing to do with what units are displayed in plots or
|
|
files. Those units are specified in the skin configuration
|
|
file, <span class="code">skin.conf</span>, as described in
|
|
the <a href="customizing.htm">Customizing Guide</a>, under
|
|
section
|
|
<em><a href="customizing.htm#Changing_options">Changing
|
|
options</a></em>. Because of this, unless you have a special
|
|
purpose application, there is really no good reason to change
|
|
from the default, which is <span class="code">US</span>.</p>
|
|
|
|
<p class="warning"><strong>Warning!</strong><br/>
|
|
If, despite these precautions, you do decide to change the units of data
|
|
stored in the database, be sure to read the sections
|
|
<span class="code"><a href="#StdCalibrate">[StdCalibrate]</a></span> and
|
|
<span class="code"><a href="#StdQC">[StdQC]</a></span>, and change the
|
|
units there as well!</p>
|
|
|
|
<p class="config_option" id="option_target_unit">target_unit</p>
|
|
|
|
<p>Set to either <span class="code">US</span>, <span class="code">METRICWX</span>,
|
|
or <span class="code">METRIC</span>. The difference between
|
|
<span class="code">METRICWX</span>, and <span class="code">METRIC</span> is that
|
|
the former uses <span class="code">mm</span> instead of <span class="code">cm</span>
|
|
for rain, and <span class="code">m/s</span> instead of
|
|
<span class="code">km/hr</span> for wind speed. See the Appendix <a href="customizing.htm#units">
|
|
Units</a> in the Customizing Guide for the exact differences beween
|
|
these three choices.
|
|
Default is <span class="code">US</span>.</p>
|
|
|
|
<h2 class="config_section" id="StdCalibrate">[StdCalibrate]</h2>
|
|
|
|
<p>This section is for configuring the <span class="code">StdCalibrate</span>
|
|
service. This service offers an opportunity to correct for any calibration errors
|
|
in your instruments. It is very general and flexible. </p>
|
|
|
|
<p>Because this service is normally run after <span class="code">StdConvert</span>,
|
|
the units to be used should be the same as the target unit system chosen in
|
|
<a href="#StdConvert"><span class="code">StdConvert</span></a> above. It is
|
|
also important that this service be run before the archiving service
|
|
<span class="code">StdArchive</span>, so that it is the corrected data that
|
|
are stored. </p>
|
|
|
|
<p>In a default configuration, calibrations are applied to
|
|
observations from the hardware. They are not applied to derived
|
|
calculations since the <span class="code">StdWXCalculate</span>
|
|
service runs after <span class="code">StdCalibrate</span>.</p>
|
|
|
|
<h3 class="config_section">[[Corrections]]</h3>
|
|
|
|
<p>In this section you list all <em>correction expressions</em>. For example,
|
|
say that you know your outside thermometer reads high by 0.2°F. You could add
|
|
the expression: </p>
|
|
|
|
<p class='tty'>outTemp = outTemp - 0.2</p>
|
|
|
|
<p>Perhaps you need a linear correction around a reference temperature of 68°F:
|
|
</p>
|
|
|
|
<p class='tty'>outTemp = outTemp + (outTemp-68) * 0.02</p>
|
|
|
|
<p>It is even possible to do corrections involving more than one variable. Suppose
|
|
you have a temperature sensitive barometer: </p>
|
|
|
|
<p class='tty'>barometer = barometer + (outTemp-32) * 0.0091</p>
|
|
|
|
<p>All correction expressions are run in the order given. </p>
|
|
|
|
<p>Both LOOP data and archive data will be corrected. </p>
|
|
|
|
<p>If you are using a Davis Vantage instrument and all you require is a simple
|
|
correction offset, this can also be done in the hardware. See your manual for
|
|
instructions. </p>
|
|
|
|
<h2 class="config_section" id="StdQC">[StdQC]</h2>
|
|
|
|
<p>This section is for configuring the <span class="code">StdQC</span> service.
|
|
This service offers a very simple <em>Quality Control</em> that only checks
|
|
that values are within a minimum and maximum range.</p>
|
|
|
|
<p>Because this service is normally run after <span class="code">StdConvert</span>,
|
|
the units to be used should be the same as the target unit system chosen in
|
|
<a href="#StdConvert"><span class="code">StdConvert</span></a>. It is also
|
|
important that it be run after the calibration service, <span class="code">StdCalibrate
|
|
</span>and before the archiving service <span class="code">StdArchive</span>,
|
|
so that it is the calibrated and corrected data that are stored. </p>
|
|
|
|
<p>In a default configuration, quality control checks are applied to
|
|
observations from the hardware. They are not applied to derived
|
|
calculations since the <span class="code">StdWXCalculate</span>
|
|
service runs after the quality control.</p>
|
|
|
|
<h3 class="config_section">[[MinMax]]</h3>
|
|
|
|
<p>In this section you list the observation types you wish to have checked,
|
|
along with their minimum and maximum values. If not specified, the units
|
|
should are in <em>the same unit system as specified in section
|
|
<span class="code"><a href="#StdConvert">StdConvert</a></span></em>.
|
|
</p>
|
|
|
|
<p>For example, </p>
|
|
<pre class="tty">[[MinMax]]
|
|
outTemp = -40, 120
|
|
barometer = 28, 32.5
|
|
outHumidity = 0, 100 </pre>
|
|
<p>With <span class='code'>target_unit = US</span> (the default), if a
|
|
temperature should fall outside of the inclusive
|
|
range -40 °F through 120 °F, then it will be set to the null
|
|
value, <span class="code">None</span>, and ignored. In a similar manner,
|
|
the acceptable values for barometric pressure would be 28 through 32.5
|
|
inHg, for humidity 0 through 100%. </p>
|
|
|
|
<p>You can also specify units.</p>
|
|
|
|
<p>For example, </p>
|
|
<pre class="tty">[[MinMax]]
|
|
outTemp = -40, 60, degree_C
|
|
barometer = 28, 32.5, inHg</pre>
|
|
<p>In this example, if a temperature should fall outside of the inclusive
|
|
range -40 °C through 60 °C, then it will be set to the null
|
|
value, <span class="code">None</span>, and ignored. In a similar manner,
|
|
the acceptable values for barometric pressure would be 28 through 32.5
|
|
inHg. Since the units are specified, these values apply no matter what
|
|
the <span class='code'>target_unit</span>.</p>
|
|
|
|
<p>Both LOOP and archive data will be checked. </p>
|
|
|
|
<p>Knowing the details of how your hardware encodes data helps to minimize
|
|
the number of observations that need to be checked. For example, the VP2
|
|
devotes only one unsigned byte to storing wind speed, and even then
|
|
<span class="code">0xff</span> is devoted to a bad value, so the only
|
|
possible values that could appear are 0 through 126 mph, a reasonable
|
|
range. So, for the VP2, there is no real point in checking wind speed.
|
|
</p>
|
|
|
|
<h2 class="config_section" id="StdWXCalculate">[StdWXCalculate]</h2>
|
|
|
|
<p>The calculation service calculates derived quantities such as
|
|
<span class='code'>dewpoint</span>, <span class='code'>windchill</span>,
|
|
and <span class='code'>heatindex</span>.</p>
|
|
|
|
<p>Some hardware provides derived quantities, others provide only raw
|
|
observations. The calculation service provides derived quantities for
|
|
hardware that does not provide them, and known algorithms for hardware
|
|
that provides unreliable or antiquated calculations.</p>
|
|
|
|
<p>The calculation service can calculate the following values:</p>
|
|
<ul>
|
|
<li>pressure</li>
|
|
<li>barometer</li>
|
|
<li>altimeter</li>
|
|
<li>windchill</li>
|
|
<li>heatindex</li>
|
|
<li>dewpoint</li>
|
|
<li>inDewpoint</li>
|
|
<li>rainRate</li>
|
|
<li>maxSolarRad</li>
|
|
<li>cloudbase</li>
|
|
<li>humidex</li>
|
|
<li>appTemp</li>
|
|
<li>ET</li>
|
|
<li>windrun</li>
|
|
</ul>
|
|
<p>In its default configuration, the service calculates values only if
|
|
they have not already been provided by the hardware or driver. This is
|
|
the default configuration:</p>
|
|
|
|
<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>
|
|
|
|
<p>The options for each quantity are <span class='code'>hardware</span>,
|
|
<span class='code'>software</span>, or
|
|
<span class='code'>prefer_hardware</span></p>
|
|
<table class="indent">
|
|
<tr>
|
|
<td class="code">hardware</td>
|
|
<td>Never calculate the value.</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code">software</td>
|
|
<td>Always calculate the value.</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="code">prefer_hardware</td>
|
|
<td>Calculate the value only if it is not provided by hardware.</td>
|
|
</tr>
|
|
</table>
|
|
<p>For example, if your weather station calculates windchill using the
|
|
pre-2001 algorithm, and you prefer to have
|
|
<span class='code'>weewx</span> calculate it using a current algorithm,
|
|
specify the following:</p>
|
|
|
|
<pre class="tty">[StdWXCalculate]
|
|
...
|
|
windchill = software</pre>
|
|
|
|
<p class="config_option">ignore_zero_wind</p>
|
|
|
|
<p>
|
|
Indicates whether the wind direction should be undefined when the wind
|
|
speed is zero. The default value is True; by default, the wind
|
|
direction will be undefined when wind speed is zero.
|
|
</p>
|
|
|
|
<p>
|
|
To report the wind vane direction even when there is no wind speed,
|
|
change this to False:
|
|
</p>
|
|
<pre class="tty">[StdWXCalculate]
|
|
...
|
|
ignore_zero_wind = False</pre>
|
|
|
|
<h2 class="config_section" id="StdArchive">[StdArchive]</h2>
|
|
|
|
<p>This section is for configuring <span class="code">StdArchive</span>, the
|
|
service that stores data in a database.</p>
|
|
|
|
<p class="config_option">archive_interval</p>
|
|
|
|
<p>If your station hardware supports data logging then the archive interval
|
|
will be downloaded from the station. Otherwise, you must specify it here in
|
|
seconds. Optional. Default is 300 seconds.</p>
|
|
|
|
<p class="config_option">archive_delay </p>
|
|
|
|
<p>How long to wait in seconds after the top of an archiving interval before
|
|
fetching new data off the station. For example, if your archive interval is
|
|
5 minutes and archive_delay is set to 15, then the data will be fetched at 00:00:15,
|
|
00:05:15, 00:10:15, etc. This delay is to give the station a few seconds to
|
|
archive the data internally, and in case your server has any other tasks to
|
|
do at the top of the minute. Default is 15 seconds. </p>
|
|
|
|
<p class="config_option" id="record_generation">record_generation</p>
|
|
|
|
<p>Set to whether records should be downloaded off the hardware (recommended),
|
|
or generated in software. If set to <span class="code">hardware</span>, then
|
|
<span class="code">weewx</span> tries to download archive records from your
|
|
station. However, not all types of stations support this, in which case
|
|
<span class="code">weewx</span> falls back to software generation. A setting
|
|
of <span class="code">hardware</span> will work for most users. A notable
|
|
exception is <a href="http://www.wxforum.net/index.php?topic=10315.0">users
|
|
who have cobbled together homebrew serial interfaces</a> for the Vantage stations
|
|
that do not include memory for a logger. These users should set this option
|
|
to <span class="code">software</span>, forcing software record generation.
|
|
Default is <span class="code">hardware</span>.</p>
|
|
|
|
<p class="config_option">loop_hilo</p>
|
|
|
|
<p>Set to <span class="code">True</span> to have LOOP data and archive
|
|
data to be used for high / low statistics. Set to <span class="code">False</span>
|
|
to have only archive data used. If your sensor emits lots of spiky data,
|
|
setting to <span class="code">False</span> may help. Default is
|
|
<span class="code">True</span>.</p>
|
|
|
|
<p class="config_option">data_binding</p>
|
|
|
|
<p>The data binding to be used to store the data. This should match one
|
|
of the bindings in the <span class="code">[DataBindings]</span> section, below. Optional. Default
|
|
is <span class="code">wx_binding</span>.</p>
|
|
|
|
<h2 class="config_section">[StdTimeSynch]</h2>
|
|
|
|
<p>This section is for configuring <span class="code">StdTymeSynch</span>, a
|
|
service that can synchronize the onboard clock of station with your computer.
|
|
Not all weather station hardware supports this.</p>
|
|
|
|
<p class="config_option">clock_check</p>
|
|
|
|
<p>How often to check the clock on the weather station in seconds. Default is
|
|
14,400 seconds (every 4 hours)</p>
|
|
|
|
<p class="config_option">max_drift</p>
|
|
|
|
<p>The maximum amount of clock drift to tolerate, in seconds, before resetting
|
|
the clock. Default is 5.</p>
|
|
|
|
<h2 class="config_section" id="DataBindings">[DataBindings]</h2>
|
|
|
|
<p>
|
|
A "data binding" associates storage characteristics with a specific
|
|
database. Each binding contains a database from the
|
|
<a href="#Databases"><span class='code'>[Databases]</span></a>
|
|
section plus parameters such as schema, table name, and mechanism
|
|
for aggregating data.
|
|
</p>
|
|
|
|
<h3 class="config_section" id="wx_binding">[[wx_binding]]</h3>
|
|
|
|
<p>
|
|
This is the binding normally used for weather data. A typical <span
|
|
class="code">[[wx_binding]]</span> section looks something like
|
|
this:
|
|
</p>
|
|
<pre class="tty">
|
|
[[wx_binding]]
|
|
database = archive_sqlite
|
|
table_name = archive
|
|
manager = weewx.wxmanager.WXDaySummaryManager
|
|
schema = schemas.wview.schema</pre>
|
|
<p>What follows is more detailed information about each of the
|
|
binding options.</p>
|
|
|
|
<p class="config_important">database</p>
|
|
|
|
<p>
|
|
The actual database to be used — it should match one of the
|
|
sections in <a href="#Databases"><span class="code">[Databases]</span></a>.
|
|
Should you decide to use a MySQL database, instead of the default
|
|
SQLite database, this is the place to change it. See the
|
|
section <a href="#configuring_mysql"><em>Configuring MySQL</em></a>
|
|
for details. Required.
|
|
</p>
|
|
|
|
<p class="config_option">table_name</p>
|
|
|
|
<p>
|
|
Internally, the archive data is stored in one, long, flat table.
|
|
This is the name of that table. Normally this does not need to be
|
|
changed. Optional. Default is <span class="code">archive</span>
|
|
</p>
|
|
|
|
<p class="config_option">manager</p>
|
|
|
|
<p>
|
|
The name of the class to be used to manage the table. Optional.
|
|
Default is class <span class="code">weewx.wxmanager.WXDaySummaryManager</span>.
|
|
This class stores daily summaries in the database, and a
|
|
few types, such as heating- and cooling-degree days, appropriate
|
|
for weather. Normally, this does not need to be changed.
|
|
</p>
|
|
|
|
<p class="config_option">schema</p>
|
|
|
|
<p>
|
|
A Python list holding the structure of the schema to be used to
|
|
initialize the database. After initialization, it is not used.
|
|
Optional. Default is <span class="code">schemas.wview.schema</span>,
|
|
the schema used by the <a href="http://www.wviewweather.com">wview</a>
|
|
weather system.
|
|
</p>
|
|
|
|
<h2 class="config_section" id="Databases">[Databases]</h2>
|
|
|
|
<p>This section lists actual databases. The name of each database is
|
|
given in double brackets, for example,
|
|
<span class="code">[[archive_sqlite]]</span>. Each database section
|
|
contains the parameters necessary to create and manage the database.
|
|
The number of parameters varies depending on the type of database.</p>
|
|
|
|
<h3 class="config_section">[[archive_sqlite]]</h3>
|
|
|
|
<p>This definition uses the <a href="http://sqlite.org/">SQLite</a> database
|
|
engine to store data. SQLite is open-source, simple, lightweight, highly
|
|
portable, and memory efficient. For most purposes it serves nicely.</p>
|
|
|
|
<p class="config_option">database_type</p>
|
|
|
|
<p>Set to <span class="code">SQLite</span> to signal that this is a
|
|
SQLite database.</p>
|
|
|
|
<p class="config_option">database_name</p>
|
|
|
|
<p>The path to the SQLite file relative to the <span class="code">SQLITE_ROOT</span>
|
|
option. Default is <span class="code">weewx.sdb</span>.</p>
|
|
|
|
<h3 class="config_section">[[archive_mysql]]</h3>
|
|
|
|
<p>This definition uses the MySQL database engine to store data.
|
|
It is free, highly-scalable, but more complicated to administer. </p>
|
|
|
|
<p class="config_option">database_type</p>
|
|
|
|
<p>Set to <span class="code">MySQL</span> to signal that this is a
|
|
MySQL database.</p>
|
|
|
|
<p class="config_option">database_name</p>
|
|
|
|
<p>The name of the database. Default is <span class="weewx">weewx</span>.
|
|
Required.</p>
|
|
|
|
<h2 class="config_section">[DatabaseTypes]</h2>
|
|
|
|
<p>This section defines defaults for the various kinds of databases.</p>
|
|
|
|
<h3 class="config_section">[[SQLite]]</h3>
|
|
|
|
<p>This section defines default values for SQLite databases. They
|
|
can be overridden by individual databases.</p>
|
|
|
|
<p class="config_option">driver</p>
|
|
|
|
<p>The sqlite driver name. Required.</p>
|
|
|
|
<p class="config_option">SQLITE_ROOT</p>
|
|
|
|
<p>
|
|
The location of the directory holding the SQLite databases. For <span
|
|
class="code">setup.py</span> installations, the default is the <span
|
|
class="symcode">WEEWX_ROOT</span><span class="code">/archive</span>
|
|
directory. For DEB or RPM installations, it is <span class="code">/var/lib/weewx</span>.
|
|
</p>
|
|
|
|
<p class="config_option" id='archive_timeout'>timeout</p>
|
|
|
|
<p>
|
|
When the database is accessed by multiple threads and one of those
|
|
threads modifies the database, the SQLite database is locked until
|
|
that transaction is completed. The <span class='code'>timeout</span>
|
|
option specifies how long other threads should wait for the lock to
|
|
go away before raising an exception. The default is 5 seconds.
|
|
</p>
|
|
|
|
<p class='config_option'>isolation_level</p>
|
|
|
|
<p>
|
|
Set the current isolation level. See the pysqlite documentation on <a
|
|
href="http://docs.python.org/2.7/library/sqlite3.html#sqlite3.Connection.isolation_level">
|
|
isolation levels</a> for more information. There is no reason to change
|
|
this, but it is here for completeness. Default is <span class='code'>None</span>
|
|
(autocommit).
|
|
</p>
|
|
|
|
<h3 class="config_section">[[MySQL]]</h3>
|
|
|
|
<p>This section defines default values for MySQL databases. They
|
|
can be overridden by individual databases.</p>
|
|
|
|
<p>
|
|
Note that if you choose the <a href="http://www.mysql.com/">MySQL</a>
|
|
database, it is assumed that you know how to administer it. In
|
|
particular, you will have to set up a user with appropriate create
|
|
and modify privileges.
|
|
</p>
|
|
|
|
<p class="config_option">driver</p>
|
|
|
|
<p>The MySQL driver name. Required.</p>
|
|
|
|
<p class="config_important">host</p>
|
|
|
|
<p>
|
|
The name of the server on which the database is located. Default is <span
|
|
class="code">localhost</span>.
|
|
</p>
|
|
|
|
<p class="config_important">user</p>
|
|
|
|
<p>The user name to be used to log into the server. Required.</p>
|
|
|
|
<p class="config_important">password</p>
|
|
|
|
<p>The password. Required.</p>
|
|
|
|
<p class="config_option">port</p>
|
|
|
|
<p>The port number to be used. Optional. Default is 3306.</p>
|
|
|
|
<p class="config_option">engine</p>
|
|
|
|
<p>The type of MySQL database storage engine to be used. This should not
|
|
be changed without a good reason. Default is <span class="code">INNODB</span>.
|
|
</p>
|
|
|
|
<h2 class="config_section">[Engines]</h2>
|
|
|
|
<p>
|
|
This section is used to configure the internal service engine in <span
|
|
class="code">weewx</span>. It is for advanced customization. Details
|
|
on how to do this can be found in the section <em> <a
|
|
href="customizing.htm#service_engine">Customizing the weewx
|
|
service engine</a></em> of the <a href="customizing.htm">Customizing
|
|
Guide</a>.
|
|
</p>
|
|
|
|
|
|
<h3 class="config_section">[[Services]]</h3>
|
|
|
|
<p>
|
|
Internally, <span class="code">weewx</span> consists of many <em>services</em>,
|
|
each responsible for some aspect of the program's functionality.
|
|
After an event happens, such as
|
|
the arrival of a new LOOP packet, any interested service gets a
|
|
chance to do some useful work on the event. For example, a service
|
|
might manipulate the packet, print it out, store it in a database,
|
|
etc. This section controls which services are loaded and in what
|
|
order they get their opportunity to do that work. Before <span
|
|
class="code">weewx</span> v2.6, this section held one, looong
|
|
option called <span class="code">service_list</span>, which held
|
|
the names of all the services that should be run. Since then, this
|
|
list has been broken down into five, smaller, lists, given below.
|
|
They are run in the order given below.
|
|
</p>
|
|
|
|
<p class="config_option" id="prep_services">prep_services</p>
|
|
|
|
<p>
|
|
These services get called before any others. They are typically
|
|
used to prepare the console. For example, the service <span
|
|
class="code">weewx.wxengine.StdTimeSynch</span>, which is
|
|
responsible for making sure the console's clock is up to date, is
|
|
a member of this group.
|
|
</p>
|
|
|
|
<p class="config_option" id="process_services">process_services</p>
|
|
|
|
<p>Services in this group tend to process any incoming data.
|
|
They typically do things like quality control, or unit conversion,
|
|
or sensor calibration.</p>
|
|
|
|
<p class="config_option" id="archive_services">archive_services</p>
|
|
|
|
<p>Once data have been processed, services in this group archive
|
|
them.</p>
|
|
|
|
<p class="config_option" id="restful_services">restful_services</p>
|
|
|
|
<p>RESTful services, such as the Weather Underground, or CWOP,
|
|
are in this group. They need processed data that have been
|
|
archived, hence they are run after the preceeding groups.</p>
|
|
|
|
<p class="config_option" id="report_services">report_services</p>
|
|
|
|
<p>The various reporting services run in this group, including
|
|
the standard reporting engine.</p>
|
|
|
|
<p>For reference, here is the standard set of services that are
|
|
run with the default distribution.</p>
|
|
<pre class="tty">
|
|
prep_services = weewx.engine.StdTimeSynch
|
|
process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate,\
|
|
weewx.engine.StdQC, weewx.wxservices.StdWXCalculate
|
|
archive_services = weewx.engine.StdArchive
|
|
restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground,\
|
|
weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW,\
|
|
weewx.restx.StdAWEKAS
|
|
report_services = weewx.engine.StdPrint, weewx.engine.StdReport
|
|
</pre>
|
|
<p>If you're the type who likes to clean out your car trunk after every
|
|
use it, then you may also be the type who wants to pare this down
|
|
to the bare minimum. However, this will only make a slight
|
|
difference in execution speed and memory use.</p>
|
|
|
|
<h1 id="configuring_hardware">Configuring hardware</h1>
|
|
|
|
<p>This section describes how to configure some of the more popular
|
|
station hardware.</p>
|
|
|
|
<p>Some stations can be configured using the
|
|
<span class='code'>wee_device</span> utility supplied with weewx.
|
|
This utility uses code in the hardware-specific driver to set EEPROM
|
|
constants, read station memory, set the station archive interval, set
|
|
the altitude, configure rain bucket types, and many other options,
|
|
depending on the hardware.</p>
|
|
|
|
<p>Note that some stations cannot be configured by software at all,
|
|
and some stations are only partly configurable by software.</p>
|
|
|
|
<p>Run the utility with the <span class='code'>--help</span> option
|
|
to see which options are available.</p>
|
|
|
|
<p class="tty cmd">wee_device --help</p>
|
|
|
|
<p>The utility requires a <span class='code'>weewx.conf</span> file.
|
|
If no file is specified, it will look for
|
|
<span class='code'>weewx.conf</span> in the standard location. If
|
|
your configuration file is in a non-standard location, specify the
|
|
path to the configuration file as the first argument. For example,</p>
|
|
|
|
<p class="tty cmd">wee_device /path/to/weewx.conf --help</p>
|
|
|
|
|
|
<h2 id="wee_device_acurite">AcuRite</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure AcuRite stations.</p>
|
|
|
|
<p>The AcuRite console must be set to USB mode 3 or 4. Communication
|
|
via USB is disabled in modes 1 and 2. Mode 4 is more reliable than
|
|
mode 3; mode 3 enables logging of data, mode 4 does not. When the
|
|
console is logging it frequently causes USB communication problems.</p>
|
|
|
|
<p>The wind speed updates every 18 seconds. The wind direction updates
|
|
every 30 seconds. Other sensors update every 60 seconds.</p>
|
|
|
|
<p>The AcuRite stations do not record wind gusts.</p>
|
|
|
|
<p>The station emits partial packets, which may confuse some online
|
|
services</p>
|
|
|
|
|
|
<h2 id="wee_device_cc3000">CC3000</h2>
|
|
|
|
<p>The CC3000 data logger may be configured to return data in
|
|
METRIC or US units. These are not the same groups of METRIC and US
|
|
units as defined within <span class='code'>weewx</span>. However, the
|
|
CC3000 driver will convert to the appropriate units for the
|
|
<span class='code'>weewx</span> configuration.</p>
|
|
|
|
<p>The CC3000 data logger stores 2MB of records.</p>
|
|
|
|
<p>The CC3000 driver supports catchup on startup, but it does not
|
|
support hardware record generation.</p>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility can be used to
|
|
configure the station hardware. When the
|
|
<span class='code'>station_type</span> is
|
|
<span class='code'>CC3000</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class="tty">CC3000 driver version 0.8
|
|
Usage: wee_device [config_file] [options] [--debug] [--help]
|
|
|
|
Configuration utility for weewx devices.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--info display weather station configuration
|
|
--current display current weather readings
|
|
--history=N display N records (0 for all records)
|
|
--history-since=N display records since N minutes ago
|
|
--clear-memory clear station memory
|
|
--set-clock set station clock to computer time
|
|
--set-interval=N set logging interval to N minutes
|
|
--set-units=UNITS set units to METRIC or ENGLISH
|
|
|
|
Mutating actions will request confirmation before proceeding.</pre>
|
|
|
|
<h3>Station information</h3>
|
|
|
|
<p>Display the station settings with the <span class='code'>--info</span>
|
|
option.</p>
|
|
<pre class="tty cmd">wee_device --info</pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class='tty'>firmware: Rainwise CC-3000 Version: 1.3 Build 006 Sep 04 2013
|
|
time: 2014/06/02 08:22:17
|
|
units: ENGLISH
|
|
memory: 251372 bytes, 4334 records, 12%
|
|
interval: 1</pre>
|
|
|
|
<h3 id="cc3000_changing_the_archive_interval">Changing the archive interval</h3>
|
|
|
|
<p>CC3000 loggers ship from the factory with an archive interval
|
|
of 1 minutes (60 seconds). To change the station's
|
|
interval to 5 minutes, do the following:</p>
|
|
|
|
<p class="tty cmd">wee_device --set-interval=5</p>
|
|
|
|
|
|
<h2 id="wee_device_fousb">FineOffsetUSB</h2>
|
|
|
|
<p>The station clock can only be set manually via buttons on the
|
|
console, or (if the station supports it) by WWVB radio. The
|
|
FineOffsetUSB driver ignores the station clock since it cannot be
|
|
trusted.</p>
|
|
|
|
<p>The station reads data from the sensors every 48 seconds.
|
|
The 30xx stations read UV data every 60 seconds.</p>
|
|
|
|
<p>The 10xx and 20xx stations can save up to 4080 historical readings.
|
|
That is about 85 days of data with the default recording interval of
|
|
30 minutes, or about 14 days with a recording interval of 5 minutes.
|
|
The 30xx stations can save up to 3264 historical readings.</p>
|
|
|
|
<p>When <span class='code'>weewx</span> starts up it will attempt
|
|
to download all records from the console since the last record in
|
|
the archive database.</p>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility can be used to
|
|
configure the station hardware. When the
|
|
<span class='code'>station_type</span> is
|
|
<span class='code'>FineOffsetUSB</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class="tty">FineOffsetUSB driver version 1.7
|
|
Usage: wee_device [config_file] [options] [--debug] [--help]
|
|
|
|
Configuration utility for weewx devices.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--info display weather station configuration
|
|
--current get the current weather conditions
|
|
--history=N display N records
|
|
--history-since=N display records since N minutes ago
|
|
--clear-memory clear station memory
|
|
--set-time set station clock to computer time
|
|
--set-interval=N set logging interval to N minutes
|
|
--live display live readings from the station
|
|
--logged display logged readings from the station
|
|
--fixed-block display the contents of the fixed block
|
|
--check-usb test the quality of the USB connection
|
|
--check-fixed-block monitor the contents of the fixed block
|
|
--format=FORMAT format for output, one of raw, table, or dict
|
|
|
|
Mutating actions will request confirmation before proceeding.</pre>
|
|
<h3>Station information</h3>
|
|
|
|
<p>Display the station settings with the <span class='code'>--info</span>
|
|
option.</p>
|
|
<pre class="tty cmd">wee_device --info</pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class='tty'>Fine Offset station settings:
|
|
local time: 2013.02.11 18:34:28 CET
|
|
polling_mode: ADAPTIVE
|
|
|
|
abs_pressure: 933.3
|
|
current_pos: 592
|
|
data_changed: 0
|
|
<span class="highlight">data_count: 22</span>
|
|
date_time: 2007-01-01 22:49
|
|
hum_in_offset: 18722
|
|
hum_out_offset: 257
|
|
id: None
|
|
lux_wm2_coeff: 0
|
|
magic_1: 0x55
|
|
magic_2: 0xaa
|
|
model: None
|
|
rain_coef: None
|
|
<span class="highlight">read_period: 30</span>
|
|
<span class="highlight">rel_pressure: 1014.8</span>
|
|
temp_in_offset: 1792
|
|
temp_out_offset: 0
|
|
timezone: 0
|
|
unknown_01: 0
|
|
unknown_18: 0
|
|
version: 255
|
|
wind_coef: None
|
|
wind_mult: 0</pre>
|
|
<p><span class="highlight">Highlighted </span> values can be modified with the <span
|
|
class='code'>wee_device</span> utility.</p>
|
|
|
|
<h3 id="fo_changing_the_archive_interval">Changing the archive interval</h3>
|
|
|
|
<p>Fine Offset stations ship from the factory with an archive interval
|
|
(read_period) of 30 minutes (1800 seconds). To change the station's
|
|
interval to 5 minutes, do the following:</p>
|
|
|
|
<p class="tty cmd">wee_device --set-interval=5</p>
|
|
|
|
<h3 id="fo_dumping_the_console_memory">Dumping the console memory</h3>
|
|
|
|
<p>Fine Offset stations store records in a circular buffer — once the buffer fills, the oldest records are
|
|
replaced by newer records. The 1080 and 2080 consoles store up to 4080 records. The 3080 consoles store up to
|
|
3264 records. The <span class='code'>data_count</span> indicates how many records are in memory. The <span
|
|
class='code'>read_period</span> indicates the number of minutes between records. <span class='code'>wee_device</span>
|
|
can display these records in space-delimited, raw bytes, or dictionary format.</p>
|
|
|
|
<p>For example, to display the most recent 30 records from the console memory:</p>
|
|
<pre class="tty cmd">wee_device --history=30</pre>
|
|
<p>To clear the console memory:</p>
|
|
<pre class="tty cmd">wee_device --clear-memory</pre>
|
|
|
|
<h3>Checking the USB quality</h3>
|
|
|
|
<p>Use the <span class='code'>wee_device</span> utility to test the quality of the USB connection between computer
|
|
and console. Poor quality USB cables, under-powered USB hubs, and other devices on the bus can interfere with
|
|
communication.</p>
|
|
|
|
<p>To test the quality of the USB connection to the console:</p>
|
|
<pre class="tty cmd">wee_device --check-usb</pre>
|
|
<p>Let the utility run for at least a few minutes, or possibly an hour or two. It is not unusual to see a few bad
|
|
reads in an hour, but if you see many bad reads within a few minutes, consider replacing the USB cable, USB hub,
|
|
or removing other devices from the bus.</p>
|
|
|
|
<h3 id="polling_mode_and_the_polling_interval">Polling mode and the polling interval</h3>
|
|
|
|
<p>When reading 'live' data, <span class='code'>weewx</span> can read as fast as possible, or at a user-defined
|
|
period. This is controlled by the <span class='code'>polling_mode</span> parameter.
|
|
</p>
|
|
<table class='indent'>
|
|
<caption>Polling modes for Fine Offset stations</caption>
|
|
<tr class="first_row">
|
|
<td width='15%'>Mode</td>
|
|
<td width='30%'><span class='code'>weewx.conf</span></td>
|
|
<td>Notes</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="first_col">ADAPTIVE</td>
|
|
<td>
|
|
<pre class='tty' style='margin:0'>[FineOffsetUSB]
|
|
polling_mode = ADAPTIVE</pre>
|
|
</td>
|
|
<td>
|
|
<p>In this mode, <span class='code'>weewx</span> reads data from the station as often as possible, but
|
|
at intervals that avoid communication between the console and the sensors. Nominally this results in
|
|
reading data every 48 seconds.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="first_col">PERIODIC</td>
|
|
<td>
|
|
<pre class='tty' style='margin:0'>[FineOffsetUSB]
|
|
polling_mode = PERIODIC
|
|
polling_interval = 60</pre>
|
|
</td>
|
|
<td>
|
|
<p>In this mode, <span class='code'>weewx</span> reads data from the station every <span class='code'>polling_interval</span>
|
|
seconds.</p>
|
|
|
|
<p>The console reads the sensors every 48 seconds (60 seconds for UV), so setting the <span
|
|
class='code'>polling_interval</span> to a value less than 48 will result in duplicate readings.
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h2 id="wee_device_te923">TE923</h2>
|
|
|
|
<p>Some station models will recognize up to 5 remote
|
|
temperature/humidity sensor units. Use the hardware switch in each
|
|
sensor unit to identify sensors. Use the
|
|
<span class='code'>map</span> in
|
|
<span class='code'>weewx.conf</span> to associate each sensor with a
|
|
database field.
|
|
</p>
|
|
|
|
<p>The station has either 208 or 3442 history records, depending on
|
|
the model. That is just over a day (208 records) or about 23 days
|
|
(3442 records) with an archive interval of 5 minutes.</p>
|
|
|
|
<p>The TE923 driver will read history records from the station when weewx
|
|
starts up, but it does not support hardware record generation.</p>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility can be used to
|
|
configure the station hardware. When the
|
|
<span class='code'>station_type</span> is
|
|
<span class='code'>TE932</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class='tty'>Using configuration file /home/weewx/weewx.conf
|
|
Using TE923 driver version 0.16 (weewx.drivers.te923)
|
|
Usage: wee_device [config_file] [options] [--debug] [--help]
|
|
|
|
Configuration utility for weewx devices.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--info display weather station configuration
|
|
--current get the current weather conditions
|
|
--history=N display N history records
|
|
--history-since=N display history records since N minutes ago
|
|
--minmax display historical min/max data
|
|
--get-date display station date
|
|
--set-date=YEAR,MONTH,DAY
|
|
set station date
|
|
--get-location-local display local location and timezone
|
|
--set-location-local=CITY|USR,LONG_DEG,LONG_MIN,E|W,LAT_DEG,LAT_MIN,N|S,TZ,DST
|
|
set local location and timezone
|
|
--get-location-alt display alternate location and timezone
|
|
--set-location-alt=CITY|USR,LONG_DEG,LONG_MIN,E|W,LAT_DEG,LAT_MIN,N|S,TZ,DST
|
|
set alternate location and timezone
|
|
--get-altitude display altitude
|
|
--set-altitude=ALT set altitude
|
|
--get-alarms display alarms
|
|
--set-alarms=WEEKDAY,SINGLE,PRE_ALARM,SNOOZE,MAXTEMP,MINTEMP,RAIN,WIND,GUST
|
|
set alarm state
|
|
--get-interval display archive interval
|
|
--set-interval=INTERVAL
|
|
set archive interval
|
|
--format=FORMAT formats include: table, dict
|
|
|
|
Be sure to stop weewx first before using. Mutating actions will request
|
|
confirmation before proceeding.</pre>
|
|
|
|
<h3>Station information</h3>
|
|
|
|
<p>Use the <span class="code">--info</span> option to display the
|
|
station configuration:</p>
|
|
<pre class="tty cmd">wee_device --info</pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class="tty">Querying the station for the configuration...
|
|
altitude: 16
|
|
bat_1: True
|
|
bat_2: True
|
|
bat_3: True
|
|
bat_4: True
|
|
bat_5: True
|
|
bat_rain: True
|
|
bat_uv: False
|
|
bat_wind: True
|
|
latitude: 43.35
|
|
longitude: -72.0
|
|
version_bar: 23
|
|
version_rcc: 16
|
|
version_sys: 41
|
|
version_uv: 20
|
|
version_wind: 38</pre>
|
|
|
|
<h3>Display sensor status</h3>
|
|
|
|
<p>Use the <span class="code">--current</span> option to display the
|
|
current status of each sensor:</p>
|
|
<pre class="tty cmd">wee_device --current</pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class="tty">Querying the station for current weather data...
|
|
dateTime: 1454615168
|
|
forecast: 5
|
|
h_1: 41
|
|
h_1_state: ok
|
|
h_2: 48
|
|
h_2_state: ok
|
|
h_3: None
|
|
h_3_state: no_link
|
|
h_4: None
|
|
h_4_state: no_link
|
|
h_5: None
|
|
h_5_state: no_link
|
|
h_in: 44
|
|
h_in_state: ok
|
|
rain: 2723
|
|
rain_state: ok
|
|
slp: 1012.4375
|
|
slp_state: ok
|
|
storm: 0
|
|
t_1: 13.9
|
|
t_1_state: ok
|
|
t_2: 21.5
|
|
t_2_state: ok
|
|
t_3: None
|
|
t_3_state: no_link
|
|
t_4: None
|
|
t_4_state: no_link
|
|
t_5: None
|
|
t_5_state: no_link
|
|
t_in: 22.85
|
|
t_in_state: ok
|
|
uv: None
|
|
uv_state: no_link
|
|
windchill: None
|
|
windchill_state: invalid
|
|
winddir: 12
|
|
winddir_state: invalid
|
|
windgust: None
|
|
windgust_state: invalid
|
|
windspeed: None
|
|
windspeed_state: invalid</pre>
|
|
|
|
<h3 id="te923_changing_the_archive_interval">Changing the archive interval</h3>
|
|
|
|
<p>TE923 stations ship from the factory with an archive interval of 1
|
|
hour (3600 seconds). To change the station's
|
|
interval to 5 minutes (300 seconds), do the following:</p>
|
|
|
|
<p class="tty cmd">wee_device --set-interval=300</p>
|
|
|
|
<h3 id="te923_dumping_the_logger_memory">Dumping the logger memory</h3>
|
|
|
|
<p><span class='code'>wee_device</span> can display the records from the
|
|
logger in tabular or dictionary format.</p>
|
|
|
|
<p>For example, to display the most recent 30 records:</p>
|
|
<pre class="tty cmd">wee_device --history=30 --format dict</pre>
|
|
|
|
|
|
<h2 id="wee_device_ultimeter">Ultimeter</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure Ultimeter stations.</p>
|
|
|
|
<p>The Ultimeter driver operates the Ultimeter in Data Logger Mode,
|
|
which results in sensor readings every 1/2 second or so.</p>
|
|
|
|
<p>The Ultimeter driver ignores the maximum, minimum, and average
|
|
values recorded by the station.</p>
|
|
|
|
|
|
<h2 id="wee_device_vantage">Vantage</h2>
|
|
|
|
<p>When the <span class='code'>station_type</span> is
|
|
<span class='code'>Vantage</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class="tty">Using configuration file /home/weewx/weewx.conf
|
|
Using Vantage driver version 3.0 (weewx.drivers.vantage)
|
|
Usage: wee_device [config_file] [--help] [--info] [--clear]
|
|
[--set-interval=SECONDS] [--set-altitude=FEET] [--set-barometer=inHg]
|
|
[--set-bucket=CODE] [--set-rain-year-start=MM]
|
|
[--set-offset=VARIABLE,OFFSET]
|
|
[--set-transmitter-type=CHANNEL,TYPE,TEMP,HUM]
|
|
[--set-time] [--set-dst=[AUTO|ON|OFF]]
|
|
[--set-tz-code=TZCODE] [--set-tz-offset=HHMM]
|
|
[--set-lamp=[ON|OFF]] [--dump] [--logger_summary=FILE]
|
|
[--start | --stop]
|
|
|
|
Configures the Davis Vantage weather station.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--info To print configuration, reception, and barometer
|
|
calibration information about your weather station.
|
|
--clear To clear the memory of your weather station.
|
|
--set-interval=SECONDS
|
|
Sets the archive interval to the specified number of
|
|
seconds. Valid values are 60, 300, 600, 900, 1800,
|
|
3600, or 7200.
|
|
--set-altitude=FEET Sets the altitude of the station to the specified
|
|
number of feet.
|
|
--set-barometer=inHg Sets the barometer reading of the station to a known
|
|
correct value in inches of mercury. Specify 0 (zero)
|
|
to have the console pick a sensible value.
|
|
--set-bucket=CODE Set the type of rain bucket. Specify '0' for 0.01
|
|
inches; '1' for 0.2 MM; '2' for 0.1 MM
|
|
--set-rain-year-start=MM
|
|
Set the rain year start (1=Jan, 2=Feb, etc.).
|
|
--set-offset=VARIABLE,OFFSET
|
|
Set the onboard offset for VARIABLE inTemp, outTemp,
|
|
extraTemp[1-7], inHumid, outHumid, extraHumid[1-7],
|
|
soilTemp[1-4], leafTemp[1-4], windDir) to OFFSET
|
|
(Fahrenheit, %, degrees)
|
|
--set-transmitter-type=CHANNEL,TYPE,TEMP,HUM
|
|
Set the transmitter type for CHANNEL (1-8), TYPE
|
|
(0=iss, 1=temp, 2=hum, 3=temp_hum, 4=wind, 5=rain,
|
|
6=leaf, 7=soil, 8=leaf_soil, 9=sensorlink, 10=none),
|
|
as extra TEMP station and extra HUM station (both 1-7,
|
|
if applicable)
|
|
--set-time Set the onboard clock to the current time.
|
|
--set-dst=AUTO|ON|OFF
|
|
Set DST to 'ON', 'OFF', or 'AUTO'
|
|
--set-tz-code=TZCODE Set timezone code to TZCODE. See your Vantage manual
|
|
for valid codes.
|
|
--set-tz-offset=HHMM Set timezone offset to HHMM. E.g. '-0800' for U.S.
|
|
Pacific Time.
|
|
--set-lamp=ON|OFF Turn the console lamp 'ON' or 'OFF'.
|
|
--start Start the logger.
|
|
--stop Stop the logger.
|
|
--dump Dump all data to the archive. NB: This may result in
|
|
many duplicate primary key errors.
|
|
--logger-summary=FILE
|
|
Save diagnostic summary to FILE (for debugging the
|
|
logger).
|
|
|
|
Be sure to stop weewx first before using. Mutating actions will request
|
|
confirmation before proceeding.</pre>
|
|
|
|
<h3>Station information</h3>
|
|
|
|
<p>Use the <span class="code">--info</span> option to display the
|
|
current EEPROM settings: </p>
|
|
<pre class="tty cmd">wee_device --info</pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class="tty">Davis Vantage EEPROM settings:
|
|
|
|
CONSOLE TYPE: VantagePro2
|
|
|
|
CONSOLE FIRMWARE:
|
|
Date: Dec 11 2012
|
|
Version: 3.12
|
|
|
|
CONSOLE SETTINGS:
|
|
<span class="highlight">Archive interval: 300 (seconds)</span>
|
|
<span class="highlight">Altitude: 700 (foot)</span>
|
|
Wind cup type: large
|
|
<span class="highlight">Rain bucket type: 0.01 inches</span>
|
|
<span class="highlight">Rain year start: 10</span>
|
|
<span class="highlight">Onboard time: 2014-09-25 07:41:14</span>
|
|
|
|
CONSOLE DISPLAY UNITS:
|
|
Barometer: inHg
|
|
Temperature: degree_F
|
|
Rain: inch
|
|
Wind: mile_per_hour
|
|
|
|
CONSOLE STATION INFO:
|
|
Latitude (onboard): 45.7
|
|
Longitude (onboard): -121.6
|
|
<span class="highlight">Use manual or auto DST? AUTO</span>
|
|
<span class="highlight">DST setting: N/A</span>
|
|
<span class="highlight">Use GMT offset or zone code? ZONE_CODE</span>
|
|
<span class="highlight">Time zone code: 4</span>
|
|
<span class="highlight">GMT offset: N/A</span>
|
|
|
|
TRANSMITTERS:
|
|
<span class="highlight">Channel 1: iss</span>
|
|
<span class="highlight">Channel 2: (N/A)</span>
|
|
<span class="highlight">Channel 3: temp (as extra temperature 1)</span>
|
|
<span class="highlight">Channel 4: (N/A)</span>
|
|
<span class="highlight">Channel 5: (N/A)</span>
|
|
<span class="highlight">Channel 6: (N/A)</span>
|
|
<span class="highlight">Channel 7: (N/A)</span>
|
|
<span class="highlight">Channel 8: (N/A)</span>
|
|
|
|
RECEPTION STATS:
|
|
Total packets received: 10670
|
|
Total packets missed: 128
|
|
Number of resynchronizations: 0
|
|
Longest good stretch: 934
|
|
Number of CRC errors: 651
|
|
|
|
BAROMETER CALIBRATION DATA:
|
|
<span class="highlight">Current barometer reading: 29.834 inHg</span>
|
|
<span class="highlight">Altitude: 700 feet</span>
|
|
Dew point: 55 F
|
|
Virtual temperature: 59 F
|
|
Humidity correction factor: 27
|
|
Correction ratio: 1.025
|
|
Correction constant: +0.000 inHg
|
|
Gain: 0.000
|
|
Offset: -47.000
|
|
|
|
OFFSETS:
|
|
<span class="highlight">Wind direction: +0 deg</span>
|
|
<span class="highlight">Inside Temperature: +0.0 F</span>
|
|
<span class="highlight">Inside Humidity: +0%</span>
|
|
<span class="highlight">Outside Temperature: +0.0 F</span>
|
|
<span class="highlight">Outside Humidity: +0%</span>
|
|
<span class="highlight">Extra Temperature 1: +0.0 F</span></pre>
|
|
<p>The console version number is available only on consoles with firmware
|
|
dates after about 2006.</p>
|
|
|
|
<p><span class="highlight">Highlighted </span> values can be changed using this utility.</p>
|
|
|
|
<h3 id="vantage_time_zone">Time zone</h3>
|
|
|
|
<p>To set the time zone code to Central European Time (code 20):</p>
|
|
<pre class="tty cmd">wee_device --set-tz-code=20</pre>
|
|
<p class="warning">You can set either the time zone code <em>or</em> the
|
|
time zone offset, but not both. </p>
|
|
|
|
<h3 id="vantage_archive_interval">Archive interval</h3>
|
|
|
|
<p>Valid archive intervals for the Davis Vantage stations are 60,
|
|
300, 600, 900, 1800, 3600, and 7200 seconds. However, if you are
|
|
ftp'ing lots of files to a server, setting it to 60 seconds
|
|
may not give enough time to have them all uploaded before the next
|
|
archive record is due. If this is the case, you should pick an
|
|
archive interval of at least 300 seconds, or trim the number of
|
|
files you are using.</p>
|
|
|
|
<p>To change the archive interval to 10 minutes (600 seconds):</p>
|
|
<pre class="tty cmd">wee_device --set-interval=600</pre>
|
|
<p>I have found that a five minute (300 seconds) archive interval works
|
|
well for the Vantage stations. Because of the large amount of onboard
|
|
memory they carry, going to a larger interval does not have any real
|
|
advantages. </p>
|
|
|
|
<h3 id="vantage_rain_bucket_type">Rain bucket type</h3>
|
|
|
|
<p>Normally, this is set by Davis, but if you have replaced your bucket
|
|
with a different kind, you might want to reconfigure. For example, to
|
|
change to a 0.1 mm bucket (bucket code "2"), use the
|
|
following:</p>
|
|
<pre class="tty cmd">wee_device --set-bucket=2</pre>
|
|
|
|
<h3 id="vantage_configuring_additional_sensors">Additional sensors</h3>
|
|
|
|
<p>If you have additional sensors for your Vantage station, you
|
|
can configure them using your console. However, if you have
|
|
a <a href="http://www.davisnet.com/weather/products/weather_product.asp?pnum=06316">Davis
|
|
Weather Envoy receiver</a>, it will not have a console! As an alternative,
|
|
the <span class='code'>weewx</span>
|
|
utility <span class="code">wee_device</span> lets
|
|
you do this from the command line.</p>
|
|
|
|
<p>For example, to add an extra temperature sensor to channel 3, do the following:</p>
|
|
<pre class="tty cmd">wee_device --set-transmitter-type=3,1,2</pre>
|
|
<p>This says to turn on channel 3, set its type to 1 ("Temperature only"), and have it show up in the
|
|
database as <span class="code">extraTemp2</span>. Here's another example, this time for a combined
|
|
temperature / humidity sensor:</p>
|
|
<pre class="tty cmd">wee_device --set-transmitter-type=5,3,2,4</pre>
|
|
<p>This will add the combined sensor to channel 5, set its type to 3 ("Temperature and humidity"),
|
|
and it will show up in the database
|
|
as <span class="code">extraTemp2</span> and <span class="code">extraHumid4</span>.</p>
|
|
|
|
<p>The <span class="code">--help</span> option will give you the code for each sensor type.</p>
|
|
|
|
<h3 id="vantage_setting_offsets">Setting offsets</h3>
|
|
|
|
<p>The Davis instruments can correct sensor errors by adding
|
|
an <em>offset</em> to their emitted values. This is particularly
|
|
useful for Southern Hemisphere users. Davis fits the wind vane
|
|
to the Integrated Sensor Suite (ISS) in a position optimized for
|
|
Northern Hemisphere users, who face the solar panel to the
|
|
south. Users south of the equator must orient the ISS's solar
|
|
panel to the north to get maximal insolation, resulting in a
|
|
180° error in the wind direction. The solution is to add a
|
|
180° offset correction. You can do this with the following
|
|
command:</p>
|
|
|
|
<pre class="tty cmd">wee_device --set-offset=windDir,180</pre>
|
|
|
|
<h3 id="vantage_dumping_the_logger_memory">Dumping the logger memory</h3>
|
|
|
|
<p>Generally, <span class="code">weewx</span> downloads only new archive
|
|
records from the on-board logger in the Vantage. However, occasionally the
|
|
memory in the Vantage will get corrupted, making this impossible. See the
|
|
troubleshooting section below <em><a href="#html_generated_but_not_updated">Weewx
|
|
generates HTML pages, but it does not update them</a></em>. The
|
|
fix involves clearing the memory but, unfortunately, this means you may
|
|
lose any data which might have accumulated in the logger memory, but not
|
|
yet downloaded. By using the <span class="code">--dump</span> command
|
|
before clearing the memory, you might be able to save these data.
|
|
Stop <span class="code">weewx</span> first, then</p>
|
|
<pre class="tty cmd">wee_device --dump</pre>
|
|
<p>This will dump all data archived in the Vantage memory directly to the
|
|
database, without regard to whether or not they have been seen before.
|
|
Because the command dumps <em>all</em> data, it may result in many
|
|
duplicate primary key errors. These can be ignored.</p>
|
|
|
|
|
|
<h2 id="wee_device_wmr100">WMR100</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure WMR100 stations.</p>
|
|
|
|
<p>The station emits partial packets, which may confuse some online
|
|
services.</p>
|
|
|
|
|
|
<h2 id="wee_device_wmr200">WMR200</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure WMR200 stations.</p>
|
|
|
|
<p>The station emits partial packets, which may confuse some online
|
|
services.</p>
|
|
|
|
<p>When <span class='code'>weewx</span> starts up it will attempt to
|
|
download all records from the console since the last record in the
|
|
archive database.
|
|
</p>
|
|
|
|
|
|
<h2 id="wee_device_wmr300">WMR300</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure WMR300 stations.</p>
|
|
|
|
<p>The station emits partial packets, which may confuse some online
|
|
services.</p>
|
|
|
|
<p>When <span class='code'>weewx</span> starts up it will attempt to
|
|
download all records from the console since the last record in the
|
|
archive database. This can take a couple of hours, depending on the
|
|
number of records in the logger and the speed of the computer and disk.
|
|
</p>
|
|
|
|
|
|
<h2 id="wee_device_wmr9x8">WMR9x8</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure WMR9x8 stations.</p>
|
|
|
|
<p>The station includes a data logger, but the driver does not read
|
|
records from the station.</p>
|
|
|
|
<p>The station emits partial packets, which may confuse some online
|
|
services.</p>
|
|
|
|
|
|
<h2 id="wee_device_ws1">WS1</h2>
|
|
|
|
<p>The <span class='code'>wee_device</span> utility cannot
|
|
configure WS1 stations.</p>
|
|
|
|
<p>The WS1 stations produce data every 1/2 second or so.</p>
|
|
|
|
|
|
<h2 id="wee_device_ws23xx">WS23xx</h2>
|
|
|
|
<p>The hardware interface is a serial port, but USB-serial converters
|
|
can be used with computers that have no serial port. Beware that
|
|
not every type of USB-serial converter will work. Converters based
|
|
on ATEN UC-232A chipset are known to work.</p>
|
|
|
|
<p>The station does not record wind gust or wind gust direction.</p>
|
|
|
|
<p>The hardware calculates windchill and dewpoint.</p>
|
|
|
|
<p>The station has 175 history records. That is just over 7 days
|
|
of data with the factory default history recording interval of 60
|
|
minutes, or about 14 hours with a recording interval of 5 minutes.</p>
|
|
|
|
<p>When <span class='code'>weewx</span> starts up it will attempt
|
|
to download all records from the console since the last record in
|
|
the archive database.</p>
|
|
|
|
<p>When the <span class='code'>station_type</span> is
|
|
<span class='code'>WS23xx</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class="tty">WS23xx driver version 0.21
|
|
Usage: wee_device [config_file] [options] [--debug] [--help]
|
|
|
|
Configuration utility for weewx devices.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--info display weather station configuration
|
|
--current get the current weather conditions
|
|
--history=N display N history records
|
|
--history-since=N display history records since N minutes ago
|
|
--clear-memory clear station memory
|
|
--set-time set the station clock to the current time
|
|
--set-interval=N set the station archive interval to N minutes
|
|
|
|
Mutating actions will request confirmation before proceeding.</pre>
|
|
|
|
<h3>Station information</h3>
|
|
|
|
<p>Display the station settings with the <span class='code'>--info</span>
|
|
option.</p>
|
|
<pre class="tty cmd">wee_device --info </pre>
|
|
<p>This will result in something like:</p>
|
|
<pre class='tty'>buzzer: 0
|
|
connection time till connect: 1.5
|
|
connection type: 15
|
|
dew point: 8.88
|
|
dew point max: 18.26
|
|
dew point max alarm: 20.0
|
|
dew point max alarm active: 0
|
|
dew point max alarm set: 0
|
|
dew point max when: 978565200.0
|
|
dew point min: -2.88
|
|
dew point min alarm: 0.0
|
|
dew point min alarm active: 0
|
|
dew point min alarm set: 0
|
|
dew point min when: 978757260.0
|
|
forecast: 0
|
|
history interval: 5.0
|
|
history last record pointer: 8.0
|
|
history last sample when: 1385564760.0
|
|
history number of records: 175.0
|
|
history time till sample: 5.0
|
|
icon alarm active: 0
|
|
in humidity: 48.0
|
|
...</pre>
|
|
|
|
<h3 id="ws23xx_changing_the_archive_interval">Changing the archive interval</h3>
|
|
|
|
<p>WS23xx stations ship from the factory with an archive interval of 60
|
|
minutes (3600 seconds). To change the station's interval to 5 minutes,
|
|
do the following:</p>
|
|
|
|
<p class="tty cmd">wee_device --set-interval=5</p>
|
|
|
|
<p class="warning"><strong>Warning!</strong><br/>
|
|
Changing the recording interval will clear the station memory.</p>
|
|
|
|
<h3 id="ws23xx_dumping_the_console_memory">Dumping the console memory</h3>
|
|
|
|
<p>WS23xx stations store records in a circular buffer - once the
|
|
buffer fills, the oldest records are replaced by newer records. The
|
|
console stores up to 175 records.
|
|
The <span class='code'>history number of records</span> indicates how
|
|
many records are in memory. The
|
|
<span class='code'>history interval</span> indicates the number of
|
|
minutes between records.</p>
|
|
|
|
<p>For example, to display the latest 30 records from the console memory:</p>
|
|
<pre class="tty cmd">wee_device --history=30</pre>
|
|
<p>To clear the console memory:</p>
|
|
<pre class="tty cmd">wee_device --clear-memory</pre>
|
|
|
|
|
|
<h2 id="wee_device_ws28xx">WS28xx</h2>
|
|
|
|
<p><span class='code'>weewx</span> communicates with a USB transceiver,
|
|
which communicates with the station console, which in turn communicates
|
|
with the sensors. The transceiver and console must be paired and
|
|
synchronized.</p>
|
|
|
|
<p>The station has 1797 history records. That is just over 6 days
|
|
of data with an archive interval of 5 minutes.</p>
|
|
|
|
<p>When <span class='code'>weewx</span> starts up it will attempt to
|
|
download all records from the console since the last record in the
|
|
archive database.
|
|
</p>
|
|
|
|
<p>The WS28xx driver sets the station archive interval to
|
|
5 minutes.</p>
|
|
|
|
<p>The WS28xx driver does not support hardware archive record
|
|
generation.</p>
|
|
|
|
<p>When the <span class='code'>station_type</span> is
|
|
<span class='code'>WS28xx</span>,
|
|
the <span class='code'>--help</span> option will produce output
|
|
something like this:</p>
|
|
|
|
<pre class="tty">WS28xx driver version 0.33
|
|
Usage: wee_device [config_file] [options] [--debug] [--help]
|
|
|
|
Configuration utility for weewx devices.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--debug display diagnostic information while running
|
|
-y answer yes to every prompt
|
|
--check-transceiver check USB transceiver
|
|
--pair pair the USB transceiver with station console
|
|
--info display weather station configuration
|
|
--set-interval=N set logging interval to N minutes
|
|
--current get the current weather conditions
|
|
--history=N display N history records
|
|
--history-since=N display history records since N minutes ago
|
|
--maxtries=MAXTRIES maximum number of retries, 0 indicates no max
|
|
|
|
Mutating actions will request confirmation before proceeding.</pre>
|
|
|
|
<h3>Pairing</h3>
|
|
|
|
<p>The console and transceiver must be paired. Pairing ensures that your
|
|
transceiver is talking to your console, not your neighbor's console.
|
|
Pairing should only have to be done once, although you might have to
|
|
pair again after power cycling the console, for example after you replace
|
|
the batteries.</p>
|
|
|
|
<p>There are two ways to pair the console and the transceiver:</p>
|
|
<ol>
|
|
<li><strong>The Weewx way.</strong> Be sure that
|
|
<span class='code'>weewx</span> is not running.
|
|
Run the configuration utility,
|
|
press and hold the [v] button on the console until you see
|
|
'PC' in the display, then release the button. If the console pairs
|
|
with the transceiver, 'PC' will go away within a second or two.
|
|
<pre class='tty'><span class="cmd">wee_device --pair</span>
|
|
|
|
Pairing transceiver with console...
|
|
Press and hold the [v] key until "PC" appears (attempt 1 of 3)
|
|
Transceiver is paired to console</pre>
|
|
</li>
|
|
<li><strong>The HeavyWeather way.</strong> Follow the pairing
|
|
instructions that came with the station. You will have to run
|
|
HeavyWeather on a windows computer with the USB transceiver. After
|
|
HeavyWeather indicates the devices are paired, put the USB transceiver
|
|
in your <span class="code">weewx</span> computer and start weewx.
|
|
Do not power cycle the station console or you will have to start
|
|
over.
|
|
</li>
|
|
</ol>
|
|
|
|
<p>If the console does not pair, you will see messages in the log such as
|
|
this:</p>
|
|
<pre class='tty'>ws28xx: RFComm: message from console contains unknown device ID (id=165a resp=80 req=6)</pre>
|
|
<p>Either approach to pairing may require multiple attempts.</p>
|
|
|
|
<h3>Synchronizing</h3>
|
|
|
|
<p>After pairing, the transceiver and console must be synchronized in
|
|
order to communicate. Synchronization will happen automatically at the
|
|
top of each hour, or you can force synchronization by pressing the [SET]
|
|
button momentarily. Do not press and hold the [SET] button - that
|
|
modifies the console alarms.</p>
|
|
|
|
<p>When the transceiver and console are synchronized, you will see lots of
|
|
'<span class="code">ws28xx: RFComm</span>' messages in the log when <span class="code">debug=1</span>. When the
|
|
devices are
|
|
not synchronized, you will see messages like this about every 10
|
|
minutes:</p>
|
|
<pre class='tty'>Nov 7 19:12:17 raspi weewx[2335]: ws28xx: MainThread: no contact with console</pre>
|
|
<p>If you see this, or if you see an extended gap in the weather data
|
|
in the <span class="code">weewx</span> plots, press momentarily the [SET] button, or wait until
|
|
the top of the hour.</p>
|
|
|
|
<p>When the transceiver has not received new data for awhile, you will see
|
|
messages like this in the log:</p>
|
|
<pre class='tty'>Nov 7 19:12:17 raspi weewx[2335]: ws28xx: MainThread: no new weather data</pre>
|
|
<p>If you see 'no new weather data' messages with the
|
|
'no contact with console' messages,
|
|
it simply means that the transceiver has not been able to synchronize
|
|
with the console. If you see only the 'no new weather data' messages,
|
|
then the sensors are not communicating with the console, or the console
|
|
may be defective.</p>
|
|
|
|
<h3>Station information</h3>
|
|
|
|
<p>Display the station settings with the <span class='code'>--info</span>
|
|
option.</p>
|
|
|
|
<p class="tty cmd">wee_device --info</p>
|
|
|
|
<p>This will result in something like:</p>
|
|
|
|
<pre class='tty'>alarm_flags_other: 0
|
|
alarm_flags_wind_dir: 0
|
|
checksum_in: 1327
|
|
checksum_out: 1327
|
|
format_clock: 1
|
|
format_pressure: 0
|
|
format_rain: 1
|
|
format_temperature: 0
|
|
format_windspeed: 4
|
|
history_interval: 1
|
|
indoor_humidity_max: 70
|
|
indoor_humidity_max_time: None
|
|
indoor_humidity_min: 45
|
|
indoor_humidity_min_time: None
|
|
indoor_temp_max: 40.0
|
|
indoor_temp_max_time: None
|
|
indoor_temp_min: 0.0
|
|
indoor_temp_min_time: None
|
|
lcd_contrast: 4
|
|
low_battery_flags: 0
|
|
outdoor_humidity_max: 70
|
|
outdoor_humidity_max_time: None
|
|
outdoor_humidity_min: 45
|
|
outdoor_humidity_min_time: None
|
|
outdoor_temp_max: 40.0
|
|
outdoor_temp_max_time: None
|
|
outdoor_temp_min: 0.0
|
|
outdoor_temp_min_time: None
|
|
pressure_max: 1040.0
|
|
pressure_max_time: None
|
|
pressure_min: 960.0
|
|
pressure_min_time: None
|
|
rain_24h_max: 50.0
|
|
rain_24h_max_time: None
|
|
threshold_storm: 5
|
|
threshold_weather: 3
|
|
wind_gust_max: 12.874765625
|
|
wind_gust_max_time: None</pre>
|
|
|
|
<h3>Alarms</h3>
|
|
|
|
<p>When an alarm goes off, communication with the transceiver stops.
|
|
The WS28xx driver clears all alarms in the station. It is better to
|
|
create alarms in weewx, and the <span class="code">weewx</span> alarms
|
|
can do much more than the console alarms anyway.</p>
|
|
|
|
|
|
<h1 id="running">Running <span class="code">weewx</span></h1>
|
|
|
|
<p><span class="code">Weewx</span> can be run either directly,
|
|
or as a daemon. When first trying
|
|
<span class="code">weewx</span>, it is best to run it directly
|
|
because you will be able to see sensor output and diagnostics, as well
|
|
as log messages. Once everything is working properly, run it as a
|
|
daemon.</p>
|
|
|
|
<h2>Running directly</h2>
|
|
|
|
<p>To run <span class="code">weewx</span> directly, invoke
|
|
the main program, <span class="code">weewxd</span>, giving
|
|
the configuration file as its only parameter: </p>
|
|
<pre class="tty cmd">sudo weewxd weewx.conf</pre>
|
|
<p>It should start by downloading any data stored in your weather station
|
|
(if the station has a data logger) into the archive database. For some
|
|
stations, such as the Davis Vantage with a couple thousand records, this
|
|
could take a minute or two. I have found this process particularly slow
|
|
on SuSE for some reason. </p>
|
|
|
|
<p><span class="code">Weewx</span> will then start monitoring live sensor
|
|
data (also referrred to as 'LOOP' data),
|
|
printing a short version of the received data on standard output, about
|
|
once every two seconds for a Vantage station, or considerably longer
|
|
for some other stations. </p>
|
|
|
|
<p>You can tell a running instance of <span class="code">weewx</span> to
|
|
reread its configuration file by sending it the
|
|
<span class="code">HUP</span> signal.
|
|
First run <span class="code">ps</span> to find out the Process ID (PID)
|
|
number of the instance, then send it the <span class="code">HUP</span> signal: </p>
|
|
<pre class="tty"><span class="cmd">ps -a</span> # Note the PID of the weewxd process
|
|
<span class="cmd">kill -HUP <em>pid</em></span> # Send it a HUP signal</pre>
|
|
<p>Note that this <em>only</em> rereads the configuration file. It will
|
|
not reload any code.</p>
|
|
|
|
<h2>Running as a daemon</h2>
|
|
|
|
<p>For unattended operations it is best to have <span class="code">weewx</span>
|
|
run as a daemon, started automatically when the server is rebooted. </p>
|
|
|
|
<p>If you use a packaged install from a DEB or RPM distribution, this is
|
|
done automatically. You can ignore this section.</p>
|
|
|
|
<p>Start by selecting the appropriate run script. They can be found in the
|
|
source or installation under
|
|
<span class="code">util/init.d/</span>. </p>
|
|
<table class="locations" style="width:90%">
|
|
<tr>
|
|
<td style='width:30%'>Debian/Ubuntu/Mint:</td>
|
|
<td class='tty'><span class="cmd">util/init.d/weewx.debian</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Redhat/CentOS/Mint:</td>
|
|
<td class='tty'><span class="cmd">util/init.d/weewx.redhat</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>SuSE:</td>
|
|
<td class='tty'><span class="cmd">util/init.d/weewx.suse</span></td>
|
|
</tr>
|
|
</table>
|
|
<p>Check the chosen script to make sure the variable <span class="code">WEEWX_ROOT</span>
|
|
has been set to the proper root directory for your
|
|
<span class="code">weewx</span> installation (it should have been set to the correct value automatically
|
|
by the install process, but it is worth checking). </p>
|
|
|
|
<p>Copy it to the proper location for your system: </p>
|
|
<table class="locations" style="width:90%">
|
|
<tr>
|
|
<td style="width: 30%">Debian/Ubuntu/Mint:</td>
|
|
<td class='tty'><span class="cmd">cp util/init.d/weewx.debian /etc/init.d/weewx</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Redhat/CentOS/Fedora:</td>
|
|
<td class='tty'><span class="cmd">cp util/init.d/weewx.redhat /etc/rc.d/init.d/weewx</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>SuSE:</td>
|
|
<td class='tty'><span class="cmd">cp util/init.d/weewx.suse /etc/init.d/weewx</span></td>
|
|
</tr>
|
|
</table>
|
|
<p>Make sure the script is executable: </p>
|
|
<table class="locations" style="width:90%">
|
|
<tr>
|
|
<td style="width: 30%">Debian/Ubuntu/Mint:</td>
|
|
<td class='tty'><span class="cmd">chmod +x /etc/init.d/weewx</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Redhat/CentOS/Fedora:</td>
|
|
<td class='tty'><span class="cmd">chmod +x /etc/init.d/rc.d/weewx</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>SuSE:</td>
|
|
<td class='tty'><span class="cmd">chmod +x /etc/init.d/weewx</span></td>
|
|
</tr>
|
|
</table>
|
|
<p>Create symbolic links in the run level directories: </p>
|
|
<table class="locations" style="width:90%">
|
|
<tr>
|
|
<td style="width: 30%">Debian/Ubuntu/Mint:</td>
|
|
<td class='tty'><span class="cmd">update-rc.d weewx defaults 98</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Redhat/CentOS/Fedora:</td>
|
|
<td class='tty'><span class="cmd">chkconfig weewx on</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>SuSE:</td>
|
|
<td class='tty'><span class="cmd">/usr/lib/lsb/install_initd /etc/init.d/weewx</span></td>
|
|
</tr>
|
|
</table>
|
|
<p><span class="code">Weewx</span> will now start automatically whenever your
|
|
system is booted. You can also manually start, stop, and restart the
|
|
<span class="code">weewx</span> daemon: </p>
|
|
<pre class="tty cmd">sudo /etc/init.d/weewx start
|
|
sudo /etc/init.d/weewx stop
|
|
sudo /etc/init.d/weewx restart</pre>
|
|
<p>By default, the scripts are designed to have <span class="code">weewx</span>
|
|
run at run levels 2, 3, 4 and 5. Incidentally, a nice tool for setting run levels
|
|
with Debian (Ubuntu, Mint) systems is
|
|
<a href="http://sysv-rc-conf.sourceforge.net/">sysv-rc-conf</a>. It uses a curses
|
|
interface to allow you to change easily which run level any of your daemons
|
|
runs at. There is a similar tool on SuSE. From the start menu run the YAST Control
|
|
Center, then look for Systems Services (Runlevel). Pick "Expert" mode
|
|
to see the run levels. </p>
|
|
|
|
<p>You can also tell <span class="code">weewx</span> to reread its configuration
|
|
file without stopping by using the 'reload' option: </p>
|
|
<pre class="tty cmd">sudo /etc/init.d/weewx reload </pre>
|
|
|
|
<h1 id="monitoring">Monitoring <span class="code">weewx</span></h1>
|
|
|
|
<p><span class="code">Weewx</span> logs many events to the system log.
|
|
On Debian systems, this is <span class="code">/var/log/syslog</span>,
|
|
on SuSE, <span class="code">/var/log/messages</span>. Your system may
|
|
use yet another place. When troubleshooting the system, be sure to check
|
|
it! </p>
|
|
|
|
<p class='tty cmd'>tail -f /var/log/syslog</p>
|
|
|
|
<p>Set the debug option in <span class='code'>weewx.conf</span> to
|
|
generate many more checks and output more information. This can be
|
|
useful for diagnosing problems and debugging.</p>
|
|
|
|
<p class='tty'>debug = 1</p>
|
|
|
|
|
|
<h1 id="integrating_with_webserver">Integrating with a web server</h1>
|
|
|
|
<h2>If the server is on the same machine</h2>
|
|
|
|
<p>The reports generated by <span class='code'>weewx</span> can be
|
|
served by a web server running on the same computer as
|
|
<span class='code'>weewx</span>. Here's how.</p>
|
|
|
|
<p>First, install a web server on the computer on which
|
|
<span class='code'>weewx</span> is running. For example, on Debian
|
|
systems:</p>
|
|
|
|
<p class='tty cmd'>sudo apt-get install apache2</p>
|
|
|
|
<p>Then, if <span class='code'>weewx</span> was installed from DEB or RPM
|
|
package, simply enter the <span class='code'>weewx</span> URL in a web
|
|
browser in order to see your webpages.</p>
|
|
|
|
<p class='tty'>http://localhost/weewx</p>
|
|
|
|
<p>Alternatively, if <span class='code'>weewx</span> was installed using
|
|
<span class='code'>setup.py</span>, copy the Apache configuration
|
|
snippet that comes with <span class="code">weewx</span> to the apache configuration directory, then restart
|
|
Apache:</p>
|
|
|
|
<pre class='tty cmd'>sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d
|
|
sudo /etc/init.d/apache2 restart</pre>
|
|
|
|
<p>Be sure that the path in the Apache configuration snippet matches the
|
|
<span class='code'>HTML_ROOT</span> defined in the
|
|
<span class='code'>weewx</span> configuration file.</p>
|
|
|
|
<pre class='tty'>Alias /weewx <span class="highlight">/home/weewx/public_html</span>
|
|
<Directory <span class="highlight">/home/weewx/public_html</span>>
|
|
Options FollowSymlinks
|
|
AllowOverride None
|
|
Order allow,deny
|
|
Allow from all
|
|
</Directory></pre>
|
|
|
|
<p>Then open the <span class='code'>weewx</span> URL in a web browser:</p>
|
|
|
|
<p class='tty'>http://localhost/weewx</p>
|
|
|
|
<h2>If the server is on a different machine</h2>
|
|
|
|
<p>Use the FTP or RSYNC 'reports' to upload to a web server. Either of
|
|
these will copy everything from the <span class='code'>HTML_ROOT</span>
|
|
directory to a location on the remote server on which the web server
|
|
is running.</p>
|
|
|
|
|
|
<h1 id="backup">Making backups</h1>
|
|
|
|
<p>
|
|
To backup a <span class='code'>weewx</span> installation, you will need to make a copy
|
|
of</p>
|
|
<ul>
|
|
<li>configuration information;</li>
|
|
<li>skins and templates;</li>
|
|
<li>any custom code or extensions you have installed;</li>
|
|
<li>the weewx database.</li>
|
|
</ul>
|
|
<p>
|
|
It is not necessary to backup the generated images, HTML files, or NOAA reports since weewx will easily
|
|
create these again.
|
|
</p>
|
|
|
|
<p>Individual instructions follow</p>
|
|
|
|
<h2>Configuration</h2>
|
|
|
|
<p>
|
|
Save the <span class='code'>weewx.conf</span> file.
|
|
</p>
|
|
<table class="locations" style="width:70%">
|
|
<tr>
|
|
<td style="width: 30%">setup.py:</td>
|
|
<td class='tty'>/home/weewx/weewx.conf</td>
|
|
</tr>
|
|
<tr>
|
|
<td>DEB/RPM:</td>
|
|
<td class='tty'>/etc/weewx/weewx.conf</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Skins and templates</h2>
|
|
|
|
<p>
|
|
Save the contents of the skins directory if you have modified the default
|
|
skin or if you have added any new skins or template files.
|
|
</p>
|
|
<table class="locations" style="width:70%">
|
|
<tr>
|
|
<td style="width: 30%">setup.py:</td>
|
|
<td class='tty'>/home/weewx/skins</td>
|
|
</tr>
|
|
<tr>
|
|
<td>DEB/RPM:</td>
|
|
<td class='tty'>/etc/weewx/skins</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Custom code or extensions</h2>
|
|
|
|
<p>
|
|
Save the contents of the
|
|
<span class='code'>user</span> directory if you have modified the
|
|
database schema or added any extensions. If the extensions save data
|
|
to a database you should backup those databases as well.
|
|
</p>
|
|
<table class="locations" style="width:70%">
|
|
<tr>
|
|
<td style="width: 30%">setup.py:</td>
|
|
<td class='tty'>/home/weewx/bin/user</td>
|
|
</tr>
|
|
<tr>
|
|
<td>DEB/RPM:</td>
|
|
<td class='tty'>/usr/share/weewx/user</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Weewx database</h2>
|
|
|
|
<p>
|
|
Finally, you will need to backup the database.
|
|
</p>
|
|
<p>
|
|
For a SQLite configuration, you will need to backup the <span class='code'>weewx.sdb</span> file.
|
|
</p>
|
|
<p class="note">
|
|
Do not make the copy of the SQLite database while in the middle of a
|
|
transaction! Schedule the
|
|
backup for immediately after an archive record is written, and then make sure
|
|
the backup completes before the next archive record arrives.
|
|
Alternatively, stop weewx, perform the backup, then restart weewx.
|
|
</p>
|
|
|
|
<table class="locations" style="width:70%">
|
|
<tr>
|
|
<td style="width: 30%">setup.py:</td>
|
|
<td class='tty'>/home/weewx/archive/weewx.sdb</td>
|
|
</tr>
|
|
<tr>
|
|
<td>DEB/RPM:</td>
|
|
<td class='tty'>/var/lib/weewx/weewx.sdb</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
For a MySQL configuration, save a dump of the archive database.
|
|
</p>
|
|
|
|
<h2>Restoring from backup</h2>
|
|
|
|
<p>
|
|
To restore from backup, do a fresh install of
|
|
<span class='code'>weewx</span> then replace the default files with
|
|
those from a backup. Then start <span class='code'>weewx</span>.
|
|
</p>
|
|
|
|
|
|
<h1 id="configuring_mysql">Configuring MySQL</h1>
|
|
|
|
<p>This section applies only to those who wish to use the MySQL
|
|
database, instead of the default SQLite database.</p>
|
|
|
|
<p>
|
|
First, you should change your <a href="#wx_binding"><span class="code">[[wx_binding]]</span></a>
|
|
section to point to the MySQL database, <span class="code">archive_mysql</span>,
|
|
instead of the SQLite database <span class="code">archive_sqlite</span>. After the
|
|
change, it
|
|
will look something like this (change <span class="highlight">highlighted</span>):
|
|
</p>
|
|
<pre class="tty">
|
|
[[wx_binding]]
|
|
# The database should match one of the sections in [Databases]
|
|
<span class="highlight">database = archive_mysql</span>
|
|
# The name of the table within the database
|
|
table_name = archive
|
|
# The class to manage the database
|
|
manager = weewx.wxmanager.WXDaySummaryManager
|
|
# The schema defines to structure of the database contents
|
|
schema = schemas.wview.schema</pre>
|
|
|
|
<p>Assuming that you want to use the default database configuration, your
|
|
<span class="code"><a href="#Databases">[[MySQL]]</a></span> section
|
|
should look something like this:</p>
|
|
<pre class="tty">[[MySQL]]
|
|
driver = weedb.mysql
|
|
host = localhost
|
|
user = weewx
|
|
password = weewx
|
|
</pre>
|
|
<p>This assumes user <span class="code">weewx</span> would have password <span class="code">weewx</span>.
|
|
Adjust as necessary.</p>
|
|
|
|
<p>You will need to give the necessary permissions for the database <span class="code">weewx</span>
|
|
to whatever MySQL user you choose, by
|
|
default, user <span class="code">weewx</span>. Here are the necessary minimum
|
|
permissions:</p>
|
|
<pre class="tty">mysql> <span class="cmd">CREATE USER 'weewx'@'localhost' IDENTIFIED BY 'weewx';</span>
|
|
mysql> <span class="cmd">GRANT select, update, create, delete, insert, drop ON weewx.* TO weewx@localhost;</span></pre>
|
|
|
|
|
|
<h1 id="wview_compatibility">Compatibility with <span class="code">wview</span></h1>
|
|
|
|
<h2>sqlite3</h2>
|
|
|
|
<p>The SQLite archive database used by <span class="code">weewx</span>
|
|
(nominally, <span class="code">weewx.sdb</span>) is completely
|
|
compatible with the database used by
|
|
<a href="http://www.wviewweather.com">wview</a> (usually called
|
|
<span class="code">wview-archive.sdb</span>), at least as of wview
|
|
Version 5.2.X. The schema, and its semantics, is identical.
|
|
</p>
|
|
|
|
<p>If you have data from <span class='code'>wview</span>, you can
|
|
'import' them into <span class='code'>weewx</span> by simply copying the
|
|
SQLite database file. Assuming that the <span class='code'>wview</span>
|
|
data are in file
|
|
<span class='code'>/var/wview/archive/wview-archive.sdb</span>,</p>
|
|
|
|
<pre class='tty cmd'>sudo /etc/init.d/weewx stop
|
|
cd <span class="symcode">SQLITE_ROOT</span>
|
|
mv weewx.sdb weewx.sdb.bak
|
|
cp /var/wview/archive/wview-archive.sdb weewx.sdb
|
|
sudo /etc/init.d/weewx start</pre>
|
|
|
|
<p>
|
|
Internally, within the <span class="code">weewx.sdb</span> database,
|
|
<span class="code">weewx</span> also maintains a "daily summary" of all the statistics. This
|
|
is done for performance reasons. The daily summary will
|
|
automatically be built on the first startup. This could take
|
|
a few minutes if the <span class='code'>wview</span> archive contains
|
|
more than a month or two of data.
|
|
</p>
|
|
|
|
<p>
|
|
On my modest 500 MHz <a href="http://www.fit-pc.com/">fit-PC
|
|
Slim</a> with 512 MB of memory it took a little over 4 minutes for a
|
|
year and a half (25 MB) of data.
|
|
</p>
|
|
|
|
<h2>MySQL</h2>
|
|
|
|
<p>The MySQL archive database used by wview is "almost" compatible with
|
|
<span class="code">weewx</span>. The one difference is that in wview, the column <span
|
|
class="code">interval</span>
|
|
is named <span class="code">arcInt</span> (presumably because
|
|
<span class="code">interval</span> is a keyword in MySQL, although it can
|
|
still be used by surrounding the word with backquotes). </p>
|
|
|
|
<p>To change the column name to what <span class="code">weewx</span> uses, namely <span class="code">interval</span>,
|
|
use the utility <span class="code">mysql</span> and issue the command:</p>
|
|
<pre class="tty">mysql> <span class="cmd">ALTER TABLE <em>your-wview-archive-name</em> CHANGE arcInt `interval` INTEGER NOT NULL;</span> </pre>
|
|
<p>where <span class="code"><em>your-wview-archive-name</em></span> is the
|
|
name of your wview archive database. Note that the word <span class="code">
|
|
interval</span> is surrounded by backquotes.</p>
|
|
|
|
<p>Then in the <span class="code">[Databases]</span> section of
|
|
<span class="code">weewx.conf</span>, replace the name of the database
|
|
with whatever your installation of wview used <span class="code"><em>your-wview-archive-name</em></span>:</p>
|
|
<pre class="tty">[[archive_mysql]]
|
|
database_type = MySQL
|
|
database_name = <span class="highlight"><em>your-wview-archive-name</em></span></pre>
|
|
|
|
|
|
<h1 id="troubleshooting">Troubleshooting</h1>
|
|
|
|
<p>This section lists some common problems installing and running
|
|
<span class="code">weewx</span>. If you are still stuck, be sure to: </p>
|
|
<ul>
|
|
<li style="margin-bottom: 1em">Set the option <span
|
|
class="code">debug</span> to <span class="code">1</span> in <span
|
|
class='code'>weewx.conf</span>. This will put much more
|
|
information in the log file, which can be very useful for
|
|
troubleshooting and debugging!
|
|
<p class='tty'>debug = 1</p>
|
|
</li>
|
|
<li style="margin-bottom: 1em">Look at the <a href="#monitoring">log file</a>. I am
|
|
always happy to take questions, but the first thing I will ask
|
|
is, "Did you look at the log file?"
|
|
<p class='tty cmd'>sudo tail -f /var/log/syslog</p>
|
|
</li>
|
|
<li style="margin-bottom: 1em">Run <span class="code">weewxd</span>
|
|
directly from the command line, rather than as a
|
|
daemon. Generally, <span class="code">weewx</span> will catch
|
|
and log any unrecoverable exceptions. But if you are getting
|
|
strange results, it is worth running directly and looking for
|
|
any clues.
|
|
<p class='tty cmd'>sudo weewxd weewx.conf</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>The utility <span class="code">wee_debug</span></h2>
|
|
|
|
<p>Troubleshooting problems when running <span class="code">weewx</span>
|
|
often involves analysis of a number of pieces of seemingly disparate system
|
|
and <span class="code">weewx</span> related information. The
|
|
<span class="code">wee_debug</span> utility gathers this information into
|
|
a single output to make troubleshooting easier. The
|
|
<span class="code">wee_debug</span> utility is particularly useful for new
|
|
users as the output may be redirected to file then emailed or posted to a
|
|
forum to assist in remote troubleshooting.</p>
|
|
|
|
<p>Before using <span class="code">wee_debug</span>, it's worth running it
|
|
with the <span class="code">--help</span> option to see how it is used:</p>
|
|
|
|
<pre class="tty cmd">wee_debug --help</pre>
|
|
|
|
<p>This results in:</p>
|
|
|
|
<pre class="tty">Usage: wee_debug --help
|
|
wee_debug --info
|
|
[--output|--output DEBUG_PATH]
|
|
[--verbosity=0|1|2]
|
|
wee_debug --version
|
|
|
|
|
|
Generate a standard suite of system/weewx information to aid in remote
|
|
debugging. The wee_debug output consists of two parts, the first part
|
|
containing a snapshot of relevant system/weewx information and the second part
|
|
a parsed and obfuscated copy of weewx.conf. This output can be redirected to
|
|
file and posted when seeking assistance via forums or email.
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
--info Generate weewx debug output.
|
|
--output Write wee_debug output to DEBUG_PATH. DEBUG_PATH includes
|
|
path and file name. Default is /var/tmp/weewx.debug.
|
|
--verbosity=N How much detail to display, 0-2, default=1.
|
|
--version Display wee_debug version number.
|
|
|
|
wee_debug will attempt to obfuscate obvious personal/private information in
|
|
weewx.conf such as user names, passwords and API keys; however, the user
|
|
should thoroughly check the generated output for personal/private information
|
|
before posting the information publicly.
|
|
</pre>
|
|
|
|
<h3><span class="code">wee_debug</span> version number</h3>
|
|
|
|
<p>To display the <span class="code">wee_debug</span> version number:</p>
|
|
|
|
<pre class="tty cmd">wee_debug --version</pre>
|
|
|
|
<p>This displays a short message indicating the
|
|
<span class="code">wee_debug</span> version number:</p>
|
|
|
|
<pre class="tty">wee_debug version: 0.2</pre>
|
|
|
|
<h3>Generating a debug report</h3>
|
|
|
|
<p>A debug report can be generated using the <span class="code">--info</span>
|
|
option as follows:</p>
|
|
|
|
<p class="warning"><strong>Warning!</strong><br/>
|
|
The <span class="code">wee_debug</span> output includes a copy of the in use <span class="code">weewx</span> config file (usually <span class="code">weewx.conf</span>) and whilst <span class="code">wee_debug</span> attempts to obfuscate any personal or sensitive information in <span class="code">weewx.conf</span>, the user should carefully check the <span class="code">wee_debug</span> output for any remaining personal or sensitive information before emailing or posting the output publicly.</p>
|
|
|
|
<pre class="tty cmd">wee_debug --info</pre>
|
|
|
|
<p>This results in:</p>
|
|
<pre class="tty">Using verbosity=1, displaying most info
|
|
|
|
wee_debug output will be sent to stdout(console)
|
|
|
|
Using configuration file /home/weewx/weewx.conf
|
|
Using database binding 'wx_binding', which is bound to database 'archive_mysql'
|
|
|
|
System info
|
|
CPU implementer: 0x41
|
|
Features: half thumb fastmult vfp edsp java tls
|
|
CPU architecture: 7
|
|
BogoMIPS: 2.00
|
|
Hardware: BCM2708
|
|
CPU revision: 7
|
|
CPU part: 0xb76
|
|
model name: ARMv6-compatible processor rev 7 (v6l)
|
|
Serial: 000000009581b554
|
|
processor: 0
|
|
CPU variant: 0x0
|
|
Revision: 000e
|
|
|
|
Operating system: debian 7.8
|
|
Linux rosella 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l
|
|
1 minute load average: 0.19
|
|
5 minute load average: 0.15
|
|
15 minute load average: 0.12
|
|
|
|
General weewx info
|
|
Weewx version 3.2.1 detected.
|
|
|
|
Station info
|
|
Station type: Simulator
|
|
Driver: weewx.drivers.simulator
|
|
|
|
Driver info
|
|
[Simulator]
|
|
# This section is for the weewx weather station simulator
|
|
|
|
# The time (in seconds) between LOOP packets.
|
|
loop_interval = 2.5
|
|
|
|
# The simulator mode can be either 'simulator' or 'generator'.
|
|
# Real-time simulator. Sleep between each LOOP packet.
|
|
mode = simulator
|
|
# Generator. Emit LOOP packets as fast as possible (useful for testing).
|
|
#mode = generator
|
|
|
|
# The start time. If not specified, the default is to use the present time.
|
|
#start = 2011-01-01 00:00
|
|
|
|
# The driver to use:
|
|
driver = weewx.drivers.simulator
|
|
|
|
Currently installed extensions
|
|
Extension Name Version Description
|
|
Weewx-WD 1.2.0b1 Weewx support for Weather Display Live, SteelSeries Gauges and Carter Lake/Saratoga weather web site templates.
|
|
|
|
Archive info
|
|
Database name: weewx
|
|
Table name: archive
|
|
Unit system: 16(METRIC)
|
|
First good timestamp: 2013-01-01 00:00:00 AEST (1356962400)
|
|
Last good timestamp: 2015-09-06 02:15:00 AEST (1441469700)
|
|
Number of records: 281178
|
|
weewx (weewx.conf) is set to use an archive interval of 300 seconds.
|
|
The station hardware was not interrogated in determining archive interval.
|
|
|
|
Databases configured in weewx.conf
|
|
Database name: weewx
|
|
Database driver: weedb.mysql
|
|
Database host: localhost
|
|
|
|
Database name: wdsupp
|
|
Database driver: weedb.mysql
|
|
Database host: localhost
|
|
|
|
Database name: weewxwd
|
|
Database driver: weedb.mysql
|
|
Database host: localhost
|
|
|
|
|
|
Parsed and obfuscated weewx.conf
|
|
# WEEWX CONFIGURATION FILE
|
|
#
|
|
# Copyright (c) 2009-2015 Tom Keffer <tkeffer@gmail.com>
|
|
# See the file LICENSE.txt for your rights.
|
|
|
|
##############################################################################
|
|
|
|
# This section is for general configuration information.
|
|
|
|
... content removed for conciseness ...
|
|
|
|
# This section configures the internal weewx engine.
|
|
|
|
[Engine]
|
|
|
|
[[Services]]
|
|
# This section specifies the services that should be run. They are
|
|
# grouped by type, and the order of services within each group
|
|
# determines the order in which the services will be run.
|
|
prep_services = weewx.engine.StdTimeSynch
|
|
data_services = ,
|
|
process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate, user.weewxwd3.WdWXCalculate
|
|
archive_services = weewx.engine.StdArchive, user.weewxwd3.WdArchive, user.weewxwd3.WdSuppArchive
|
|
restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS, user.sync.SyncService
|
|
report_services = weewx.engine.StdPrint, weewx.engine.StdReport
|
|
|
|
################################################################################
|
|
|
|
wee_debug report successfully generated
|
|
</pre>
|
|
|
|
<h4>Redirecting <span class="code">wee_debug</span> output</h4>
|
|
|
|
<p><span class="code">wee_debug</span> output is sent by default to
|
|
<span class="code">stdout</span> unless the optional <span class="code">--output</span>
|
|
option is used. <span class="code">--output</span> with no parameter will
|
|
send the <span class="code">wee_debug</span> output to the default file
|
|
<span class="code">/var/tmp/weewx.debug</span>. Usage is as follows:</p>
|
|
|
|
<pre class="tty cmd">wee_debug --info --output</pre>
|
|
|
|
<p>output can be sent to a file other than the default by including the
|
|
path and file name as a parameter after <span class="code">--output</span>:</p>
|
|
|
|
<pre class="tty cmd">wee_debug --info --output /home/weewx/another.debug</pre>
|
|
|
|
<h4><span class="code">wee_debug</span> verbosity</h4>
|
|
|
|
<p>The depth of information included in the <span class="code">wee_debug</span>
|
|
output can be changed using the <span class="code">--verbosity</span> option.
|
|
The <span class="code">--verbosity</span> option can be set to 0, 1 or 2 with
|
|
each higher level successively displaying more information. The default level
|
|
is 1. The information displayed for each level is:</p>
|
|
|
|
<table class="indent">
|
|
<tr class="first_row">
|
|
<td>Level</td>
|
|
<td>Included Information</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan=8><span class="code">--verbosity 0</span></td>
|
|
<td>path and name of <span class="code">weewx</span> config file used (usually <span class="code">weewx.conf</span>)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>name of <span class="code">weewx</span> database binding used</td>
|
|
</tr>
|
|
<tr>
|
|
<td>operating system version</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class="code">weewx</span> version number</td>
|
|
</tr>
|
|
<tr>
|
|
<td><span class="code">weewx</span> station type and driver name</td>
|
|
</tr>
|
|
<tr>
|
|
<td>summary of currently installed extensions</td>
|
|
</tr>
|
|
<tr>
|
|
<td>summary of <span class="code">weewx</span> archive</td>
|
|
</tr>
|
|
<tr>
|
|
<td>parsed and obfusated <span class="code">weewx</span> config file (usually <span class="code">weewx.conf</span>)</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan=5><span class="code">--verbosity 1</span></td>
|
|
<td>as per <span class="code">--verbosity 0</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>cpu info summary</td>
|
|
</tr>
|
|
<tr>
|
|
<td>system load averages</td>
|
|
</tr>
|
|
<tr>
|
|
<td>driver config extract from <span class="code">weewx</span> config file (usually <span class="code">weewx.conf</span>)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>summary of databases configured in <span class="code">weewx</span> config file (usually <span class="code">weewx.conf</span>)</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight" rowspan=3><span class="code">--verbosity 2</span></td>
|
|
<td>as per <span class="code">--verbosity 1</span></td>
|
|
</tr>
|
|
<tr>
|
|
<td>list of supported SQL keys</td>
|
|
</tr>
|
|
<tr>
|
|
<td>list of supported observation types</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Hardware problems</h2>
|
|
|
|
<h3>Tips on making a system reliable</h3>
|
|
|
|
<p>If you are having problems keeping your weather station up for long
|
|
periods of time, here are some tips, in decreasing order of importance:
|
|
</p>
|
|
|
|
<div class='image image-right' style='width:205px'>
|
|
<a href="images/ferrites.jpg"><img src="images/ferrites.jpg" width='200' border='1' alt="Ferrite coils"
|
|
longdesc="Cable connection looped through a ferrite coil"/></a>
|
|
|
|
<div class='image_caption'>Ferrite coils on a Davis Envoy. There are two
|
|
coils, one on the USB connection (top wire) and one on the power
|
|
supply. Both have loops. Click for larger picture.</div>
|
|
</div>
|
|
<ul>
|
|
<li>Run on dedicated hardware. If you are using the server for other
|
|
tasks, particularly as your desktop machine, you will have reliability
|
|
problems. If you are using it as a print or network server, you will
|
|
probably be OK.
|
|
</li>
|
|
<li>Run headless. Modern graphical systems are extremely complex. As new
|
|
features are added, test suites do not always catch up. Your system
|
|
will be much more reliable if you run it without a windowing system (X
|
|
Windows, in the case of Linux).
|
|
</li>
|
|
<li>Use an Uninterruptible Power Supply (UPS). The vast majority of power
|
|
glitches are very short lived — just a second or two — so
|
|
you do not need a big one. The 425VA unit I use to protect my fit-PC
|
|
cost $55 at Best Buy.
|
|
</li>
|
|
<li>If you buy a Davis VantagePro and your computer has an old-fashioned
|
|
serial port, get the VantagePro with a serial connection, not a USB
|
|
connection. See the section on <a href="#davis_cp2101_converter">Davis
|
|
cp2101 converter problems</a> for details.
|
|
</li>
|
|
<li>If you do use a USB connection, put a ferrite coil on each end of
|
|
the cable to your console. If you have enough length and the ferrite
|
|
coil is big enough, make a loop so it goes through the coil twice.
|
|
See the figure at right.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>Establishing connectivity</h3>
|
|
|
|
<p>If you are unable to get anything out of <span class="code">weewx</span>
|
|
first check that you have connectivity to your weather station. For the
|
|
Davis stations, you can use a terminal emulator to run a simple test.
|
|
Set it up to communicate using the appropriate port and baudrate. I
|
|
like <span class="code">minicom</span> because it can be run from
|
|
through a simple TTY connection. The utility
|
|
<span class="code">screen</span> also works well. For example:</p>
|
|
<pre class="tty cmd">minicom -b 19200 -D /dev/ttyUSB0</pre>
|
|
<p>or, using <span class='code'>screen</span>:</p>
|
|
<pre class="tty cmd">screen /dev/ttyUSB0 19200</pre>
|
|
<p>Then type in <span class="code">TEST</span>, all in capital letters. It
|
|
will not echo the characters. Then hit the
|
|
<span class="code"><enter></span>
|
|
key. It should echo back <span class="code">TEST</span>.</p>
|
|
|
|
<p>If this works, then you have established connectivity with the Davis
|
|
and the problem must lie elsewhere.</p>
|
|
|
|
<h3 id="davis_cp2101_converter">Davis cp2101 converter problems</h3>
|
|
|
|
<p>The USB converter used in the Davis VantagePro is known to have some "noise"
|
|
problems. The symptom is that the Linux kernel will disconnect from your old
|
|
USB port claiming "EMI noise", and reconnect to a new and different
|
|
port, where <span class="code">weewx</span> cannot find it. Here is a
|
|
typical log output: </p>
|
|
|
|
<pre class='tty'>Nov 29 10:40:21 hummingbird kernel: [6661624.786792] hub 2-0:1.0: port 3 disabled by hub (EMI?) re-enabling...
|
|
Nov 29 10:40:21 hummingbird kernel: [6661624.786871] usb 2-3: USB disconnect, address 2
|
|
Nov 29 10:40:21 hummingbird kernel: [6661624.795778] cp2101 2-3:1.0: device disconnected
|
|
Nov 29 10:40:21 hummingbird weewx[25808]: VantagePro: Max retries exceeded while getting LOOP packets
|
|
... (messages elided)
|
|
Nov 29 10:40:22 hummingbird kernel: [6661625.352340] cp2101 2-3:1.0: cp2101 converter detected
|
|
Nov 29 10:40:22 hummingbird kernel: [6661625.528107] usb 2-3: reset full speed USB device using ohci_hcd and address 3
|
|
Nov 29 10:40:22 hummingbird kernel: [6661625.735497] usb 2-3: cp2101 converter now attached to ttyUSB1</pre>
|
|
|
|
<p>In this example, the VantagePro was connected to <span class="code">/dev/ttyUSB0</span>,
|
|
but then reconnected to <span class="code">/dev/ttyUSB1</span>. </p>
|
|
|
|
<p>If you put ferrite coils on the USB connection, you will eliminate 90% of
|
|
this problem. I did this about 3 years ago, and have not had a problem since.
|
|
</p>
|
|
|
|
<p>However, there is one final step that you can take to really harden up
|
|
your system: install a <span class="code">udev</span> script that will create
|
|
a symbolic link to the VantagePro USB port, whatever it might be. With this
|
|
approach, if the port jumps from <span class="code">ttyUSB0</span> to
|
|
<span class="code">ttyUSB1</span>, the symbolic link will follow it. You just
|
|
specify port <span class="code">/dev/vpro</span> in the configuration file
|
|
<span class="code">weewx.conf</span> and be done with it. </p>
|
|
|
|
<h3 id='udev_script'>Installing a udev script</h3>
|
|
|
|
<p>Use a udev rule to ensure that a USB device always appears at the same
|
|
location such as <span class='code'>/dev/vpro</span> instead of
|
|
<span class='code'>/dev/ttyUSB2</span></p>
|
|
|
|
<p>For example, for my VantagePro2 weather station, I have installed a file
|
|
<span class="code">/etc/udev/rules.d/vpro.rules</span>
|
|
on my fit-PC that looks like this: </p>
|
|
|
|
<pre class='tty'># Automount the VantagePro2 to port /dev/vpro.
|
|
# Install in /etc/udev/rules.d/vpro.rules
|
|
#
|
|
ACTION=="add", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", SYMLINK+="vpro"</pre>
|
|
|
|
<p>This rule says that when the USB port is plugged in (action
|
|
<span class="code">add</span>), and it has an attribute with name
|
|
<span class="code">interface</span> that is equal to
|
|
"<span class="code">CP2102 to UART Bridge Controller</span>",
|
|
then add a symbolic link for its physical port to
|
|
<span class="code">/dev/vpro</span>. </p>
|
|
|
|
<p>Here is a rule that works for my Serial-to-USB cable, made by "Y.C. Cable USA". It
|
|
not only adds a symbolic link <span class="code">vpro</span>, but also sets the
|
|
<span class="code">chmod</span>
|
|
permissions to <span class="code">666</span>, allowing any user to read or write to it.</p>
|
|
<pre class='tty'># Automount Serial-to-USB cable to port /dev/vpro
|
|
# Install in /etc/udev/rules.d/cable.rules
|
|
#
|
|
ACTION=="add",ATTRS{idVendor}=="05ad",ATTRS{idProduct}=="0fba",MODE="0666",SYMLINK+="vpro"</pre>
|
|
<p>Your devices may, and probably will, have different identifiers!! I can recommend
|
|
this article, "<a href="http://www.reactivated.net/writing_udev_rules.html"><em>Writing
|
|
udev rules</em></a>," for how to find and write an appropriate
|
|
<span class="code">udev</span> rule for your controller. (Note, however, that
|
|
this article uses the old <span class="code">udevinfo</span> command, rather
|
|
than the newer <span class="code">udevadm</span> command.) In particular, run
|
|
the command </p>
|
|
|
|
<p class='tty cmd'>udevadm info --attribute-walk --path $(udevadm info --query=path --name=/dev/ttyUSB0) </p>
|
|
|
|
<p>where<span class="code"> /dev/ttyUSB0</span> is the port (substitute
|
|
your real USB port) the weather station is attached to. It will print
|
|
out various identifiers that can be useful in identifying your weather
|
|
station to <span class="code">udev</span>.
|
|
While the first example script above used a rule that matched attribute
|
|
<span class="code">interface</span>, others are possible. For example,
|
|
the second example, for the serial-to-USB cable, chose to match the
|
|
attribute <span class="code">product</span>. </p>
|
|
|
|
<p>Once you have installed your <span class="code">udev</span> rule, you
|
|
can then set <span class="code">port=/dev/vpro</span> in
|
|
<span class="code">weewx.conf</span>, confident that it will always point
|
|
to your weather station, no matter which USB port it is actually
|
|
attached to! </p>
|
|
|
|
<p>I have tested this system many times. You can yank the USB port out of the
|
|
machine and then plug it back in while also pulling out the network connection
|
|
in the middle of an FTP upload: <span class="code">weewx</span> will recover.
|
|
</p>
|
|
|
|
<p>Or, at least, it should! </p>
|
|
|
|
<h3 id="html_generated_but_not_updated">Weewx generates HTML pages, but it does not update them</h3>
|
|
|
|
<p>If you are getting a symptom that everything appears normal, that is
|
|
image and HTML files are generated (<em>(look in the log to be sure</em>)
|
|
and sent to your webserver (if you have configured FTP or rsync), but
|
|
the values in the web pages are not being updated, it could be due to
|
|
clock skew or corrupt station memory.</p>
|
|
|
|
<h4>Clock skew</h4>
|
|
<p>If the database contains a record with time stamp (the dateTime field)
|
|
in the future, then records from the station that are older than that
|
|
future date will be ignored. How can the database contain records from
|
|
the future? Sometimes the computer clock is not set correctly. For
|
|
example, the raspberry pi has no clock, so if weewx saves data before
|
|
the pi has synchronized its clock with internet time servers, the
|
|
records will have incorrect time stamps, some of which might be in the
|
|
future.</p>
|
|
|
|
<p>The solution is to delete any records with time stamp in the future.
|
|
For a sqlite database, the procedure looks like this:</p>
|
|
|
|
<pre class="tty"><span class="cmd">cp /home/weewx/archive/weewx.sdb /home/weewx/archive/weewx.sdb.backup
|
|
sqlite3 /home/weewx/archive/weewx.sdb</span>
|
|
sqlite> <span class="cmd">delete from archive where dateTime > X;</span>
|
|
sqlite> <span class="cmd">.exit</span></pre>
|
|
|
|
<p>The timestamp X is the current time as unix epoch (number of seconds
|
|
since 1 January 1970), or a time a minute or two in the future.</p>
|
|
|
|
<h4>Corrupt station memory</h4>
|
|
<p>If you have a Vantage station, the problem might be because the data on
|
|
board your console has gotten garbled. The way the Davis Vantage series
|
|
works is that the software (<span class="code">weewx</span> in this case)
|
|
asks the console for all archive data "since" some time. The
|
|
console then downloads the records one at a time. After it gets to the
|
|
very last one, the memory wraps around, and the timestamp will suddenly
|
|
jump backwards in time a couple weeks — this how the software
|
|
knows it has downloaded the last record and so it stops.</p>
|
|
|
|
<p>However, if the internal memory gets garbled, the console will immediately
|
|
return archives in the past, and so it looks like the timestamps have decreased
|
|
in value and so <span class="code">weewx</span> figures that is it: there is
|
|
no more data.</p>
|
|
|
|
<p>I have received reports from a couple of users who have had this problem.
|
|
There seems to be two fixes:</p>
|
|
<ol>
|
|
<li>Unplug the console, take out the batteries, and wait a minute or two.
|
|
This will cause the console software to internally reboot. In one case this
|
|
has fixed the problem without data loss.
|
|
</li>
|
|
<li>If all else fails, clear the memory of the console using the utility
|
|
<span class="code">wee_device</span>. This may cause loss of data, but
|
|
usually works. Adjust paths as necessary:
|
|
</li>
|
|
</ol>
|
|
<pre class="tty cmd">wee_device --clear</pre>
|
|
<p>See also the section <em><a href="#vantage_dumping_the_logger_memory">Dumping
|
|
the logger memory</a></em>, which may help you avoid data loss.</p>
|
|
|
|
<h3>3rd party Vantage connectors</h3>
|
|
|
|
<p>This section is for those who are using a homebrew or 3rd party connector
|
|
to a Davis Vantage console that does not contain a logger, such as the
|
|
<a href="http://www.wxforum.net/index.php?topic=14063.0">DSI-01 serial interface</a>.
|
|
That is, it is a pure serial connection to the console, with no onboard memory.
|
|
</p>
|
|
|
|
<p>For these interfaces, you must set record generation to <em>software</em>.
|
|
Without this information, <span class="code">weewx</span> is unable to detect
|
|
the absence of onboard memory. If you do not do this, you will get errors that
|
|
look like the following in your syslog:</p>
|
|
<pre class="tty">Nov 27 20:30:21 rpi weewx[5607]: reportengine: Caught unrecoverable exception in generator weewx.filegenerator.FileGenerator
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** 'NoneType' object has no attribute '__getitem__'
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** Traceback (most recent call last):
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/reportengine.py", line 132, in run
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** obj.start()
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/reportengine.py", line 259, in start
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** self.run()
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 41, in run
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** self.setup()
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 52, in setup
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** self.initAlmanac(self.gen_ts)
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 87, in initAlmanac
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** rec = self.getRecord(archivedb, celestial_ts)
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 115, in getRecord
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** record_dict_vt = weewx.units.dictFromStd(record_dict)
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/units.py", line 892, in dictFromStd
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** std_unit_system = d['usUnits']
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** TypeError: 'NoneType' object has no attribute '__getitem__'
|
|
Nov 27 20:30:21 rpi weewx[5607]: **** Generator terminated...
|
|
Nov 27 20:30:23 rpi weewx[5607]: genimages: Generated 11 images in 2.53 seconds</pre>
|
|
<p>See the section on option <span class="code">
|
|
<a href="#record_generation">record_generation</a></span>.</p>
|
|
|
|
<h3>Raspberry Pi</h3>
|
|
|
|
<p>
|
|
See the <a href="https://github.com/weewx/weewx/wiki"><span
|
|
class="code">weewx</span> wiki</a> for up-to-date information on <a
|
|
href="https://github.com/weewx/weewx/wiki/Raspberry%20Pi"><i>Running
|
|
weewx on a Raspberry Pi</i></a>.
|
|
</p>
|
|
|
|
<h3>Fine Offset USB lockups</h3>
|
|
|
|
<p>The Fine Offset series
|
|
weather stations and their derivatives are a fine value and
|
|
can be made to work reasonably reliably, but they have one
|
|
problem that is difficult to work around: their USB bus can
|
|
unexpectantly lock up, making it impossible to communicate
|
|
with the console. The symptom in the log will look something
|
|
like this:</p>
|
|
<pre class="tty">Jun 7 21:50:33 localhost weewx[2460]: fousb: get archive interval failed attempt 1 of 3: could not detach kernel driver from interface 0: No data available</pre>
|
|
<p>The exact error may vary, but the thing to look for is the
|
|
"<span class='code'>could not detach kernel driver</span>"
|
|
message. Unfortunately, we have not found a software cure for
|
|
this. Instead, you must power cycle the unit. Remove the
|
|
batteries and unplug the USB, then put it back together. No
|
|
need to restart weewx.</p>
|
|
|
|
<p>More details
|
|
about <a href="https://github.com/weewx/weewx/wiki/FineOffset%20USB%20lockup">Fine
|
|
Offset lockups</a> can be found in the Wiki.</p>
|
|
|
|
<h3 id='archive_interval'>Archive interval</h3>
|
|
|
|
<p>Most hardware with data-logging includes a parameter to specify
|
|
the archive interval used by the logger. If the hardware and driver
|
|
support it, <span class='code'>weewx</span> will use this interval
|
|
as the <span class='code'><em>archive_interval</em></span>. If not,
|
|
<span class='code'>weewx</span> will fall back to the
|
|
<span class='code'>archive_interval</span> specified in
|
|
<a href='#StdArchive'><span class='code'>[StdArchive]</span></a>.
|
|
The default fallback value is 300 seconds (5 minutes).
|
|
</p>
|
|
|
|
<p>If the hardware archive interval is large, it will take a
|
|
long time before anything shows up in the
|
|
<span class='code'>weewx</span> reports. For example, WS23xx stations
|
|
ship with an archive interval of 60 minutes, and Fine Offset stations
|
|
ship with an archive interval of 30 minutes.
|
|
If you run <span class='code'>weewx</span> with a WS23xx station in
|
|
its factory default configuration, it will take 60 minutes before the
|
|
first data point shows up, then another 60 minutes until the next one,
|
|
and so on.
|
|
</p>
|
|
|
|
<p>
|
|
Since reports are generated when a new archive record arrives,
|
|
a large archive interval means that reports will be generated
|
|
infrequently.
|
|
</p>
|
|
|
|
<p>If you want data and reports closer to real-time, use the
|
|
<a href="#configuring_hardware"><span class="code">wee_device</span></a>
|
|
utility to change the interval.
|
|
</p>
|
|
|
|
<h2>Software problems</h2>
|
|
|
|
<p>This section covers some common software configuration problems.</p>
|
|
|
|
<h3>Nothing in the log file</h3>
|
|
|
|
<p>As it is running, <span class='code'>weewx</span> periodically sends
|
|
status information, failures, and other things to your system's logging
|
|
facility. They typically look something like this:</p>
|
|
<pre class='tty'>-DATE- --TIME-- HOST weewx[-PID-]: LOG_MESSAGE
|
|
|
|
Jan 1 09:46:32 saga weewx[15292]: wxengine: Initializing weewx version 2.5.1
|
|
Jan 1 09:46:32 saga weewx[15292]: wxengine: Using Python 2.6.6 (r266:84292, Dec 27 2010, 21:57:32) #012[GCC 4.4.5 20100902 (prerelease)]
|
|
Jan 1 09:46:32 saga weewx[15292]: wxengine: pid file is /var/run/weewx.pid</pre>
|
|
|
|
<p>The location of this logging file varies from system to system,
|
|
but it is typically
|
|
in <span class="code">/var/log/syslog</span>, or something
|
|
similar.</p>
|
|
|
|
<p>However, some systems default to saving only warning or
|
|
critical information, so the <span class="code">info</span>
|
|
messages from <span class="code">weewx</span> may not appear.
|
|
If this happens to you, check your system logging configuration.
|
|
On Debian systems, look
|
|
in <span class="code">/etc/rsyslog.conf</span>. On Redhat
|
|
systems, look in <span class="code">/etc/syslog.conf</span>.</p>
|
|
|
|
<h3><span class="code">configobj</span> errors</h3>
|
|
|
|
<p>These are errors in the configuration file. Two are very common.
|
|
Incidentally, these errors are far easier to diagnose when
|
|
<span class="code">weewx</span> is run directly than when it is run
|
|
as a daemon. </p>
|
|
<h4><span class="code">configobj.DuplicateError</span> exception</h4>
|
|
|
|
<p>This error is caused by using an identifier more than once in the
|
|
configuration file. For example, you may have inadvertently listed
|
|
your FTP server twice:
|
|
</p>
|
|
|
|
<pre class='tty'>[Reports]
|
|
[[FTP]]
|
|
... (details elided)
|
|
user = fred
|
|
server = ftp.myhost.com
|
|
password = mypassword
|
|
server = ftp.myhost.com # OOPS! Listed it twice!
|
|
path = /weather
|
|
... </pre>
|
|
|
|
<p>Generally, if you encounter this error, the log file will give you the
|
|
line number it happened in: </p>
|
|
|
|
<pre class='tty'>Apr 24 12:09:15 raven weewx[11480]: wxengine: Error while parsing configuration file /home/weewx/weewx.conf
|
|
Apr 24 12:09:15 raven weewx[11480]: wxengine: Unable to initialize main loop:
|
|
Apr 24 12:09:15 raven weewx[11480]: **** Duplicate keyword name at line 254.
|
|
Apr 24 12:09:15 raven weewx[11480]: **** Exiting. </pre>
|
|
|
|
<h4><span class="code">configobj.NestingError</span> exception</h4>
|
|
|
|
<p>This is a very similar error, and is caused by a misformed section nesting.
|
|
For example: </p>
|
|
|
|
<p class='tty'>[Reports]
|
|
[[FTP]]]
|
|
... (details elided)</p>
|
|
|
|
<p>Note the extra closing bracket on the subsection <span class="code">FTP</span>.
|
|
</p>
|
|
|
|
<h3>No barometer data</h3>
|
|
|
|
<p>If everything appears normal except that you have no barometer data, the
|
|
problem may be a mismatch between the unit system used for service
|
|
<span class="code">StdConvert</span> and the unit system used by service
|
|
<span class="code">StdQC</span>. For example:</p>
|
|
<pre class="tty">[StdConvert]
|
|
target_unit = METRIC
|
|
...
|
|
|
|
[StdQC]
|
|
[[MinMax]]
|
|
barometer = 28, 32.5</pre>
|
|
<p>The problem is that you are requiring the barometer data to be between
|
|
28 and 32.5, but with the unit system set to
|
|
<span class="code">METRIC</span>, the data will be in the range 990 to
|
|
1050 or so!</p>
|
|
|
|
<p>The solution is to change the values to match the units in StdConvert,
|
|
or specify the units in MinMax, regardless of the units in StdConvert.
|
|
For example:</p>
|
|
<pre class="tty">[StdConvert]
|
|
target_unit = US
|
|
...
|
|
|
|
[StdQC]
|
|
[[MinMax]]
|
|
barometer = 950, 1100, mbar</pre>
|
|
|
|
<h3><span class="code">Cheetah.NameMapper.NotFound</span> errors</h3>
|
|
|
|
<p>If you get errors of the sort: </p>
|
|
|
|
<pre class='tty'>Apr 12 05:12:32 raven reportengine[3074]: filegenerator: Caught exception "<class 'NameMapper.NotFound'>"
|
|
Apr 12 05:12:32 raven reportengine[3074]: **** Message: "cannot find 'fubar' in template /home/weewx/skins/Standard/index.html.tmpl"
|
|
Apr 12 05:12:32 raven reportengine[3074]: **** Ignoring template and continuing.</pre>
|
|
|
|
<p>you have a tag in your template that <span class="code">weewx</span>
|
|
does not recognize. In this example, it is the tag
|
|
<span class="code">$fubar</span> in the template
|
|
<span class="code">/home/weewx/skins/Standard/index.html.tmpl</span>.
|
|
</p>
|
|
|
|
<h3 id="many_loop_read_errors">Many LOOP read errors with Davis Vantage</h3>
|
|
|
|
<p>The symptom is many LOOP errors and unreliable downloading of archive records.
|
|
Your log may look like this:</p>
|
|
<pre class="tty">
|
|
Jan 18 20:38:52 rpi weewx[6024]: VantagePro: Opened up serial port /dev/ttyUSB0, baudrate 19200
|
|
Jan 18 20:38:53 rpi weewx[5977]: VantagePro: LOOP #12; read error. Try #1
|
|
Jan 18 20:38:53 rpi weewx[5977]: **** Expected to read 99 chars; got 0 instead
|
|
Jan 18 20:38:58 rpi weewx[7543]: VantagePro: LOOP #13; read error. Try #1
|
|
Jan 18 20:38:58 rpi weewx[7543]: **** Expected to read 99 chars; got 4 instead
|
|
Jan 18 20:39:03 rpi weewx[7543]: VantagePro: LOOP #14; read error. Try #2
|
|
Jan 18 20:39:03 rpi weewx[7543]: **** Expected to read 99 chars; got 0 instead
|
|
Jan 18 20:39:03 rpi weewx[5977]: VantagePro: LOOP #13; read error. Try #2
|
|
Jan 18 20:39:03 rpi weewx[5977]: **** Expected to read 99 chars; got 4 instead
|
|
Jan 18 20:39:08 rpi weewx[7543]: VantagePro: LOOP #15; read error. Try #3
|
|
Jan 18 20:39:08 rpi weewx[7543]: **** Expected to read 99 chars; got 4 instead
|
|
Jan 18 20:39:09 rpi weewx[5977]: VantagePro: LOOP #14; read error. Try #3
|
|
Jan 18 20:39:09 rpi weewx[5977]: **** Expected to read 99 chars; got 2 instead
|
|
Jan 18 20:39:14 rpi weewx[5977]: VantagePro: LOOP #15; read error. Try #4
|
|
Jan 18 20:39:14 rpi weewx[5977]: **** Expected to read 99 chars; got 2 instead</pre>
|
|
<p>If you look closely at the log above, you'll see that there are
|
|
multiple instances of <span class="code">weewx</span> running
|
|
simultaneously (process IDs 5977, 6024, and 7543). They are
|
|
contending with each other for control of the console, resulting
|
|
in missed packets and records.
|
|
</p>
|
|
|
|
<p>The cure is simple: kill all but one of them. Or, better yet,
|
|
kill them all, then do a restart.</p>
|
|
|
|
<h3 id='dots_in_plots'>Dots in the plots</h3>
|
|
|
|
<p>If you see dots instead of lines in the daily plots, you might want to
|
|
change the graphing options or adjust the station's archive interval.</p>
|
|
|
|
<p>In a default configuration, a time period greater than 1% of the
|
|
displayed timespan is considered to be a gap in data. So when the
|
|
interval between data points is greater than about 10 minutes, the
|
|
daily plots show dots instead of connected points. </p>
|
|
|
|
<p>Change the <a href="customizing.htm#line_gap_fraction"><span class='code'>line_gap_fraction</span></a>
|
|
option in <span class="code">skin.conf</span>
|
|
to control how much time is considered a break in data.</p>
|
|
|
|
<p>As for the archive interval, check the log file for an entry like this
|
|
soon after <span class='code'>weewx</span> starts up:</p>
|
|
|
|
<pre class='tty'>Dec 30 10:54:17 saga weewx[10035]: wxengine: The archive interval in the configuration file (300) does not match the station hardware interval (1800).
|
|
Dec 30 10:54:17 saga weewx[10035]: wxengine: Using archive interval of 1800</pre>
|
|
|
|
<p>In this example, interval in <span class="code">weewx.conf</span> is 5
|
|
minutes, but the station interval is 30 minutes. When the interval
|
|
in <span class="code">weewx.conf</span> does not match the station's
|
|
hardware interval, <span class="code">weewx</span> defers to the
|
|
station's interval.</p>
|
|
|
|
<p>Use the <a href="#configuring_hardware"><span class="code">wee_device</span></a> utility to change the station's
|
|
interval.</p>
|
|
|
|
<h3 id='spikes'>Spikes in the graphs</h3>
|
|
|
|
<p>Occasionally you may see anomalous readings, typically manifested as
|
|
spikes in the graphs. The source could be a flaky serial/USB connection,
|
|
radio or other interference, a cheap USB-Serial adapter, low-quality
|
|
sensors, or simply an anomalous reading.</p>
|
|
|
|
<p>Sensor quality matters. It is not unusual for some low-end hardware
|
|
to report odd sensor readings occasionally (once every few days). Some
|
|
sensors, such as solar radiation/UV, have a limited lifespan of about
|
|
5 years. The (analog) humidity sensors on older Vantage stations are
|
|
known to deteriorate after a few years in wet environments.</p>
|
|
|
|
<p>If you frequently see anomalous data, first check the hardware.</p>
|
|
|
|
<p>To keep bad data from the database, add a quality control (QC) rule
|
|
such as Min/Max bounds. See the <a href="#StdQC">QC</a> section for
|
|
details.</p>
|
|
|
|
<p>To remove bad data from the database, you will have to do some basic
|
|
SQL commands. For example, let's say the station emitted some very
|
|
high temperatures and wind speeds for one or two readings. This is
|
|
how to remove them:</p>
|
|
<ol>
|
|
<li>stop <span class='code'>weewx</span></li>
|
|
<li>Make a copy of the archive database
|
|
<pre class='tty cmd'>cp weewx.sdb weewx-YYMMDD.sdb</pre>
|
|
</li>
|
|
<li>Verify the bad data exist where you think they exist
|
|
<pre class='tty'><span class="cmd">sqlite3 weewx.sdb</span>
|
|
sqlite> <span class="cmd">select dateTime,outTemp from archive where outTemp > 1000;</span></pre>
|
|
</li>
|
|
<li>See whether the bad temperature and wind data happened at the same time
|
|
<pre class='tty'>sqlite> <span class="cmd">select dateTime,outTemp,windSpeed from archive where outTemp > 1000;</span></pre>
|
|
</li>
|
|
<li>Remove the bad data by setting to NULL
|
|
<pre class='tty'>sqlite> <span class="cmd">update archive set windSpeed=NULL where outTemp > 1000;</span>
|
|
sqlite> <span class="cmd">update archive set outTemp=NULL where outTemp > 1000;</span></pre>
|
|
</li>
|
|
<li>Delete the statistics database so that <span class='code'>weewx</span> can regenerate it without the
|
|
anomalies
|
|
</li>
|
|
<li>start <span class='code'>weewx</span></li>
|
|
</ol>
|
|
|
|
<h3>'Database is locked' error</h3>
|
|
|
|
<p>This seems to be a problem with the Raspberry Pi, <strong>when using SQLite</strong>.
|
|
There is no analogous problem with MySQL databases. You will see errors in the system log that
|
|
looks like this:</p>
|
|
<pre class='tty'>
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** File "/usr/share/weewx/weewx/archive.py", line 118, in lastGoodStamp
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** _row = self.getSql("SELECT MAX(dateTime) FROM %s" % self.table)
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** File "/usr/share/weewx/weewx/archive.py", line 250, in getSql
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** File "/usr/share/weewx/weedb/sqlite.py", line 120, in execute
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** raise weedb.OperationalError(e)
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** OperationalError: database is locked
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** _cursor.execute(sql, sqlargs)
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** File "/usr/share/weewx/weedb/sqlite.py", line 120, in execute
|
|
Feb 12 07:11:06 rpi weewx[20930]: **** raise weedb.OperationalError(e)
|
|
<span class='highlight'>Feb 12 07:11:06 rpi weewx[20930]: **** OperationalError: database is locked</span></pre>
|
|
<p>We are still trying to decipher exactly what the problem is, but it seems that
|
|
(many? most? all?) implementations of the SQLite 'C' access libraries on the RPi
|
|
sleep for a full second if they find the database locked. This gives them only
|
|
five chances within the 5 second timeout period before an exception is raised.</p>
|
|
|
|
<p>Not all Raspberry Pis have this problem. It seems to be most acute when running big
|
|
templates with lots of queries, such as the forecast extension.</p>
|
|
|
|
<p>There are a few possible fixes:</p>
|
|
<ul>
|
|
<li>Increase the <a href='#archive_timeout'><span class='code'>timeout</span> option</a>.</li>
|
|
<li>Use a high quality SD card in your RPi. There seems to be some evidence that faster
|
|
SD cards are more immune to this problem.
|
|
</li>
|
|
<li>Trim the size of your templates to minimize the number of queries necessary.</li>
|
|
</ul>
|
|
<p>None of these 'fixes' are very satisfying and we're trying to come up with a more robust solution.</p>
|
|
|
|
<h3>Strings in the database</h3>
|
|
|
|
<p>If you modify the SQLite archive database using an editing tool,
|
|
occasionally strings will get embedded in it, causing
|
|
<span class='code'>weewx</span> to raise
|
|
an exception. <strong>This is only a problem with SQLite</strong>.
|
|
There is no analogous problem with MySQL databases. You will see errors in the system log that
|
|
look something like this:</p>
|
|
<pre class='tty'>
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/wxengine.py", line 432, in __init__
|
|
Dec 31 17:01:06 arm weewx[18141]: **** self.setupStatsDatabase(config_dict)
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/wxengine.py", line 543, in setupStatsDatabase
|
|
Dec 31 17:01:06 arm weewx[18141]: **** self.statsDb.backfillFrom(self.archive)
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/stats.py", line 461, in backfillFrom
|
|
Dec 31 17:01:06 arm weewx[18141]: **** _statsDict.addRecord(_rec)
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 305, in addRecord
|
|
Dec 31 17:01:06 arm weewx[18141]: **** self._add_value(record[obs_type], obs_type, record['dateTime'], add_hilo)
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 264, in _add_value
|
|
Dec 31 17:01:06 arm weewx[18141]: **** self[obs_type].addSum(val)
|
|
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 81, in addSum
|
|
Dec 31 17:01:06 arm weewx[18141]: **** self.sum += val
|
|
<span class='highlight'>Dec 31 17:01:06 arm weewx[18141]: **** TypeError: unsupported operand type(s) for +=: 'float' and 'unicode'</span>
|
|
Dec 31 17:01:06 arm weewx[18141]: **** Exiting.</pre>
|
|
<p>The problem is that a unicode null string <span class='code'>u''</span>
|
|
got entered where a <span class='code'>NULL</span> should be. The
|
|
utility <span class='code'>wee_database</span> can fix this.
|
|
Run it with the option <span class='code'>--string-check</span> to
|
|
search for these embedded strings. Add the option
|
|
<span class='code'>--fix</span> to have the utility fix them:</p>
|
|
<pre class="tty cmd">wee_database weewx.conf --string-check --fix</pre>
|
|
|
|
<h3 id="python2_5">Python 2.5</h3>
|
|
|
|
<p>Weewx should work with Python version 2.5, but it will take some fiddling.</p>
|
|
<p>The version of pysqlite that comes with Python 2.5 does not support the "with"
|
|
statement, which is required by weewx. Unfortunately, the most modern version
|
|
of pysqlite no longer supports Python 2.5, so you will have to install an
|
|
"intermediate" version. I found that <a href="https://pypi.python.org/pypi/pysqlite/2.5.6">version 2.5.6</a>,
|
|
which can be downloaded from PyPI, works well. Download it, unpack the tarball, then use the included
|
|
<span class="code">setup.py</span> file to install</p>
|
|
<p>You will probably have to install PIL, which can be done using <span class="code">apt-get</span>,
|
|
or <span class="code">easy_install</span></p>
|
|
|
|
<p>Various possible complications:</p>
|
|
<ul>
|
|
<li>You may have to install the development environment of SQLite in
|
|
order to get <span class='code'>pysqlite</span> to install. This worked on my system:
|
|
<pre class="tty cmd">
|
|
apt-get install libsqlite3-dev</pre>
|
|
Then rerun the installation of <span class='code'>pysqlite</span>.
|
|
</li>
|
|
<li>When you run <span class='code'>weewx</span>, you may get an error that looks like this
|
|
<pre class="tty">
|
|
File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 218, in truetype
|
|
return FreeTypeFont(filename, size, index, encoding)
|
|
File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 134, in __init__
|
|
self.font = core.getfont(file, size, index, encoding)
|
|
File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 34, in __getattr__
|
|
raise ImportError("The _imagingft C module is not installed")
|
|
ImportError: The _imagingft C module is not installed</pre>
|
|
This is because your installed version of PIL was compiled without
|
|
libfreetype, which is needed for the FreeType fonts used in the
|
|
generated images. You can either change the font type (look in
|
|
file <span class='code'>skin.conf</span>), or supply the missing library. Note: if you are missing
|
|
the freetype library, you may be missing others as well. This is what worked on my system. YMMV.
|
|
<pre class="tty">
|
|
# Install the Freetype library:
|
|
<span class="cmd">sudo apt-get install libfreetype6-dev</span>
|
|
# Make sure it, and the zlib library, are visible to easy_install
|
|
<span class="cmd">sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib</span>
|
|
<span class="cmd">sudo ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib</span>
|
|
# Remove the PIL paths
|
|
<span class="cmd">sudo easy_install -m PIL</span>
|
|
# Remove PIL itself:
|
|
<span class="cmd">sudo rm -r /usr/lib/python2.5/site-packages/PIL*</span>
|
|
# Now rebuild PIL, this time with the right libraries
|
|
<span class="cmd">sudo easy_install PIL</span>
|
|
</pre>
|
|
You may have to fiddle with the exact path used in the symbolic link. A helpful tool
|
|
is the Unix tool <span class='code'>find</span>. For example, the following
|
|
uncovered where my freetype library was hiding:
|
|
<pre class="tty cmd">
|
|
find /usr/lib -name "libfreetype*" -print</pre>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>FreeBSD</h3>
|
|
|
|
<p>User Fabian reports that the following had to be done to get the
|
|
VantagePro2 working under FreeBSD:</p>
|
|
<pre class="tty">I needed the uslcom Driver for the usb/rs232 Adapter used by my vantage. Also I had to reset the memory of the weatherstation.
|
|
Loading the Driver:
|
|
Put uslcom_load="YES" in /boot/loader.conf (to load it as module).
|
|
Which gives here an output like:
|
|
uslcom0: <CP2102 USB to UART Bridge Controller> on usbus1
|
|
And put in <span class="code">weewx.conf</span>:
|
|
port = /dev/cuaU0</pre>
|
|
|
|
<h3>Apple OSX 10.9 (Mavericks)</h3>
|
|
|
|
<p>User Mike has written a
|
|
<a href='http://www.cougar.eu.com/useful-guides/weewx-installation-on-osx.html'>
|
|
very nice guide</a> on how to install <span class='code'>
|
|
weewx</span> on Apple's Mavericks operating sytem.</p>
|
|
|
|
<h3 id="funky_symbols">Funky symbols in plots</h3>
|
|
|
|
<p>If your plots have strange looking symbols for units, such as
|
|
degrees Fahrenheit (°F), that look something like this:</p>
|
|
<img src='images/funky_degree.png'/>
|
|
|
|
<p>Then the problem may be that you are missing the fonts
|
|
specified for the option
|
|
<span class="code">unit_label_font_path</span> in your
|
|
<span class="code">skin.conf</span> file and, instead,
|
|
<span class="code">weewx</span> is substituting a default font, which does not
|
|
support the UTF-8 character necessary to make a degree sign. Look in
|
|
section <span class="code">[ImageGenerator]</span> for a line
|
|
that looks like:</p>
|
|
<pre class="tty">unit_label_font_path = /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf</pre>
|
|
<p>Make sure that the specified path
|
|
(<span class='code'>/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf</span>
|
|
in this case) actually exists. If it does not, on Debian
|
|
operating systems (such as Ubuntu), you may be able to install
|
|
the necessary fonts:</p>
|
|
<pre class="tty cmd">sudo apt-get install fonts-freefont-ttf
|
|
sudo fc-cache -f -v</pre>
|
|
<p>(On older systems, the package <span class="code">fonts-freefont-ttf</span>
|
|
may be called <span class="code">ttf-freefont</span>).
|
|
The first command installs the "Truetype" fonts, the second rebuilds
|
|
the font cache. If your system does not have <span class="code">fc-cache</span>
|
|
command, then install it from the <span class="code">fontconfig</span> package:</p>
|
|
<pre class="tty cmd">sudo apt-get install fontconfig</pre>
|
|
<p>If none of this works, or if you are on a different operating
|
|
system, then you will have to change the option <span class="code">unit_label_font_path</span>
|
|
to point to something on your system which does support UTF-8 characters.</p>
|
|
|
|
<h3>UnicodeEncodeError</h3>
|
|
|
|
<p>This problem is closely related to the <a href="#funky_symbols">"Funky symbols"</a>
|
|
problem above. In this case, you may see errors in your log that look like:</p>
|
|
<pre class="tty">May 14 13:35:23 web weewx[5633]: cheetahgenerator: Generated 14 files for report StandardReport in 1.27 seconds
|
|
May 14 13:35:23 web weewx[5633]: reportengine: Caught unrecoverable exception in generator weewx.imagegenerator.ImageGenerator
|
|
May 14 13:35:23 web weewx[5633]: **** 'ascii' codec can't encode character u'\xe8' in position 5: ordinal not in range(128)
|
|
May 14 13:35:23 web weewx[5633]: **** Traceback (most recent call last):
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weewx/reportengine.py", line 139, in run
|
|
May 14 13:35:23 web weewx[5633]: **** obj.start()
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weewx/reportengine.py", line 170, in start
|
|
May 14 13:35:23 web weewx[5633]: **** self.run()
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weewx/imagegenerator.py", line 36, in run
|
|
May 14 13:35:23 web weewx[5633]: **** self.genImages(self.gen_ts)
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weewx/imagegenerator.py", line 220, in genImages
|
|
May 14 13:35:23 web weewx[5633]: **** image = plot.render()
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weeplot/genplot.py", line 175, in render
|
|
May 14 13:35:23 web weewx[5633]: **** self._renderTopBand(draw)
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/share/weewx/weeplot/genplot.py", line 390, in _renderTopBand
|
|
May 14 13:35:23 web weewx[5633]: **** top_label_size = draw.textsize(top_label, font=top_label_font)
|
|
May 14 13:35:23 web weewx[5633]: **** File "/usr/lib/python2.7/dist-packages/PIL/ImageDraw.py", line 278, in textsize
|
|
May 14 13:35:23 web weewx[5633]: **** return font.getsize(text)
|
|
May 14 13:35:23 web weewx[5633]: <span class="highlight">**** UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 5: ordinal not in range(128)</span>
|
|
May 14 13:35:23 web weewx[5633]: **** Generator terminated...</pre>
|
|
|
|
<p>This is frequently caused by the necessary Truetype fonts not being installed on
|
|
your computer and, instead, a default font is being substituted, which only knows
|
|
how to plot ASCII characters. The cure is as before: install the font.</p>
|
|
|
|
<h2>Meteorological problems</h2>
|
|
|
|
<h3 id='pressure_mismatch'>The pressure reported by <span class='code'>weewx</span> does not match the pressure on the console</h3>
|
|
|
|
<p>
|
|
Be sure that you are comparing the right values. There are three different types of pressure:
|
|
</p>
|
|
<dl>
|
|
<dt>Station Pressure</dt>
|
|
<dd>
|
|
The <em>Station Pressure</em> (SP), which is the raw, absolute
|
|
pressure measured by the station.
|
|
This is <span class='code'>pressure</span> in
|
|
<span class='code'>weewx</span> packets and archive records.</dd>
|
|
<dt>Sea Level Pressure</dt>
|
|
<dd>
|
|
The <em>Sea Level Pressure</em> (SLP) is obtained by correcting
|
|
the <em>Station Pressure</em> for altitude and local temperature.
|
|
This is <span class='code'>barometer</span> in
|
|
<span class='code'>weewx</span> packets and archive records.
|
|
</dd>
|
|
<dt>Altimeter</dt>
|
|
<dd>
|
|
The <em>Altimeter Setting</em> (AS) is obtained by correcting the
|
|
<em>Station Pressure</em> for altitude.
|
|
This is <span class='code'>altimeter</span> in
|
|
<span class='code'>weewx</span> packets and archive records.
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>
|
|
Any station might require calibration. For some hardware, this can
|
|
be done at the weather station console. Alternatively, use the
|
|
<span class='code'>StdCalibrate</span> section to apply an offset.
|
|
</p>
|
|
|
|
<p>
|
|
If your station is significantly above (or below) sea level, be sure
|
|
that the station altitude is specified properly. Also, be sure that
|
|
any calibration results in a station pressure and/or barometric
|
|
pressure that matches those reported by other stations in your area.
|
|
</p>
|
|
|
|
<h3 id='rain_mismatch'>The rainfall and/or rain rate reported by <span class='code'>weewx</span> do not match the console</h3>
|
|
|
|
<p>
|
|
First of all, be sure that you are comparing the right quantities. The value <span class='code'>rain</span> is the amount of rainfall observed in a period of time. The period of time might be a LOOP interval, in which case the <span class='code'>rain</span> is the amount of rain since the last LOOP packet. Or the period of time might be an archive interval, in which case the <span class='code'>rain</span> is the total of rain reported in each LOOP packet since the last archive record.
|
|
</p>
|
|
|
|
<p>
|
|
Some consoles report the amount of rain in the past hour, or the amount of rain since midnight.
|
|
</p>
|
|
|
|
<p>
|
|
The rain rate is a derived quantity. Some stations report a rain rate, but for those that do not, <span class='code'>weewx</span> will calculate the rain rate.
|
|
</p>
|
|
|
|
<p>
|
|
Be sure that the units are correct.
|
|
</p>
|
|
|
|
<p>
|
|
Finally, beware of calibration factors specific to the hardware. For example, the bucket type on a Vantage station must be specified when you set up the weather station. If you modify the rain bucket with a larger collection area, then you will have to add a multiplier in the <span class='code'>StdCalibrate</span> section.
|
|
</p>
|
|
|
|
<p>
|
|
To diagnose rain issues, run <span class='code'>weewx</span> directly so that you can see each LOOP packet and REC archive record. Tip the bucket to verify that each bucket tip is detected and reported by <span class='code'>weewx</span>. Verify that each bucket tip is converted to the correct rainfall amount. Then check the database to verify that the values are properly added and recorded.
|
|
</p>
|
|
|
|
<h3 id='pressure_calibration'>Calibrating <span class='code'>barometer</span> does not change the pressure displayed by <span class='code'>weewx</span></h3>
|
|
|
|
<p>
|
|
Be sure that the calibration is applied to the correct quantity.
|
|
</p>
|
|
|
|
<p>
|
|
The corrections in the <span class='code'>StdCalibrate</span> section
|
|
apply only to raw values from the hardware; corrections are not applied
|
|
to derived quantities.
|
|
</p>
|
|
|
|
<p>
|
|
The station hardware matters. Some stations report gauge pressure
|
|
(<span class='code'>pressure</span>) while other stations report
|
|
sea-level pressure (<span class='code'>barometer</span>). For example,
|
|
if the hardware is a Vantage station, the correction must be applied
|
|
to <span class='code'>barometer</span> since the Vantage station
|
|
reports <span class='code'>barometer</span> and
|
|
<span class='code'>weewx</span> calculates
|
|
<span class='code'>pressure</span>. However, if the hardware
|
|
is a FineOffset station, the correction must be applied to
|
|
<span class='code'>pressure</span> since the FineOffset stations
|
|
report <span class='code'>pressure</span> and
|
|
<span class='code'>weewx</span> calculates
|
|
<span class='code'>barometer</span>.
|
|
</p>
|
|
|
|
<h3 id="zero_windspeed">There is no wind direction when wind speed is zero</h3>
|
|
|
|
<p>
|
|
This is by design - if there is no wind, then the wind direction is undefined. An undefined value is represented by a NULL in the database or a None in Python. This policy is enforced by the <span class='code'>StdWXCalculate</span> service. If necessary, it can be overridden. See the <a href="#StdWXCalculate"><span class='code'>StdWXCalculate</span></a> section for instructions.
|
|
</p>
|
|
<p>
|
|
<span class='code'>weewx</span> distinguishes between a value of zero and no value (NULL or None). However, some services do not make this distinction and replace a NULL or None with a clearly invalid value such as -999.
|
|
</p>
|
|
|
|
|
|
<h1 id="architecture">Architectural Notes</h1>
|
|
|
|
<p>This section is not required to get started, but it should help you
|
|
understand a bit more about how <span class="code">weewx</span> works. </p>
|
|
|
|
<h2>Goals</h2>
|
|
|
|
<p>The primary design goals of <span class="code">weewx </span>are: </p>
|
|
<ul>
|
|
<li>Architectural simplicity. No semaphores, no named pipes, no inter-process
|
|
communications, no complex multi-threading to manage.
|
|
</li>
|
|
<li>Extensibility. Make it easy for the user to add new features or to modify
|
|
existing features.
|
|
</li>
|
|
<li>"Fast enough." In any design decision, architectural simplicity
|
|
and elegance trump speed.
|
|
</li>
|
|
<li>One code base. The same code base should be used for all platforms,
|
|
all weather stations, all reports, and any combination of features. Ample
|
|
configuration and customization options should be provided so the user does not
|
|
feel tempted to start hacking code. At worse, the user may have to subclass,
|
|
which is much easier to port to newer versions of the code base, than customizing
|
|
the base code.
|
|
</li>
|
|
<li>Minimal reliance on external packages, so the user does not have
|
|
to go chase them down all over the Web before getting started.
|
|
</li>
|
|
<li>Support only the Davis VantagePro2 initially (that is what I have),
|
|
but make no architectural decisions that lock out other stations.
|
|
</li>
|
|
<li>As "pythonic" as I know how to make it. I am a beginner
|
|
Python programmer with two decades of experience in C++. I tried hard to
|
|
not make the code base look like it was written by a C++ programmer who
|
|
stumbled across a Python manual!
|
|
</li>
|
|
</ul>
|
|
<h2>Strategies</h2>
|
|
|
|
<p>To meet these goals, the following strategies were used: </p>
|
|
<ul>
|
|
<li>A "micro-kernel" design. The <span class="code">weewx</span>
|
|
engine actually does very little. Its primary job is to load and run <em>
|
|
services</em> at runtime, making it easy for users to add or subtract features.
|
|
</li>
|
|
<li>A largely stateless design style. For example, many of the processing
|
|
routines read the data they need directly from the database, rather than
|
|
caching it and sharing with other routines. While this means the same data
|
|
may be read multiple times, it also means the only point of possible cache
|
|
incoherence is through the database, where transactions are easily controlled.
|
|
This greatly reduces the chances of corrupting the data, making it much
|
|
easier to understand and modify the code base.
|
|
</li>
|
|
<li>Isolate the data collection and archiving code in a single thread that
|
|
is simple enough that it is unlikely to crash. The report processing is
|
|
where most mistakes are likely to happen, so isolate that in a separate
|
|
thread. If it crashes, it will not affect the main data thread.
|
|
</li>
|
|
<li>A powerful configuration parser,
|
|
<a href="http://www.voidspace.org.uk/python/configobj.html">ConfigObj</a>,
|
|
by Michael Foord and Nicola Larosa, was chosen to read the configuration
|
|
file. This allows many options that might otherwise have to go in the code
|
|
to go instead in a configuration file.
|
|
</li>
|
|
<li>A powerful templating engine,
|
|
<a href="http://www.cheetahtemplate.org/">Cheetah</a>, was used. This allows
|
|
many variables that I may not have thought of to be accessed from within
|
|
the HTML templates, without starting to modify the code.
|
|
</li>
|
|
<li>Pure Python. The code base is 100% Python — no underlying C libraries
|
|
need be built to install <span class="code">weewx</span>. This also means
|
|
no Makefiles are needed.
|
|
</li>
|
|
</ul>
|
|
<p>While <span class="code">weewx</span> is nowhere near as fast at generating
|
|
images and HTML as its predecessor, <span class="code">wview</span> (this is
|
|
partially because <span class="code">weewx</span> uses fancier fonts and a much more powerful templating
|
|
engine), it is fast enough for all platforms but the slowest. I run
|
|
it regularly on a 500 MHz machine where generating the 9 images used in the "Current
|
|
Conditions" page takes just under 2 seconds (compared with
|
|
0.4 seconds for <span class="code">wview</span>). </p>
|
|
|
|
<p>Unfortunately, the architectural goal of one code base is likely to be broken
|
|
with the arrival of Python V3.X. It has so many changes that are not backwards
|
|
compatible with V2.X, that a separate code base will most likely be needed.
|
|
My intention is to stick with the V2.X versions until V3.X is so widespread
|
|
it cannot be ignored, then make a permanent switch. Given the slow adoption
|
|
rate of V3.X this is unlikely to happen anytime soon. In any case, I doubt the
|
|
transition will affect the average <span class="code">weewx</span> user. </p>
|
|
|
|
<p>All writes to the databases are protected by transactions. You can kill the
|
|
program at any time (either Control-C if run directly or "<span class="code">/etc/init.d/weewx
|
|
stop</span>" if run as a daemon) without fear of corrupting the databases. </p>
|
|
|
|
<p>The code makes ample use of exceptions to insure graceful recovery from problems
|
|
such as network outages. It also monitors socket and console timeouts, restarting
|
|
whatever it was working on several times before giving up. In the case of an
|
|
unrecoverable console error (such as the console not responding at all), the
|
|
program waits 60 seconds then restarts the program from the top.</p>
|
|
|
|
<p>Any "hard" exceptions, that is those that do not involve network
|
|
and console timeouts and are most likely due to a logic error, are logged, reraised,
|
|
and ultimately cause thread termination. If this happens in the main thread
|
|
(not likely due to its simplicity), then this causes program termination. If
|
|
it happens in the report processing thread (much more likely), then only the
|
|
generation of reports will be affected — the main thread will continue downloading
|
|
data off the instrument and putting them in the database. You can fix the problem
|
|
at your leisure, without worrying about losing any data. </p>
|
|
|
|
<h2>Terminology</h2>
|
|
|
|
<p>This is a glossary of terminology used throughout the code. </p>
|
|
<table style="width: 95%" class='indent'>
|
|
<caption>Terminology used in weewx</caption>
|
|
<tr class="first_row">
|
|
<td>Name</td>
|
|
<td>Description</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">archive record</td>
|
|
<td>A record obtained from the SQL database</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">archive packet</td>
|
|
<td>A packet obtained from the store on the weather station. For
|
|
example, with a Davis VantagePro, it is obtained using the
|
|
<span class="code">DMPAFT</span> command.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">datetime</td>
|
|
<td>An instance of the Python object
|
|
<span class="code">datetime.datetime</span>. Variables of type
|
|
datetime usually have a suffix <span class="code">_dt</span>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">db_dict</td>
|
|
<td>A dictionary with all the data necessary to bind to a database.
|
|
An example for SQLite would be <span class="code">
|
|
{'driver':'db.sqlite',
|
|
'root':'/home/weewx',
|
|
'database_name':'archive/weewx.sdb'}</span>,
|
|
an example for MySQL would be <span class="code">{
|
|
'driver':'db.mysql',
|
|
'host':'localhost',
|
|
'user':'weewx',
|
|
'password':'mypassword',
|
|
'database_name':'weewx'}</span>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">epoch time</td>
|
|
<td>Sometimes referred to as "unix time," or "unix
|
|
epoch time." The number of seconds since the epoch, which is
|
|
1 Jan 1970 00:00:00 UTC. Hence, it always represents UTC (well...
|
|
after adding a few leap seconds. But, close enough). This is the
|
|
time used in the databases and appears as type <span class="code">
|
|
dateTime</span> in the SQL schema, perhaps an unfortunate name
|
|
because of the similarity to the completely unrelated Python type
|
|
<span class="code">datetime</span>. Very easy to manipulate, but
|
|
it is a big opaque number.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">loop packet</td>
|
|
<td>A packet with the current observations. For example, with a Davis
|
|
VantagePro, it is obtained using the <span class="code">LOOP</span>
|
|
command.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">observation type</td>
|
|
<td>A type that can be used in the presentations. This is generally
|
|
all of the SQL types, plus calculated data (such as
|
|
<span class="code">rms</span> or <span class="code">vecavg</span>).
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">packet</td>
|
|
<td>Something obtained from the weather station. Frequently uses a
|
|
complex internal encoding, so it requires some processing to be
|
|
useful.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">record</td>
|
|
<td>Something obtained from the SQL database.</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">SQL type</td>
|
|
<td>A type that appears in the SQL database. This usually looks
|
|
something like <span class="code">outTemp</span>,
|
|
<span class="code">barometer</span>,
|
|
<span class="code">extraTemp1</span>,
|
|
and so on.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">time stamp</td>
|
|
<td>A variable in unix epoch time. Always in UTC. Variables carrying
|
|
a time stamp usually have a suffix
|
|
<span class="code">_ts</span>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">tuple-time</td>
|
|
<td>An instance of the Python object <span class="code">
|
|
<a href="http://docs.python.org/2/library/time.html#time.struct_time">
|
|
time.struct_time</a></span>. This is a 9-wise tuple that
|
|
represent a time. It could be in either local time or UTC, though
|
|
usually the former. See module <span class="code">
|
|
<a href="http://docs.python.org/2/library/time.html">time</a>
|
|
</span> for more information. They are useful because they are a
|
|
little closer in format to what the Davis VantagePro uses, although
|
|
they still require a bit of processing. Variables carrying tuple
|
|
time usually have a suffix <span class="code">_tt</span>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">unit system</td>
|
|
<td>A complete set of units used together. Either <span class="code">US</span>,
|
|
<span class="code">METRIC</span>, or <span class="code">METRICWX</span>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="text_highlight">value tuple</td>
|
|
<td>A 3-way tuple. First element is a value, second element
|
|
the unit type the value is in, the third the unit group. An
|
|
example would be <span class="code">(21.2,
|
|
'degree_C', 'group_temperature')</span>.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Units</h2>
|
|
|
|
<p>In general, there are three different areas where the unit system makes a
|
|
difference.: </p>
|
|
<ol>
|
|
<li>On the weather station. As far as I know, the Davis Vantage series
|
|
supports only U.S. Customary units internally. The Oregon Scientific
|
|
stations use an odd mix of US and metric. The Fine Offset
|
|
stations are metric. The LaCrosse stations are metric. The
|
|
Hideki stations are a mix of US and metric. One-wire devices
|
|
can be either US or metric. RainWise data loggers can be configured
|
|
to use either US or metric. PeetBros devices use a mix of US and
|
|
metric.
|
|
</li>
|
|
<li>In the database. Either US or Metric can be used.</li>
|
|
<li>In the presentation (i.e., html and image files).</li>
|
|
</ol>
|
|
<p>The general strategy is that measurements are converted by service
|
|
<span class="code">StdConvert</span> as they come off the weather station into
|
|
a target unit system, then stored internally in the database. Then, as they
|
|
come off the database to be used for a report, they are converted into a target
|
|
unit, specified by the skin. </p>
|
|
|
|
<h2>Value "<span class="code">None</span>"</h2>
|
|
|
|
<p>The Python special value <span class="code">None</span> is used
|
|
throughout to signal a missing data point. All functions expect it. </p>
|
|
|
|
<p>However, the time value must never be <span class="code">None</span>.
|
|
This is because it is used as the primary key in the SQL database. </p>
|
|
|
|
<h2>Time</h2>
|
|
|
|
<p><span class="code">Weewx </span>stores all data in UTC (roughly, "Greenwich"
|
|
or "Zulu") time. However, usually one is interested in weather events
|
|
in local time and want image and HTML generation to reflect that. Furthermore,
|
|
most weather stations are configured in local time. This requires that many
|
|
data times be converted back and forth between UTC and local time. To avoid
|
|
tripping up over time zones and daylight savings time, <span class="code">weewx</span>
|
|
generally uses Python routines to do this conversion. Nowhere in the code base
|
|
is there any explicit recognition of DST. Instead, its presence is implicit
|
|
in the conversions. At times, this can cause the code to be relatively inefficient.
|
|
</p>
|
|
|
|
<p>For example, if one wanted to plot something every 3 hours in UTC time, it
|
|
would be very simple: to get the next plot point, just add 10,800 to the epoch
|
|
time: </p>
|
|
<pre class="tty">next_ts = last_ts + 10800 </pre>
|
|
<p>But, if one wanted to plot something for every 3 hours <em>in local time</em>
|
|
(that is, at 0000, 0300, 0600, etc.), despite a possible DST change in the middle,
|
|
then things get a bit more complicated. One could modify the above to recognize
|
|
whether a DST transition occurs sometime between <span class="code">last_ts</span>
|
|
and the next three hours and, if so, make the necessary adjustments. This is
|
|
generally what <span class="code">wview</span> does. <span class="code">Weewx
|
|
</span>takes a different approach and converts from UTC to local, does the arithmetic,
|
|
then converts back. This is inefficient, but bulletproof against changes in
|
|
DST algorithms, etc: </p>
|
|
<pre class="tty">time_dt = datetime.datetime.fromtimestamp(last_ts)
|
|
delta = datetime.timedelta(seconds=10800)
|
|
next_dt = time_dt + delta
|
|
next_ts = int(time.mktime(next_dt.timetuple()))</pre>
|
|
<p>Other time conversion problems are handled in a similar manner. </p>
|
|
|
|
</div>
|
|
|
|
<div class="footer">
|
|
<p class="copyright"> © <a href="copyright.htm">Copyright</a> Tom Keffer </p>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<!-- Our scripts load last so the content can load first -->
|
|
<script type="text/javascript" src="js/jquery-1.11.1.min.js"></script>
|
|
<script type="text/javascript" src="js/jquery-ui-1.10.4.custom.min.js"></script>
|
|
<script type="text/javascript" src="js/jquery.tocify-1.9.0.min.js"></script>
|
|
<script type="text/javascript" src="js/weewx.js"></script>
|
|
<script type="text/javascript" >
|
|
$(function () {
|
|
var level = get_default_level();
|
|
create_toc_control(level);
|
|
generate_toc(level);
|
|
});
|
|
</script>
|
|
|
|
<script type="text/javascript">
|
|
function showtab(tab, id) {
|
|
document.getElementById(tab + '-deb').style.display = 'none';
|
|
document.getElementById(tab + '-rpm').style.display = 'none';
|
|
document.getElementById(tab + '-setup').style.display = 'none';
|
|
document.getElementById(tab + '-' + id).style.display = 'block';
|
|
|
|
document.getElementById(tab + '-tab-deb').className = 'tab';
|
|
document.getElementById(tab + '-tab-rpm').className = 'tab';
|
|
document.getElementById(tab + '-tab-setup').className = 'tab';
|
|
document.getElementById(tab + '-tab-' + id).className = 'tab selected';
|
|
}
|
|
</script>
|
|
|
|
</body>
|
|
</html>
|