unsubbed.co

WeeWX

WeeWX is a self-hosted self-hosting tools tool that provides software for your weather station.

Open-source weather station software, honestly reviewed. No marketing fluff — just what you actually get when you self-host it.

TL;DR

  • What it is: Free, open-source (GPL-3.0) Python software that collects data from your physical weather station, generates HTML pages and graphs, and publishes to weather networks and your own website [README].
  • Who it’s for: Weather enthusiasts, hobbyists, and technically curious homeowners who own a physical weather station and want full control over their data — not a managed SaaS service standing between them and their readings [1][3].
  • Cost: $0 for the software. Runs on a Raspberry Pi (~$35 one-time) or a $5/mo VPS. Compare that to proprietary manufacturer software that locks your data behind their cloud [README].
  • Key strength: Genuinely impressive hardware support — 70+ station models from Davis, Oregon Scientific, Fine Offset, LaCrosse, AcuRite, and dozens more. If you own a weather station, WeeWX probably supports it [3][README].
  • Key weakness: This is a Python daemon you configure via text files. There is no slick GUI setup wizard. If the command line makes you anxious, budget extra time or find someone to set it up for you [1].

What is WeeWX

WeeWX is a Python daemon that runs continuously on a Linux machine (or Raspberry Pi, or macOS), reads data from a physical weather station, stores it in SQLite or MySQL, and generates static HTML pages, plots, and summary reports. It can push that data to popular weather networks like Weather Underground, CWOP, PWSweather, Windy, and Open Weathermap. It can also feed InfluxDB via MQTT for anyone building a proper metrics stack [README].

The project was written by Tom Keffer in the winter of 2008-2009, originally to drive a Davis VantagePro2 on a Linux box. He had been using wview — a C-based weather system at 45,000+ lines of code that was powerful but opaque and hard to customize. WeeWX is his answer: roughly 15,000 lines of Python for the core, another 15,000 for hardware drivers, and a micro-kernel architecture designed to be read and extended by a competent developer [website]. That philosophy shows. The code is not magic. It is legible Python with a clean plugin system, which is why thousands of stations worldwide run it and the third-party extension ecosystem is healthy [README].

As of this review, the GitHub repository sits at 1,150 stars. That number undercounts the actual install base significantly — WeeWX users tend to be hobbyists who install software and get on with their lives rather than starring repos [README].


Why people choose it

The honest answer is: because the alternatives are worse.

Proprietary weather station software — the kind Davis or Fine Offset ship with their hardware — is either Windows-only, requires an ongoing cloud subscription to get data off the station, or both. Weather Underground, which used to offer a free data-sharing service for personal weather stations, has degraded its API access over the years. The commercial path for a Davis Vantage Pro owner in 2026 runs through WeatherLink.com, Davis’s subscription service. WeeWX offers an exit from that dependency entirely: your data, your machine, your database, no ongoing subscription required [README][1].

The topslakr.com author [1] — a self-described weather nerd who finally bought a full weather station kit — captures the use case cleanly: someone who has real hardware, wants real data, and wants it running on their own Linux box rather than routed through a vendor’s cloud. The install walkthrough he documents on CentOS 8 shows someone who is comfortable with dnf install and python3 setup.py install but is not an enterprise sysadmin — WeeWX sits squarely in the technically enthusiastic hobbyist tier [1].

LinuxLinks [3] emphasizes the breadth of the feature set relative to the project’s scope: software simulator for testing, celestial almanac calculations (moon phase, sunrise/sunset, etc.), calibration and anomaly filtering, multiple skin support, full localization. For a volunteer-maintained project with a small core team, that feature surface is substantial [3].

What you almost never hear about WeeWX is switching costs going the other direction. Nobody migrates from WeeWX to something more expensive. The data is in SQLite or MySQL. The configs are text files. You own it completely.


Features

Based on the README and primary documentation:

Data collection and storage:

  • Continuous polling of supported weather station hardware via USB, serial, or network [README]
  • Storage in SQLite (default) or MySQL [README][3]
  • Calibration corrections and anomalous value filtering — important for consumer-grade sensors that drift [README][3]
  • Data aggregation: daily, monthly, yearly summaries [README]

Reporting and display:

  • Generates static HTML pages and PNG plots on a configurable schedule [README]
  • Multiple skin support — the look of your weather site is fully customizable [README][3]
  • Publish to your own website via FTP, FTPS, or rsync [README][3]
  • Extensive celestial almanac: sunrise, sunset, moon phase, solstices [README][3]
  • Internationalized UI and localized date/time formatting [README]
  • US and metric unit systems [README]

Upstream weather services:

  • Weather Underground, CWOP, PWSweather, WOW, WOW-BE, AWEKAS, Windy, Open Weathermap, WeatherBug, Weather Cloud, Wetter, Windfinder [README]

