Cat successfully skinned!

Regular visitors may remember a mention I made of an ESP8266/433Mhz gateway project a couple of weeks back.  Well, one of the reasons I found it so interesting was that I have a (fairly long-in-the-tooth) Oregon Scientific weather station installation which has always frustrated me with its lack of connectivity.  It does have a 9-pin, D-type serial connector on the bottom, but that assumes that you have an RS232 equipped machine within cable reach of the display unit (and that HID‡ would not object to yet another trailing cable).

I had toyed with the idea of plugging an ESP8266 into that port, with the excellent serial adapter  firmware from JeeLabs, but it doesn’t really address the HID/cable/ugliness issue.

Both of these methods also suffer from a fatal design flaw with this particular model of weather station, in that data isn’t squirted out of the serial port unless all of the sensors which this model was sold with are operational (otherwise you just get an error message along the lines of “Rain sensor not detected” and nothing else).  So I concluded that, by collecting the (433Mhz) transmitted data from the actual sensors (which are remote from the display unit), I could just use the data directly and ignore the base-station/display part of my weather station completely.  Hence my interest in the 433Mhz gateway project.

The final piece of the puzzle to drop into place for one of those light-bulb moments came when I was reading through the comments to one of Pete Scargill’s recent articles on the 433Mz RFLink project.  Commenter Paul gave a link to a GitHub repository called “rtl_433”, which is a 433Mhz decoder for SDR dongles by Benjamin Larsson.  Benjamin’s project is specifically for picking up the data from remote sensors (from many, many manufacturers) which operate in that open, 433Mhz band.

I’d recently bought an SDR dongle from a vendor on Ebay which was advertised as having an R820T tuner chip, suitable for ADS-B monitoring.  It turned out to be a bogus ad, with the actual tuner chip being a 0012, which doesn’t even cover the 1090Mhz ADS-B band.  I threw the useless dongle into the drawer and ordered a decent one directly from the manufacturer (which, incidentally, has worked perfectly from the first moment it was plugged in – Nooelec.com is the place to go), writing off the $10 Ebay one to experience.

Having seen Paul’s post, retrieved and compiled Benjamin’s “rtl_433” package and pulled out the “useless” dongle from the murky depths of the spares drawer, I had direct data from all of the Oregon Scientific sensors published to MQTT in less than five minutes after plugging it in.  One cat neatly skinned in a completely different way to that which I’d originally envisaged.

Just for your reference, here’s the simple pipe to publish your data:-

./rtl_433 -F json   |  mosquitto_pub -l -h hazeltonrig.throgmortons-bottom.org -t sensors/rtl_433

The “-F json” argument to rtl_433 is to force the data to be output in JSON format.  It will also accept “csv” (comma separated values) and “kv” (key:value pair) format arguments.

And here are a few lines of sample data from the various sensors:-

{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "THGR968", "id" : 204, "channel" : 1, "battery" : "OK", "temperature_C" : 8.300, "humidity" : 49}
{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:25", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:26", "brand" : "OS", "model" : "WGR968", "id" : 183, "channel" : 0, "battery" : "OK", "gust" : 1.400, "average" : 1.400, "direction" : 902.000}

Note that the “direction” readings are meant to be in degrees, so 902.000 (last line) doesn’t make much sense. Looking at the code and at the actual weather station display, it seems like there’s a nibble ordering issue with the decoding of the raw data and that should actually read “290”, instead (the fix is tested here and is now working its way backup the line).


‡  “Her InDoors”

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s