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.
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
command:
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
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:
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
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
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
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.
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).
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âŚ
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.
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
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âŚ
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âŚ