Data pipelines:

  • MQTT publishing for integration with Home Assistant, Node-RED, Grafana, or any MQTT consumer [README]
  • InfluxDB uploader — pairs naturally with a Grafana dashboard for a proper time-series metrics stack [README]

Hardware support (70+ devices including):

  • Davis Vantage Pro, Pro2, Vue, Envoy [README][3]
  • Oregon Scientific WMR100, WMR200, WMR300 [README][3]
  • Fine Offset WH10xx, WH20xx, WH30xx, WH2600, HP1000, GW1000/GW1100/GW2000 (including Ecowitt) [README]
  • LaCrosse WS-23XX, WS-28XX, GW1000U bridge [README]
  • AcuRite 5-in-1, Atlas [README]
  • Software Defined Radio (SDR) [README]
  • One-wire sensors [README]

Extensibility:

  • Plugin architecture: third-party extensions available via the project wiki [README]
  • Software simulator built in — useful for testing without hardware [3]

Pricing: SaaS vs self-hosted math

WeeWX itself costs nothing. GPL-3.0, no license fees, no “community vs enterprise” split, no commercial gating of features [README].

What you need to run it:

Hardware:

  • Raspberry Pi 4 (2GB RAM): roughly $35–45 one-time. More than enough for a single station with reports and web publishing.
  • Alternatively: any Linux VPS at $4–8/mo if you want it cloud-hosted and remotely accessible.

The alternative — manufacturer SaaS:

  • Davis Instruments’ WeatherLink.com charges for data retention, API access, and advanced features on a subscription basis. Exact current pricing is not available in this review’s source data, but the friction of needing an active account to access your own station’s historical data is well-documented in hobbyist communities.
  • WeatherLink Live hardware adds an internet bridge device cost on top of the subscription.

Concrete math: A Raspberry Pi at $40 + a $15 microSD card = $55 one-time. Electricity draw is under 5W, adding roughly $3–5/year. A WeeWX install running for five years costs approximately $70–75 in hardware and electricity. Any subscription service charging $5–10/mo costs $300–600 over the same period. The gap only grows with time.

For users already paying Weather Underground’s subscription tier or locked into a Davis cloud plan, the migration math is clear. The software cost is zero. The real cost is setup time [1][README].


Deployment reality check

The topslakr.com install walkthrough [1] is the most honest documentation of what the setup actually involves. It is not a horror story, but it is not a five-minute DigitalOcean one-click either.

What you need:

  • A Linux machine or Raspberry Pi with Python 3.7+ [README]
  • Python packages: configobj, Cheetah, Pillow, pyusb, pyserial, ephem (for almanac), and a database client if using MySQL [1]
  • A web server (Apache or nginx) if you want to serve the generated HTML locally or publicly [1]
  • Your weather station physically connected (USB, serial, or network depending on model)

Installation paths:

  • Debian/Ubuntu: package install via .deb — the officially supported easy path [README]
  • Red Hat/CentOS: .rpm available, or install from source tarball [1][README]
  • pip/Poetry: modern Python install for those who prefer virtual environments [README]
  • macOS, *BSD, Solaris: supported but less documented [README]

What can go sideways:

The topslakr.com author [1] notes several CentOS-specific friction points: EPEL repository setup, the need to install ephem via pip because no RPM package exists, SELinux policy conflicts with web server access, and the fact that the default install path from the tarball differs from the distro package paths — which means standard documentation may not match your file locations if you mix methods [1].

The configuration file (weewx.conf) is INI-style and well-documented, but you will need to look up your specific station’s driver name and configuration keys. For common hardware like Davis or Fine Offset, this is straightforward. For less common stations, budget time with the wiki [README].

Realistic time estimates:

  • Technically comfortable Linux user with supported hardware: 1–2 hours to a working, reporting station.
  • Hobbyist following a guide: 3–6 hours including web server setup, domain configuration, and getting reports to publish correctly.
  • No Linux experience: difficult. Find someone to help, or use the Debian package path which removes the most friction [1][README].

Community support runs through a Google Group (groups.google.com/group/weewx-user) rather than Discord or Slack — this is a signal of the project’s age and user demographic, not a quality problem [README].


Pros and cons

Pros

  • Genuinely free. GPL-3.0 with no feature gating. The full feature set — all hardware drivers, all upload services, all reporting — is in the free package [README].
  • Hardware support breadth. 70+ station models across every major consumer brand. If you bought a weather station in the last 15 years, there is a reasonable chance WeeWX supports it [README][3].
  • MQTT and InfluxDB native. Integrates cleanly with modern monitoring stacks (Grafana, Home Assistant, Node-RED) without third-party middleware [README].
  • You own the data. SQLite or MySQL, locally stored, queryable directly. No vendor lock-in, no API deprecation risk [README][1].
  • Extensible and legible. The micro-kernel architecture makes adding a custom service or uploader a real Python extension, not a config hack [README].
  • Active enough to trust. Thousands of worldwide deployments, ongoing commits, maintained documentation. Not abandonware [README].
  • Runs on minimal hardware. A Raspberry Pi Zero 2W handles it. No cloud instance required [README].

