Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
arduino-based decoder for Oregon Scientific weather station
Arduino Shell Python
branch: master
Failed to load latest commit information.
scripts Initial commit. More details about packet decoding.
WeatherStation.ino Initial commit.


Arduino code, tools and utilities to receive and publish data from an Oregon Scientific weather station.

The Arduino code here is a modified version of the decoder found at


  • Arduino-compatible board.
  • 433MHz receiver. I bought the Freetronics 433MHz shield, but any old 433MHz receiver will do. The data pin from the receiver should be connected to analogue pin 1 (the Freetronics shield connects the input to D8, I ran a jumper from it to A1).
  • An Oregon Scientific THGN132N temperature / humidity sensor. This was the sensor provided with BAR808HG weather station.
  • A Linux server. The arduino is plugged in to my Ubuntu media server, but any current distribution should be fine.


The Linux server will need:

  • rrdtool (rrdtool package in Debian/Ubuntu)
  • python, and python rrdtool interface (python-rrdtool in Debian/Ubuntu)
  • cron
  • A web server. I use apache on this box.

udev is optional but nice to have.

As well as the arduino sketch, this repository contains:

  • weather-station.rules. A udev config fragment to give the arduino a persistent device name. Update this file with your arduino's serial number, stick it in /etc/udev/rules.d/, and the arduino will always be available as /dev/weatherstation when it's plugged in.
  • will create an RRD to store temperature and humidity.
  • will poll the arduino and retrieve the latest weather data.
  • polls the arduino, parses the received data, and updates the RRD.
  • downloads sunrise and sunset data, which is used in graphs.
  • generates graphs.
  • weatherstation.cron is entries from my user crontab to run everything.

THGN132N Decoding

This sensor uses the Oregon Scientific V2 protocol. The Ook_OSv2 sketch from decodes the data packets. A data packet looks similar to Oregon Scientific devices - the header stuff is identical, and numbers from the sensor are stored in binary-coded decimal. A sample packet looks like this:

1A 2D 10 EC 32 27 50 06 44 25

The nibbles that I know about are:

  • 0-3: Device ID. The ID for THGN132N sensors is 1A2D.
  • 4: Channel. This corresponds to the channel slider on the back of the sensor.
  • 5: Battery? All of my readings have 0 for this nibble. I'm half-expecting it to become non-zero on low battery.
  • 6-7: Rolling code. This is a unique identifier for the sensor. It resets when the battery is replaced.
  • 8: The tenths digit of the temperature.
  • 10: The tens digit of the temperature.
  • 11: The unit digit of the temperature.
  • 12: The unit digit of the humidity.
  • 13: The sign for the temperature. This nibble will be 0 for a +ve temp, and non-zero for -ve. During my testing with the sensor in the freezer, I've only seen this return 0 or 8.
  • 15: The tens digit of the humidity.

The sample packet above is from a THGN132N on channel 1 with rolling code EC. It's returning a temperature of +27.3°C, and humidity 65%.

I'm expecting the checksum to work like other Oregon Scientific devices, but haven't yet implemented it.

Something went wrong with that request. Please try again.