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 than 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" : 860.000}

‡  “Her InDoors”

Getting started with PlatformIO and the ESP32

Here’s the shortest “Getting Started” you’ve ever seen (disclaimer†  …I’m making the huge assumption that you already use PlatformIO as your development environment for your ESP8266 projects.  If you don’t, you should!).

Add support for the ESP32 with:-

platformio platform install espressif32

Create your new development (project) directory and, in that new directory, initialize the environment for the type of board you have‡  with:-

platformio init --board=esp32dev

Start writing code, as normal, in the newly created src directory and then compile with:-

platformio run

At this point, PlatformIO will go off and automatically download the framework support for your environment (this first time, only) and then compile your code.

You just can’t get any easier than that!


† I don’t actually have an ESP32 board yet.

‡ List the available target boards with “platformio boards

Ψ If you’re tired of typing “platformio” in full each time, you can shorten it to “pio” (“platformio” is used for clarity here).

ω For more information on getting started with PlatformIO, see the full documentation at:- http://docs.platformio.org/

Nice little TFT screen adapter board

Johan Kanflo has an interesting site which is definitely worth browsing.  One of his ESP8266 projects which caught my eye was the “Commadorable-64”.  Although the Commodore 64 isn’t a shared experience, using a tiny TFT display connected to an ESP is.  Johan has put together a neat little carrier board for the ESP8266 which solders directly onto the pins of the TFT display board.  Instant wireless display!

Johan’s project actually covers more than just one model of display, with the ESP Johan Kanflo's TFT Adapter Boardcarrier board being available for the 2.2, 2.4 and 2.8 inch TFTs (the larger models have connections for touch control, too);  follow the links on Johan’s project page to reach the DirtyPCBs pages for the one which interests you.

Johan has a Github repository with the code for this project (and many more) available for download.

433MHz/IR MQTT Gateway Project

It’s nice to see a project that develops over time and Florian has a good example on his blog.  He started off in the middle of last year by putting together a low-cost, arduino-based sensor for his garden and things seem to have just grown from there :-).  You can follow along on his blog from the initial version of his bidirectional 433MHz, ESP8266-based, MQTT gateway, progressing to the IR enabled version by the end of the year and his OpenMQTTGateway project this year.  It’s a good read and a great little project to follow.

 

 

Want a new workshop?

Hackster.io is currently hosting a competition promoting IOT2020 units, with the first prize being several thousand dollars worth of lab equipment for your electronics workshop.

The IOT2020 is an Intel Quark based controller (running Yocto Linux), packaged into an industry standard, DIN-rail mountable case, designed to enable your project to morph directly into a product by providing a unit which is already FCC approved.  The main requirement for the competition is that your entry be based around the IOT2020, but the nice thing is that they are actually giving away ten of the units in the opening round, so all you need to do is submit an idea and you could win an IOT2020 to play with and also have a chance at the grand prize.

Peter Oakes (who is promoting the competition) does specifically mention ESP8266-based projects as being a prime example of where this unit might be used (as, for instance, a gateway between a local network of ESP8266 modules and the internet).

Currently there are only about seventy entries registered, so those are pretty good odds.  If you have an idea for an IOT device that you think would sell as a product, you’re not going to lose anything (other than the element of surprise) by entering.

 

 

How to do a Sonoff memory upgrade

Jonathan Oxer, over at SuperHouseTV, has been running a series of video episodes on the Sonoff product line recently and I really recommend his latest.  The theme of the video is Sonoff-specific hints and hint #1 is how to upgrade the memory chip in a Sonoff.  Jonathan does a great job of demonstrating how to remove the chip with nothing more than “a big, old, clunky soldering iron” and a screwdriver.  A picture is worth a thousand words, so you need to multiply that by whatever the frame rate of a YouTube video is.  Watch it!  It’s worth it.

0.96″ OLED with an SPI interface

There’s a metric ton of those tiny, cheap, 0.96″ displays for sale out there, but one of the drawbacks is that you’re never quite sure which of the interface type you’ll be getting (the photos displayed by the vendors rarely match to the shipped product and the descriptions almost never do).  I ended up with an SPI version on my bench the other week, when what I was really after was the good old I2C version.  Oh well, how hard can this be, anyway?

Well, when you look at the back of the display there are some silk-screened instructions for what combination of resistors are used for which interface, but I have to admit that the idea of moving SMD devices of that size around without losing one on the floor, or pulling off a trace, didn’t seem too attractive to me.  An internet search found a StackExchange thread dealing with the subject and, although the procedure described didn’t look too intimidating after all, it also yielded important clues to the connections needed to have the module just work in its intended mode of SPI.  I was using a Node-MCU module, so I had pins to spare for the extra three wires, so it wasn’t really much extra effort to slap the whole lot onto a breadboard and mess around to try and get it working. OLED breadboarded with NODE_MCU I was also using Squix’s “PlaneSpotter” package as the software to test it with, as Squix’s excellent implementation of the SSD1306 driver library is claimed to be interface agnostic and should work with the SPI as well as the I2C interface (all of his current examples use the I2C interface).

The one thing that did confuse me to begin with were which of the SPI pins to connect on the ESP side; specifically the “DI” and “DO” pins from the display.  It’s SPI, so those should be the MOSI and MISO lines, right?  Err ..no!  With the help of the above mentioned StackExchange thread, I eventually cottoned-on to the fact that the display doesn’t use DO as MISO at all, it uses it as the SPI clock line, so ignore that wonderfully helpful labelling on the display connector.

The next step was working out which pins were which on the Node-MCU.  This is the first time I’ve used one of these beasties and I didn’t find its pin labelling particularly helpful, either (on the other hand, it is undeniably a nice packaging of the ESP module and USB interface components).  Eventually I got it all worked out, loaded up “PlaneSpotter” and had Tokyo to Seoul traffic showing up first try (all due to Squix’s neat programming and packaging).

Well that was the test part and now that I’ve verified that the display works, I need to move on to implementing my own, more modest project.  Before I leave you though, I’d just like to make a note of the hardware connections and minor software changes which were needed, as they might be of help to someone else.

First, here are the connections for both Node-MCU and normal ESP8266 GPIO pins for the display:-

Display NodeMCU ESP8266
CS D8 GPIO15
DC D4 GPIO2
RES D0 GPIO16
DI D7 GPIO13
DO(CLK) D5 GPIO14

 

…and here are the changes to the main.cpp file of the PlaneSpotter code.  As you can see, we just comment-out the I2C defines and add our own pin definitions below (note that the SPI pins, DI, DO and SCL, are hard-coded into the ESP8266 library and can’t be changed):-


// Display Settings
//const int I2C_DISPLAY_ADDRESS = 0x3c;
//const int SDA_PIN = D2;
//const int SDC_PIN = D3;


// 4-pin SPI Version.
const int RES = D0; // GPIO16. \
const int DC = D4; // GPIO2. - Normal ESP pin numbering.
const int CS = D8; // GPIO15. /

Next we just comment-out the init call for the I2C version and add in the call to the SPI one:-


// Initialize the oled display for address 0x3c
// sda-pin=14 and sdc-pin=12
//SSD1306Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
//SH1106Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
SSD1306Spi display(RES, DC, CS);
OLEDDisplayUi ui(&display);

For all of the other required local settings for this app, please refer to Squix’s notes.