Cons

  • No GUI. Configuration is entirely via text file. There is no web-based setup wizard, no admin panel during initial setup [1].
  • Linux assumed. Windows “support” is informal and undocumented. macOS works but is not the primary target [README].
  • Setup friction varies by hardware. Common stations (Davis, Fine Offset) are well-documented. Obscure hardware may require digging through the wiki or mailing list [1].
  • Reporting design is dated. The default skins look like 2009 web design, because they are. Custom skins exist but require Cheetah template knowledge to produce something modern [README].
  • Small active developer team. Tom Keffer, Matthew Wall, and Gary Roderick are the named copyright holders. A three-person core team is functional but not bulletproof for long-term maintenance [README].
  • Google Groups for support. The community mailing list format is functional but slow compared to real-time chat [README].
  • No mobile app. WeeWX generates static HTML. Viewing your station data on mobile means either a responsive skin (available from the community) or an external weather service that pulls your uploaded data [3].

Who should use this / who shouldn’t

Use WeeWX if:

  • You own a physical weather station from a supported brand and want software that isn’t tied to the manufacturer’s cloud or subscription.
  • You run Linux (even casually) and are comfortable editing configuration files.
  • You want your weather data in a real database, queryable directly, feeding Grafana or Home Assistant.
  • You are happy with a Raspberry Pi as your always-on server.
  • You want to publish to Weather Underground, Windy, CWOP, or multiple services simultaneously without juggling vendor portals.

Skip it (use manufacturer software) if:

  • You want a plug-and-play experience with a GUI from first boot. Manufacturer apps — despite their limitations — get you to a display in minutes, not hours.
  • Your station is not on the supported hardware list and you’re unwilling to write a driver.

Skip it (use Cumulus MX) if:

  • You run Windows and want a GUI-configured alternative with similar feature coverage. Cumulus MX is free, Windows-native, and covers much of the same ground.

Skip it (use a commercial gateway) if:

  • You want cellular or cloud failover, professional-grade uptime guarantees, or your station is in a remote location where you cannot maintain a Raspberry Pi.

Alternatives worth considering

  • Cumulus MX — free, Windows-primary (Mono on Linux), GUI-configured, similar hardware support. Good choice for users who don’t want text-file configuration.
  • Weather Display — commercial ($60 one-time), Windows-focused, very long-established. More polished UI than WeeWX’s defaults but costs money and is closed source.
  • Meteobridge — commercial hardware/software bridge ($100+) that handles station → weather service uploads without a full Linux install. Less flexible but genuinely turnkey.
  • Home Assistant weather integrations — if you’re already running Home Assistant, many stations integrate directly and store data in its recorder database. Less purpose-built for weather reporting but avoids a second server.
  • rtl_433 + InfluxDB + Grafana — for SDR-based sensor reading, building your own pipeline with rtl_433 feeding InfluxDB gives more flexibility than WeeWX at the cost of more assembly required.

For most hobbyists with a mid-range weather station (Davis, Fine Offset, AcuRite), the realistic shortlist is WeeWX vs Cumulus MX. Pick WeeWX if you’re on Linux and comfortable with text config. Pick Cumulus MX if you’re on Windows or want a GUI.


Bottom line

WeeWX does one thing and does it well: it takes data from your physical weather station and puts it somewhere useful — your own database, your own website, and the weather networks you choose. It has been doing this reliably since 2009, it runs on a $35 Raspberry Pi, and it costs nothing. The trade-off is real: this is software configured via text files on Linux, not a consumer product with an onboarding flow. If you have a weather station gathering dust because the manufacturer’s app was too limiting or the cloud subscription felt wrong, WeeWX is the correct answer. If you’ve never touched a Linux terminal, the correct answer is to find someone who has and ask them for an afternoon.


Sources

  1. Topslakr.com“Installing WeeWx on Centos 8 – The Basics” (Jul 2020). https://topslakr.com/2020/07/installing-weewx-on-centos-8-the-basics/
  2. Topslakr.com“WeeWx tag archive”. https://topslakr.com/tag/weewx/
  3. LinuxLinks“WeeWX – software for your weather station”. https://www.linuxlinks.com/weewx-software-weather-station/

Primary sources:

Features

Analytics & Reporting

  • Metrics & KPIs

Localization & Accessibility

  • Multi-Language / i18n