WeeWX - Open source software for your weather station

WeeWX is a free, open source, software program, written in Python, which interacts with your weather station to produce graphs, reports, and HTML pages. It can optionally publish to weather sites or web servers. It uses modern software concepts, making it simple, robust, and easy to extend. It includes extensive documentation.

WeeWX runs under most versions of Linux, as well as macOS, *BSD, and Solaris. Many users are running on the Raspberry Pi. The images on this page and throughout this web site are from sample stations running WeeWX.

Thousands of stations throughout the world run WeeWX, many of whom have opted-in to be shown on our station map.

Key features:

  • Support for many popular weather stations;
  • Uploads to popular weather sites including WeatherUnderground, PWSweather.com, CWOP,WOW, and AWEKAS and others;
  • Uploads to your website using FTP or rsync;
  • Extensive celestial almanac ;
  • Ability to create or modify skins (the look and feel of your weather site);
  • Support for localization ;
  • Simple, but extensible templating system;
  • Native support for US or Metric unit systems;
  • Support for sqlite or MySQL databases;
  • Calibration corrections;
  • Filtering of anomalous values;
  • An easy to understand, simple, extensible micro-kernel architecture;
  • Ability to extend weeWX with new services and reports.

Last, but definitely not least,



Added so WeeWX users have a place to help each other with the application.

1 Like

You forgot the most important link…to the weewx WeatherFlow UDP station driver!



I didn’t forget. It has a link on this forum.


Hi Arthur @vreihen
I tried this:
"Installation should be as simple as grabbing a .ZIP download of this
entire project from the GitHub web interface, and then running this

wee_extension --install weatherflow-udp-master.zip"

But Perhaps I dont have things in their correct locations or permissions because it doesnt work for me.
Could you add any specific folder location to save it to (I saved it to /home/pi/Downloads), and location to run the command from (I tried from downloads and from /etc/weewx), and if I need to change any file permissions or something.

So then I tried copying the sensor_map stanza in the driver
stanza into my weewx.conf file but I will have to spend some more time figuring how to do that because I couldnt get my new file to save and I have run out of time now.

note: I got weewx running in my browser using the simulator ok.

And another dummies question does weewx create its own database from the udp data or can I choose to change it to read the data in the ArchiveSW database?
cheers Ian :slight_smile:

I still need to back-port the revised instructions (and a whole lot of other good wee_config functionality stuff) from my new Atmocom-UDP driver to the weatherflow-udp driver. Here’s a quick/untested edit:



I believe that I have correctly followed the instructions provided by weewx
in order to provide the complete weewx extension package layout here.

extensions · weewx/weewx Wiki · GitHub

  1. Starting with a fresh weewx installation, choose the “Simulator” station
    driver during the package install process.

  2. Next, grab a .ZIP download of this entire project from the GitHub web

    wget -O weatherflow-udp-master.zip https://github.com/captain-coredump/weatherflow-udp/archive/master.zip

  3. Install the driver package by running this command:

    wee_extension --install weatherflow-udp-master.zip

If you are using a Debian-based Linux (like Ubuntu or Raspbian on a Pi), the “sudo” command is probably needed for one or more of these commands to give it admin permissions.

WeeWX creates/manages its own database, with a well-documented schema that can be expanded with additional observation types. Let it do its thing. I’m planning to import my historical weather data from another program into the WeeWX database this weekend, because the Belchertown WeeWX skin can finally make it useful…

[Belchertown WeeWX skin on my new 10-inch Amazon Fire Tablet]


I can attest that the weatherflow-UDP driver is just-another-driver that installs fine in the usual weewx way. @iladyman should definitely read up in the weewx google group to learn the software.

We also need far better problem descriptions than

