instantlinux/weewx repository overview

⁠weewx

Weather station software WeeWX

This is a multi-architecture image for AMD, ARM, Intel, Raspberry Pi: see the platform badge above for supported platforms. This includes WeeGreen skin; see the live site⁠ for an example.

⁠Usage

First create secrets as defined below, in /var/adm/admin/secrets. Ensure your weather station device (usually /dev/ttyUSB0) is read/writeable by user "weewx" (uid 2071) or by gid 20 (group "dialout") via udev rules--all other parameters can be set as below.

Then deploy this service with docker-compose; see the example docker-compose.yml. Available environment variables are below.

To create the external-facing web site which runs as a separate containerized service, use the simple nginx.conf configuration provided here⁠ under docker swarm with the docker-compose-nginx.yml stack definition, or (even easier) under Kubernetes deploy the wx-nginx.yaml⁠ resource definition.

⁠Variables

You can volume-mount a different skin to a subdirectory of /home/weewx/skins if you prefer one that isn't already included.

If OPTIONAL_ACCESSORIES is specified, you must upgrade database (see below).

⁠Secrets

⁠Upgrading

⁠To 4.x

Version 4 supports an optional new database schema called wview_extended. The official WeeWX Upgrade Guide⁠ inexplicably omits any information about how to migrate your database; here's a rough outline of what you need to do if you have existing 3.x data and want to migrate (in order to gain new features such as AQI):

• Backup your current database
• Create a blank database weewx_a_new with same access grants
• Launch the docker container with 4.x and invoke ~weewx/bin/wee_database --reconfigure
• After the above operation completes (takes many minutes, could be over an hour for several years' worth data), stop any running copy of weewx
• Replace database weewx_a with contents of weewx_a_new (for mariadb/mysql, you have to dump/import the data)
• Make sure only one table archive exists in the database: reconfigure only generates that table, not the 50+ daily summary tables; if present they are likely to trigger a ViolatedPrecondition exception
• Restart weewx and wait another lengthy period for it to automatically rebuild the daily summary tables (you can track progress using SELECT COUNT(*) FROM archive_day_outTemp;)

Because the new schema contains almost twice as many columns, future backups will require almost twice as much storage.

⁠Notes

This can run in kubernetes but not in swarm because it needs to attach the weather stations as devices. Kubernetes may be more secure than docker-compose, because docker-compose requires that secrets be stored as plain-text files, but the container needs to be run in privileged mode to access the weather-station device(s).

Example docker-compose.yml⁠, helm chart⁠ and kubernetes.yaml⁠ files are included here. See the Makefile in k8s⁠ to launch with kubernetes.

Sadly, forecasts are no longer supported. It was once possible to integrate weather-service forecasts with the observational data collected and uploaded by this software. The online API was discontinued in a September 2018 decision by IBM after the company acquired Weather Underground. Also, the weewx-forecast module never got updated from 3.3.2 to support python3.

Tide info for US locations can be generated by a library called xtide⁠; there's no binary package for it in Alpine Linux so it has to be built from source within Dockerfile. Support for this was lost in 2018 when the forecasting UI quit working.

Output logging from weewx is a bit of a mess: when running in foreground, a lot of verbose clutter appears on stdout; the real logs go to syslog and there's no configuration method to send these elsewhere (like stdout to conform to Docker's logging standard). So the SYSLOG_DEST environment variable provided here can provide a way to send proper logging (via the rsyslogd process included in this image) to a central syslog service.

⁠Contributing

If you want to make improvements to this image, see CONTRIBUTING⁠.