mirror/weewx
1
0
Fork 0
mirror of https://github.com/weewx/weewx.git synced 2026-04-18 16:46:56 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
a3ecdb17d1e1832cd6997ab35308b2b3e877df4e
weewx/docs/usersguide.htm
davies-barnard 46224382d9 CSS Changes 
Conversion of font sizes to %ages and addition of media queries.
2016-02-26 18:22:01 +00:00

5718 lines
246 KiB
HTML
Raw Blame History

<!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 id="page">
<div id="toc_parent" class="sidebar">
<div class="fixed">
<p><a href="index.html">Docs Index</a></p>
<div id="toc_controls"></div>
</div>
<div id="toc" class="scrollable">
<!-- The table of contents will get injected here -->
</div>
</div>
<div id="technical_content" class="main">
<div class="header">
<a href='http://weewx.com'>
<img src='images/logo-weewx.png' class='logo' align='right' alt="weewx logo"/>
</a>
<h1 class="title">User's Guide to the <span class="code">weewx</span> Weather System<br/>
<span class='version'>Version: 3.4.0</span>
</h1>
</div><!-- End Header -->
<p>
This is the complete guide to installing and configuring <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> &mdash;
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 &mdash; 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">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">&nbsp;</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 &quot;Vantage&quot; series</a> of weather
stations, including the
<a href="http://www.davisnet.com/weather/products/vantage-pro-professional-weather-stations.asp">VantagePro2</a>&trade;
and
<a href="http://www.vantagevue.com/">VantageVue</a>&trade;,
using serial, USB, or
<a href="http://www.davisnet.com/weather/products/weather_product.asp?pnum=06555">WeatherLinkIP</a>&trade;
connections. Both the &quot;Rev A&quot; (firmware dated before
22 April 2002) and &quot;Rev B&quot; 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 WMR200A</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 (Quick Start)</a></h2>
<p>For Debian, Ubuntu, Mint, and Raspian operating systems, follow the
<a href='debian.htm'>"Quick Start" 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 &mdash; described in detail in the <a href="#weewxconf">next section</a>
&mdash; 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> &mdash;
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 &quot;default value&quot; 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 &quot;<span class="code">Standard</span>&quot;, which generates
four HTML pages (&quot;day&quot;, &quot;week&quot;, &quot;month&quot;, and &quot;year&quot;
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 &quot;report&quot; 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 (&#39;<span class="code">/</span>&#39;),
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 &quot;report&quot; 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&deg;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&deg;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 &deg;F through 120 &deg;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 &deg;C through 60 &deg;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>
<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 &mdash; 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&nbsp;</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 &mdash; 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&nbsp;</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&#39;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 &quot;2&quot;), 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&deg; error in the wind direction. The solution is to add a
180&deg; 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="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&gt; <span class="cmd">CREATE USER 'weewx'@'localhost' IDENTIFIED BY 'weewx';</span>
mysql&gt; <span class="cmd">GRANT select, update, create, delete, insert, drop ON weewx.* TO weewx@localhost;</span></pre>
<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 &quot;Expert&quot; 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 &#39;reload&#39; 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="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="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>
&lt;Directory <span class="highlight">/home/weewx/public_html</span>&gt;
Options FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all
&lt;/Directory&gt;</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="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, &quot;Did you look at the log file?&quot;
<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. To enable users to gather a standard set of
troubleshooting information in a single report the
<span class="code">wee_debug</span> utility has been developed. The
<span class="code">wee_debug</span> utility is particularly useful for new
users as the <span class="code">wee_debug</span> output may be redirected to
file and 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 cmd">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 &mdash; just a second or two &mdash; 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">&lt;enter&gt;</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 &quot;noise&quot;
problems. The symptom is that the Linux kernel will disconnect from your old
USB port claiming &quot;EMI noise&quot;, 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==&quot;add&quot;, ATTRS{interface}==&quot;CP2102 USB to UART Bridge Controller&quot;, SYMLINK+=&quot;vpro&quot;</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
&quot;<span class="code">CP2102 to UART Bridge Controller</span>&quot;,
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, &quot;<a href="http://www.reactivated.net/writing_udev_rules.html"><em>Writing
udev rules</em></a>,&quot; 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 &quot;since&quot; 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 &mdash; 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 &quot;&lt;class &#39;NameMapper.NotFound&#39;&gt;&quot;
Apr 12 05:12:32 raven reportengine[3074]: **** Message: &quot;cannot find &#39;fubar&#39; in template /home/weewx/skins/Standard/index.html.tmpl&quot;
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&gt; <span class="cmd">select dateTime,outTemp from archive where outTemp &gt; 1000;</span></pre>
</li>
<li>See whether the bad temperature and wind data happened at the same time
<pre class='tty'>sqlite&gt; <span class="cmd">select dateTime,outTemp,windSpeed from archive where outTemp &gt; 1000;</span></pre>
</li>
<li>Remove the bad data by setting to NULL
<pre class='tty'>sqlite&gt; <span class="cmd">update archive set windSpeed=NULL where outTemp &gt; 1000;</span>
sqlite&gt; <span class="cmd">update archive set outTemp=NULL where outTemp &gt; 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=&quot;YES&quot; in /boot/loader.conf (to load it as module).
Which gives here an output like:
uslcom0: &lt;CP2102 USB to UART Bridge Controller&gt; 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 (&deg;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><span class="code">UnicodeEncodeError</span></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>
<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>&quot;Fast enough.&quot; 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 &quot;pythonic&quot; 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 &quot;micro-kernel&quot; 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 &mdash; 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 &quot;Current
Conditions&quot; 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 &quot;<span class="code">/etc/init.d/weewx
stop</span>&quot; 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 &quot;hard&quot; 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 &mdash; 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 &quot;unix time,&quot; or &quot;unix
epoch time.&quot; 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&nbsp;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,
&#39;degree_C&#39;, &#39;group_temperature&#39;)</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 &quot;<span class="code">None</span>&quot;</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, &quot;Greenwich&quot;
or &quot;Zulu&quot;) 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>
<p class="copyright"> &copy; <a href="copyright.htm">Copyright</a> Tom Keffer </p>
</div><!-- #technical_content -->
</div><!-- End of Page -->
<!-- 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>
Reference in New Issue View Git Blame Copy Permalink