Regardless, the procedure I use is the same as any other driver:

  • download the extension

  • run wee_extension to install it

    • it’s usually better provide the full pathname to wee_extension in your command.

    • If you want to provide the full pathname to the .zip file you’re installing, that works too. The extension installer is very flexible

      If you installed via setup.py then the path is /home/weewx/bin/wee_extension. If you installed from the .dpkg pre-packaged weewx, the path would be /usr/share/bin/wee_extension I think - consult the weewx user guide 'where to find things` for the authoritative answer (sorry, I can’t check currently)

  • edit your weewx.conf to add the stanza mapping the WeatherFlow data to weewx db elements. The README.md on @vreihen’s github site provides examples. If you want to use wee_config --reconfigure that should work too. All that does is give you a menu of drivers to pick from.

  • personally, I’d stop weewx if it’s running and delete the weewx.sdb file, and delete the contents of the public_html tree so it comes up cleanly as a new installation

  • I’d recommend setting debug=1 in weewx.conf for more verbose logging

  • start weewx. Watch your syslog. In 5 minutes you should see data in your public_html tree.


I would edit weewx.conf manually at this point. I never tested it myself, and the version that’s online has no [intentional] support for that feature.

A few months ago, I was drafted to write a UDP driver for the new Atmocom hub that’s still in beta. I started by forking the existing WF driver, cleaned up some stuff, and took the opportunity to implement the features that are on the to-do list for the WF driver. The big one is a full console dialog for “wee_config --reconfigure” that even goes as far as to build a default sensor_map by asking questions! I intended to back-port these improvements into the next revision (v2.0) of the WF driver, but then somebody who shall remain nameless (@vinceskahan) reminded me that WeeWX 4.0 is on the horizon…and requires Python 3…and that it isn’t exactly 100% compatible with Python 2. Before I start the back-port, I need to set up a WeeWX 4.0 / Python 3 test environment to ensure that v2. of my driver works on all versions of WeeWX and Python. (Spoiler alert: it probably isn’t compatible as it sits today.)

FWIW, the new instructions used with the Atmocom driver (and edited above for the WF driver) were inspired by Matthew Wall’s current install directions for his drivers and stuff. The beauty of his way is that the instructions need not worry about where the download is being placed, since it is dropped into whatever the current directory is and added from there…


Might be wise to work the install.py enhancements first before worrying python3 compatibility under the hood. That’ll get you more bang for your buck in making everybody’s installation+support lives easier, especially for weewx and/or pi newbies.


Hi @vreihen,
Thank you, the sudo command helped a lot :slight_smile:
Because I am a linux newbie I didnt want to risk doing something wrong so I didnt use sudo unless I was sure that I was correct.
Lots more searching documentation, updating and upgrading, deleting and reloading and experimenting and wondering what all the different logs meant and with changing weewx.conf and restarting etc.
Then when I thought I had broken everything with ArchiveSW not working at all on the same RPi I read about the setting ‘share_socket=True’ and now I think I have everything working.
It has been challenging and frustrating at times but I am gradually learning what is going on on the surface.
Thanks Arthur, cheers Ian :slight_smile:

1 Like

I have given this speech before, but here goes again. The Raspberry Pi Foundation was formed to build cheap computers for school-age children to experiment with electronics circuits and programming, at a price where they are disposable if a kid blows one up. They multiply like rabbits in my house, and there is truly no reason to have more than one function running on a single Pi. You can also buy some spare microSD cards, and make a backup clone (or completely different Linux environment) that’s just a card swap and reboot away. Long story short, don’t be afraid to blow things up!!!


You ‘really’ need to read the weewx-users google group and just get a feel for what others are experiencing. The intent is that the docs are good enough for all experience levels, but of course that can’t possibly be true. If there’s something unclear, ask ‘there’ - that’s where hundreds of weewx users are there and ‘do’ help.

I’d also suggest you get some free linux training, just to help ensure you feel comfortable doing the minimal things needed (install software, edit files, monitor health, etc.). There ‘is’ some baseline linux skillset needed. This isn’t windows :slight_smile:

Suggestions - edx.org, udemy.org, linuxacademy.org, and many many others have free training courses. Spend a few hours of your time. It’ll lower your blood pressure.


Morning all,

This may well be a Weewx user group question but your see why i am posting here first.

If you take a look at my graphs via Weewx:



