Tag Archives: oregonscientific

Weather Station Progress

(Note, this old post is background on some of the things I was doing here before.)

A few weeks ago I lost my rfxcom receiver during a lightning storm. Which meant my old weather station reporting on http://home.dague.net went defunct. My plan had already been to move away from that code (some incredibly hacky and fragile ruby) and do this over again less hacky in python on a raspberry pi. I’d even ordered and received a new rfxtrx receiver for this purpose. However, nothing gets you quite so motivated to make progress as downed infrastructure….

All through the week I’ve been getting data collection working and finally getting it uploaded to Weather Underground, where I’m personal weather station KNYPOUGH7.

I’ve even started to get some local graphing working as well, like the following:

test(outdoor temp, outdoor temp in cold frame, bedroom temp (sensor moved in the middle of the day for the spike), refrigerator temp, freezer temp)

The Raspberry Pi has made things interesting…. First, it’s mobile, as I have it connected via wifi to the home network. This has been incredibly useful, as it turns out there is a sweet spot for seeing all my sensors consistently, which is only possible to get to if I don’t have to worry about wired ethernet. The old solution had this sensor plugged directly into my home server, which meant drop outs on some of the sensors.

My old approach to data collection was rrdtool. As soon as I got a sensor reading I dumped it into an rrdtool database, which also made graphs. This had the advantage of being easy, and the disadvantage that rrdtool is a one way black hole for data. Once in, you can’t ever get it out sanely. It’s really designed to make operations centers look impressive and give admins the ability to eye trends, but makes working with that data not very useful. It does have the advantage of having a known fixed size, so you won’t overrun your local storage.

In the new system I’m using mysql, on the pi. It’s slow. Really slow. Often surprisingly slow. That slowness force one change in my thinking, which is to not use d3 to graph things client side, but instead generate static graphs with matplotlib on a cronjob, so user interaction won’t be slow. It means the data might be a couple minutes behind, but for weather, that’s fine.

The code… is currently terrible. However I’ve gone with the point of view that brute forcing working code right now is what I need to do to understand the patterns I want to build in this code. I spent too much time paralyzed on this project thinking through different ways to do it. So this will require some major refactoring and despecializing, already starting to happen, before it’s of any value to anyone else. Once I get there, I’ll have everything up on github as open source.

New Temperature Sensors

I got my self some new temperature sensors for my hacked together home thermal monitor. The software that runs this is still aweful, that’s on my project list. But at least now I’m able to figure out thermal variance inside the house, which is broader than I’d have expected.

A couple other changes were made in loading in the new sensors as well.

The outdoor temperature sensor is now on the North side of the house. This should minimize the amount of the day sunlight can hit the thing. While Oregon Scientific believes it can live in direct sunlight, my experience over the last two weeks is that it definitely can not. You get a 4 – 6 degree spike under direct sunlight. I could almost use the spikes to generate a map of the trees on the south side of the house based on when their shadows hit the sensor. The short of it, my reporting to Wunderground should be more accurate now.

The cold frame sensor is still at the far edge of receptivity, especially with the amount of earth it needs to go through. I build a tin foil reflector which seems to be helping a little, but it still drops out from time to time, generating the square waves in the curve. Not much I can do about that.

If you want to know more about this project, this post is probably the best starting point.

Sniffing Oregon Scientific Weather Sensor Data

A few years ago I bought an Oregon Scientific wireless weather station.  It’s a nice way to keep an eye on what’s going on outside.  The unit supports up to 3 of these remote sensors (shown here), and aggregates it at a base station.  It doesn’t have a computer interface, so while it displays nicely in the living room, I can’t get access to that data.

Once upon a time I bought some 1-wire thermo sensors that I was going to wire that into my computer for data collection.  After the house was hit by lightning, I got far more gun shy about running conductive cables from the outside to a computer.

It occurred to me recently that there was good odds that someone must have figured out to sniff that wireless communication.  These aren’t complicated devices, and Oregon Scientific seems to be letting different generations of sensors work with different generations of head units, implying that they have some pseudo standard protocol.  It would also solve my spark gap problem, as I could gather this data without any wires connected to the sensors.

After some googling I discovered that yes, these devices are operating in the 433 Mhz band, and yes, thanks to the folks at rfxcom, there is a unit out there which will receive this and spit it out in a reasonable usb interface.

Under Linux, this information can be very easily decoded with the heyu program.  This is really more of a command line system for home automation, but it also includes the rfxcom protocol and the decoders for just about everything Oregon Scientific makes.

After plugging in the rfxcom device, it took me about all of 30 minutes to get heyu compiled and configured for my devices.  The first time you run the heyu monitor you’ll actually get big hex strings which are the raw data.  Once you tell heyu what kinds of sensors they are, you’ll get it decoded in much more friendly units.  Here are the relevant lines in the heyu config file:

TTY	dummy
ALIAS Sensor1 A1 ORE_TH1 0xB1
ALIAS Outside A2 ORE_TH1 0x83
ALIAS Sensor3 A3 ORE_TH1 0xCE
ORE_TSCALE Fahrenheit

After configured and running, I now have sensor data being collected continuously:

gallifrey:~> heyu monitor
02/25 21:49:54  Monitor started
02/25 21:50:11  rcva func      oreTemp : hu A3  Ch 3 Temp 58.6F (Sensor3)
02/25 21:50:11  rcva func        oreRH : hu A3  Ch 3 RH 42% (Sensor3)
02/25 21:50:20  rcva func      oreTemp : hu A1  Ch 1 Temp 43.7F LoBat (Sensor1)
02/25 21:50:20  rcva func        oreRH : hu A1  Ch 1 RH 54% LoBat (Sensor1)
02/25 21:50:22  rcva func      oreTemp : hu A2  Ch 2 Temp 34.3F (Outside)
02/25 21:50:22  rcva func        oreRH : hu A2  Ch 2 RH 87% (Outside)

The next steps here are going to be gathering this into something that I can use for graphing.  I’ve now got all the sensors I was looking for to be able to build my better thermostat brain.  Next steps will be tying this all together and starting my graphing.