This is the complete guide to installing and configuring weewx.
weewx is software, written in Python, 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 WeatherUnderground, CWOP, or PWSweather.com.
Initial development began in the winter of 2008-2009, with the first release in 2009. The SourceForge project was registered in October of 2009.
weewx is about 8,000 lines of code, plus another 8,000 for the many drivers used by the supported hardware.
Many types of station hardware are supported. In addition to hardware support, weewx comes with a software simulator, useful for testing and evaluation.
The following table enumerates many of the weather stations that are known to work with weewx. If your station is not in the table, check the pictures at the supported hardware page — it could be a variation of one of the supported models. You can also check the station comparison table — sometimes new models use the same communication protocols as older hardware.
The maturity column indicates the degree of confidence in the driver. For stations marked Tested, 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 Experimental, we are still working on the driver. There can be problems.
Vendor | Model | Hardware Interface |
Required Package |
Station Driver |
Maturity |
Argent Data Systems | WS1 | Serial | pyusb | WS19 | |
Aercus | WS2083 | USB | pyusb | FineOffsetUSB5 | |
WS3083 | USB | pyusb | FineOffsetUSB5 | ||
Ambient Weather | WS1090 | USB | pyusb | FineOffsetUSB5 | Tested |
WS2080 | USB | pyusb | FineOffsetUSB5 | Tested | |
WS2080A | USB | pyusb | FineOffsetUSB5 | Tested | |
WS2090 | USB | pyusb | FineOffsetUSB5 | ||
WS2095 | USB | pyusb | FineOffsetUSB5 | ||
Cresta | WRX815 | USB | pyusb | TE9238 | Experimental |
PWS720 | USB | pyusb | TE9238 | Experimental | |
Davis | VantagePro2 | Serial or USB | pyserial | Vantage1 | Tested |
VantagePro2 | WeatherLink IP | Vantage1 | Tested | ||
VantageVue | Serial or USB | pyserial | Vantage1 | Tested | |
Elecsa | 6975 | USB | pyusb | FineOffsetUSB5 | |
6976 | USB | pyusb | FineOffsetUSB5 | ||
Fine Offset | WH1080 | USB | pyusb | FineOffsetUSB5 | |
WH1081 | USB | pyusb | FineOffsetUSB5 | ||
WH1091 | USB | pyusb | FineOffsetUSB5 | ||
WH1090 | USB | pyusb | FineOffsetUSB5 | ||
WS1080 | USB | pyusb | FineOffsetUSB5 | ||
WA2080 | USB | pyusb | FineOffsetUSB5 | ||
WA2081 | USB | pyusb | FineOffsetUSB5 | ||
WH2080 | USB | pyusb | FineOffsetUSB5 | ||
WH2081 | USB | pyusb | FineOffsetUSB5 | ||
WH3080 | USB | pyusb | FineOffsetUSB5 | ||
WH3081 | USB | pyusb | FineOffsetUSB5 | ||
General Tools | WS831DL | USB | pyusb | TE9238 | Experimental |
Hideki | DV928 | USB | pyusb | TE9238 | Experimental |
TE821 | USB | pyusb | TE9238 | Experimental | |
TE827 | USB | pyusb | TE9238 | Experimental | |
TE831 | USB | pyusb | TE9238 | Experimental | |
TE923 | USB | pyusb | TE9238 | Experimental | |
Huger | WM918 | Serial | pyserial | WMR9x84 | |
IROX | Pro X | USB | pyusb | TE9238 | Experimental |
La Crosse | C86234 | USB | pyusb | WS28xx7 | Experimental |
WS-23XX | Serial | fcntl/select | WS23xx6 | Experimental | |
WS-28XX | USB | pyusb | WS28xx7 | Experimental | |
Maplin | N96GY | USB | pyusb | FineOffsetUSB5 | |
N96FY | USB | pyusb | FineOffsetUSB5 | ||
Meade | TE923W | USB | pyusb | TE9238 | Experimental |
TE923W-M | USB | pyusb | TE9238 | Experimental | |
TE924W | USB | pyusb | TE9238 | Experimental | |
Mebus | TE923 | USB | pyusb | TE9238 | Experimental |
National Geographic | 265 | USB | pyusb | FineOffsetUSB5 | |
Oregon Scientific | WMR88 | USB | pyusb | WMR1002 | |
WMR100 | USB | pyusb | WMR1002 | ||
WMR100N | USB | pyusb | WMR1002 | Tested | |
WMR180 | USB | pyusb | WMR1002 | ||
WMRS200 | USB | pyusb | WMR1002 | ||
WMR200 | USB | pyusb | WMR2003 | Experimental | |
WMR918 | Serial | pyserial | WMR9x84 | ||
WMR928N | Serial | pyserial | WMR9x84 | Tested | |
WMR968 | Serial | pyserial | WMR9x84 | Tested | |
PeetBros | Ultimeter 100 | Serial | pyserial | Ultimeter10 | Experimental |
Ultimeter 800 | Serial | pyserial | Ultimeter10 | Experimental | |
Ultimeter 2000 | Serial | pyserial | Ultimeter10 | Experimental | |
Ultimeter 2100 | Serial | pyserial | Ultimeter10 | Experimental | |
RainWise | Mark III | Serial | pyserial | CC300011 | Experimental |
CC3000 | Serial | pyserial | CC300011 | Experimental | |
Radio Shack | 63-256 | USB | pyusb | WMR1002 | |
WX200 | USB | pyusb | WMR2003 | Experimental | |
63-1016 | Serial | pyserial | WMR9x84 | ||
Sinometer | WS1080 / WS1081 | USB | pyusb | FineOffsetUSB5 | |
WS3100 / WS3101 | USB | pyusb | FineOffsetUSB5 | ||
TechnoLine | WS-2300 | Serial | fcntl/select | WS23xx6 | Experimental |
WS-2350 | Serial | fcntl/select | WS23xx6 | Experimental | |
TFA | Matrix | Serial | fcntl/select | WS23xx6 | Experimental |
Nexus | USB | pyusb | TE9238 | Experimental | |
Opus | USB | pyusb | WS28xx7 | Experimental | |
Primus | USB | pyusb | WS28xx7 | Experimental | |
Sinus | USB | pyusb | TE9238 | Experimental | |
Tycon | TP1080WC | USB | pyusb | FineOffsetUSB5 | |
Watson | W-8681 | USB | pyusb | FineOffsetUSB5 | |
WX-2008 | USB | pyusb | FineOffsetUSB5 | ||
Velleman | WS3080 | USB | pyusb | FineOffsetUSB5 | |
Ventus | W831 | USB | pyusb | TE9238 | Experimental |
W928 | USB | pyusb | TE9238 | Experimental |
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!
I run weewx 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, 80 MB of virtual memory, and 20 MB of real memory.
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.
You should run a NTP 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.
The time on some stations is automatically synchronized with the weewx server nominally every four hours. The synchronization frequency can be adjusted in the weewx configuration.
Python 2.5, 2.6, or 2.7 is required. Python 3 will not work.
In the world of open-source hobbyist software, weewx 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.
You should have the following skills:
If you get stuck, there is a very active User's Group to help, but, please, try to solve the problem yourself before posting.
weewx can be installed using the standard Python utility setup.py or it can be installed from a DEB or RPM package.
Installation using setup.py is the recommended method for those who plan to write custom services and reports for weewx. It will put everything in a single directory, making it easier to modify. If the user installing weewx has permission to write to the directory, root privileges will not be required to install, run, or modify weewx.
By contrast, the package approach is somewhat simpler, but it requires root privileges, and will install the bits and pieces of weewx 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.
When installing using setup.py, the installation location is specified by the home parameter in the setup.cfg file. This file is not used by the other installation methods.
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.
Application layout for install using DEB package | ||
Role | Symbolic Name | Nominal Location |
Executables | $BIN_ROOT | /usr/share/weewx/ |
Configuration directory | $CONFIG_ROOT | /etc/weewx/ |
Skins and templates | $SKIN_ROOT | /etc/weewx/skins/ |
SQLite databases | $SQLITE_ROOT | /var/lib/weewx/ |
Web pages and images | $HTML_ROOT | /var/www/weewx/ |
Documentation | $DOC_ROOT | /usr/share/doc/weewx/ |
PID file | /var/run/weewx.pid | |
Log file | /var/log/syslog |
For Debian, Ubuntu, Mint, and Raspian operating systems, follow the instructions for Debian-based systems.
For Redhat, CentOS, Fedora operating systems, follow the the instructions for Redhat-based systems.
For SuSE and OpenSUSE, follow the instructions for SuSE-based systems.
For all operating systems, follow the setup.py instructions.
This section covers configuring weewx, in particular the configuration file $CONFIG_ROOT/weewx.conf.
There is another configuration file, skin.conf, for presentation-specific options. It is described in the Customizing Guide, under section The Standard skin.conf.
This section is the definitive guide to the configuration options available in weewx.conf. It documents way more options than you are likely to need! — you can safely ignore most of them. The truly important ones, the ones you are likely to have to customize for your station, are highlighted.
Default values are provided for many options, meaning that if they are not listed in the configuration file at all, weewx will pick sensible values. When the documentation below gives a "default value" this is what it means.
What follows is organized by the different sections of the configuration file.
The options declared at the top are not actually part of any section.
debug
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).
WEEWX_ROOT
Set to the root directory of the weewx file hierarchy for this station. Normally, this is set automatically by the installation process. Required. No default.
socket_timeout
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.
gc_interval
Set to how often garbage collection should be performed by the Python runtime engine. Default is every 10,800 seconds (3 hours).
This section covers options relating to your weather station setup.
location
The station location should be a UTF-8 string that describes the geography of where your weather station is located. Required. No default.
location = "A small ranch in Kentucky"
latitude
longitude
The lat/lon should be set in decimal degrees, negative for southern and western hemispheres, respectively. Required. No default.
latitude = 38.8977 longitude = -77.0366
altitude
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:
altitude = 700, foot
An example in meters:
altitude = 220, meter
station_type
Set to the type of hardware you are using.
station_type = Simulator
Valid options include:
Option | Description |
Simulator | A software weather station simulator. Useful for testing and debugging. |
CC3000 | RainWise CC3000 data logger |
FineOffsetUSB | Fine Offset 10xx, 20xx, and 30xx stations |
TE923 | Hideki TE923 stations |
Ultimeter | PeetBros Ultimeter stations |
Vantage | Davis Vantage weather stations |
WMR100 | Oregon Scientific WMR100 series stations |
WMR200 | Oregon Scientific WMR200 series stations |
WMR9x8 | Oregon Scientific WMR-918/968 series stations |
WS1 | Argent Data Systems WS1 stations |
WS23xx | La Crosse 23xx stations |
WS28xx | La Crosse 28xx stations |
station_url
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 station registry, it will also be included in the map of weewx stations.
Example:
station_url = http://www.mywebsite.com
rain_year_start
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.
rain_year_start = 1
week_start
Start of the week. 0=Monday, 1= Tuesday, ... , 6 = Sunday. Default is 6 (Sunday)
week_start = 0
This section is for options relating to the software weather station simulator that comes with weewx.
loop_interval
The time (in seconds) between emitting loop packets. Default is 2.5
mode
One of either simulator or generator. Default is simulator.
simulator | Real-time simulator. It will sleep between emitting packets. |
generator | Emit packets as fast as it can. Useful for testing. |
start
The start time for the generator in the format YYYY-MM-DD hh:mm. Optional. Default is the present time.
This section is for options relating to the RainWise Mark III weather stations and CC3000 data logger.
port
The serial port, e.g., /dev/ttyS0. When using a USB-Serial converter, the port will be something like /dev/ttyUSB0. Default is /dev/ttyUSB0
polling_interval
The polling_interval determines how often weewx will query the station for data. The default is 1 second.
This section is for options relating to the Fine Offset series of weather stations with USB connectors.
model
Set to the station model. For example, WH1080, WS2080, WH3081, etc.
polling_mode
One of PERIODIC or ADAPTIVE. In PERIODIC mode, weewx queries the console at regular intervals determined by the polling_interval. In ADAPTIVE mode, weewx attempts to query the console at times when it is not reading data from the sensors or writing data to memory. See the section Polling Mode and the Polling Interval for details. The default is PERIODIC.
polling_interval
The frequency, in seconds, at which weewx will poll the console for data. Default is 60. This setting applies only when the polling_mode is PERIODIC.
This section is for options relating to the Hideki TE923 series of weather stations.
model
Set to the station model. For example, Meade TE923W or TFA Nexus. Default is "TE923".
sensor_map
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.
The default mapping is:
[[sensor_map]] outTemp = t_1 outHumidity = h_1 extraTemp1 = t_2 extraHumid1 = h_2 extraTemp2 = t_3 extraHumid2 = h_3 extraTemp3 = t_4 extraHumid3 = h_4 extraTemp4 = t_5 extraHumid4 = h_5
battery_map
This option defines the mapping between battery status values in the database and the remote sensors. The default mapping is:
[[battery_map]] txBatteryStatus = batteryUV windBatteryStatus = batteryWind rainBatteryStatus = batteryRain outTempBatteryStatus = battery1 extraBatteryStatus1 = battery2 extraBatteryStatus2 = battery3 extraBatteryStatus3 = battery4 extraBatteryStatus4 = battery5
This section is for options relating to the PeetBros Ultimeter weather stations.
port
The serial port, e.g., /dev/ttyS0. When using a USB-Serial converter, the port will be something like /dev/ttyUSB0. Default is /dev/ttyUSB0
model
Set to the station model. For example, Ultimeter 2000 or Ultimeter 800. Default is "Ultimeter".
This section is for options relating to the Davis Vantage series of hardware (VantagePro, VantagePro2 or VantageVue).
type
Set to either serial, for a serial or USB connection to the VantagePro (by far the most common), or to ethernet for the WeatherLinkIP. No default.
port
If you chose serial, for type, then set to the serial port name used by the station. For example, /dev/ttyUSB0 is a common location for USB ports, /dev/ttyS0 for serial ports. Otherwise, not required. No default.
host
If you chose ethernet, then specify either the IP address (e.g., 192.168.0.1) or hostname (e.g., console.mydomain.com) to the console. Otherwise, not required. No default.
baudrate
Set to the baudrate of the station. The default is 19200.
tcp_port
The port where WeatherLinkIP will be listening. Default is 22222.
tcp_send_delay
How long to block after sending a socket packet to the WeatherLinkIP. Default is 1 second.
iss_id
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.
timeout
How many seconds to wait for a response from the station before giving up. Default is 5 seconds.
wait_before_retry
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.
max_tries
How many times to try again before giving up. Default is 4.
This section is for options relating to the Oregon Scientific WMR100 series of weather stations with USB connectors.
model
Set to the station model. For example, WMR100 or WMRS200.
stale_wind
How long a wind record can be used to calculate wind chill (in seconds). Default is 30.
This section is for options relating to the Oregon Scientific WMR200 series of weather stations with USB connectors.
model
Set to the station model. For example, WMR200 or WMR200A.
use_pc_time
If True, use the computer time, otherwise use the station time. Default is True.
archive_interval
Set the wmr200 archive interval in seconds. Default is 60 seconds.
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.
erase_archive
If True, erase onboard console memory archive on startup. Default is False.
archive_startup
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.
archive_threshold
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).
sensor_status
If True, emit sensor faults and failures to log. Default is True.
This section is for options relating to the Oregon Scientific WMR-918/968 series of weather stations with serial connectors.
type
For the moment, only serial is supported.
port
Along with the serial option above, you must set the serial port name used by the station. For example, /dev/ttyUSB0 is a common location for USB ports, /dev/ttyS0 for serial ports. No default.
model
Set to the station model. For example, WMR968 or WMR918.
This section is for options relating to the Argent Data Systems WS1 weather stations.
port
The serial port, e.g., /dev/ttyS0. When using a USB-Serial converter, the port will be something like /dev/ttyUSB0. Default is /dev/ttyUSB0
polling_interval
The polling_interval determines how often weewx will query the station for data. The default is 1 second.
This section is for options relating to the La Crosse WS-23xx series of weather stations.
port
The serial port, e.g., /dev/ttyS0. When using a USB-Serial converter, the port will be something like /dev/ttyUSB0. Default is /dev/ttyUSB0
model
Set to the station model. For example, WS-2315, LaCrosse WS2317, etc. Default is "LaCrosse WS23xx".
polling_interval
The polling_interval determines how often weewx will query the station for data. If no polling_interval is specified (the default), weewx 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.
This section is for options relating to the La Crosse WS-28xx series of weather stations.
transceiver_frequency
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.
model
Set to the station model. For example, LaCrosse WS2810, TFA Primus, etc. Default is "LaCrosse WS28xx".
This section is for configuring the StdRESTful services, which upload to simple RESTful servers such as the Weather Underground, PWSweather.com, or CWOP.
A registry of weewx weather stations is maintained at weewx.com. Stations are displayed on a map and a list at http://weewx.com/stations.html
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 weewx version. No personal information, nor any meteorological data, is sent.
To add your station to this list, you must do two things:
The station_url is used to uniquely identify each station, so choose it carefully before you set register_this_station to True.
[StdRestful] [[StationRegistry]] register_this_station = True
register_this_station
Set this to True to register the weather station.
description
A description of the station. If no description is specified, the location from the [Station] section will be used.
station_url
The URL to the weather station. If no URL is specified, the station_url from the [Station] section will be used.
log_success
In case of success, make a note in the system log. The default is True.
log_failure
In case of failure, make a note in the system log. The default is True.
Weewx can send your current data to the Weather Underground. If you do not wish to do this, leave the option station commented.
[StdRestful] [[Wunderground]] station = 12345678 # Replace with your station number password = xxxxx # Replace with your password rapidfire = False
station
Set to your Weather Underground station ID (e.g., KORHOODR3). Required.
password
Set to your Weather Underground password. Required.
rapidfire
Set to True to have weewx post using the Weather Underground's "Rapidfire" protocol. 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 False.
archive_post
This option tells weewx 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 rapidfire. However, if for some reason you want to do both, then you may set both options to True.
log_success
In case of success, make a note in the system log. The default is False for Rapidfire mode, True for PWS mode.
log_failure
In case of failure, make a note in the system log. The default is False for Rapidfire mode, True for PWS mode.
Weewx can send your current data to the PWSweather.com service. If you do not wish to do this, leave the option station commented.
[StdRestful] [[PWSweather]] station = 12345678 # Replace with your station number password = xxxxx # Replace with your password
station
Set to your PWSweather station ID. Required.
password
Set to your PWSweather password. Required.
log_success
In case of success, make a note in the system log. The default is True.
log_failure
In case of failure, make a note in the system log. The default is True.
Weewx can send your data to the Citizen Weather Observer Program. If you do not wish to do this, leave the station commented.
[StdRestful] [[CWOP]] station = 12345678 # Replace with your station number passcode = xxxxx # Replace with your passcode (APRS stations only) post_interval = 600
station
Set to your CWOP station ID (e.g., CW1234). Required.
passcode
This is used for APRS (amateur radio) stations only. Set to the passcode given to you by the CWOP operators. Otherwise, leave this option commented. Required for APRS stations, ignored for others.
post_interval
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 zero.
stale
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 weewx attempts a catch up, old data could be interpreted as the current conditions. Optional. Default is 1800 seconds.
server_list
A comma-delimited list of the servers that should be tried for uploading data. Optional. Default is: cwop.aprs.net:14580, cwop.aprs.net:23
log_success
In case of success, make a note in the system log. The default is True.
log_failure
In case of failure, make a note in the system log. The default is True.
Weewx can send your current data to the British Weather Observations Website (WOW) service. If you do not wish to do this, leave the station option commented.
[StdRestful] [[WOW]] station = 12345678 # Replace with your site ID password = xxxxx # Replace with your site authentication key
station
Set to your WOW station ID. Required.
password
Set to your WOW password. Required.
log_success
In case of success, make a note in the system log. The default is True.
log_failure
In case of failure, make a note in the system log. The default is True.
Weewx can send your current data to the Automatisches Wetterkarten System (AWEKAS). If you do not wish to do this, leave the username option commented.
[StdRestful] [[AWEKAS]] username = joeuser # Replace with your awekas username password = xxxxx # Replace with your awekas password
username
Set to your AWEKAS username. Required.
password
Set to your AWEKAS password. Required.
language
Set to your preferred language. Default is en.
log_success
In case of success, make a note in the system log. The default is True.
log_failure
In case of failure, make a note in the system log. The default is True.
This section is for configuring the StdReport 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.
Each report is represented by a sub-section, marked with double brackets (e.g., [[MyReport]]). 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 [[StandardReport]] will be run first, then report [[FTP]] (which actually optionally uploads the results to a remote web server). Details for how to customize reports are in the section Customizing reports, in the Customizing Guide.
SKIN_ROOT
The directory where the skins live. A relative path is relative to $WEEWX_ROOT.
HTML_ROOT
The target directory for the generated files. A relative path is relative to $WEEWX_ROOT. Generated files and images will be put here.
data_binding
The data source to be used for the reports. It should match a binding given in section [DataBindings] below. The binding can be overridden in individual reports. Optional. Default is wx_binding.
This is the standard report that will be run on every archiving interval. It uses the skin "Standard", which generates four HTML pages ("day", "week", "month", and "year" observations), plot graphs for same, an RSS feed, and NOAA monthly and yearly reports. The default configuration uses US Customary Units and puts the results in public_html and subdirectory public_html/NOAA.
While this "report" does not actually generate anything, it uses the report machinery to upload files from directory $HTML_ROOT 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.
If you do not use such a server, comment out the first four options below.
user
Set to the username you use for your FTP connection to your web server. Required. No default.
password
Set to the password you use for your FTP connection to your web server. Required. No default.
server
Set to the name of your web server (e.g., www.threefools.org, in my case). Required. No default
path
Set to the path where the weather data will be stored on your webserver (e.g., /weather). NB: some FTP servers require a leading slash ('/'), some do not. Required. No default.
port
Set to the port ID of your FTP server. Default is 21.
passive
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 Active FTP vs. Passive FTP, a Definitive Explanation for a good explanation of the difference. Default is 1 (passive mode).
max_tries
Weewx will try up to this many times to FTP a file up to your server before giving up. Default is 3.
While this "report" does not actually generate anything, it uses the report machinery to upload files from directory $HTML_ROOT 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.
If you do not use such a server, comment out the options below.
server
Set to the name of your web server (e.g., www.threefools.org, in my case). Required. No default
user
Set to the ssh username you use for your rsync connection to your web server. The local user that weewx runs as must have passwordless ssh configured for user@server. Required. No default.
path
Set to the path where the weather data will be stored on your webserver (e.g., /weather). Required. No default.
delete
Files that don't exist in the local report are removed from the remote location. USE WITH CAUTION: If you make a mistake in setting the path, 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.
This section is for configuring the StdConvert 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.
Once chosen, it cannot be changed! 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 Changing the unit system in the Customizing Guide.
Note!
This service only
affects the units used in the databases. 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, skin.conf, as described in
the Customizing Guide, under
section
Changing
options. Because of this, unless you have a special
purpose application, there is really no good reason to change
from the default, which is US.
Warning!
If, despite these precautions, you do decide to change the units of data
stored in the database, be sure to read the sections
[StdCalibrate] and
[StdQC], and change the
units there as well!
target_unit
Set to either US, METRICWX, or METRIC. The difference between METRICWX, and METRIC is that the former uses mm instead of cm for rain, and m/s instead of km/hr for wind speed. See the Appendix Units in the Customizing Guide for the exact differences beween these three choices. Default is US.
This section is for configuring the StdCalibrate service. This service offers an opportunity to correct for any calibration errors in your instruments. It is very general and flexible.
Because this service is normally run after StdConvert, the units to be used should be the same as the target unit system chosen in StdConvert above. It is also important that this service be run before the archiving service StdArchive, so that it is the corrected data that are stored.
In this section you list all correction expressions. For example, say that you know your outside thermometer reads high by 0.2°F. You could add the expression:
outTemp = outTemp - 0.2
Perhaps you need a linear correction around a reference temperature of 68°F:
outTemp = outTemp + (outTemp-68) * 0.02
It is even possible to do corrections involving more than one variable. Suppose you have a temperature sensitive barometer:
barometer = barometer + (outTemp-32) * 0.0091
All correction expressions are run in the order given.
Both LOOP data and archive data will be corrected.
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.
This section is for configuring the StdQC service. This service offers a very simple Quality Control that only checks that values are within a minimum and maximum range.
Because this service is normally run after StdConvert, the units to be used should be the same as the target unit system chosen in StdConvert. It is also important that it be run after the calibration service, StdCalibrate and before the archiving service StdArchive, so that it is the calibrated and corrected data that are stored.
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 the same unit system as specified in section StdConvert.
For example,
[[MinMax]] outTemp = -40, 120 barometer = 28, 32.5 outHumidity = 0, 100
With target_unit = US (the default), if a temperature should fall outside of the inclusive range -40 °F through 120 °F, then it will be set to the null value, None, and ignored. In a similar manner, the acceptable values for barometric pressure would be 28 through 32.5 inHg, for humidity 0 through 100%.
You can also specify units.
For example,
[[MinMax]] outTemp = -40, 60, degree_C barometer = 28, 32.5, inHg
In this example, if a temperature should fall outside of the inclusive range -40 °C through 60 °C, then it will be set to the null value, None, 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 target_unit.
Both LOOP and archive data will be checked.
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 0xff 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.
The calculation service calculates derived quantities such as dewpoint, windchill, and heatindex.
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.
The calculation service can calculate the following values:
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:
[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
The options for each quantity are hardware, software, or prefer_hardware
hardware | Never calculate the value. |
software | Always calculate the value. |
prefer_hardware | Calculate the value only if it is not provided by hardware. |
For example, if your weather station calculates windchill using the pre-2001 algorithm, and you prefer to have weewx calculate it using a current algorithm, specify the following:
[StdWXCalculate] ... windchill = software
This section is for configuring StdArchive, the service that stores data in a database.
archive_interval
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.
archive_delay
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.
record_generation
Set to whether records should be downloaded off the hardware (recommended), or generated in software. If set to hardware, then weewx tries to download archive records from your station. However, not all types of stations support this, in which case weewx falls back to software generation. A setting of hardware will work for most users. A notable exception is users who have cobbled together homebrew serial interfaces for the Vantage stations that do not include memory for a logger. These users should set this option to software, forcing software record generation. Default is hardware.
loop_hilo
Set to True to have LOOP data and archive data to be used for high / low statistics. Set to False to have only archive data used. If your sensor emits lots of spiky data, setting to False may help. Default is True.
data_binding
The data binding to be used to store the data. This should match one of the bindings in the [DataBindings] section, below. Optional. Default is wx_binding.
This section is for configuring StdTymeSynch, a service that can synchronize the onboard clock of station with your computer. Not all weather station hardware supports this.
clock_check
How often to check the clock on the weather station in seconds. Default is 14,400 seconds (every 4 hours)
max_drift
The maximum amount of clock drift to tolerate, in seconds, before resetting the clock. Default is 5.
A "data binding" associates storage characteristics with a specific database. Each binding contains a database from the [Databases] section plus parameters such as schema, table name, and mechanism for aggregating data.
This is the binding normally used for weather data. A typical [[wx_binding]] section looks something like this:
[[wx_binding]] database = archive_sqlite table_name = archive manager = weewx.wxmanager.WXDaySummaryManager schema = schemas.wview.schema
What follows is more detailed information about each of the binding options.
database
The actual database to be used — it should match one of the sections in [Databases]. Should you decide to use a MySQL database, instead of the default SQLite database, this is the place to change it. Required.
table_name
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 archive
manager
The name of the class to be used to manage the table. Optional. Default is class weewx.wxmanager.WXDaySummaryManager. 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.
schema
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 schemas.wview.schema, the schema used by the wview weather system.
This section lists actual databases. The name of each database is given in double brackets, for example, [[archive_sqlite]]. Each database section contains the parameters necessary to create and manage the database. The number of parameters varies depending on the type of database.
This definition uses the SQLite database engine to store data. SQLite is open-source, simple, lightweight, highly portable, and memory efficient. For most purposes it serves nicely.
database_name
The path to the SQLite file. A relative path is relative to $SQLITE_ROOT. Required.
timeout
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 timeout option specifies how long other threads should wait for the lock to go away before raising an exception. The default is 5 seconds.
isolation_level
Set the current isolation level. See the pysqlite documentation on isolation levels for more information. There is no reason to change this, but it is here for completeness. Default is None (autocommit).
This definition uses the MySQL database engine to store data. It is free, highly-scalable, but more complicated to administer.
Note that if you choose the MySQL 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.
host
The name of the server on which the database is located. Default is localhost.
user
The user name to be used to log into the server. Required.
password
The password. Required.
database_name
The name of the database. Required.
This section is used to configure the internal service engine in weewx. It is for advanced customization. Details on how to do this can be found in the section Customizing the weewx service engine of the Customizing Guide.
Internally, weewx consists of many services, 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 weewx v2.6, this section held one, looong option called service_list, 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.
prep_services
These services get called before any others. They are typically used to prepare the console. For example, the service weewx.wxengine.StdTimeSynch, which is responsible for making sure the console's clock is up to date, is a member of this group.
process_services
Services in this group tend to process any incoming data. They typically do things like quality control, or unit conversion, or sensor calibration.
archive_services
Once data have been processed, services in this group archive them.
restful_services
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.
report_services
The various reporting services run in this group, including the standard reporting engine.
For reference, here is the standard set of services that are run with the default distribution.
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
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.
This section describes how to configure some of the more popular station hardware.
Some stations can be configured using the wee_config_device 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.
Note that some stations cannot be configured by software at all, and some stations are only partly configurable by software.
Run the utility with the --help option to see which options are available.
$BIN_ROOT/wee_config_device --help
The utility requires a weewx.conf file. If no file is specified, it will look for weewx.conf 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,
$BIN_ROOT/wee_config_device /path/to/weewx.conf --help
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 weewx. However, the CC3000 driver will convert to the appropriate units for the weewx configuration.
The CC3000 data logger stores 2MB of records.
The CC3000 driver supports catchup on startup, but it does not support hardware record generation.
When the station_type is CC3000, the --help option will produce output something like this:
CC3000 driver version 0.8 Usage: wee_config_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.
Display the station settings with the --info option.
$BIN_ROOT/wee_config_device --info
This will result in something like this:
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
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:
$BIN_ROOT/wee_config_device --set-interval=5
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.
The station reads data from the sensors every 48 seconds. The 30xx stations read UV data every 60 seconds.
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.
When weewx starts up it will attempt to download all records from the console since the last record in the archive database.
When the station_type is FineOffsetUSB, the --help option will produce output something like this:
FineOffsetUSB driver version 1.7 Usage: wee_config_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.
Display the station settings with the --info option.
$BIN_ROOT/wee_config_device --info
This will result in something like this:
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 data_count: 22 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 read_period: 30 rel_pressure: 1014.8 temp_in_offset: 1792 temp_out_offset: 0 timezone: 0 unknown_01: 0 unknown_18: 0 version: 255 wind_coef: None wind_mult: 0
Highlighted values can be modified with the wee_config_device utility.
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:
$BIN_ROOT/wee_config_device --set-interval=5
Fine Offset stations store records in a circular buffer — once the buffer fills, the oldest records are replaced by newer records. The 1080 and 2080 consoles store up to 4080 records. The 3080 consoles store up to 3264 records. The data_count indicates how many records are in memory. The read_period indicates the number of minutes between records. wee_config_device can display these records in space-delimited, raw bytes, or dictionary format.
For example, to display the most recent 30 records from the console memory:
$BIN_ROOT/wee_config_device --history=30
To clear the console memory:
$BIN_ROOT/wee_config_device --clear-memory
Use the wee_config_device 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.
To test the quality of the USB connection to the console:
$BIN_ROOT/wee_config_device --check-usb
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.
When reading 'live' data, weewx can read as fast as possible, or at a user-defined period. This is controlled by the polling_mode parameter.
Mode | weewx.conf | Notes |
ADAPTIVE |
[FineOffsetUSB] polling_mode = ADAPTIVE |
In this mode, weewx 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. |
PERIODIC |
[FineOffsetUSB] polling_mode = PERIODIC polling_interval = 60 |
In this mode, weewx reads data from the station every polling_interval seconds. The console reads the sensors every 48 seconds (60 seconds for UV), so setting the polling_interval to a value less than 48 will result in duplicate readings. |
The wee_config_device utility cannot configure TE923 stations.
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 sensor_map in weewx.conf to map each sensor to a database field.
The station has either 200 or 3300 history records, depending on the model. That is just over a day (200 records) or about 23 days (3300 records) with an archive interval of 5 minutes.
The TE923 driver is not capable of reading archive records from the station.
The wee_config_device utility cannot configure Ultimeter stations.
The Ultimeter driver operates the Ultimeter in Data Logger Mode, which results in sensor readings every 1/2 second or so.
The Ultimeter driver ignores the maximum, minimum, and average values recorded by the station.
When the station_type is Vantage, the --help option will produce output something like this:
Vantage driver version 3.0 Usage: wee_config_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). Mutating actions will request confirmation before proceeding.
Use the --info option to display the current EEPROM settings:
$BIN_ROOT/wee_config_device --info
This will print out something like:
Davis Vantage EEPROM settings: CONSOLE TYPE: VantagePro2 CONSOLE FIRMWARE: Date: Dec 11 2012 Version: 3.12 CONSOLE SETTINGS: Archive interval: 300 (seconds) Altitude: 700 (foot) Wind cup type: large Rain bucket type: 0.01 inches Rain year start: 10 Onboard time: 2014-09-25 07:41:14 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 Use manual or auto DST? AUTO DST setting: N/A Use GMT offset or zone code? ZONE_CODE Time zone code: 4 GMT offset: N/A TRANSMITTERS: Channel 1: iss Channel 2: (N/A) Channel 3: temp (as extra temperature 1) Channel 4: (N/A) Channel 5: (N/A) Channel 6: (N/A) Channel 7: (N/A) Channel 8: (N/A) 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: Current barometer reading: 29.834 inHg Altitude: 700 feet 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: Wind direction: +0 deg Inside Temperature: +0.0 F Inside Humidity: +0% Outside Temperature: +0.0 F Outside Humidity: +0% Extra Temperature 1: +0.0 F
The console version number is available only on consoles with firmware dates after about 2006.
Highlighted values can be changed using this utility.
To set the time zone code to Central European Time (code 20):
$BIN_ROOT/wee_config_device --set-tz-code=20
You can set either the time zone code or the time zone offset, but not both.
Valid archive intervals for the Davis Vantage stations are 60, 300, 600, 900, 1800, 3600, and 7200 seconds. However, if you are ftp'ing lots of files to a server, setting it to 60 seconds may not give enough time to have them all uploaded before the next archive record is due. If this is the case, you should pick an archive interval of at least 300 seconds, or trim the number of files you are using.
To change the archive interval to 10 minutes (600 seconds):
$BIN_ROOT/wee_config_device --set-interval=600
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.
Normally, this is set by Davis, but if you have replaced your bucket with a different kind, you might want to reconfigure. For example, to change to a 0.1 mm bucket (bucket code "2"), use the following:
$BIN_ROOT/wee_config_device --set-bucket=2
If you have additional sensors for your Vantage station, you can configure them using your console. However, if you have a Davis Weather Envoy receiver, it will not have a console! As an alternative, the weewx utility wee_config_device lets you do this from the command line.
For example, to add an extra temperature sensor to channel 3, do the following:
$BIN_ROOT/wee_config_device --set-transmitter-type=3,1,2
This says to turn on channel 3, set its type to 1 ("Temperature only"), and have it show up in the database as extraTemp2. Here's another example, this time for a combined temperature / humidity sensor:
$BIN_ROOT/wee_config_device --set-transmitter-type=5,3,2,4
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 extraTemp2 and extraHumid4.
The --help option will give you the code for each sensor type.
The Davis instruments can correct sensor errors by adding an offset to their emitted values. This is particularly useful for Southern Hemisphere users. Davis fits the wind vane to the Integrated Sensor Suite (ISS) in a position optimized for Northern Hemisphere users, who face the solar panel to the south. Users south of the equator must orient the ISS's solar panel to the north to get maximal insolation, resulting in a 180° error in the wind direction. The solution is to add a 180° offset correction. You can do this with the following command:
$BIN_ROOT/wee_config_device --set-offset=windDir,180
Generally, weewx 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 Weewx generates HTML pages, but it does not update them. 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 --dump command before clearing the memory, you might be able to save these data.
$BIN_ROOT/wee_config_device --dump
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 all data, it may result in many duplicate primary key errors. These can be ignored.
The wee_config_device utility cannot configure WMR100 stations.
The station emits partial packets, which may confuse some online services.
The wee_config_device utility cannot configure WMR200 stations.
The station emits partial packets, which may confuse some online services.
When weewx starts up it will attempt to download all records from the console since the last record in the archive database.
The wee_config_device utility cannot configure WMR9x8 stations.
The station includes a data logger, but the driver does not read records from the station.
The station emits partial packets, which may confuse some online services.
The wee_config_device utility cannot configure WS1 stations.
The WS1 stations produce data every 1/2 second or so.
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.
The station does not record wind gust or wind gust direction.
The hardware calculates windchill and dewpoint.
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.
When weewx starts up it will attempt to download all records from the console since the last record in the archive database.
When the station_type is WS23xx, the --help option will produce output something like this:
WS23xx driver version 0.21 Usage: wee_config_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.
Display the station settings with the --info option.
$BIN_ROOT/wee_config_device --info
This will result in something like this:
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 ...
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:
$BIN_ROOT/wee_config_device --set-interval=5
Warning!
Changing the recording interval will clear the station memory.
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 history number of records indicates how many records are in memory. The history interval indicates the number of minutes between records.
For example, to display the latest 30 records from the console memory:
$BIN_ROOT/wee_config_device --history=30
To clear the console memory:
$BIN_ROOT/wee_config_device --clear-memory
weewx 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.
The station has 1797 history records. That is just over 6 days of data with an archive interval of 5 minutes.
When weewx starts up it will attempt to download all records from the console since the last record in the archive database.
The WS28xx driver sets the station archive interval to 5 minutes.
The WS28xx driver does not support hardware archive record generation.
When the station_type is WS28xx, the --help option will produce output something like this:
WS28xx driver version 0.33 Usage: wee_config_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.
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.
There are two ways to pair the console and the transceiver:
wee_config_device --pair Pairing transceiver with console... Press and hold the [v] key until "PC" appears (attempt 1 of 3) Transceiver is paired to console
If the console does not pair, you will see messages in the log such as this:
ws28xx: RFComm: message from console contains unknown device ID (id=165a resp=80 req=6)
Either approach to pairing may require multiple attempts.
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.
When the transceiver and console are synchronized, you will see lots of 'ws28xx: RFComm' messages in the log when debug=1. When the devices are not synchronized, you will see messages like this about every 10 minutes:
Nov 7 19:12:17 raspi weewx[2335]: ws28xx: MainThread: no contact with console
If you see this, or if you see an extended gap in the weather data in the weewx plots, press momentarily the [SET] button, or wait until the top of the hour.
When the transceiver has not received new data for awhile, you will see messages like this in the log:
Nov 7 19:12:17 raspi weewx[2335]: ws28xx: MainThread: no new weather data
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.
Display the station settings with the --info option.
$BIN_ROOT/wee_config_device --info
This will result in something like this:
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
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 weewx alarms can do much more than the console alarms anyway.
This section applies only to those who wish to use the MySQL database, instead of the default SQLite database.
First, you should change your [[wx_binding]] section to point to MySQL, instead of SQLite. After the change, it will look something like this (change highlighted):
[[wx_binding]]
# The database should match one of the sections in [Databases]
database = archive_mysql
# 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
Assuming that you want to use the default database configuration, your [Databases] section should look something like this:
[Databases] [[archive_mysql]] host = localhost user = weewx password = weewx database_name = weewx driver = weedb.mysql
This assumes user weewx would have password weewx. Adjust as necessary.
You will need to give the necessary permissions for the database weewx to whatever MySQL user you choose, by default, user weewx. Here are the necessary minimum permissions:
mysql> CREATE USER 'weewx'@'localhost' IDENTIFIED BY 'weewx'; mysql> GRANT select, update, create, delete, insert ON weewx.* TO weewx@localhost;
Weewx can be run either directly, or as a daemon. When first trying weewx, 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.
To run weewx directly, invoke the main program, weewxd, giving the configuration file as its only parameter:
sudo $BIN_ROOT/weewxd $CONFIG_ROOT/weewx.conf
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.
Weewx 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.
You can tell a running instance of weewx to reread its configuration file by sending it the HUP signal. First run ps to find out the Process ID (PID) number of the instance, then send it the HUP signal:
ps -a # Note the PID of the weewxd process kill -HUP pid # Send it a HUP signal
Note that this only rereads the configuration file. It will not reload any code.
For unattended operations it is best to have weewx run as a daemon, started automatically when the server is rebooted.
If you use a packaged install from a DEB or RPM distribution, this is done automatically. You can ignore this section.
Start by selecting the appropriate run script. They can be found under $WEEWX_ROOT/util/init.d/.
Debian/Ubuntu/Mint: | $WEEWX_ROOT/util/init.d/weewx.debian |
Redhat/CentOS/Mint: | $WEEWX_ROOT/util/init.d/weewx.redhat |
SuSE: | $WEEWX_ROOT/util/init.d/weewx.suse |
Check the chosen script to make sure the variable WEEWX_ROOT has been set to the proper root directory for your weewx installation (it should have been set to the correct value automatically by the install process, but it is worth checking).
Copy it to the proper location for your system:
Debian/Ubuntu/Mint: | cp $WEEWX_ROOT/util/init.d/weewx.debian /etc/init.d/weewx |
Redhat/CentOS/Fedora: | cp $WEEWX_ROOT/util/init.d/weewx.redhat /etc/rc.d/init.d/weewx |
SuSE: | cp $WEEWX_ROOT/util/init.d/weewx.suse /etc/init.d/weewx |
Make sure the script is executable:
Debian/Ubuntu/Mint: | chmod +x /etc/init.d/weewx |
Redhat/CentOS/Fedora: | chmod +x /etc/init.d/rc.d/weewx |
SuSE: | chmod +x /etc/init.d/weewx |
Create symbolic links in the run level directories:
Debian/Ubuntu/Mint: | update-rc.d weewx defaults 98 |
Redhat/CentOS/Fedora: | chkconfig weewx on |
SuSE: | /usr/lib/lsb/install_initd /etc/init.d/weewx |
Weewx will now start automatically whenever your system is booted. You can also manually start, stop, and restart the weewx daemon:
sudo /etc/init.d/weewx start sudo /etc/init.d/weewx stop sudo /etc/init.d/weewx restart
By default, the scripts are designed to have weewx run at run levels 2, 3, 4 and 5. Incidentally, a nice tool for setting run levels with Debian (Ubuntu, Mint) systems is sysv-rc-conf. It uses a curses interface to allow you to change easily which run level any of your daemons runs at. There is a similar tool on SuSE. From the start menu run the YAST Control Center, then look for Systems Services (Runlevel). Pick "Expert" mode to see the run levels.
You can also tell weewx to reread its configuration file without stopping by using the 'reload' option:
sudo /etc/init.d/weewx reload
Weewx logs many events to the system log. On Debian systems, this is /var/log/syslog, on SuSE, /var/log/messages. Your system may use yet another place. When troubleshooting the system, be sure to check it!
tail -f /var/log/syslog
Set the debug option in weewx.conf to generate many more checks and output more information. This can be useful for diagnosing problems and debugging.
debug = 1
The SQLite archive database used by weewx (nominally, weewx.sdb) is completely compatible with the database used by wview (usually called wview-archive.sdb), at least as of wview Version 5.2.X. The schema, and its semantics, is identical.
If you have data from wview, you can 'import' them into weewx by simply copying the SQLite database file. Assuming that the wview data are in file /var/wview/archive/wview-archive.sdb,
sudo /etc/init.d/weewx stop cd $SQLITE_ROOT mv weewx.sdb weewx.sdb.bak cp /var/wview/archive/wview-archive.sdb weewx.sdb sudo /etc/init.d/weewx start
Internally, within the weewx.sdb database, weewx 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 wview archive contains more than a month or two of data.
On my modest 500 MHz fit-PC Slim with 512 MB of memory it took a little over 4 minutes for a year and a half (25 MB) of data.
The MySQL archive database used by wview is "almost" compatible with weewx. The one difference is that in wview, the column interval is named arcInt (presumably because interval is a keyword in MySQL, although it can still be used by surrounding the word with backquotes).
To change the column name to what weewx uses, namely interval, use the utility mysql and issue the command:
ALTER TABLE your-wview-archive-name CHANGE arcInt `interval` INTEGER NOT NULL;
where your-wview-archive-name is the name of your wview archive database. Note that the word interval is surrounded by backquotes.
Then in the [Databases] section of weewx.conf, replace the name of the database with whatever your installation of wview used your-wview-archive-name:
[[archive_mysql]] host = ... user = ... database_name = your-wview-archive-name
The reports generated by weewx can be served by a web server running on the same computer as weewx. Here's how.
First, install a web server on the computer on which weewx is running. For example, on Debian systems:
sudo apt-get install apache2
Then, if weewx was installed from DEB or RPM package, simply enter the weewx URL in a web browser in order to see your webpages.
http://localhost/weewx
Alternatively, if weewx was installed using setup.py, copy the Apache configuration snippet that comes with weewx to the apache configuration directory, then restart Apache:
sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d sudo /etc/init.d/apache2 restart
Be sure that the path in the Apache configuration snippet matches the HTML_ROOT defined in the weewx configuration file.
Alias /weewx /home/weewx/public_html <Directory /home/weewx/public_html> Options FollowSymlinks AllowOverride None Order allow,deny Allow from all </Directory>
Then open the weewx URL in a web browser:
http://localhost/weewx
Use the FTP or RSYNC 'reports' to upload to a web server. Either of these will copy everything from the HTML_ROOT directory to a location on the remote server on which the web server is running.
To backup a weewx installation, make a copy of the weewx configuration, weather data, skins/templates, and custom code. In most cases these can be copied while weewx is running. The location of these files depends on which method was used to install weewx.
It is not necessary to backup the images and HTML files generated from templates, since weewx will easily create those again. This includes the NOAA reports in some skins.
Save the weewx.conf file.
setup.py: | /home/weewx/weewx.conf |
DEB/RPM: | /etc/weewx/weewx.conf |
Meteorological data are saved in the archive database. For a SQLite configuration, simply save the weewx.sdb file. For a MySQL configuration, save a dump of the archive database.
setup.py: | /home/weewx/archive/weewx.sdb |
DEB/RPM: | /var/lib/weewx/weewx.sdb |
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.
setup.py: | /home/weewx/skins |
DEB/RPM: | /etc/weewx/skins |
Save the contents of the user 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.
setup.py: | /home/weewx/bin/user |
DEB/RPM: | /usr/share/weewx/user |
To restore from backup, do a fresh install of weewx then replace the default files with those from a backup. Then start weewx.
This section lists some common problems installing and running weewx. If you are still stuck, be sure to:
debug = 1
sudo tail -f /var/log/syslog
sudo $BIN_ROOT/weewxd $CONFIG_ROOT/weewx.conf
If you are having problems keeping your weather station up for long periods of time, here are some tips, in decreasing order of importance:
If you are unable to get anything out of weewx 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 minicom because it can be run from through a simple TTY connection. The utility screen also works well. For example:
minicom -b 19200 -D /dev/ttyUSB0
or, using screen:
screen /dev/ttyUSB0 19200
Then type in TEST, all in capital letters. It will not echo the characters. Then hit the <enter> key. It should echo back TEST.
If this works, then you have established connectivity with the Davis and the problem must lie elsewhere.
The USB converter used in the Davis VantagePro is known to have some "noise" problems. The symptom is that the Linux kernel will disconnect from your old USB port claiming "EMI noise", and reconnect to a new and different port, where weewx cannot find it. Here is a typical log output:
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
In this example, the VantagePro was connected to /dev/ttyUSB0, but then reconnected to /dev/ttyUSB1.
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.
However, there is one final step that you can take to really harden up your system: install a udev script that will create a symbolic link to the VantagePro USB port, whatever it might be. With this approach, if the port jumps from ttyUSB0 to ttyUSB1, the symbolic link will follow it. You just specify port /dev/vpro in the configuration file weewx.conf and be done with it.
Use a udev rule to ensure that a USB device always appears at the same location such as /dev/vpro instead of /dev/ttyUSB2
For example, for my VantagePro2 weather station, I have installed a file /etc/udev/rules.d/vpro.rules on my fit-PC that looks like this:
# Automount the VantagePro2 to port /dev/vpro. # Install in /etc/udev/rules.d/vpro.rules # ACTION=="add", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", SYMLINK+="vpro"
This rule says that when the USB port is plugged in (action add), and it has an attribute with name interface that is equal to "CP2102 to UART Bridge Controller", then add a symbolic link for its physical port to /dev/vpro.
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 vpro, but also sets the chmod permissions to 666, allowing any user to read or write to it.
# 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"
Your devices may, and probably will, have different identifiers!! I can recommend this article, "Writing udev rules," for how to find and write an appropriate udev rule for your controller. (Note, however, that this article uses the old udevinfo command, rather than the newer udevadm command.) In particular, run the command
# udevadm info --attribute-walk --path $(udevadm info --query=path --name=/dev/ttyUSB0)
where /dev/ttyUSB0 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 udev. While the first example script above used a rule that matched attribute interface, others are possible. For example, the second example, for the serial-to-USB cable, chose to match the attribute product.
Once you have installed your udev rule, you can then set port=/dev/vpro in weewx.conf, confident that it will always point to your weather station, no matter which USB port it is actually attached to!
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: weewx will recover.
Or, at least, it should!
If you are getting a symptom that everything appears normal, that is HTML is getting generated and getting FTP'd to your webserver (look in the log to be sure!), but your web pages are not being updated, it could be because the data on board your console has gotten garbled. The way the Davis Vantage series works is that the software (weewx in this case) asks the console for all archive data "since" some time. The console then downloads the records one at a time. After it gets to the very last one, the memory wraps around, and the timestamp will suddenly jump backwards in time a couple weeks — this how the software knows it has downloaded the last record and so it stops.
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 weewx figures that is it: there is no more data.
I have received reports from a couple of users who have had this problem. There seems to be two fixes:
$BIN_ROOT/wee_config_device --clear
See also the section Dumping the logger memory, which may help you avoid data loss.
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 DSI-01 serial interface. That is, it is a pure serial connection to the console, with no onboard memory.
For these interfaces, you must set record generation to software. Without this information, weewx 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:
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
See the section on option record_generation.
Running weewx on a Raspberry Pi has become very popular. You'll have to look elsewhere for instructions on setting up your RPi, but there are a few very common problems with setting them up.
You must run NTP on your RPi, and you must make sure it starts and updates the time before weewx runs.
The reason is that the RPi does not have an onboard clock. If you lose power and, say, an hour later it comes back, your RPi will simply pick up where it left off — one hour behind. The symptom that something is amiss is that everything will appear to be running normally, but your webpage will not get updated (at least, until the length of the power failure has elapsed). Here's one user's nice analysis of the problem.
What this means is that it is not enough to simply run the weewx daemon. You need some way of delaying its start until NTP is not only up and running, but has contacted a time server and corrected the RPi's clock.
Several users are working on a solution to this problem. Perhaps you'll be the one to figure it out?!
The SD card supplied with most RPis seems to be of very low quality. Make sure you use a good, Class 10 card. User William Phelps reports, "You can usually spot a failing card by watching the kernel I/O wait time. Once the card starts to go, the I/O wait time will increase significantly."
Many Raspbian versions of Debian do not seem to include an FTP client. You may have to install this if you plan on using FTP.
sudo apt-get install ftp
A lot of problems with the RPi seem to center around inadequate power supplies. Many weather stations can demand a lot of current through their USB connection. Make sure your RPi can supply it, either by getting a good power supply (I use a Innogear 1.5 A supply, which costs all of $5.50 from Amazon), or, alternatively, by using a powered USB hub.
The RPi is astonishingly powerful for its size, but it does have its limitations. If you plan on running a webserver on it, perhaps to serve your home, then use a lightweight one, such as lighttpd or nginx. Apache works, but it uses far more memory. In my tests:
Webserver | VIRT | RES |
Apache | 222 Mb | 3 Mb |
lighttpd | 7 Mb | 2 Mb |
nginx | 11 Mb | 1.7 Mb |
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:
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
The exact error may vary, but the thing to look for is the "could not detach kernel driver" 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.
More details about Fine Offset lockups can be found in the Wiki.
Most hardware with data-logging includes a parameter to specify the archive interval used by the logger. If the hardware and driver support it, weewx will use this interval as the archive_interval. If not, weewx will fall back to the archive_interval specified in [StdArchive]. The default fallback value is 300 seconds (5 minutes).
If the hardware archive interval is large, it will take a long time before anything shows up in the weewx 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 weewx 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.
Since reports are generated when a new archive record arrives, a large archive interval means that reports will be generated infrequently.
If you want data and reports closer to real-time, use the wee_config_device utility to change the interval.
This section covers some common software configuration problems.
As it is running, weewx periodically sends status information, failures, and other things to your system's logging facility. They typically look something like this:
-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
The location of this logging file varies from system to system, but it is typically in /var/log/syslog, or something similar.
However, some systems default to saving only warning or critical information, so the info messages from weewx may not appear. If this happens to you, check your system logging configuration. On Debian systems, look in /etc/rsyslog.conf. On Redhat systems, look in /etc/syslog.conf.
These are errors in the configuration file. Two are very common. Incidentally, these errors are far easier to diagnose when weewx is run directly than when it is run as a daemon.
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:
[Reports] [[FTP]] ... (details elided) user = fred server = ftp.myhost.com password = mypassword server = ftp.myhost.com # OOPS! Listed it twice! path = /weather ...
Generally, if you encounter this error, the log file will give you the line number it happened in:
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.
This is a very similar error, and is caused by a misformed section nesting. For example:
[Reports] [[FTP]]] ... (details elided)
Note the extra closing bracket on the subsection FTP.
If everything appears normal except that you have no barometer data, the problem may be a mismatch between the unit system used for service StdConvert and the unit system used by service StdQC. For example:
[StdConvert] target_unit = METRIC ... [StdQC] [[MinMax]] barometer = 28, 32.5
The problem is that you are requiring the barometer data to be between 28 and 32.5, but with the unit system set to METRIC, the data will be in the range 990 to 1050 or so!
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:
[StdConvert] target_unit = US ... [StdQC] [[MinMax]] barometer = 950, 1100, mbar
If you get errors of the sort:
Apr 12 05:12:32 raven reportengine[3074]: filegenerator: Caught exception "<class 'NameMapper.NotFound'>" Apr 12 05:12:32 raven reportengine[3074]: **** Message: "cannot find 'fubar' in template /home/weewx/skins/Standard/index.html.tmpl" Apr 12 05:12:32 raven reportengine[3074]: **** Ignoring template and continuing.
you have a tag in your template that weewx does not recognize. In this example, it is the tag $fubar in the template /home/weewx/skins/Standard/index.html.tmpl.
The symptom is many LOOP errors and unreliable downloading of archive records. Your log may look like this:
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
If you look closely at the log above, you'll see that there are multiple instances of weewx 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.
The cure is simple: kill all but one of them. Or, better yet, kill them all, then do a restart.
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.
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.
Change the line_gap_fraction option in skin.conf to control how much time is considered a break in data.
As for the archive interval, check the log file for an entry like this soon after weewx starts up:
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
In this example, interval in weewx.conf is 5 minutes, but the station interval is 30 minutes. When the interval in weewx.conf does not match the station's hardware interval, weewx defers to the station's interval.
Use the wee_config_device utility to change the station's interval.
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.
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.
If you frequently see anomalous data, first check the hardware.
To keep bad data from the database, add a quality control (QC) rule such as Min/Max bounds. See the QC section for details.
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:
cp $SQLITE_ROOT/weewx.sdb $SQLITE_ROOT/weewx-YYMMDD.sdb
sqlite3 $SQLITE_ROOT/weewx.sdb sqlite> select dateTime,outTemp from archive where outTemp > 1000;
sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000;
sqlite> update archive set windSpeed=NULL where outTemp > 1000; sqlite> update archive set outTemp=NULL where outTemp > 1000;
This seems to be a problem with the Raspberry Pi, when using SQLite. There is no analogous problem with MySQL databases. You will see errors in the system log that looks like this:
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)
Feb 12 07:11:06 rpi weewx[20930]: **** OperationalError: database is locked
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.
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.
There are a few possible fixes:
None of these 'fixes' are very satisfying and we're trying to come up with a more robust solution.
If you modify the SQLite archive database using an editing tool, occasionally strings will get embedded in it, causing weewx to raise an exception. This is only a problem with SQLite. There is no analogous problem with MySQL databases. You will see errors in the system log that look something like this:
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
Dec 31 17:01:06 arm weewx[18141]: **** TypeError: unsupported operand type(s) for +=: 'float' and 'unicode'
Dec 31 17:01:06 arm weewx[18141]: **** Exiting.
The problem is that a unicode null string u'' got entered where a NULL should be. The utility wee_config_database can fix this. Run it with the option --string-check to search for these embedded strings. Add the option --fix to have the utility fix them:
$BIN_ROOT/wee_config_database $CONFIG_ROOT/weewx.conf --string-check --fix
Weewx should work with Python version 2.5, but it may take some fiddling to get it to work. Later versions of Python come with pysqlite and PIL already installed. You may have to do this yourself. Here is how to do it with easy_install, but you may be able to use apt-get or other tools, depending on your operating system.
sudo easy_install pysqlite sudo easy_install PIL
Various possible complications:
apt-get install libsqlite3-devThen rerun the installation of pysqlite.
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 installedThis 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 skin.conf), 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.
# Install the Freetype library: sudo apt-get install libfreetype6-dev # Make sure it, and the zlib library, are visible to easy_install sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib sudo ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib # Remove the PIL paths sudo easy_install -m PIL # Remove PIL itself: sudo rm -r /usr/lib/python2.5/site-packages/PIL* # Now rebuild PIL, this time with the right libraries sudo easy_install PILYou may have to fiddle with the exact path used in the symbolic link. A helpful tool is the Unix tool find. For example, the following uncovered where my freetype library was hiding:
find /usr/lib -name "libfreetype*" -print
User Fabian reports that the following had to be done to get the VantagePro2 working under FreeBSD:
I needed the uslcom Driver for the usb/rs232 Adapter used by my vantage. Also I had to reset the memory of the weatherstation.
Loading the Driver:
Put uslcom_load="YES" in /boot/loader.conf (to load it as module).
Which gives here an output like:
uslcom0: <CP2102 USB to UART Bridge Controller> on usbus1
And put in weewx.conf:
port = /dev/cuaU0
User Mike has written a very nice guide on how to install weewx on Apple's Mavericks operating sytem.
If your plots have strange looking symbols for units, such as degrees Fahrenheit (°F), that look something like this:
Then the problem may be that you are missing the fonts specified for the option unit_label_font_path in your skin.conf file and, instead, weewx is substituting a default font, which does not support the UTF-8 character necessary to make a degree sign. Look in section [ImageGenerator] for a line that looks like:
unit_label_font_path = /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf
Make sure that the specified path (/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf 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:
sudo apt-get install ttf-freefont sudo fc-cache -f -v
The first command installs the "Truetype" fonts, the second rebuilds the font cache. If your system does not have fc-cache command, then install it from the fontconfig package:
sudo apt-get install fontconfig
If none of this works, or if you are on a different operating system, then you will have to change the option unit_label_font_path to point to something on your system which does support UTF-8 characters.
This section is not required to get started, but it should help you understand a bit more about how weewx works.
The primary design goals of weewx are:
To meet these goals, the following strategies were used:
While weewx is nowhere near as fast at generating images and HTML as its predecessor, wview (this is partially because weewx uses fancier fonts and a much more powerful templating engine), it is fast enough for all platforms but the slowest. I run it regularly on a 500 MHz machine where generating the 9 images used in the "Current Conditions" page takes just under 2 seconds (compared with 0.4 seconds for wview).
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 weewx user.
All writes to the databases are protected by transactions. You can kill the program at any time (either Control-C if run directly or "/etc/init.d/weewx stop" if run as a daemon) without fear of corrupting the databases.
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.
Any "hard" exceptions, that is those that do not involve network and console timeouts and are most likely due to a logic error, are logged, reraised, and ultimately cause thread termination. If this happens in the main thread (not likely due to its simplicity), then this causes program termination. If it happens in the report processing thread (much more likely), then only the generation of reports will be affected — the main thread will continue downloading data off the instrument and putting them in the database. You can fix the problem at your leisure, without worrying about losing any data.
This is a glossary of terminology used throughout the code.
Name | Description |
archive record | A record obtained from the SQL database |
archive packet | A packet obtained from the store on the weather station. For example, with a Davis VantagePro, it is obtained using the DMPAFT command. |
datetime | An instance of the Python object datetime.datetime. Variables of type datetime usually have a suffix _dt. |
db_dict | A dictionary with all the data necessary to bind to a database. An example for SQLite would be {'driver':'db.sqlite', 'root':'/home/weewx', 'database_name':'archive/weewx.sdb'}, an example for MySQL would be { 'driver':'db.mysql', 'host':'localhost', 'user':'weewx', 'password':'mypassword', 'database_name':'weewx'}. |
epoch time | Sometimes referred to as "unix time," or "unix epoch time." The number of seconds since the epoch, which is 1 Jan 1970 00:00:00 UTC. Hence, it always represents UTC (well... after adding a few leap seconds. But, close enough). This is the time used in the databases and appears as type dateTime in the SQL schema, perhaps an unfortunate name because of the similarity to the completely unrelated Python type datetime. Very easy to manipulate, but it is a big opaque number. |
loop packet | A packet with the current observations. For example, with a Davis VantagePro, it is obtained using the LOOP command. |
observation type | A type that can be used in the presentations. This is generally all of the SQL types, plus calculated data (such as rms or vecavg). |
packet | Something obtained from the weather station. Frequently uses a complex internal encoding, so it requires some processing to be useful. |
record | Something obtained from the SQL database. |
SQL type | A type that appears in the SQL database. This usually looks something like outTemp, barometer, extraTemp1, and so on. |
time stamp | A variable in unix epoch time. Always in UTC. Variables carrying a time stamp usually have a suffix _ts. |
tuple-time | An instance of the Python object time.struct_time. 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 time 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 _tt. |
unit system | A complete set of units used together. Either US, METRIC, or METRICWX. |
value tuple | 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 (21.2, 'degree_C', 'group_temperature'). |
In general, there are three different areas where the unit system makes a difference.:
The general strategy is that measurements are converted by service StdConvert 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.
The Python special value None is used throughout to signal a missing data point. All functions expect it.
However, the time value must never be None. This is because it is used as the primary key in the SQL database.
Weewx stores all data in UTC (roughly, "Greenwich" or "Zulu") time. However, usually one is interested in weather events in local time and want image and HTML generation to reflect that. Furthermore, most weather stations are configured in local time. This requires that many data times be converted back and forth between UTC and local time. To avoid tripping up over time zones and daylight savings time, weewx 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.
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:
next_ts = last_ts + 10800
But, if one wanted to plot something for every 3 hours in local time (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 last_ts and the next three hours and, if so, make the necessary adjustments. This is generally what wview does. Weewx 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:
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()))
Other time conversion problems are handled in a similar manner.
© Copyright Tom Keffer