In recent weeks i have noticed the data for the air has missing points. I moved it closed to the main hub (now within 5 metres) and replaced the batteries - this seemed to fix it for a while but now the data seems to be getting lost again.

It could of course be a Weewx thing, but noting the wind graph is fine (that said Solar does have a few missing points).

So just wondering if anyone has any ideas?




The RSSI on your Air (-48 as I write this) looks great, and WeatherFlow’s web data is intact. This doesn’t exclude a communications problem, since I have never tested the WeeWX driver against “catch-up” packets from times where the data is buffered because something is temporarily offline. That could explain why WF has them but not WeeWX.

Since the driver depends on a steady stream of UDP broadcast packets that contain no handshaking or error-correction routines, the most likely cause is wired/wireless network congestion or wifi channel interference with a neighbor. Given that the problem seems to have more or less gone away since 8:00 AM this morning, my first thought is that one of your neighbors has university-aged kids doing a “Netflix and chill” on the same 2.4 Ghz wifi channel that your WF Hub is using.

The solar data gaps are a clue that congestion may be the reason. The default sensor_map grabs WF rapid_wind packets every 3 seconds, whereas the Solar data (and everything but lightning from the Air) is only sent once per minute. Missing a few one-minute packets in a row is a big gap, whereas missing a few 3-second packets might not even be noticeable at that graph zoom.

Another known cause for WeeWX packet loss with UDP is running it on an under-powered server (like a Raspberry Pi Zero), especially with some other program installed that is hogging resources.

If the server isn’t overloaded, my first step would be to try changing 2.4 Ghz wifi channels to rule out neighbor interference…

1 Like

I use WiFi Analyzer from the Google Play store to check for WiFi signals in my area and adjust my system to the best channels. I’m sure there are similar apps on iOS, too.

1 Like

You are missing observations because you are trying to do too much on a too-slow raspberry pi, and I’m guessing you’re also listening over wifi, not a wired connection (true ?)

You’re also running the Belchertown skin, which is notoriously compute-intensive, and on a pi that is a bad combination. Disable any other skins you have enabled (Seasons ? Standard ? others ?) for sure to try to give the pi a chance.

But make sure your pi is connected ‘wired’ as listening for UDP over wifi just doesn’t work reliably on a pi. It’s not the weewx software nor @vreihen’s driver. You are definitely going to miss a ‘lot’ of observations if you’re listening over wifi in a badly-configured wifi environment with lots of channel overlap from neighbors.

(another reason why WF being only 2.4GHz is not a great implementation, but lots of other vendors omit the 5GHz radios for their network-enabled products too)

But that said, this is again nothing for a WF forum. There are hundreds of users in the weewx-users google group and a decade+ of data there that would have said the same thing.

Three brilliant answers - thanks, what a great forum this is.

Yep running on a Pi - but a 3B+ so i guess its as good as a Pi gets. I am on wifi so i will try a wired connection. I did think it could be a temperature thing as it does often kick back in just after sun rise - we only have one neighbour and they are not the netflix types but interesting to know about the 2.4ghz channel. I will try out a Wifi Analyzer as well.

The latest Belchertown skin (vr 1) is about to come out and is apparently stripped down so that may also help…

So thanks again, i will move it so its wired and then see how it goes :slight_smile:


I’m running a pre-release of Belchertown v1.0 on my Pi 3B+, and it is truly the cat’s meow with dark mode enabled (my feature request) on my wall-mounted 10" Amazon Fire tablet:


Breaking the Highcharts config out into a separate graphs.conf file makes it easy to add new graphs, customize existing ones, etc. There are still a few documentation and default config option issues being addressed, so I suggest waiting for the official v1.0 package at this point…


Just to update - the move to ethernet rather than wifi seems to have helped out a lot, graphs are now updating happily:


Thanks for all the help



Just upgraded to version 1 of Belchertown - its really nice :slight_smile: (http://www.finchamweather.co.uk/weewx/)

I have been trying to get a graph of lightning to work but with little success so far - if anyone has any ideas how lightning is logged from WF in Weewx - i have tried “lightning_strikes” but it often comes up ‘invalid’ and the graph does not load…