wview is a collection of linux/unix daemons which interface with a supported weather station to retrieve archive records (if generated by the station) and current conditions. If the station does not generate archive records internally, wview will auto-generate archive records based on the sensor readings collected for that interval. The archive records and High/Low (HILOW) data are stored in SQLite3 databases. At a configurable interval, wview will utilize the archive history and current conditions to generate weather images (buckets, dials and graphs) and HTML web pages based on user-configurable HTML templates. XML, PHP, Perl, Python, etc. template files can also be defined using wview meta-tags which will be replaced with current values when generated by wview.
Features:
wview should work on any system with a unix or unix derivative operating system. These include: linux, Mac OSX (Darwin), FreeBSD, NetBSD, Solaris. Your platform should support ethernet and either RS-232 or USB for the station interface.
wview and some utility install and upgrade scripts can be obtained from the wview Sourceforge Homepage.
The wview user's group is hosted on Google Groups:
wview User's Group
To report problems or vote on enhancements you can use the
wview Mantis Database.
To use wview, you must:
Run Environment:
There are several configuration variables which affect the location of the
wview run environment. "--prefix=xxx" (defaults to /usr/local for source
builds) is the top-level root for wview install. If "--sysconfdir=xxx" is
given to the configure script, it will override the $prefix value for
location of the configuration files. If "--localstatedir=xxx" is given, it
will override the $prefix value for location of the data files for wview.
Most source installs will want to use the default prefix "/usr/local" (by
not specifying any location parameters to configure).
There are two file system installation locations of importance for wview.
The configuration "tree" is found at: $prefix/etc/wview and the data "tree"
is located at: $prefix/var/wview. The configuration tree includes the
SQLite3 configuration database, file generation configuration including
templates and several file to support SQL export activities. The data tree
contains the generated web site (img), all archived weather data (archive)
and NOAA files.
Each installation section below will indicate the default locations for
these trees.
The Debian Advanced Packaging Tool (APT) is the most comprehensive and
mature unix package management system in existence. APT is the compelling
reason many linux users (such as me) use Debian or a Debian derivative for
their linux distribution of choice.
radlib and wview are now available in the wviewweather.com APT repository.
You may also install radlib and wview from source.
The easiest method to install wview on a debian or ubuntu/kubuntu server is to use the debian packages provided by the wviewweather.com APT repository:
|
For debian squeeze: deb http://www.wviewweather.com/apt/squeeze squeeze main deb-src http://www.wviewweather.com/apt/squeeze squeeze main For debian wheezy: deb http://www.wviewweather.com/apt/wheezy wheezy main deb-src http://www.wviewweather.com/apt/wheezy wheezy main For ubuntu/kubuntu lucid: deb http://www.wviewweather.com/apt/lucid lucid main deb-src http://www.wviewweather.com/apt/lucid lucid main For ubuntu/kubuntu precise: deb http://www.wviewweather.com/apt/precise precise main deb-src http://www.wviewweather.com/apt/precise precise main For ubuntu/kubuntu quantal: deb http://www.wviewweather.com/apt/quantal quantal main deb-src http://www.wviewweather.com/apt/quantal quantal main For ubuntu/kubuntu raring: deb http://www.wviewweather.com/apt/raring raring main deb-src http://www.wviewweather.com/apt/raring raring main For ubuntu/kubuntu saucy: deb http://www.wviewweather.com/apt/saucy saucy main deb-src http://www.wviewweather.com/apt/saucy saucy main |
|
apt-get method: #> sudo apt-get update #> apt-cache search wview (wview should be listed now) #> sudo apt-get install wview (this will install radlib and any other missing prerequisites) (when done, wview will be fully installed, configured and running as the station simulator) (you can stop it any time using "sudo /etc/init.d/wview stop") |
|
#> sudo wviewcleardata (this will purge all archive records, delete the HILOW, history and NOAA databases) (leaving a clean weather data environment for your station) |
|
wview Run Environment: Configuration: /etc/wview Data: /var/lib/wview wviewmgmt: /var/lib/wviewmgmt linked at /var/www/wviewmgmt Weather web site: /var/lib/wview/img linked at /var/www/weather |
|
#> sudo apt-get update (this updates the package list) #> sudo apt-get -u upgrade (this upgrades any out of date packages, including wview or radlib) (if you are asked if you want to replace certain "config" files, it is safe to say "Y") |
|
#> sudo mkdir -p ~/wview-save #> sudo mkdir -p ~/wview-save/etc #> sudo mkdir -p ~/wview-save/var #> sudo /etc/init.d/wview stop #> sudo rm -rf /usr/local/var/wview/archive/wview-history.sdb #> sudo rm -rf /etc/init.d/wview #> sudo cp -rf /usr/local/etc/wview ~/wview-save/etc #> sudo cp -rf /usr/local/var/wview ~/wview-save/var #> sudo rm -f /var/www/weather (this should be a symbolic link) #> sudo rm -rf /var/www/wviewmgmt (this should be a symbolic link) #> cd [radlib_old_source_location] (the old distro source directory, typically /usr/local/src/radlib-X.Y.Z) #> sudo make uninstall #> cd [wview_old_source_location] (the old distro source directory, typically /usr/local/src/wview-X.Y.Z) #> sudo make uninstall #> sudo apt-get install wview (if it asks about replacing /etc/init.d/wview, say "Y") (at this point the simulator will be configured and running) #> sudo /etc/init.d/wview stop #> sudo cp -f ~/wview-save/var/wview/archive/*.* /var/lib/wview/archive #> sudo cp -rf ~/wview-save/etc/wview/* /etc/wview #> sudo wviewconfig (or use wviewmgmt to update the generation and html paths) HTMLGEN_IMAGE_PATH - /var/lib/wview/img HTMLGEN_HTML_PATH - /etc/wview/html (You may need to update Alarm or FTP or SSH paths as well) #> sudo /etc/init.d/wview start |
| #> sudo apt-get remove wview |
| #> sudo apt-get --purge remove wview |
Just be aware that "purge" removes everything. It will prompt you first
to make sure that is what you want to do. It is pretty idiot-proof.
The wview distribution includes a Debian install script and an upgrade
script which greatly simplify installing and keeping wview up to date
the old-fashioned way: from source. The latest versions of these scripts
can always be downloaded from Sourceforge:
wview-install-debian
wview-update
There is no need to download or build wview or its prerequisites directly
as the install script will take care of all that for you.
The wview-update script can be used for any unix system with tar, wget and
a reasonable build environment installed.
To use the wview-install-debian script:
| #> chmod +x wview-install-debian |
| #> sudo ./wview-install-debian |
There will be a few choices to make along the way. Answer "yes" to any
package management questions.
The script will invoke wviewconfig and wviewhtmlconfig to do initial
configuration for your station, environment and desired features. These
will also require input in order to proceed.
|
wview Run Environment: Configuration: /usr/local/etc/wview Data: /usr/local/var/wview wviewmgmt: /usr/local/var/wviewmgmt linked at /var/www/wviewmgmt Weather web site: /usr/local/var/wview/img linked at /var/www/weather |
To update wview installations of version 5.4.0 or later:
| #> chmod +x wview-update |
| #> sudo /etc/init.d/wview stop |
| #> sudo ./wview-update |
| #> sudo /etc/init.d/wview start |
The MacPorts package management system for Mac OSX (Darwin) includes source
packages for radlib and wview. This greatly simplifies installing wview and
keeping it up to date.
Note: For a step-by-step procedure to install wview and all prerequisites
(including configuration of apache2 and PHP) please see the excellent
tutorial:
Mac OS X (10.6.x) Installation Instructions (Advanced)
To install wview:
| #> sudo port -d selfupdate |
| #> sudo port upgrade outdated |
| #> sudo port install wview |
This will install all prerequisites and wview.
|
wview Run Environment: Configuration: /opt/local/etc/wview Data: /opt/local/var/wview wviewmgmt: /opt/local/var/wviewmgmt Weather web site: /opt/local/var/wview/img |
To update OSX wview installations:
| #> sudo /sbin/SystemStarter stop "wview" |
| #> sudo port -d selfupdate |
| #> sudo port upgrade outdated |
| #> sudo /sbin/SystemStarter start "wview" |
If you are going to install from source, please take care to install the
prerequisites and follow these instructions carefully.
Note:
Note: Some of these libraries may be represented as "-dev" or "-devel" or similar in your package management utility, i.e., "libcurl-dev". If they are, you should install the dev version in order to get the development libraries that radlib/wview needs.
For purposes of these instructions, the following conventions are used:
[wview_bld_path] is the staging area for building wview (i.e., /usr/local/src).
wview-x.y.z is the version of wview you are installing.
|
#> cd [wview_bld_path] #> tar zxvf wview-x.y.z.tar.gz |
| #> cd [wview_bld_path]/wview-x.y.z |
--prefix (default: /usr/local) Controls the installation root for wview.A typical new installation:
--prefix=/ --bindir=/usr/bin --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib Configure options to use when building from source after a Debian APT installation. This places all binaries and support files in the same locations as the Debian package. This is handy when modifying source code or testing proposed releases.
| #> ./configure |
| #> ./configure |
| #> make |
| #> sudo make install |
Make sure it is executable:
SuSE cp wview-x.y.z/examples/SuSE/wview /etc/init.d FreeBSD cp wview-x.y.z/examples/FreeBSD/wview /etc/rc.d FedoraCore cp wview-x.y.z/examples/FedoraCore/wview /etc/rc.d/init.d Debian cp wview-x.y.z/examples/Debian/wview /etc/init.d
Create a symbolic link in the runlevel directory you boot your server:
SuSE chmod +x /etc/init.d/wview FreeBSD chmod +x /etc/rc.d/wview FedoraCore chmod +x /etc/rc.d/init.d/wview Debian chmod +x /etc/init.d/wview
SuSE cd /etc/init.d/rc3.d; ln -s ../init.d/wview S99wview FedoraCore cd /etc/rc.d/rc3.d; ln -s ../init.d/wview S99wview Debian update-rc.d wview defaults 99
|
wview Run Environment: Configuration: /usr/local/etc/wview Data: /usr/local/var/wview wviewmgmt: /usr/local/var/wviewmgmt linked at /var/www/wviewmgmt Weather web site: /usr/local/var/wview/img linked at /var/www/weather |
See the scripts in the cross-compile folder for "./configure" alternatives.
This directory contains example configure scripts for cross compilation. libz,
libpng, libgd, librad and wview scripts are included (and should be built in
that order). Use these scripts instead of "./configure" to configure these
libraries for cross compilation. These scripts configure for arm-linux
targets but can be edited for other targets.
Note: The config-radlib-arm-linux and config-wview-arm-linux scripts will accept
up to 3 additional configure options.
The general build sequence is:
|
#> ./config-[pkgname]-arm-linux #> make #> sudo make install |
All libs and applications are installed in the toolchain root, defined in the
config scripts.
The general build order is:
libz
libpng
libgd2
libreadline5
libsqlite
libusb
librad
wview
If your build fails it is almost certainly because you are missing a
prerequisite. Messages such as "unable to open gd.h" followed by a host
of other errors means you are missing libgd2-dev. It is not sufficient
to have the run time library only installed (libgd2), you also need
the development package installed.
Also note that when a library or other dependency is missing, the first
error message is generally the one which will tell you what you are
missing.
wview configuration is often where users cause themselves problems. wview is extremely configurable but with that flexibility comes more complexity and more opportunities to misunderstand the purpose of the parameters and their range of possible values. It is best to not change a parameter's value until you are confident you know what/why you are doing it. New wview installations default to the station simulator and a base working configuration. Use that as a starting point and limit the number of parameters you change simultaneously until you become more comfortable with wview.
wview configuration can be accomplished from the command line (wviewconfig)
or using the web interface (wviewmgmt). wviewmgmt requires a working http
server with PHP and sqlite3 support. It is the easiest method once the
http/PHP/SQLite3 prerequisites are installed and confirmed. Many linux
distributions come with apache2+PHP+SQLite3 support already enabled.
The command line interface (CLI) for wview configuration is wviewconfig. It is installed when wview is installed.
|
#> sudo wviewconfig (this will start an interactive session - take your time) |
wviewmgmt is an html/java/php web site designed to provide a graphical interface for wview configuration. It also provides system status information.
|
Local server access: Enter the URL: http://localhost/wviewmgmt/login.php The default password is "wview" (you should change this). Remote server access: Enter the URL: http://[remote_host_or_IP]/wviewmgmt/login.php |
|
#> sudo ln -s $prefix/var/wviewmgmt [your_document_root]/wviewmgmt (of course replacing $prefix and [your_document_root] appropriately) |
|
Add the http user to the sudo group: #> sudo adduser www-data sudo Update /etc/sudoers to allow start/stop control: #> sudo visudo (Add the following lines to the bottom of the file): Cmnd_Alias WVIEW = /etc/init.d/wview www-data ALL= NOPASSWD: WVIEW |
There is only one wviewmgmt user so only a password is required to log in. By default the password is "wview".
This page displays the current status (running/not running) of wview as well as certain database record counts. You may also change the wviewmgmt password on this page.
This page allows you to select which wview services to be run. If
you disable all services, you will have an archiving-only wview
server which stores archive and HILOW data which could be retrieved
periodically for post processing.
It also allows system log verbosity to be selected by service.
You can configure which wview processes are monitored by the wview
process monitor.
This page allows the configuration of the station type and interface
settings. Station presets, timing parameters and location can be
configured. See Chapter 4: Station Setup for
station-specific information.
Note: If you have a WeatherlinkIP datalogger, you will need to select a static
IP address and configure the datalogger with it. See the section
Davis Vantage Pro for more details on this.
Station-specific Parameters: Some parameters are specific to a particular
station type. They are displayed or hidden based on the station type selected.
Station name and location can be set for file generation. Other configuration settings for generation and certain text settings are also configured here.
Up to 10 alarms may be defined on this page.
This page allows configuration for FTP export of generated files and images.
This page allows configuration for SSH export of generated files and images.
This page allows configuration for Citizens Weather Observer Program (CWOP) participation.
Weather Underground and Weather For You participation is configured on this page.
wview supports calibration of certain weather data to compensate for poor or faulty station sensors.
wview supports the export of the archive and HILOW databases to MySQL or PostgreSQL database servers.
This chapter describes any specific setup necessary for supported weather stations. It also describes any data tags that are unique for a given station.
The station simulator provides a way to demo the wview software without a
connection to an external station. It generates fake sensor readings so the
capabilities of wview including the weather web site generation can be
observed before going live with a station.
There is no specific setup for the station simulator.
The Virtual weather station allows you to run a wview server which
connects to another remote wview server via the datafeed TCP/IP socket
interface. Using the datafeed capabilities of the remote server, the virtual
server can generate files and web sites based on the remote station's data.
The remote station can be a low power device just running the station interface
process (wviewd) and the alarm process to serve the data to the virtual
wview server.
Note: It is imperative that both the remote and local wview servers are
running the same version of wview in case LOOP or ARCHIVE data definitions
have been modified.
To configure the virtual and remote servers (on the virtual server's
wviewmgmt Station page):
If you are installing a new VP console, there are a few initial settings
that you need to set up so that your weather station and wview operate
properly. Configuration of archive interval, station location (elevation,
latitude and longitude) and your desired rain season start month must be
set up before you start wview for the first time.
Below is a short description of each of these:
Archive Interval - this determines how often the VP console will generate
an archive record and store it in its internal memory.
These records are retrieved by wview from the console
and stored in the archive files (and the archive database,
if database archiving is enabled). The valid values are:
5, 10, 15, 30, 60 (minutes). Keep in mind that the
shorter the archive interval, the more records that will be
generated. More records means a shorter time span for
internal storage in the VP console memory and larger archive
files on the wview server disk (and larger database tables
if stored in a database). I use an archive interval of 5
minutes. TO AVOID HAVING TO DELETE ALL OF YOUR ARCHIVE DATA
LATER IN ORDER TO CHANGE THE ARCHIVE INTERVAL, IT IS VERY
IMPORTANT THAT YOU MAKE THIS CHOICE CAREFULLY AND NOT
CHANGE IT AFTER ARCHIVE DATA HAS BEEN STORED BY WVIEW.
This does NOT effect how often HTML files containing
current conditions are generated or the up to the minute
values they contain, this is controlled by the configuration
value "Generate Interval" on the wviewmgmt File Generation page. It will
effect the granularity of your charts for the last 24 hours.
Elevation - this is given in feet above (or below) sea level. This is
the recommended way to calibrate your barometer.
Lat/Long - this describes the location of your weather station.
Rain Season Start - this defines the first month of each year when yearly
rain totals will begin. Most people will use a value of
"1" here.
In order to set these parameters in the VP console, the "vpinstall" script is
provided with the wview distribution. Note that all of these can be configured
using the On-Screen VP console setup utility. After building and installing wview,
the vpinstall script can be found in ${exec-prefix}/bin (usually /usr/local/bin). It
is an interactive script which queries you for these initial values then uses the
vpconfig utility to commit them to your new VP console. Once completed, it is
advisable to wait 10 minutes or so before starting wview for the first time as
it takes the VP console a little while to "digest" the new settings, in
particular for the barometer.
WeatherlinkIP Datalogger Setup: If you have purchased the WeatherlinkIP
datalogger you will need to do some additional setup.
You must configure the WeatherlinkIP datalogger with a static IP address
on your local network segment. By default the datalogger is configured for
DHCP to obtain its IP address. The trick is to find what address it has been
assigned by your wired or wireless router. I used the utility on my router's
DHCP status page to find the IP address given to the datalogger after I had
connected the ethernet cable and powered it on. My intranet is
10.0.0.0/255.255.255.0 and the datalogger had been assigned 10.0.0.116.
Unfortunately the Vantage Vue console does not provide this information directly.
Once you have the IP address (a.b.c.d), enter the URL "http://a.b.c.d" in your favorite
browser. A very simple configuration screen is provided by the datalogger.
wview defaults to port 22222 for ethernet interfaces (as of 5.18.0) so no need
to modify it. Disable the "Upload to weatherlink.com" option and select
"Save Configuration". Then select "Use the following IP Address" and enter
your local network information. Select "Save IP Settings". You will need to
modify the URL to use the new static IP address you selected if you need to
get back to this configuration (which you probably will not). Remember the
IP address you selected so you can enter it in the station configuration page
of wviewmgmt. Note: you cannot access the datalogger configuration page while
any software is connected to the datalogger (wview or Weatherlink).
Extended Sensors: If you do not have a Vantage Pro Plus or Vantage Pro2
Plus and you haven't added additional sensors ($$) to your VP, then there
is no reason to enable Plus extended data on the wviewmgmt Station page or to
enable extended sensor generation in images.conf. You will only be
wasting CPU cycles as the extended sensors will not be populated
with anything meaningful.
The Vantage Pro Plus adds Solar Radiation, UV and Evapotranspiration (ET)
sensors with the potential to add other sensors. wview provides support
for historical charts (day, month and year) for the following VP Plus
sensors:
Solar Radiation
UV
ET
LeafTemp1
LeafTemp2
LeafWetness1
LeafWetness2
SoilTemp1
SoilTemp2
SoilTemp3
SoilTemp4
ExtraHumidity1
ExtraHumidity2
ExtraTemp1
ExtraTemp2
ExtraTemp3
SoilMoisture1
SoilMoisture2
SoilMoisture3
SoilMoisture4
wview also can generate current condition buckets for Radiation,
UV and ET. See the $prefix/etc/wview/images.conf file for optional
images which can be generated.
To enable extended sensors:
vpconfig Usage
Note 1: It is not advisable to use vpconfig to change the archive
interval or rain season start after the initial configuration
(using vpinstall). This will skew your rain season totals or
render your archived data unusable. If you do change the archive
interval after records have been stored by wview, you will need
to delete all archive data in $prefix/var/wview/archive/wview-archive.sdb
before restarting wview.
Note 2: You MUST stop wview before using vpconfig to view or change
settings!
Usage: vpconfig [station_dev] [command] [cmnd_args]
station_dev serial device the VP console is connected to:
FreeBSD: /dev/cuaa0 - /dev/cuaa4
Linux: /dev/ttyS0 - /dev/ttyS4
command command to execute, one of:
show
- retrieve and display VP console config
cleararchive
- clear the archive memory without changing the interval
setinterval [interval in minutes]
- set the archive interval (this clears the archive memory)
setelevation [elevation in feet]
- set the station elevation (feet) - use this to adjust barometer
setgain [0 for off, 1 for on]
- sets the gain of the radio receiver
setlatlong [latitude (negative for S)] [longitude (negative for W)]
- set the station latitude and longitude in tenths of a degree
setrainseasonstart [month (1-12)]
- set the month that the yearly rain total begins
The Vaisala WXT510 Weather Transmitter is a semi-professional instrument
about the size of a 2 liter bottle of Coke. Ultrasonic wind speed sensors,
non-tipping rain/hail measurement and low power are a few of the nice features
of this station. A very simple NMEA 0183 protocol implementation is provided
to retrieve the readings.
Preparing a WXT510 For wview:
The wxt510config utility simply autobauds the WXT510 until it finds the
station's current comm settings then resets the station to 19200-8-N-1.
wview startup will do the remaining initialization of the station.
To run it, determine what serial device your station is connected to,
then as root execute:
|
#> sudo wxt510config [station_dev] (where [station_dev] is something like /dev/ttyS0, /dev/cuaa0, /dev/ttyUSB0, etc.) |
Additional Data Tags (see examples/html/parameterlist.txt for tag format):
wxt510Hail
wxt510Hailrate
wxt510HeatingTemp
wxt510HeatingVoltage
wxt510SupplyVoltage
wxt510ReferenceVoltage
wxt510RainDuration
wxt510RainPeakRate
wxt510HailDuration
wxt510HailPeakRate
wxt510Rain
wxt510RainDurationMin
wxt510HailDurationMin
All Texas Weather Instruments stations with serial interface support
use the same simple protocol. wview autobauds the station each time it
starts so there is literally nothing to configure on the station's
console. wview should just work. The station should be configured to output
Imperial (US) units. Select the "TWI" station type when configuring wview.
The Oregon Scientific WMR918 Series (WMR918/928N/968) Personal Weather Station
is a low-cost consumer grade station.
There is no preparation required - just connect to your serial port and go!
Notes:
Additional Data Tags (see examples/html/parameterlist.txt for tag format):
wmr918Humid3
wmr918Pool
wmr918Tendency
wmr918WindBatteryStatus
wmr918RainBatteryStatus
wmr918OutTempBatteryStatus
wmr918InTempBatteryStatus
wmr918poolTempBatteryStatus
wmr918extra1BatteryStatus
wmr918extra2BatteryStatus
wmr918extra3BatteryStatus
The Oregon Scientific WMR88/WMR88A/WMR100/WMR100N/WMR200/WMRS200/RMS300/RMS600 Series Personal Weather Stations
are a low-cost consumer grade station. Select the "WMRUSB" station type
when configuring wview.
Like their older serial interface brethren, the WMR USB stations "blast out"
the sensor data as opposed to responding to commands like most reasonable
protocols for other stations. This fact coupled with the reality that the
USB HID interface allows no event-driven mechanism to know when there is
data ready to be read requires wview to poll the USB interface periodically in
order to receive the unsolicited sensor data packets from the console. wview
requires one packet from each sensor suite (Temp, Wind, Pressure and Rain) before
it can complete initialization. If one or more of your sensors is out of range,
the battery is weak or the sensor is malfunctioning, wview will not function
properly, i.e., it will not complete initialization.
There is no preparation required - just connect to your USB port and go!
Notes:
Additional Data Tags (see examples/html/parameterlist.txt for tag format):
The WMR stations can support up to 8 additional Temperature/Humidity sensors. The
tags will be populated if you have the sensors. Sensor IDs 0 and 1 are used for inside
and outside main sensors respectively, so WMR sensor ID 2 is stored in extraTemp
sensor 1, etc.
genExtraTemp1 - genExtraTemp8
genExtraHumidity1 - genExtraHumidity8
The La Crosse WS-2300 Series (WS-2300/2308/2310/2315) Personal Weather
Station is a low-cost consumer grade station. Although it is proud to be
wireless, it is best implemented "cabled" between the sensors and the
console. When cabled, it will update the console with new data every
8 seconds. When ran wirelessly, it updates on the order of minutes,
which is nearly useless for our purposes.
There is no preparation required - just connect to your serial port and
go!
Note: The La Crosse weather stations do not provide Rain Rate calculation,
so wview provides it for you. It is a very simple implementation which
looks at the last 5 minutes of rainfall and scales it up to one hour.
The Fine Offset 1080 Series (including Fine Offset: WH-1080, WH-1081; Watson: W-8681, WX-2008;
National Geographic: 265 NE; Elecsa: 6975, 6976; Ambient Weather: WS-1080, WS-1090, WS-2080;
Tycon: TP1080WC) Personal Weather Station is a low-cost consumer grade station.
The sensors will update no faster than once per minute so there is no need for
a faster "STATION_POLL_INTERVAL" than 60 seconds.
Note: The Fine Offset weather stations do not provide Rain Rate calculation,
so wview provides it for you. It is a very simple implementation which
looks at the last 5 minutes of rainfall and scales it up to one hour.
The Honeywell TE923W (including Hideki, Nexus, Mebus, Irox, Honeywell,
Cresta TE923, TE923W, TE821W, WXR810, DV928) Personal Weather Station is a
low-cost consumer grade station sold under many brand names and models
around the world. These have by far the best quality of sensors and console
for stations in the $200 or less category. It is highly recommended.
The sensor data from the console will update no faster than once per minute
so there is no need for a faster "STATION_POLL_INTERVAL" than 60 seconds.
Note: The TE923 weather stations do not provide Rain Rate calculation,
so wview provides it for you. It is a very simple implementation which
looks at the last 5 minutes of rainfall and scales it up to one hour.
Additional Data Tags (see examples/html/parameterlist.txt for tag format):
The TE923 stations can support up to 4 additional Temperature/Humidity sensors. The
tags will be populated if you have the sensors. Sensor ID 0 is used for the
primary outside temperature sensor, so sensor ID 2 is stored in extraTemp
sensor 1, etc.
genExtraTemp1 - genExtraTemp4
genExtraHumidity1 - genExtraHumidity4
genExtraTempBatteryStatus1 - genExtraTempBatteryStatus4
genExtraUVBatteryStatus
genExtraWindBatteryStatus
genExtraRainBatteryStatus
wview file generation is the process of replacing well-defined wview data tags (defined in parameterlist.txt) found in template files with their current values. These template files can be the HTML templates used for the default wview weather data web site or they can be any user-defined files containing one or more data tags (PHP, XML, etc.).
|
Configuration files referenced in this chapter: $prefix/etc/wview/html-templates.conf - lists the template files in $prefix/etc/wview/html to be generated. $prefix/etc/wview/images.conf - lists the weather images (buckets, graphs, dials) to be generated. $prefix/etc/wview/forecast.conf - configures forecast text for Vantage Pro stations. |
Generic File Generation
For any template file named "example.[ext]x" and listed in html-templates.conf,
wview will generate a file named "example.[ext]". For example, "myscript.phpx"
listed in html-templates.conf and found in $prefix/var/wview/html will have
all wview tags replaced and the resulting file will be named "myscript.php".
The resulting files are stored at the location specified on the wviewmgmt
File Generation page: "Generation Target Path".
Please note that if you are using FTP/SSH to transfer your files you will need
to add rules for any new extensions you want to support in wview configuration.
HTML File Generation and the wview Web Site
The default generation model for wview is to generate a weather web site
based on a series of HTML file templates and images defined in images.conf.
For any template file named "example.htx" and listed in html-templates.conf,
wview will generate a file named "example.htm".
Notes:
Changing HTML templates in $prefix/etc/wview/html does not require a
restart of wview. The changes you make will take effect at the next
htmlgend generation cycle.
Changing the config files images.conf, html-templates.conf and
(if supported) forecast.conf does not require a restart of wview
but does require a HUP signal to be sent to htmlgend to cause these
files to be re-read. Do this as follows
(this will also toggle log verbosity):
| #> sudo kill -s HUP `cat $prefix/var/wview/htmlgend.pid` |
| #> sudo wviewhtmlconfig |
Macro File Inclusion
wview supports template macro file inclusion in template files. The meta-tag
is !--include filename.xxx-- (brackets omitted). Any template macro file
that is to be included in one or more template files should be listed BEFORE
any templates including it in the $prefix/etc/wview/html-templates.conf
configuration file. There is no restriction on the levels of inclusion,
just be sure you specify macro templates early in the html-templates.conf
file. The wview default web site templates utilize several header macro
files.
Language
HTML template files (in $prefix/etc/wview/html) should be customized to
your language and your design preferences. The configuration file
html-templates.conf specifies the template files to be used for generation.
You may add or remove from this list as needed.
Weather image captions can be edited in the $prefix/etc/wview/images.conf
file for your language preferences.
Metric Units
The configuration parameter on the File Generation Page "Enable Metric
Units For Generation?" allows configuration of metric units. If set to
"yes" it will cause wview to output all images (buckets and charts) as
well as all values for HTML tags in metric units.
The units are:
Temperature ........... Celsius
Barometer ............. Millibars
Wind Speed ............ Kilometers per hour
Rain .................. Millimeters or Centimeters
images.conf can be edited to translate the English labels, titles, and
units to any language. By editing this file and the HTML template files,
any language can be supported by wview. In fact one can easily switch
back and forth between US and metric units by toggling this configuration
parameter and restarting wview.
Note:
All weather data in the SQLite3 database is still stored in US format - the
conversions are only done for real time image and HTML file generation.
XML and RSS Feed
XML templates should be named "*.xtx" and placed in $prefix/etc/wview/html.
An example RSS feed template is included in the distro:
$prefix/etc/wview/html/wxrss.xtx. An href to it is included in all home
page template examples so the RSS feed may be discovered while visiting
your home page. wxrss.xtx should be edited for your site.
Forecast Support
The Vantage Pro stations produce a forecast rule value and an icon specifier.
The data tags are !--forecastRule-- and !--forecastIcon-- (brackets omitted)
respectively. The configuration file forecast.conf allows the user to
define the icon files and text associated with the forecast rules. See
the example forecast.conf file for details. The icon tag will be replaced
by an image html construct pointing at the appropriate icon image file.
The rule tag will be replaced by the corresponding text string defined in
forecast.conf. Because these capabilities require 35 KB or more of memory
(and I think the VP forecasts are hokey), they are disabled by default.
To enable them, rename the file $prefix/etc/wview/forecast.conf-no-forecast
to $prefix/etc/wview/forecast.conf. You must restart wview for this change
to take effect.
Generic Tag Generation
The template file $prefix/etc/wview/html/parameterlist.htx is provided as
an example of how to obtain all data tags and values through file generation.
It could be copied/modified to a PHP template such that the generated file
is appropriate for PHP inclusion. An XML template could also be developed.
In this way wview can be used as a minimal generation engine to provide
weather tags and post processing can be used in any environment you choose.
Pre/Post-Generation Scripts
The script file $prefix/etc/wview/pre-generate.sh (if it exists) will be
executed by the htmlgend daemon immediately before the generation of all
images and templates. The script file $prefix/etc/wview/post-generate.sh
(if it exists) will be executed by the htmlgend daemon immediately
following the generation of all images and templates. This can be used to
perform custom transformations of generated images or files. It should NOT
be used to perform network tasks such as FTP or other tasks which may
block and interrupt execution of the htmlgend daemon.
Note: Empty generation scripts should be renamed so wview does not execute them,
which in rare cases can cause zombie processes.
Based on your intended use for generated files, you may need to export them to a remote server. If your wview server is also the HTTP server in your setup, then a proper definition of the location specified on the wviewmgmt File Generation page: "Generation Target Path" may be all you require to publish your web site. This is the most straightforward approach. However, if it is not possible or desirable to run your HTTP server locally or if you have other plans for the files you generate, you may need to export them. wview supports FTP or SSH processes for file exportation. The wview ftp service tries to be somewhat intelligent: it maintains a "marker" file which contains the date/time of the last FTP update. It will only transfer files in your defined rules which are newer than that date. This conserves time and bandwidth.
wview's ftp daemon no longer requires the tnftp utility. The curl library
is used for direct transfer of files including a 20 second timeout per
file transferred to avoid hang ups when the remote server stops responding.
Remote Server Directory Setup
wviewftpd will place all files it transfers into the [conf_directory]
directory under your ftp login directory on the remote server.
[conf_directory] is the value of the "Remote Directory" configuration
parameter on the FTP page. The curl library facilitates creating any remote
directories needed so manual setup is not required.
Move Static Files to Server
It is no longer necessary to move static files manually. The new wview FTP
service only sends files which have changed since the transfer, so all
static files are sent on the initial transfer.
Configure wview FTP Service
The wviewmgmt FTP page allows configuration of remote_username,
remote_password and remote_host as well as the conf_directory parameters.
You should also enable the FTP service on the Services page.
Troubleshooting
If you are having problems and wish to get more feedback concerning
the FTP transfers, do the following:
Re-Transmitting All Local Files
The wview ftp service tries to be somewhat intelligent: it maintains a
"marker" file which contains the date of the last FTP update. It will only
transfer files in your defined rules which are newer than that date. This
conserves time and bandwidth. To cause the wview ftp service to start over,
resending all files in your defined rules, you must delete the marker file:
$prefix/var/wview/ftp_marker. wview will send all files and save the new
marker file at the next defined update interval.
Notes:
wview also supports the secure shell protocol for secure file transfers.
Using rsync, the wviewsshd service can export files or directories. rsync
is more efficient than FTP because only changed files are transmitted.
To work properly, the wview server must be able to login and/or execute
commands on the destination server via ssh WITHOUT entering a password.
This is accomplished by copying the wview server's root account shared
ssh key to the remote server's login account.
Suggestion: Don't mix hostname with IP address for the remote
server during the configuration below. Decide NOW whether you are going
to use a hostname or an IP address, and use it consistently for all
references to [remote_host] below. ssh does make a distinction when
storing and verifying shared keys.
Placeholders:
[remote_host] - the host we want to update
[ssh_login_user] - the user account name on the [remote_host] we want to
use for the ssh logins
[remote_test_dir] - remote directory to receive files, relative to the
[ssh_login_user] login home directory ([ssh_login_user] must have write
access to this directory)
[wview_server] - the wview host
I have included prompts of the form "username@host:# " to help clarify
what is being executed on what host. Your actual shell prompts may be
different, this is only for clarity in this procedure.
This procedure assumes compatible versions of ssh - version 1 and
version 2 of openssh have compatability problems as well as with
ssh.com versions 1 and 2. If you are having problems with the setup,
I strongly suggest going to the following URL for advanced help:
http://gentoo-wiki.com/SECURITY_SSH_without_a_password.
Prerequisites
Verify rsync is installed on the wview server:
| root@[wview_server]:# whereis rsync |
|
root@[wview_server]:# ssh -l [ssh_login_user] [remote_host] [enter password] [ssh_login_user]@[remote_host]:# whereis rsync Logout: [ssh_login_user]@[remote_host]:# exit |
If that doesn't produce /usr/bin/rsync or similar, install rsync.
Shared Key Setup
Generate a public/private key pair for the root user on the wview
server (if it does not already exist) (execute as the root user):
| root@[wview_server]:# mkdir -p ~/.ssh root@[wview_server]:# ssh-keygen -t rsa |
Just hit enter for default values when asked questions.
This will create two files, we are interested in the ~/.ssh/id_rsa.pub
file.
Transfer id_rsa.pub to [remote_host]. Use ftp, scp, email, floppy
disk, whatever you want to get this file to the remote host.
Login to [remote_host] as [ssh_login_user] and append the contents of
id_rsa.pub into ~/.ssh/authorized_keys (if authorized_keys does not
exist, just rename id_rsa.pub to authorized_keys).
|
root@[wview_server]:# ssh -l [ssh_login_user] [remote_host] [enter password] [ssh_login_user]@[remote_host]:# mkdir -p ~/.ssh [ssh_login_user]@[remote_host]:# cd ~/.ssh [ssh_login_user]@[remote_host]:# cat id_rsa.pub >> authorized_keys [ssh_login_user]@[remote_host]:# chmod 600 authorized_keys |
Stay logged in - we need it for the next step.
As root on the wview server, ssh into [remote_host] as [ssh_login_user],
answer "yes" if this is the first time, then logout. This sets the
[remote_host] up in the wview server root account's "known_hosts" file.
|
root@[wview_server]:# ssh -l [ssh_login_user] [remote_host] [no password should be required!] [ssh_login_user]@[remote_host]:# exit |
Proper Login Access
Finally, we need to set up ssh for the root user so that when
[remote_host] is logged into, ssh uses [ssh_login_user] instead of
root for the login on [remote_host]. This must be done for every
[remote_host] entry on the wviewmgmt SSH page. This is what specifies which
user account is used for the ssh login to each [remote_host].
Edit /root/.ssh/config and put the following at the top of the file
(just create a new file if it does not exist):
|
Host [remote_host] User [ssh_login_user] |
Mandatory Tests
These tests must succeed before proceeding.
As root on the wview server execute:
| root@[wview_server]:# ssh [remote_host] |
You should be logged in to [remote_host] as [ssh_login_user] without
entering a password.
Exit the remote host shell:
| [ssh_login_user]@[remote_host]:# exit |
You should now be able to remotely execute commands over ssh. Verify
this by executing the date command from the wview server as root:
| root@[wview_server]:# ssh [remote_host] date |
This MUST execute without requiring a password. If it does not, go back
to the beginning of shared key setup and double check your steps.
DO NOT proceed if you cannot login/execute commands remotely as
[ssh_login_user] without a password. This is critical! There is much
online documentation concerning ssh setup, this is only a bare-bones
treatment of the subject.
Confirming rsync Functionality
Place files in $prefix/var/wview/img (if it is not already your
"Generation Target Path" on the wviewmgmt File Generation page):
| root@[wview_server]:# cp [some_test_files] $prefix/var/wview/img |
Create/Verify the destination path on the remote server
(as [ssh_login_user]):
|
root@[wview_server]:# ssh [remote_host] (you are now logged in as [ssh_login_user] without a password, right?) [ssh_login_user]@[remote_host]:# cd ~ (this is your ssh login directory - all destination paths are relative to this directory) [ssh_login_user]@[remote_host]:# mkdir -p [remote_test_dir] ([remote_test_dir] is a relative path from the [ssh_login_user] login directory - it CANNOT contain a leading "slash") Logout: [ssh_login_user]@[remote_host]:# exit |
Test rsync over ssh from the wview server:
| root@[wview_server]:# rsync -aqz --rsh=ssh $prefix/var/wview/img/ [remote_host]:[remote_test_dir] |
This should transfer the files you placed in $prefix/var/wview/img to the
remote server in the [remote_test_dir] directory without a password
being required. If it prompts for a password, you need to fix it. Left
in this state, the wview ssh daemon will not provide any negative feedback
because the stdin pipe that the rsync command prompts for a password on
will not exist when invoked within wview and rsync will just exit quietly.
*****!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT !!!!!!!!!!!!!!!!!!!!!!!!!*****
wview ssh file transfer capability will NOT work until you can
successfully execute this command from the wview server and verify
the file transfers on the remote server.
*****!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT !!!!!!!!!!!!!!!!!!!!!!!!!*****
Configuring wview For Secure Transfers
Add transfer rules on the wviewmgmt SSH page.
Note: Each [remote_host] entry must have a corresponding "Host" entry in
/root/.ssh/config which specifies the login account ([ssh_login_user])
to use for ssh. See section 14.3 above. Further, the procedures outlined
above MUST be followed for each unique [remote_host] [ssh_login_user]
combination.
You may change the SSH remote port number (default is 22) if required.
You may change the "-l" argument passed to ssh during remote login (this
should not be required under normal conditions).
wview stores archive data in an SQLite3 database, namely
$prefix/var/wview/archive/wview-archive.sdb. This allows easy data viewing,
modifying and post-processing.
HILOW data is stored in the database $prefix/var/wview/archive/wview-hilow.sdb.
NOAA data is stored in the database $prefix/var/wview/archive/wview-noaa.sdb.
This section will describe each of these databases including when and from
what data they are created/updated.
Database Origins
Database Data Source How Generated
------------------ ------------------------------- -------------------------------
wview-archive.sdb WLK conversion via wlk2sqlite Not autogenerated - requires
or stored run time by wview an existing template (found at
$distro/bin/archive/wview-archive.sdb)
wview-hilow.sdb Archive records for initial Autogenerated during wview init
creation; LOOP packets during (can be very slow on some platforms);
run time by wview Offline creation via the hilowcreate
utility
wview-noaa.sdb HILOW records for initial Autogenerated during wview init
creation and during run time (not too long to generate)
What to Protect and Why
wview-archive.sdb - do NOT delete this database without a backup copy; this file
should be backed up for data security
wview-hilow.sdb - if you delete this file, wview will regenerate it but you
will lose the higher resolution of LOOP data as wview can
only use archive records for historical generation; this
file should be backed up for data security
wview-noaa.sdb - there is no data loss associated with deleting this database
and letting wview regenerate it during init
Archive Data
Conversion from WLK to SQLite3
A conversion utility, wlk2sqlite, is provided as part of the wview
distribution.
Usage: wlk2sqlite source_directory [destination_directory]
source_directory is a required argument but can be the same as
[destination_directory] - typically you can use the default archive
file location for your installation, $prefix/var/wview/archive, since there
is nothing destructive about the conversion with respect to the old
WLK files, it only reads them.
So an example using the default prefix /usr/local would be:
| #> sudo wlk2sqlite /usr/local/var/wview/archive |
This places the newly populated SQLite3 archive database file in the
proper location for wview 5.0.0 + operation.
Note: The conversion can take some time depending upon your platform
and how much archive data you have.
When the conversion is complete, you have one coherent SQL archive database.
Viewing/Modifying Your Data With the sqlite3 CLI Utility
Let's look at your data:
|
#> sudo sqlite3 /usr/local/var/wview/archive/wview-archive.sdb sqlite> .help (This displays available commands; non-SQL commands begin with '.') sqlite> select * from archive; (This displays every column of every row) sqlite> .schema archive (This displays the CREATE statement for the archive table including column names) sqlite> update archive set altimeter='777.88' where altimeter is NULL; (This changes the value of column altimeter wherever it is NULL) sqlite> .dump archive (This dumps every row of the archive table in SQL format - very handy for moving your table from one platform to another) |
Note: SQL syntax as recognized by SQLite3 is documented at:
http://www.sqlite.org/lang.html
Moving Your Data to a Different Platform
This is where having our data in an SQL database starts to pay off.
|
Dump the archive table in SQL format: #> sudo sqlite3 /usr/local/var/wview/archive/wview-archive.sdb .dump > ~/temp/[my_sql_filename] Copy [my_sql_filename] to the target platform. On the target platform: #> sudo sqlite3 [new_database_filename] .read [my_sql_filename] (This will execute each SQL statement in [my_sql_filename] for the new database [new_database_filename]) |
HILOW Data
Overview
The database $prefix/var/wview/archive/wview-hilow.sdb will be created
and back-filled using archive records for all records in the archive
database.
This initialization process can take some time (8-12 minutes per year)
but is only required during the first run of wview after an upgrade >=
5.1.0.
Once $prefix/var/wview/archive/wview-hilow.sdb has been created and
back-filled, wview will add each LOOP sample to the HILOW database.
Structure
The $prefix/var/wview/archive/wview-hilow.sdb database has one table
for each of the supported sensor types (i.e., inTemp, outTemp, ...
rain, rainRate). Each table contains a record for each hour. The data
starts with your earliest archive record.
The columns for each table are:
dateTime - timestamp for the beginning of the hour for this record
low - low value for this hour
timeLow - timestamp when the low occured
high - high value for this hour
timeHigh - timestamp when the high occured
whenHigh - additional value at the time of the high
(currently only used for wind direction when high wind occured)
cumulative - the sum of all samples in this record
samples - the number of samples in this record
Thus the average for an hour is cumulative/samples.
The windDir table has a unique structure. Each row includes the dateTime
stamp and 20 integer bins. Each wind direction reading is tallied in
one of the 20 bins, with each bin representing an 18-degree window.
These bins are used for consensus averaging (the algorithm is found in
windAverage.c).
Samples Stored
During creation, wview uses archive records to back-fill the HILOW
database. During normal wview operation, LOOP samples are used to
populate the HILOW database, providing a much higher granularity for
detecting low and high events.
Regeneration
To regenerate the HILOW database:
#> /etc/init.d/wview stop #> sudo rm $prefix/var/wview/archive/wview-hilow.sdb #> /etc/init.d/wview start |
Note: Doing this will delete the LOOP sample resolution stored while wview is running, replacing it with back-filled archive data. For a station with a 5 minute archive interval and 30 second LOOP interval, that is the difference between 120 samples per hour and 12 samples per hour.
NOAA Data
Overview
The NOAA data is stored in an SQLite3 database. The database is generated
based on records in the HILOW database (much faster and more accurate than
archive records).
Structure
Each record in wview-noaa.sdb represents one day. The columns for the
noaaHistory table are:
dateTime - timestamp for the beginning of the day for this record
meanTemp - average temperature for the day
highTemp - high temperature for the day
highTempTime - unix time of high
lowTemp - low temperature for the day
lowTempTime - unix time of low
heatDegDays - heat degree days for the day
coolDegDays - cool degree days for the day
rain - rain for the day
avgWind - average wind for the day
highWind - high wind for the day
highWindTime - unix time of high wind
domWindDir - dominant wind direction for the day
Regeneration
To regenerate the NOAA database:
#> /etc/init.d/wview stop #> sudo rm $prefix/var/wview/archive/wview-noaa.sdb #> /etc/init.d/wview start |
Day history Table (wview-history.sdb)
Overview
This table is generated internally by wview to avoid having to compute
the daily summary records used for the yearly charts every time wview
starts. This was not a time concern with the flat WLK files but became
more costly when we started storing data in SQLite3. The external use
or utility of this table is limited at best.
Regeneration
To regenerate the NOAA database:
#> /etc/init.d/wview stop #> sudo rm $prefix/var/wview/archive/wview-history.sdb #> /etc/init.d/wview start |
SQLite3 Tips
To display the dateTime timestamp of any table as local time:
| sqlite> select datetime(dateTime, 'unixepoch', 'localtime') from archive; |
To fix any archive entries having 255 for the outHumidity:
| sqlite> update archive set outHumidity = '50' where outHumidity = '255'; |
Note: If you modify records in the archive table, you will probably want
to regenerate the HILOW tables
Purging All Weather Data
wview will be running the simulator once installation is complete. When
you are ready to "go live" with your station or you just want to purge
all weather data and start over, use the "wviewcleardata" utility to purge
all weather data:
|
#> sudo wviewcleardata (this will purge all archive records, delete the HILOW, history and NOAA databases) (leaving a clean weather data environment for your station) |
WARNING - take care using this utility, it does not backup data so you should do that yourself prior to running it if there is any possibility you want to recover/keep the old weather data!
Overview
CWOP (Citizen Weather Observer Program, http://www.wxqa.com/) is a system
by which individuals with weather stations and the proper software can
submit their weather data to an APRS-based data storage system so that
anyone, including NOAA, can use the data however they see fit. There are
some really neat station display web sites including some java apps to
look up station data, position, maps, etc.
As an example, see http://www.findu.com/cgi-bin/wxpage.cgi?call=CW4097
for my weather station.
CWOP participation requires registering for an APRS "Call Sign". Once you
have configured wview for CWOP properly and confirmed your data online, you
must contact the maintainers via email to confirm your registration. Then
your data will be available for anyone to see and possibly be used in NOAA
forecast models, etc. Pretty cool, eh?
When CWOP support is enabled and configured properly, wview will transmit
a new WX packet to the APRS server every 10 minutes based on the last digit
of your callsign.
wview supports the APRS-IS Rollover functionality by enforcing the
definition of 3 APRS-IS server:port pairs - the goal is to avoid data
loss to the CWOP system caused by connection errors. Select 3 different
servers from the list at http://www.wxqa.com/activecwd.html - be advised,
the arizona server is heavily burdened and often refuses connections.
Prerequisites
Setup
Register for an APRS Call Sign (unless you already have one):
http://www.findu.com/citizenweather/signup.html
Determine your accurate latitude and longitude:
http://www.topozone.com/viewmaps.asp
Enable CWOP support in wview:
Enable the CWOP service on the wviewmgmt Services page.
Configure the CWOP settings on the wviewmgmt CWOP page.
Check the wview logs for wvcwopd activity:
Look in /var/log/messages for something similar to:
"CWOP: configured to submit station CW4097 data to:"
"CWOP: Primary: cwop.aprs.net:23"
"CWOP: Secondary: cwop.aprs.net:23"
"CWOP: Tertiary: cwop.aprs.net:23"
during initialization, and:
"CWOP-sending: CW4097>APRS,TCPXX*,qAX,CW4097:@132235z3334.14N/09654.66W_284/002g005t093P002h40b10131.wview160"
every 10 minutes at the minute of your last CWOP ID digit.
Confirm your data in the CWOP stream:
Goto http://www.findu.com/cgi-bin/wxpage.cgi?call=CWxxxx where CWxxxx is
your Call Sign. This should start displaying your weather data graphically
with links on the left for looking at your raw data. Make sure it is all
good - there is much information and many sites to visit to help you verify
your data. Just start at http://www.wxqa.com/activecwd.html.
When all is good, send an email to the CWOP maintainers. Congratulations,
you are now contributing data for the greater good!
Overview
The Weather Underground (www.wunderground.com/) (Wunderground) is a privately
held organization which provides many weather services - some free and some
not. Among the free services is the ability to register your weather station
and submit your data to them so that you can access your data and some nice
graphs from their site. Weatherforyou.com is also a privately held outfit
with similar capabilities to wunderground.
Prerequisites
Weather Underground
Register for a Weather Underground Station ID (unless you already have one):
http://www.wunderground.com/weatherstation/usersignup.asp
Determine your accurate latitude and longitude:
http://www.topozone.com/viewmaps.asp
Enable Wunderground support in wview:
Enable the HTTP service on the wviewmgmt Services page.
Configure the HTTP settings on the wviewmgmt HTTP Services page.
WeatherForYou
Register for a Weatherforyou Station ID (unless you already have one):
http://www.hamweather.net/weatherstations/
Determine your accurate latitude and longitude:
http://www.topozone.com/viewmaps.asp
Enable Weatherforyou support in wview:
Enable the HTTP service on the wviewmgmt Services page.
Configure the HTTP settings on the wviewmgmt HTTP Services page.
Check the wview logs for wvhttpd activity:
Your archive interval determines how often wview will update your weather
data to the Wunderground/Weatherforyou systems. The first record should be
generated at the next archive record generation after wview has started.
Look in /var/log/messages for something similar to:
"WUNDERGROUND: configured to submit station KTXCOLLI1 data to wunderground.com"
"WEATHERFORYOU: configured to submit station KTXCOLLI1 data to weatherforyou.com"
Confirm your data at the Wunderground server:
Goto http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=XXXXXXX
where XXXXXXX is your Wunderground Station ID. This should start displaying
your weather data graphically and as a packet list.
Confirm your data at the Weatherforyou server:
Goto http://www.hamweather.net/weatherstations/pwsupdate.php?ID=XXXXXXX
where XXXXXXX is your Weatherforyou Station ID. This should start displaying
your weather data as a packet list.
Overview
From the AWEKAS site (
http://www.awekas.at/en/index.php):
"AWEKAS is an acronym for "Automatisches WEtterKArten System" (= automatic
weather map system) and is, as the name already states, a system which
produces overview maps from the data from private weather stations.
The values are made available
by the participants on their websites as Text or CSV files and are
collected by the programme. The process is fully automatic and always
provides maps with up to date weather situations."
Simply put, if we provide the properly formatted HTML template to wview,
AWEKAS will periodically poll the resulting HTML file for data and store
it in their database for online retrieval.
Setup
Add (or uncomment if already there) the Awekas template in
$prefix/etc/wview/html-templates.conf:
|
#> sudo vi $prefix/etc/wview/html-templates.conf (Add the following lines or just remove the '#' from awekas_wl.htx if already there) [snip] ############################################################################### ### AWEKAS Data Submission Template ############################################################################### awekas_wl.htx [/snip] Save the file. |
That's it! Once you have registered with AWEKAS this file should be polled
by them periodically to update your station data.
Overview
Software calibration of basic sensors for any station type are configured
using wviewconfig or the wviewmgmt web interface. Archive data and loop data
used for highs/lows/averages is calibrated before being stored to file or
sent to external data consumers (CWOP, WeatherUnderground, Alarms, etc.).
The format of the calibration equation is:
CSV = M * X + C, where:
CSV is the calibrated sensor value
M is the multiplier configuration value on the wviewmgmt Calibration page
X is the raw sensor value
C is the constant configuration value on the wviewmgmt Calibration page
Sensor List
The following sensors can be calibrated:
Sensor Units
------------------ -----------------
Barometer US inches
Station Pressure US inches
Altimeter US inches
Inside Temp degrees fahrenheit
Outside Temp degrees fahrenheit
Inside Humidity %
Outside Humidity %
Wind Speed miles per hour (mph)
Wind Direction degrees (0-359)
Rain US inches
Rain Rate US inches per hour
Pressure Calibration
Each station type produces one type of pressure sensor: Barometric
Pressure (BP), Station Pressure (SP) or Altimeter (ALT). wview converts
the sensor provided to the other two types algorithmically. It is only
necessary to calibrate the pressure type provided by your station - wview
will apply the calibration prior to the conversion to the other two types.
Calibration values entered for the two derived types will be ignored by
wview.
Station Pressure Type to Calibrate
---------------- --------------------------
Vantage Pro BP
WXT510 SP
WS-2300 SP
WMR918 SP
Regardless of the type you are calibrating, you will generally be using
the BP value to compare to local stations. Just remember to adjust the
sensor calibration for the native pressure of your station.
Notes
Calibration is done in US units only. Station data is always received/
stored in imperial units. Thus calibration is done in imperial units.
If you are a metric station, *figure out* what the imperial equivalent
for your metric calibration would be, and use that for the calibration
settings.
Overview
If the wviewmgmt Services page has "Enable Alarms (wvalarmd)" disabled
when wvalarmd starts, it will exit and alarms will be disabled.
If enabled, wvalarmd "registers" with the wviewd daemon to receive
LOOP data at an interval determined by the "Data Push Interval (seconds)"
parameter of the wviewmgmt Station page (the default is every 60 seconds).
When a new LOOP data packet is received by wvalarmd, it checks all defined
alarms to determine if an alarm has been triggered. If so, the alarm
abatement counter is initialized and the alarm binary/script is invoked
with the following arguments:
argv[0]/$0 full path of binary/script being run
argv[1]/$1 alarm type (see definitions below)
argv[2]/$2 alarm threshold
argv[3]/$3 value which triggered the alarm
It is not hard to conclude the following:
Alarm Abatement
To control the frequency for which an alarm script/binary is invoked
while the data type is exceeding the threshold, an alarm configuration
parameter called Abatement is provided. This is simply the number of
seconds after an alarm triggers to "hold off" or not invoke the alarm
binary/script. Once this abatement period expires, a new alarm
binary/script invocation will occur if the alarm is triggered.
Alarm Update Frequency
This is controlled by the "Data Push Interval (seconds)" parameter of
the wviewmgmt Station page (the default is every 60 seconds). It is
given in seconds. One should avoid setting it to anything less than 10 -
I'm sure it would be fine, but you are not going to get new data updates
from the VP Console any faster than once every 10 seconds.
Weather Data Update Frequency
This is controlled by the "Sensor Polling Interval (seconds)" parameter
on the wviewmgmt Station page. This determines how often the wviewd
daemon polls the station for current conditions. It is given in seconds
and should not reasonably be set to anything less than 10 seconds, and
must be an even divisor of 60.
Raw Data Feeds
wvalarmd implements a TCP socket server to accept connections for clients
wanting a raw feed of loop packet data. See the section "Socket-Based
Data Feeds" below for details.
Configuration
Configure the "Data Push Interval (seconds)" parameter of the wviewmgmt
Station page to your requirements. This value is given in seconds. This
determines how often wvalarmd will receive current conditions data.
Choose your station units type by indicating "Enable Metric Units for
Alarms?" on the wviewmgmt Alarms page.
Specify your alarm definitions for up to 10 distinct alarms on the wviewmgmt
Alarms page.
Scripts: $prefix/etc/wview/alarms/*.sh
If using notification scripts, they should be placed in
$prefix/etc/wview/alarms and will receive the arguments described above
when invoked.
There are a few example scripts in the distribution directory
examples/alarms - these will be copied to $prefix/etc/wview/alarms for new
installs.
If using custom binaries, make note of the arguments passed to the binary
above.
The example scripts log alarm events to a log file:
$prefix/var/wview/alarms/alarm.log. This may be a feature you want to keep -
even if you are doing other things in your alarm notification scripts.
Alarm Type Definitions
Type (wview-conf.sdb) Value (passed to script/binary)
---------------------- -------------------------------
Barometer 0
InsideTemp 1
InsideHumidity 2
OutsideTemp 3
WindSpeed 4
TenMinuteAvgWindSpeed 5
WindDirection 6
OutsideHumidity 7
RainRate 8
StormRain 9
DayRain 10
MonthRain 11
YearRain 12
TxBatteryStatus 13
ConsoleBatteryVoltage 14
DewPoint 15
WindChill 16
HeatIndex 17
Radiation 18
UV 19
ET 20
ExtraTemp1 21
ExtraTemp2 22
ExtraTemp3 23
SoilTemp1 24
SoilTemp2 25
SoilTemp3 26
SoilTemp4 27
LeafTemp1 28
LeafTemp2 29
ExtraHumid1 30
ExtraHumid2 31
Trying It Out
To get an idea how it works and to gain familiarity with configuration,
do the following:
| #> tail -f $prefix/var/wview/alarms/alarm.log |
Overview
For true data feeds, wvalarmd provides a socket server which listens on port 11011 of the wview server for connections. When a datafeed client connects on that port, wvalarmd adds the client to the datafeed client list. Then when loop data is received from wviewd, wvalarmd will write the loop packet into each datafeed client's socket, preceded by a start frame sequence. When an archive record is generated by the wviewd daemon wvalarmd will write it into each datafeed client's socket, preceded by a start frame sequence unique to archive data. Newly connected clients may request archive records in order to synchronize any records generated since the last connection. There is a unique start frame for this archive request packet which just contains the epoch time to indicate "get the next record after this time" (or alternatively, "this is the last record I have, give me the next one"). Other than this synchronization of archive records process, it is a one-way interface and the client may disconnect at any time by calling "shutdown" followed by "close" to close the socket. The number of active client connections is only limited by system resources.
The datafeed client will receive modified loop and archive packets as
defined in common/datafeed.h - see the structures "LOOP_PKT_FP" and
"ARCHIVE_PKT_FP". Conversion utilities are provided in common/datafeed.c
to convert the fixed point representations transmitted over the socket
back to the floating point format used internally by wview. See the
alarms/sample-datafeed-client/datafeedClient.c file for an example
implementation of a client and the use of the conversion utilities.
Note that "HTON" denotes "host to network" and "NTOH" denotes "network
to host" in the conversion utility function names. The Virtual station
type uses the remote datafeed server for its data source and is another
good example of the use of the datafeed server interface.
Configuration
None required for socket data feeds, just the wviewmgmt Station page
"Data Push Interval" which controls how often LOOP data is pushed to the
clients. Archive packets will be pushed each time a new archive record
is generated. No alarm entries are required in the configuration database
for datafeed clients.
Client Requirements
The datafeed sockets are regular TCP/stream PF_INET sockets. The general
connection steps (in C) are as follows:
socket (...) // create the socket descriptor
[setup server address and port in socckaddr_in structure]
connect (...)
The client then may add the socket descriptor to an fdset for select
calls, simply block on the socket for reads, however you want to design
it. Other programming language procedures may differ, but the general
approach should be the same.
Normal Processing "Loop":
To disconnect:
shutdown (sockfd, 2)
close (sockfd)
Note: There is a handy radlib socket API which is illustrated in the
sample datafeed client source code which takes care of most of the
above connection procedure for you.
Running the Example Datafeed Client
The directory alarms/sample-datafeed-client contains a simple client
example including Makefile. It accepts an argument for host but will
use "localhost" if none is given. It connects to the wvalarmd server
and logs the current temperature when loop packets are received and
logs the dateTime of the archive when archive records are received.
|
Build the example client: #> cd alarms/sample-datafeed-client #> make (or "gmake" for *BSD) Run it: (with wview already running) #> ./datafeedClient [wview_hostname] Watch the system log for wvalarmd connection messages Watch the console for client update messages from the example client: #> tail -f /var/log/syslog |
Kill the example client:
Either "ctrl-c" if you ran it in the foreground, or "kill -15 [pid]"
if you backgrounded it when you started it.
Testing multiple clients:
Just repeatedly run the datafeed client application - each client
will have its own socket connection to wview. Kill them as described
above when you are done.
Overview
MySQL and PostgreSQL storage of weather data is now accomplished through
export scripts which are provided in the wview distribution. These scripts
are run via CRON periodically to export data from the SQLite3 databases
to the export databases.
MySQL Installation and Setup
|
Create the MySQL Database, tables and user: (Be sure you have set your MySQL account settings using wviewmgmt or wviewconfig before creating locally). #> wview-mysql-export create [root_mysql_user_password] (This runs wview-mysql-create for you locally using configuration database settings) |
|
Copy the wview-mysql-create script to the remote server: #> scp $exec_prefix/wview-mysql-create [username]@[mysql_host]:/downloads (copy wherever you like on the remote server) (wview-mysql-create can be found by executing: whereis wview-mysql-create) Login to the remote server: #> ssh [username]@[mysql_host] Execute the create script (make sure the admin user has the right privileges): #> wview-mysql-create help (to see usage text) #> wview-mysql-create [admin_username] [admin_password] [db_username] [db_password] [db_name] (admin_username can be the same as db_username) Log out of the remote server: #> exit |
PostgreSQL Installation and Setup
|
Login to the PostgreSQL account: user@wview_server> su root@wview_server:# su postgres Create an administrative user based on the root unix account: postgres@wview_server:# createuser root Answer the question: Shall the new role be a superuser? (y/n) y Logout of the PostgreSQL account: postgres@wview_server:# exit |
|
Create the wview database: root@wview_server:# createdb wviewDB Note: wviewDB should be the same value specified on the wviewmgmt SQL Export page for "SQL Database Name". |
|
root@wview_server:# wview-pgsql-create wviewDB |
Test Run and Debug
The end game is to create a cron job which runs wview-mysql-export
periodically (every 5 minutes seems reasonable although the export is
surprisingly fast so 1 minute periods are not out of the question). First,
let's run it from the command line and confirm it is working.
Note: If using PostgreSQL, substitute "wview-pgsql-export" for
"wview-mysql-export".
|
Execute with debugs enabled: #> wview-mysql-export debug Examine the CSV export files: #> cat $prefix/etc/wview/export/archive.csv #> cat $prefix/etc/wview/export/outTemp.csv #> cat $prefix/etc/wview/export/noaaHistory.csv These will probably be large given this was the first export. They should contain all records up to the present time. Examine the MySQL tables: (login to the remote server if not local) #> mysql --user=[db_username] --password=[db_password] mysql> use [db_name]; mysql> select count(*) from archive; (This should match the record count in your SQLite3 database) mysql> select * from windDir; (The 20 wind direction bins should display direction counts = 60/archive_interval for each row) mysql> select * from noaaHistory; (There should be one record for each day of archive data) Examine the Import Logs: #> cat $prefix/etc/wview/export/mysql_import.log |
Production Setup
|
Add to the root crontab on the wview server: #> sudo crontab -e Add the following line and save the crontab: 1,6,11,16,21,26,31,36,41,46,51,56 * * * * $exec_prefix/wview-mysql-export This runs the wview-mysql-export script every 5 minutes (1 minute past archive record reception for 5 minute archive interval) Example where $exec_prefix is "/usr/local/bin": 1,6,11,16,21,26,31,36,41,46,51,56 * * * * /usr/local/bin/wview-mysql-export |
Done - you can check the $prefix/etc/wview/export directory and the MySQL
database to confirm the updates.
Notes
The records imported into the MySQL database tables are set to replace any
existing records with the same dateTime stamp. This is so we get the latest
HILOW records for the current hour and so if better/more complete data is
re-exported, it will take precedence over older data. You will notice in the
debug log file $prefix/etc/wview/export/mysql_import.log that records are
deleted and inserted at incremental updates. This is the HILOW last record
phenomenon.
If you need to cause a complete re-export of all data, delete the file
$prefix/etc/wview/export/mysql_export_marker. The next time the wview-mysql-export
script runs, all data will be exported (and replace existing data in the MySQL
database).
PostGreSQL and FreeBSD Semaphore Resources
FreeBSD starts with a limited number of semaphores available for application
use. radlib and wview use some semaphores and so does PostgreSQL. Often the
default number is not sufficient. Here is how to increase the number of
semaphores available:
Overview
If you have existing archive files (*.wlk) that you want to import, use
the wlk2sqlite utility to import all archive records into the SQLite3
database prior to starting wview. It will find them and use them for
historical charts and NOAA reports. Be sure they were collected using the
same archive interval that you are going to use for your VP with wview.
Configuration
Configuration Files ($prefix/etc/wview)
*.conf - configuration files described below
html/*.htx - HTML template files to be customized for your
site and language
html/parameterlist.txt - contains the list of all available HTML tags
which can be placed in *.htx template files.
These tags are replaced each time htmlgend
generates new image and html files.
Data Files ($prefix/var/wview)
*.pid - run time pid files created/deleted by the wview
daemons. Do NOT alter or delete these files. They
should only be present if the corresponding wview
daemon is running.
archive/wview-archive.sdb - SQLite 3 archive database file
dev/* - FIFO device files created by wview - do NOT alter
or delete them
img/* - default destination for generated image and HTML
files - in particular if subsequent ftp/ssh of
files is required
noaa/noaa.dat - NOAA data file
[snip]
root@localhost:/root/dev# telnet 10.10.10.22
Trying 10.10.10.22...
Connected to 10.10.10.22.
Escape character is '^]'.
ABLELink Ethernet-Serial Server
User name:admin
Password:
Login ok
0.Exit 1.Overview 2.Networking 3.Security 4.COM1
Input choice and enter(0~4): 4
4
COM0:
1. Link Mode (TCP Server/Virtual COM Disabled/Pair Connection Disabled/Filter disabled/3001 /Alive=10*10 sec)
2. COM Port (VP/RS-232/19200,None,8,1/RTS/CTS)
3. Keep Serial Buffer's Data While Connecting(Disabled)
4. Packet Delimiter (1 ms)
5. Accept Control Command from COM port (Disabled)
Input choice and enter(1~5):
[snip]
Lantronix MSS1 Version V3.5/5(980529)
Type HELP at the 'Local_2> ' prompt for assistance.
Username> admin
Local_2> show server
MSS1 Version V3.5/5(980529) Uptime: 0:06:16
Hardware Addr: 00-80-a3-0f-f3-e2 Name/Nodenum: MSS_0FF3E2/ 0
Ident String: Micro Serial Server
Inactive Timer (min): 30 Serial Delay (msec): 10
Password Limit: 3 Session Limit: 4
Queue Limit: 32 Node/Host Limits: 50/20
LAT Circuit Timer (msec): 80 Keepalive Timer (sec): 20
Multicast Timer (sec): 30 Retrans Limit: 10
TCP/IP Address: 10.10.10.22 Subnet Mask: 255.255.255.0
Nameserver: (undefined) Backup Nameserver: (undefined)
TCP/IP Gateway: 10.10.10.1 Backup Gateway: (undefined)
Domain Name: (undefined) Daytime Queries: Enabled
TCP Keepalives: Enabled
DHCP Server: None Lease Time: 0:00
Load Address: 00-00-00-00-00-00 Prompt: Local_%n%P>
Characteristics:
Incoming Logins: Telnet (No Passwords Required)
LAT Groups: 0
Local_2>
The port to use on the MSS1-T is the raw mode port 3001.
Given the above configuration, your wview ethernet configuration should
be:
Host: 10.10.10.22 (whatever the IP address is that you assigned it)
Port: 3001 (not configurable)
wview provides two command-line utilities to convert wview archive directories
from Big Endian-to-Little Endian or Little Endian-to-Big Endian. These are
necessary if you want to change your wview host from a Mac/NSLU2 to a PC or
vice versa.
arc_be2le
Usage: arc-be2le [source_directory] [dest_directory]
Convert wview archive data in [source_directory] from big endian
to little endian then store the result in [dest_directory].
arc_le2be
Usage: arc_le2be [source_directory] [dest_directory]
Convert wview archive data in [source_directory] from little endian
to big endian then store the result in [dest_directory].
This chapter provides invaluable information for understanding wview operation and diagnosing problems you may encounter.
Please note there are two unix processes for each wview daemon: this is
normal radlib operation. One is the actual daemon and the other is a
"reflector" process which allows the daemon to send events to itself and
to open the message queue FIFO properly. Don't let that bother you.
Here are the processes running on my server (no ssh/ftp because I don't
need it):
root@localhost:/root# ps aux | grep wv
root 73863 0.0 0.2 2320 1808 ?? Ss 7:08AM 0:00.02 /usr/local/bin/radmrouted 1 $prefix/var/wview
root 73865 0.0 0.2 2300 1780 ?? I 7:08AM 0:00.00 /usr/local/bin/radmrouted 1 $prefix/var/wview
root 73868 0.0 0.1 2380 1472 ?? Ss 7:08AM 0:00.36 /usr/local/bin/wviewd
root 73870 0.0 0.1 2356 1196 ?? I 7:08AM 0:00.00 /usr/local/bin/wviewd
root 73873 0.0 0.1 2376 1524 ?? Is 7:08AM 0:35.43 /usr/local/bin/wviewsqld
root 73875 0.0 0.1 2324 1140 ?? I 7:08AM 0:00.00 /usr/local/bin/wviewsqld
root 73879 0.0 0.1 2336 1468 ?? Ss 7:08AM 0:00.01 /usr/local/bin/wvalarmd
root 73881 0.0 0.1 2312 1136 ?? I 7:08AM 0:00.00 /usr/local/bin/wvalarmd
root 73882 0.0 0.1 2392 1504 ?? Is 7:08AM 0:00.01 /usr/local/bin/wvcwopd
root 73884 0.0 0.1 2304 1136 ?? I 7:08AM 0:00.00 /usr/local/bin/wvcwopd
root 73885 0.0 0.3 4944 3100 ?? Is 7:08AM 0:00.03 /usr/local/bin/wvhttpd
root 73886 0.0 0.2 4788 2216 ?? I 7:08AM 0:00.00 /usr/local/bin/wvhttpd
root@localhost:/root# ps aux | grep htmlgen
root 73876 0.0 0.3 3960 2800 ?? Is 7:08AM 0:05.82 /usr/local/bin/htmlgend
root 73878 0.0 0.2 3860 1964 ?? I 7:08AM 0:00.00 /usr/local/bin/htmlgend
root@localhost:/root#
This indicates I have 6 wview daemons running: wviewd, htmlgend, wviewsqld,
wvalarmd, wvcwopd and wvhttpd. It also displays the radlib message router
process radmrouted.
wview logs quite a bit of information about what is being initialized,
daemons started, etc. in the system log file (/var/log/messages,
/var/log/syslog, etc.). This is where to go to try to investigate a startup
problem or just observe what wview is "doing".
On the other hand, once you get everything set up the way you want, you
can disable informational logs if you are concerned about how quickly your
/var/log/syslog file is rolling over (you are rotating your log files,
right?). Set verbosity off as required on the wviewmgmt Services page to
disable informational log entries. You can always re-enable it if you need
the verbosity.
The daily historical charts are generated using the archive records from
the last 24 hours. The granularity depends upon your archive interval
choice. These charts are updated at the same frequency as the archive
interval to include the last archive interval.
The weekly and28-day> historical charts are generated using the
hourly average of archive records for the last 28 days. These charts are
updated once per hour to include the last hour's averages.
The 365-day historical charts are generated using the daily average
of archive records for the last 365 days. These charts are updated once per
day (12:01AM) to include the last day's averages.
wview uses many radlib facilities which are based on the system V IPC
concepts of shared memory and semaphores.
Here is a listing of IPC objects while wview is running (FreeBSD):
root@localhost:/root# ipcs
Message Queues:
T ID KEY MODE OWNER GROUP
Shared Memory:
T ID KEY MODE OWNER GROUP
m 4128768 126979 --rw-rw-r-- root wheel
m 4128769 126977 --rw-rw-r-- root wheel
m 4128770 267386882 --rw-rw-r-- root wheel
Semaphores:
T ID KEY MODE OWNER GROUP
s 4128768 267386881 --rw-r--r-- root wheel
s 4128769 126978 --rw-r--r-- root wheel
root@localhost:/root#And, after running /etc/rc.d/wview stop: root@localhost:/root# /etc/rc.d/wview stop Shutting down weather daemons... root@localhost:/root# ipcs
Message Queues:
T ID KEY MODE OWNER GROUP
Shared Memory:
T ID KEY MODE OWNER GROUP
Semaphores:
T ID KEY MODE OWNER GROUP
root@localhost:/root# |
Linux systems tend to have other IPC objects defined - you do not want to
disturb those. The wview objects are discernable by the "KEY" values:
126977 (0x1F001) - 126979 (0x1F003) (wview-specific)
267386881 (0xFF00001) - 267386882 (0xFF00002) (radlib general)
If, after shutting down wview, any of the IPC objects associated with wview
(or radlib) still remain, you will need to remove them manually using the
"ipcrm" command. This is normally caused by failed wview starts when
initially installing wview with improper configuration or by a faulty wview
start/stop script which is leaving wview processes running.
wview generates a number of log messages, in particular during
initialization. The system log file is normally /var/log/messages. I
typically run "tail -f /var/log/syslog" in a separate console when
starting up wview. You should also when you first install it. Informational
logs can later be disabled using the wviewmgmt web interface (Services page)
then sending a HUP signal to wviewd and htmlgend:
(kill -s HUP `cat $prefix/var/wview/wviewd.pid`) and
(kill -s HUP `cat $prefix/var/wview/htmlgend.pid`) respectively.
If you have errors in your startup log, you will need to stop all wview
daemons using the wview start script (/etc/init.d/wview stop). These are
independent processes which will not shut down automatically if there is
an error in one of them. You must use the wview script.
Here is what the log file looks like on my server when wview starts up, so
you know what a good start looks like:
Apr 18 08:48:44 linuxquad radmrouted[11676]: <1240062524756> : radlib: radmrouted started as a daemon ...
Apr 18 08:48:44 linuxquad radmrouted[11676]: <1240062524764> : started on radlib system 1, workdir /usr/local/var/wview
Apr 18 08:48:44 linuxquad radmrouted[11676]: <1240062524764> : running...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525759> : radlib: wviewd started as a daemon ...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525759> : wview 5.4.0 starting ...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525777> : station interface: serial ...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525777> : Rain Season Start Month set to 1
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525777> : Rain Storm Start Trigger set to 0.05 in/hr
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525778> : Rain Storm Stop Time set to 12 hours
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525778> : Rain YTD preset set to 0.00 inches
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525778> : ET YTD preset set to 0.000 inches
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525778> : bad rain/ET YTD Year given, disabling...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525778> : station polling interval set to 30 seconds
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525837> : HILOW: database OK
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525837> : HILOW: beginning normal LOOP operation
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525837> : -- Station Init Start --
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525838> : station archive interval: 5 minutes
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525838> : Simulator station opened: 720 minute data generation period...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525839> : running...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525839> : station location: elevation: 751 feet
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525839> : station location: latitude: 33.6 N longitude: 96.9 W
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525839> : initializing computed data values...
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525841> : computeDataAllTime: 200904
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525846> : computeDataYear: 200904
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525851> : computeDataMonth: 200904
Apr 18 08:48:45 linuxquad wviewd[11680]: <1240062525856> : computeDataWeek: 20090414
Apr 18 08:48:46 linuxquad wviewd[11680]: <1240062526054> : -- Station Init Complete --
Apr 18 08:48:46 linuxquad wviewd[11680]: <1240062526055> : newest archive record: 2009-04-14 22:40
Apr 18 08:48:46 linuxquad htmlgend[11686]: <1240062526745> : radlib: htmlgend started as a daemon ...
Apr 18 08:48:46 linuxquad wvalarmd[11691]: <1240062526746> : radlib: wvalarmd started as a daemon ...
Apr 18 08:48:46 linuxquad htmlgend[11686]: <1240062526746> : generating to /usr/local/var/wview/img
Apr 18 08:48:46 linuxquad htmlgend[11686]: <1240062526746> : templates at /usr/local/etc/wview/html
Apr 18 08:48:46 linuxquad htmlgend[11686]: <1240062526747> : !! Dual units will be displayed !!
Apr 18 08:48:46 linuxquad htmlgend[11686]: <1240062526747> : Tag Search red-black tree: max black node tree height: 7
Apr 18 08:48:46 linuxquad wvalarmd[11691]: <1240062526747> : ALARM daemon not enabled - exiting...
Apr 18 08:48:46 linuxquad wvcwopd[11696]: <1240062526747> : radlib: wvcwopd started as a daemon ...
Apr 18 08:48:46 linuxquad wvcwopd[11696]: <1240062526748> : CWOP daemon is NOT enabled - exiting...
Apr 18 08:48:46 linuxquad wviewftpd[11701]: <1240062526749> : radlib: wviewftpd started as a daemon ...
Apr 18 08:48:46 linuxquad wviewftpd[11701]: <1240062526750> : ftp daemon disabled - exiting...
Apr 18 08:48:46 linuxquad wviewsshd[11706]: <1240062526751> : radlib: wviewsshd started as a daemon ...
Apr 18 08:48:46 linuxquad wviewsshd[11706]: <1240062526752> : ssh daemon disabled - exiting...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526753> : radlib: wvpmond started as a daemon ...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wviewd: 0
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wviewd process monitoring is disabled
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: htmlgend: 0
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: htmlgend process monitoring is disabled
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wvalarmd: 120
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: pid file /usr/local/var/wview/wvalarmd.pid not present, disable monitoring...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wvcwopd: 120
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: pid file /usr/local/var/wview/wvcwopd.pid not present, disable monitoring...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wvhttpd: 120
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: pid file /usr/local/var/wview/wvhttpd.pid not present, disable monitoring...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: wviewsqld: 600
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : PMON: pid file /usr/local/var/wview/wviewsqld.pid not present, disable monitoring...
Apr 18 08:48:46 linuxquad wvpmond[11711]: <1240062526829> : running...
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527294> : running...
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527294> : received station info from wviewd: 20090414 22:40:00
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527298> : htmlmgrInit: 51 built-in image definitions added
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527306> : htmlmgrInit: 0 user image definitions added
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527314> : htmlmgrInit: 14 templates added
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527314> : htmlmgrInit: forecast html tags are disabled - /usr/local/etc/wview/forecast.conf not found...
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527316> : initializing barometric pressure trend
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527316> : initializing historical stores (this may take some time...)
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527316> : htmlHistoryInit: DAY: samples=0
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527325> : htmlHistoryInit: DAY: samples=50
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527333> : htmlHistoryInit: DAY: samples=100
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527341> : htmlHistoryInit: DAY: samples=150
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527349> : htmlHistoryInit: DAY: samples=200
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527357> : htmlHistoryInit: DAY: samples=250
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527364> : htmlHistoryInit: DAY: samples=288
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527364> : htmlHistoryInit: WEEK: samples=0
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527372> : htmlHistoryInit: WEEK: samples=50
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527393> : htmlHistoryInit: WEEK: samples=100
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527401> : htmlHistoryInit: WEEK: samples=150
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527404> : htmlHistoryInit: WEEK: samples=168
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527404> : htmlHistoryInit: MONTH: samples=0
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527412> : htmlHistoryInit: MONTH: samples=50
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527421> : htmlHistoryInit: MONTH: samples=100
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527429> : htmlHistoryInit: MONTH: samples=150
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527437> : htmlHistoryInit: MONTH: samples=200
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527445> : htmlHistoryInit: MONTH: samples=250
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527453> : htmlHistoryInit: MONTH: samples=300
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527461> : htmlHistoryInit: MONTH: samples=350
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527470> : htmlHistoryInit: MONTH: samples=400
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527478> : htmlHistoryInit: MONTH: samples=450
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527486> : htmlHistoryInit: MONTH: samples=500
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527494> : htmlHistoryInit: MONTH: samples=550
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527515> : htmlHistoryInit: MONTH: samples=600
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527523> : htmlHistoryInit: MONTH: samples=650
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527527> : htmlHistoryInit: MONTH: samples=672
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527550> : htmlHistoryInit: YEAR: samples=0
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527578> : htmlHistoryInit: YEAR: samples=50
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527607> : htmlHistoryInit: YEAR: samples=100
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527635> : htmlHistoryInit: YEAR: samples=150
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527664> : htmlHistoryInit: YEAR: samples=200
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527692> : htmlHistoryInit: YEAR: samples=250
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527721> : htmlHistoryInit: YEAR: samples=300
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527749> : htmlHistoryInit: YEAR: samples=350
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527769> : htmlHistoryInit: storing day history for Tue Apr 14 00:05:00 2009
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527783> : htmlHistoryInit: YEAR: samples=365
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527784> : HILOW: OK
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527785> : NOAA DB: OK
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527785> : NOAA: initilizing reports (this may take some time...)
Apr 18 08:48:47 linuxquad htmlgend[11686]: <1240062527785> : NOAA DB: syncing 19700101 => 20090417
Apr 18 08:49:01 linuxquad htmlgend[11686]: <1240062541977> : NOAA DB: done: 4 HILOW records => 1 NOAA records
Apr 18 08:49:02 linuxquad htmlgend[11686]: <1240062542006> : NOAA Generate: creating monthly NOAA reports starting 200904
Apr 18 08:49:02 linuxquad htmlgend[11686]: <1240062542029> : NOAA Generate: creating yearly NOAA reports starting 2009
Apr 18 08:49:02 linuxquad htmlgend[11686]: <1240062542033> : ARCREC: initializing archive browser files (this may take some time...)
Apr 18 08:49:03 linuxquad htmlgend[11686]: <1240062543000> : starting html generation in 1 mins 7 secs
Apr 18 08:49:03 linuxquad htmlgend[11686]: <1240062543000> : doing initial html generation now...
Apr 18 08:49:03 linuxquad htmlgend[11686]: <1240062543113> : Generated: 113 ms: 51 images, 14 template files
Linux systems tend to have other IPC objects defined - you do not want to
disturb those. The wview objects are discernable by the "KEY" values:
126977 (0x1F001) - 126979 (0x1F003) (wview-specific)
267386881 (0xFF00001) - 267386882 (0xFF00002) (radlib general)
If, after shutting down wview, any of the IPC objects associated with wview
(or radlib) still remain, you will need to remove them manually using the
"ipcrm" command. This is normally caused by failed wview starts when
initially installing wview with improper configuration or by a faulty wview
start/stop script which is leaving wview processes running.
Log Verbosity refers to status level logs - "normal" operation informational
messages. These can be quite interesting when first starting wview or after
an upgrade. But when enabled it can generate a bit of log file volume.
While wview is running, you can toggle the log verbosity for a given wview
daemon by sending a HUP signal to that process (this also causes a reload of
image/html configuration for htmlgend). Below are the suitable shell commands
for each daemon:
kill -s HUP `cat $prefix/var/wview/wviewd.pid`
kill -s HUP `cat $prefix/var/wview/htmlgend.pid`
kill -s HUP `cat $prefix/var/wview/wviewftpd.pid`
kill -s HUP `cat $prefix/var/wview/wviewsshd.pid`
kill -s HUP `cat $prefix/var/wview/wvalarmd.pid`
kill -s HUP `cat $prefix/var/wview/wvcwopd.pid`
kill -s HUP `cat $prefix/var/wview/wvhttpd.pid`
Wireless Reception
If you are missing archive records, receiving bad archive records, or your
current conditions values don't update as expected, you may have problems
with the wireless reception from the Vantage Pro Integrated Sensor Suite
(ISS). You can access a chart which displays the percentage of successful
packets received at: http://[your_weather_site_url]/rxcheck.png.
If the graph displays points equal to zero or at very low values, you should
investigate why your wireless reception is so poor. Possible solutions
include: changing the gain on your VP Console, moving your VP Console to
improve reception or perhaps moving your ISS for better reception.
Serial Interface Problems
If you see a log message similar to:
daemonStartProcState: lat and long failed
or periodic logs similar to:
wakeupConsole: Read ERROR!
or:
wakeupConsole: Invalid data: FE 13 (data values "FE 13" will vary)
you have a serial interface problem. The best test is to stop wview if it
is running and use vpconfig to verify your serial interface.
You should be able to run "vpconfig [device] show" repeatedly without any
failures being reported (see section 15.6 for vpconfig usage).
Possible culprits are:
Comm Problems
If you see error messages like "NMEA: nmea0183Init: XXX failed!" when
starting wview, it is a good indication that the comm settings on the WXT510
have not been set correctly. Be sure you run wxt510config BEFORE your first
wview start. wxt510config searches through all possible comm setting
combinations until it "fimds" the WXT510, then it sets the comm parameters
properly for wview.
Sensor Problems
If you see an error similar to:
"NMEA: nmea0183GetReadings: 0x7FC1: not all sensors updated..."
then there is the possibility that the THP sensor connector header under the
very top of the WXT510 is not making good contact. You can remove the long
screws which hold the entire station together then remove the 3 very small
screws which retain the upper PCB cover. Take care to mate the small header
in the middle well then hold the cover in place while screwing the retaining
screws back in. Make sure you do not dislodge the ribbon cable connections.
raddebug is a general debug utility which is installed when you install
radlib. It can be used to display semaphore usage, buffer usage and
radmrouted statisitics:
|
#> raddebug 1 $prefix/var/wview |
It will output something like:
Attached to radlib system 1: UP 0 years, 0 months, 0 days, 5 hours, 17 minutes, 26 seconds
Buffer Allocation by Size:
Dumping index 0: size 64: Free/Total 64/64
Dumping index 1: size 128: Free/Total 128/128
Dumping index 2: size 256: Free/Total 244/256
Dumping index 3: size 512: Free/Total 256/256
Dumping index 4: size 1024: Free/Total 128/128
Dumping index 5: size 2048: Free/Total 64/64
Dumping index 6: size 4096: Free/Total 32/32
Buffer Summary:
Total Free: 916
Total Allocated: 12
Total Allocations Since Started: 121628
Semaphore Info:
INDEX COUNT WAITERS ZCNT PID
0 0 0 0 0
1 0 0 0 0
2 1 0 0 63615
3 0 0 0 0
4 1 0 0 61597
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0
10 0 0 0 0
11 0 0 0 0
12 0 0 0 0
13 0 0 0 0
14 0 0 0 0
15 0 0 0 0
raddebug[63615]: [3310611880] : radlib: raddebug started ...
Dumping message router stats to the system log file...
Then view the message router (radmrouted) statistics:
|
#> sudo tail -n 400 -f /var/log/syslog |
With output like:
raddebug[63615]: [3310611880] : radlib: raddebug started ...
radmrouted[61576]: [3310611917] : ---------- Message Router Totals: TX:0000001851 RX:0000001662 ----------
radmrouted[61576]: [3310611917] : Name MSGS TX MSGS RX TXERRS RXERRS
radmrouted[61576]: [3310611917] : -------------- ---------- ---------- ---------- ----------
radmrouted[61576]: [3310611917] : wviewd 1021 641 0 0
radmrouted[61576]: [3310611917] : wviewsqld 1 64 0 0
radmrouted[61576]: [3310611917] : wvalarmd 1 318 0 0
radmrouted[61576]: [3310611917] : htmlgend 637 700 0 0
radmrouted[61576]: [3310611917] : wvcwopd 1 64 0 0
radmrouted[61576]: [3310611917] : wvhttpd 1 64 0 0
radmrouted[61576]: [3310611917] : raddebug 0 0 0 0
radmrouted[61576]: [3310611917] : --------------------------------------------------------------------------
Typically wview processes run in the background as daemons which among other
properties implies that they have no controlling terminal and stdin/stdout/stderr
have been closed. This makes it difficult to debug using traditional tools
such as gdb since the process that gdb starts is forked of to a daemon and
closes.
To allow foreground process debugging for the wview processes, a command line
argument is defined which forces all process to run in the foreground and
not as daemons. "-f" given as an argument to any wview process binary will
cause it to run in the foreground thus enabling use of gdb or other debugging
tools. This should only be done for debugging or analysis purposes and
not for production environments.
Note that some wview startup scripts support the argument "start-trace" which
runs the processes in the foreground and traces their system calls using the
strace unix utility. Output of strace is placed in the file
${prefix}/var/wview/[process_name].trace (i.e., htmlgend.trace).
| /stations/common | Source directory for the station daemon |
| /stations/VantagePro | Source directory for the Davis Vantage Pro/Pro2 interface |
| /stations/Simulator | Source directory for the station simulator |
| /stations/WXT510 | Source directory for the Vaisala WXT510 interface |
| /stations/WS-2300 | Source directory for the La Crosse WS-23XX interface |
| /stations/WMR918 | Source directory for the Oregon Scientific WMR9X8 interface |
| /htmlgenerator | Source directory for the file generator |
| /common | Common source and build files |
| /wviewmgmt | Source directory for the wview management web site |
| /examples/conf | Example config files (see description below) |
| /examples/html/classic | Example HTML template files and tag description file parameters.txt (see description below) |
| /examples/html/chrome | Example HTML template files and tag description file parameters.txt (see description below) |
| /utilities/archive-be2le | Source directory for the wview archive directory Big-Endian to Little-Endian command line convertor |
| /utilities/archive-le2be | Source directory for the wview archive directory Little-Endian to Big-Endian command line convertor |
| /utilities/wlk2sqlite | Source directory for the wview WLK to SQLite3 archive convertor |
| /utilities/sqlite2wlk | Source directory for the wview SQLite3 to WLK archive convertor |
| /configure | build configuration script to be executed before building wview |
| /cross-compile | Contains example configure scripts for cross compilation. libz, libpng, libgd, librad and wview scripts are included (and should be built in that order). Use these scripts instead of "./configure" to configure these libraries for cross compilation. These scripts configure for arm-linux targets but could easily be edited for a different target. |
| /scripts | Contains example helper scripts for wview installation and update. |
| /ChangeLog | The release notes file |
| /wview-User-Manual.html | This file, the User Manual |
| /wview-Quick-Start.html | Quick Start Guide |
| /wview-Quick-Start-MacOSX.html | MacOSX-specific Quick Start Guide |
| /wview-Quick-Start-Debian.html | Debian-specific Quick Start Guide |
| /UPGRADE |
Notes on upgrading from previous versions |
The wview station API is prototyped in ../stations/common/station.h. For full details of the functional requirements please refer to station.h and existing station interfaces.
Init Function
Can Be Asynchronous - event indication required.
MUST (in this order):
Optional:
Initialize a state machine or any other construct required for the
station interface - these should be stored in the 'stationData' store
(see the VantagePro station interface for an example of this).
'archiveIndication' - indication callback used to pass back an archive
record generated as a result of 'stationGetArchive' being called; should
receive a NULL pointer for 'newRecord' if no record available; only used
if 'stationGeneratesArchives' flag is set to TRUE by the station interface.
extern int stationInit
(
WVIEWD_WORK *work,
void (*archiveIndication)(ARCHIVE_RECORD *newRecord)
);
Exit Function
Cleans up any data created during init call.
extern void stationExit (WVIEWD_WORK *work);
stationGetPosition Function
Station-supplied function to retrieve positional info (lat, long, elev) -
should populate WVIEWD_WORK fields: latitude, longitude, elevation.
Synchronous.
If station does not store these parameters, they can be retrieved from the
wview-conf.sdb file (see the 'stationGetConfigValue' utilities below) - user
must choose station type "NameOfStation" when running the wviewconfig
script. Returns: OK or ERROR.
extern int stationGetPosition (WVIEWD_WORK *work);
stationSyncTime Function
Station-supplied function to indicate a time sync should be performed
if the station maintains time, otherwise may be safely ignored. Can be
asynchronous. Returns: OK or ERROR.
extern int stationSyncTime (WVIEWD_WORK *work);
stationGetReadings Function
station-supplied function to indicate sensor readings should be performed -
should populate 'work' struct: loopPkt (see datadefs.h for minimum field
requirements). Can Be Asynchronous.
Indicate readings are complete by sending the STATION_LOOP_COMPLETE_EVENT
event to this process
(radProcessEventsSend (NULL, STATION_LOOP_COMPLETE_EVENT, 0)).
extern int stationGetReadings (WVIEWD_WORK *work);
stationGetArchive Function
Station-supplied function to indicate an archive record should be
generated - MUST populate an ARCHIVE_RECORD struct and indicate it to
'archiveIndication' function passed into 'stationInit'. Asynchronous -
callback indication required. Returns: OK or ERROR.
Note: 'archiveIndication' should receive a NULL pointer for the newRecord
if no record is available.
Note: This function will only be invoked by the wview daemon if the
'stationInit' function set the 'stationGeneratesArchives' to TRUE.
extern int stationGetArchive (WVIEWD_WORK *work);
stationDataIndicate Function
Station-supplied function to indicate data is available on the station
interface medium (serial or ethernet) - it is the responsibility of the
station interface to read the data from the medium and process
appropriately. The data does not have to be read within the context of
this function, but may be used to stimulate a state machine. Can be
asynchronous.
extern void stationDataIndicate (WVIEWD_WORK *work);
stationIFTimerExpiry Function
Station-supplied function to indicate the interface timer has expired -
It is the responsibility of the station interface to start/stop the
interface timer as needed for the particular station requirements. The
station interface timer is specified by the 'ifTimer' member of the
WVIEWD_WORK structure. No other timers in that structure should be
manipulated in any way by the station interface code. Can be asynchronous.
extern void stationIFTimerExpiry (WVIEWD_WORK *work);
STATION_INIT_COMPLETE_EVENT used to asynchronously indicate station-
specific initialization is complete
STATION_LOOP_COMPLETE_EVENT used to asynchronously indicate that a
current readings acquisition is complete