Raspberry Pi Weather Station In Progress

[Jeremy Morgan] is building a weather station from scratch using a Raspberry Pi, and he has put together a nice write up that shows where he is at, and how it works. Currently, his setup is in the breadboard stage and is measuring humidity, temperature, pressure and light level using sensors that connect over one wire and I2C. He also shows how he is using Google Docs to store the data, by getting the Pi to write to a Google Spreadsheet over email: the Pi emails the data to Google every 30 seconds.

There is an analysis portion, with a Microsoft Azure web site that graphs the data over time. It’s a bit of a dogs breakfast (he might have used one interface technology for all of the sensors, for instance), but it is still a nice overview of the overall process.

Automatically channeling data into an easily accessible medium has been the target of many hacks going way back. We’ve seen a ton of companies pop up to help satisfy the need but between those and the hacked together (usually) open source solutions, there doesn’t seem to be a clear winner. What’s your favorite method of gathering and displaying data from projects like this onto the web? Let us know in the comments.

13 thoughts on “Raspberry Pi Weather Station In Progress

  1. I have 5 of those dht21 / dht22 / am2302 sensors connected to esp8266, teensy, bbb, rpi, etc and all give different values for temperature/humidity, sometimes with absolute humidity error exceeding 15% and temperature +-5C. The humidity reading is very temperature dependent, and according to some that might be caused by self-heating. I also have the bmp180 pressure/temperature sensor close by and it gives more realistic values for the temperature. I would be wary of using these kind of sensors for anything important. Apparently there’s better alternatives (AM2320/AM2320B) that use i2c instead of the weird dht22/am2302 protocol, and go to sleep between readings to avoid the self-heating problem, but I don’t have them yet to attest the veracity of those claims. You can also get much more expensive sensors (e.g. SHT25 ) or design your own, but then you have to calibrate them.

    1. Sparkfun was having problems with some SHT1x sensors because the reflow oven dried them out excessively, causing problems with accuracy. Rehydrating them in a humidor corrected the problem, see https://www.sparkfun.com/news/1090 for details. I haven’t read the data sheets on the sensors you’re using, but it might be worth checking if that’s a potential problem for your sensors as well.

    2. Yup, I had same problems with that crappy dht22/am2302 sensors bought on the eBay. On the other hand, all DS18B20 temperature sensors from the same source seem to work within the spec. Good quality humidity sensor like SHT75 costs about $70, those eBay dht22 can be bought for about $3, I guess further explanation is not needed.

    1. He took the easier path, RPi and Google Docs. Harder way would be to use simple REST and let PHP script handle all the Google API stuff. In that case simple 8bit micro would be enough and continous operation based on small solar panel would be very possible.

  2. I have build my own RPI weather station too using 2 DHT22 and 1 ds18b20 sensors (BMP180 is still in a mail). I used MySQL + php for storing and visualizing sensor data (more info http://paulius.bautrenas.lt/blog/?p=642). One strange problem I had to deal with was an incorrect DHT22 readings. For example 1 out of 10 reading could differ from the other by several degrees. Maybe it was due to poor quality sensors or long cable or magnetic radiation or smth., but I just couldn’t stand storing incorrect data. Simple data points averaging did’t help, but I did found a way how to eliminate misleading data point using python and “Interquartile range” method. More info can be found here: http://paulius.bautrenas.lt/blog/?p=550 (sorry it’s in Lithuanian)

    1. I have written a google docs script a few years back. It was working fine until this Spring, when google introduced Google Store for Google Spreadsheet scripts, and a minimal “validation fee”, and obligatory upload to the store even for personal use.

      So I got enough of Google for some time. It is the most unreliable service ever.
      And not because the bad infrastructure, but the constant product changing/shifting and making obsolete on purpose.

      I do not base anything upon google service in future.
      If I write something using my own tools it will work in 20 years from now, when google may be extinct by then.

      So I’m superconservative if I need to base something on external service.

  3. A few people have mentioned issues with noisy sensors, this can be fixed for the cost of a little more code space on the MCU.

    see:
    https://www.youtube.com/watch?v=biY7F-tLwE8
    https://github.com/TKJElectronics/KalmanFilter
    http://kalman.sourceforge.net/

    I haven’t tried ganging cheap sensors and ADCs, yet, but I suspect that will be equally effective as noise tends to cancel itself out. i.e. 3 of the cheapest sensors into 3 ATTinys sitting on a serial bus to a bigger MCU or *Pi running Kalman code to fuse the inputs. Why more than one ATTiny? Because they add noise in the ADC stage but it is not the same across multiple MCUs should cancel out. It is a question of it you can do all this for less than the cost of a single high quality sensor and ADC. My gut feeing is that the sensor fusion hack is cheaper.

Leave a Reply to NunoCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

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