Raspberry Pi Weather Station Mk2

Back in 2015 I built a Raspberry Pi Weather Station based off a version I saw a Professor do for Students on the Raspberry Pi site. I tried to build as many parts by hand and it is was one of my first serious forays into the Pi world. I even wrote an Instructable about it, submitted it, and won 3rd prize in the Pi Day Contest that year. However, a lot of how I did the project was trial and error and figuring it out as I went, so there wasn’t a lot of documentation or diagrams, which was unfortunate from a “sharing how I did it” perspective. I had the station up and operational for not that long, maybe a month, before it wasn’t working reliably and I then I quickly cannibalized it for parts. I liked the project, and some part of it, maybe collecting all that data, scratched the Scientist part of my brain that I don’t get to use as often in my day to day computer job. Fast forward a couple years, and I decide to rebuild the station, trying to learn from the past mistakes and make it better. This post covers some of that story: my Raspberry Pi Weather Station Mark 2.

First off, the sensor package, what’s different, what’s the same. Both systems have all that you would expect from a weather system. Temperature, Humidity, Pressure, Light (via a Photoresistor), Rain Gauge, Wind Direction and Wind Speed. But in the MK2, instead of using a home-built rain and wind sensors, I opted for “store bought” ones that I got off Sparkfun. The new sensors that the MK2 does have are Soil Temperature, Soil Humidity, and two different Air quality sensors: one that is sensitive to dust and smoke, and the other that reacts to gasses like Butane and Methane. I also found and added in a Lightning detector, which is pretty cool, it detects lightning based of the RF signal emitted, and can even preprocess out man-made sources. It works on a I2C bus to the Pi, but I haven’t been having a lot of luck with mine, so it’s equipped (the black chip in the bottom left of the image), but it is not enabled. The first had a camera, and this one does too, but it’s mounted so high up on the back of the house and the camera is not very wide angle so it just snaps an uninteresting picture of the back woods, so I don’t use to do time-lapses like I did in the first version.

Building the Circuit

I have much more experience with PCB burning so for this version, rather than using prototype boards, after I designed out the circuit board in Fritzing, I “made” two different boards, 1 for the “home base”, and one for a “away base” that housed the sensors in a Radiation Shield (which just shields the sensors from direct sunlight but still allows air to move freely through).

The circuit is pretty simple and the boards were easy to make using thermal transfer paper and the toner laser printer. The biggest thing I screwed up the first time through is when printing to the thermal transfer paper I forgot to use the mirror image (since it’s transferring) so the circuit ended up backward and I had to clean off the boards and try again, (while wasting some of that expensive toner).

Testing, Testing, Testing

Due to other unforeseen issues it took a long time to build out this project and therefore once of the unexpected benefits was that I had prototyped it out on a breadboard and ran this system for almost a month.

I was also learning Gitlab Pipelines at the same time so I also used the long development time to make some automated checks and pipeline hooks. This had the added challenge of not running on a traditional x86/x64 processor and I ran the code inside Docker containers so I setup another Pi as my gitlabrunner to run everything on. Overall, the whole thing was nothing too fancy, it just linted my code using flake8 and did some basic tests. Definitely not full test driven development but it was a start towards CICD with sensors and Pi and it used web-hooks and posted to a private Slack channel and that was pretty cool.

For displaying the data I switched from a PHP site to storing the data in Postgres and using the Google Charts API to make my plots. This was definitely not optimal since I ended up reusing a LOT of code inefficiently across pages. Plus in the end I ended up using PHP code to extract out the data from Postgres and format it accordingly into the Javascript used by Google Charts. You read that write: i wrote PHP code that wrote Javascript code. This was seriously stupid and the whole thing probably needs to be thrown out and written in Python or NodeJS.

Overall the Mark 2 came out much better than the original weather station. I think the long development time was an unexpected advantage. Due to the downtime in between it forced me to update diagrams and documentation as well as take decent notes when I was working on the project, otherwise when I came back to work on the project I would have forgotten all the changes and how certain pieces worked and were connected to each other.

The other thing that worked well was I had a plan but was not married to it. I had an idea of how things would hook together, what would be where and what GPIO pins I would use, but these were not set in stone so if I ran in to unexpected roadblocks like not having enough space here, or this component needed these pins or operated different than how I thought it did, then I was able to adapt, update my diagrams and notes and move on. I think by following that process the end result was more robust and “tested” and will ultimately have more longevity.

As of this writing the station has been running continuously since mid-April, which makes the Mark 2 already more successful then it’s predecessor.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.