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.



ITEAD Recall

Just in case you haven’t seen it already, ITEAD Studio is recalling some of their Sonoff devices.Sonoff damaged by heat

The recall covers Sonoff TH16 and Sonoff POW units, manufactured during December 2016 and January 2017, which were produced without the correct amount of tinning on the AC power traces required to carry the maximum specified current.

There doesn’t seem to be any easy way to identify affected units though and the recall Sonoff PCB damagenotice seems to infer that only Sonoffs with existing, visible damage will be exchanged.

It’s worth noting that this issue only affects units which are being used with high current loads, so it’s unlikely that you’re going to have problems if you’re only using the modules to switch on your porch lights at dusk.  However, as these units were sold specifically for their higher current handling ability over the original Sonoffs, it is probable that there are many use cases out there which will be affected by this issue.  If you’ve purchased a TH16 or POW unit recently and you’re using it with a load which draws quite a lot of current (any sort of heater, for instance), you should probably stop using it until you can verify with ITEAD Studio whether it is amongst the affected units or not.

ITEAD are asking that people who believe they have an affected TH16 or POW to open a support ticket on their site at:-  https://www.itead.cc/contact-us

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.

Olimex ESP32 Development Board

Just in case you haven’t seen it elsewhere already, the good news for ESP aficionados today is that Olimex have announced an ESP32-based (WROOM-32) development board with a couple of novel features.

Olimex ESP32 Dev Board

The most obvious is that prominent ethernet connector.  According to the specs it’s a “fast” ethernet port, so 10/100Mbs.  The two relays are rated at 10A/250V and it’s worth noting that, from the photograph of the bottom of the board, both the N/O (normally open) and N/C (normally closed) contacts are broken out to the screw terminals.

Olimex ESP32 Dev Board (bottom)

What makes that more useful than N/O only?  Well with two relays, you now have complete control over a switched device and the existing wall switch still works as normal if your ESP32 board is powered off:-

  • The N/C relay is in series with the existing wall switch and the N/O relay is in parallel.
  • If the light is switched on at the wall switch, you can switch it off remotely by activating the N/C relay to open the series contacts.
  • If the light is off at the wall switch, you can activate the N/O relay to close the parallel contacts, switching the light on.
  • Fail-safe operation. If the power to the ESP32 board fails, your wall switch still works as normal.
  • If the light isn’t being controlled by the ESP32 board, the relays are both off, so the relays don’t draw current and your wall switch, as above, still works normally.

This isn’t by any means novel, but a lot of the low-cost ESP relay control boards out there only have a single, normally-open relay contact pair available.

Moving on from the relays, there is also a micro-SD card slot available for on-board storage, two buttons, a decently sized barrel connector for an external +5V supply and a connector for a LiPo battery, with an on-board charger and step-up converter to enable battery powered operation.

There’s a 40-pin connector, which apparently gives access to all of the available GPIO pins (the pin map for the connector is silk-screened onto the bottom of the board) and, finally, a “UEXT” connector (the ten pin socket, next to the 40-pin connector).  If you’re not familiar with the UEXT connector (and I certainly wasn’t), it turns out that it’s something which Olimex developed, are already using on many of their boards and have made available to the community as an Open-Source (as in royalty-free) standard.  It consists of 3V3 and GND power pins, TX and RX serial pins, SDA and SCL I2C pins and MISO, MOSI, SCK and SSEL SPI pins.  Now before you get too excited and start pulling all of those 30-year-old floppy disk cables out of your junk box, you should note that there’s no special magic used here; the I2C and SPI busses are still basically short-haul, on-board interconnects and you won’t be connecting remote devices over miles of (ancient) ribbon cable.  On the other hand, it is quite a neat idea to be able to plug (for instance) an LCD display directly onto the board.  You can check Olimex’s UEXT documentation for a (surprisingly long) list of their boards which already have this connector built in.

Unfortunately, although they’ve announced the price, at €22, the board isn’t actually available for sale quite yet.  According to the Olimex blog, the prototypes are in and as soon as they’ve been tested and some example code has been written, it’ll be going into full production.

Thanks to CNXSoft for breaking the news on this one.

A neat toy (but not an ESP)

Here I go with yet another not-quite-ESP-related diversion, but one which the audience of this blog this should find interesting, I hope.

A couple of weeks back I bought a cheap USB GPS dongle from Amazon.

U-Blox USB GPS Dongle

It was amazingly cheap (the Yen equivalent of $8 U.S.) and I wasn’t expecting too much, but I have a yearning to get a local reference clock for NTP set up on my local network and I thought that, if nothing else, this would be a good starting point for fiddling around with GPS before paying for (and possibly breaking) something more expensive.USB GPS dongle, antenna side  I have to say that I’m really, really impressed with this little thing.  I’m sitting in a valley with major mountain ranges to both the east and west of me (~3,000m on each side), so I have a fairly narrow view of the sky, but this little unit acquires and holds nine satellites from inside the house and about 1.5m from the window.

The second thing I did (after verifying that the unit did actually work) was to rip the covers off to verify the make and model of the receiver chip and, as you can see from the photo above, the built-in antenna covers most of the board space on the top side of the PCB (the single, other component, top L/H side, is the green, status LED).

USB GPS dongle, component side

The component side has the U-Blox G7020-KT chip in the bottom,R/H corner.  Note that there’s no FDTI (or equivalent) chip, as the G7020 has a USB interface included.

There’s a back-up battery on the board to maintain memory contents between power cycles (which, it turns out, is critical for reasonable start-up times for GPS receivers).

Unlike another (non-GPS) dongle which I bought recently‡, this unit barely gets warm to the touch and there are no ventilation slots or holes in the plastic cover.

Anyway, for anyone else interested in playing with these beasties, here are some hints to get you started:-

  • The very first time you power on this unit, it will take up to 25-minutes to locate the satellites and lock on. Apart from a very brief flash of the green LED when you first connect it, it will appear to be dead. It’s not! Just leave it connected and it will download the data it needs (the “almanac”) from the satellites it can see and eventually the green LED will start flashing once per second to show that it is now operational.
  • After that initial connection, the unit will come to ready (green LED flashing) in only a few seconds the next time you power on. This is because it saves that initial data to internal memory (with battery back-up).
  • If, on that first power-up, you don’t see a green flashing LED after 30-minutes, it’s because the unit can’t get a decent signal. Move it as close as you can to a window, or if you have a laptop, take it outside. If that doesn’t work, grab a 1m or 2m USB extension cable from your local 100-Yen shop and move your GPS dongle as far away from the computer (and as close to a window) as you can.
  • If you’re using Windows, you can get the genuine Windows driver directly from the chip manufacturer’s web site:-        https://www.u-blox.com/ja/support      -or- https://www.u-blox.com/en/support
  • The chip inside this unit is the U-Blox G7020-KT.
  • If you’re using open-source, you will probably find that your OS correctly identifies the USB device as soon as you plug it in. The application you need (as already noted) is the GPS daemon, “gpsd”. When you install “gpsd” you’ll get some additional helper applications bundled in, such as the invaluable “gpsmon” and “gpspipe”, which allow you to view the GPS data in several formats.
  • The device which you use to connect to the USB dongle will be different between various OSes. OpenBSD and FreeBSD will see it as /dev/cuaU0. Linux will see it as /dev/ttyACM0 or /dev/USB0.
  • To run gpsd you should use the “-n” option (“no-wait” – don’t wait for a client to connect before handling GPS data) and the device. So something like this:- /usr/local/sbin/gpsd -n /dev/cuaU0
  • After starting gpsd you should be able to run gpsmon (just type “gpsmon”) and see data coming from the device.
  • If you want to run your GPS dongle as a local source for the NTP daemon, you still need to start “gpsd” (and it’s important to use that “-n” option in this case). The gpsd process will automatically populate shared memory segments, which the ntpd daemon can then read to get time information (you may have to check your OS for sysctl settings for PPS to get this working). There are notes in both the ntpd and gpsd manual pages on how to do this. So far I have only managed to get ntpd to use the GPS embedded time information, not PPS.

As you can see from the photos above, the board has most of the components (including the battery and the G7020-KT chip) on one side and the antenna on the other. The green LED is on the same side as the antenna, so when you position your USB dongle, you should always have the green LED facing –upwards-. If your USB forces it to be downwards (unusual) or sideways (fairly common), you might want to buy an adapter or extender cable to ensure that you can position it so that the antenna (and LED) are pointing upwards.


‡ – A generic, black SDR dongle, bought for the advertised “R820T” tuner chip and specifically for receiving 1090Mhz ADS-B traffic from aircraft flying overhead (see the previous post on “PlaneSpotter”).  Not only does this thing get hot, it -doesn’t- have an R820T tuner chip at all (they use a cheaper and completely useless NC00012 tuner, which has a frequency range which cuts off at 985Mhz, so it doesn’t even cover the ADS-B band).  If you want to play with SDR (and especially ADS-B), save your money and buy a NooElec “Mini 2+” bundle (directly from nooelec.com) instead.  It has an R820T2 tuner chip, plus a temperature controlled, 0.5PPM accuracy oscillator and comes with a “starter” antenna and a remote control unit (??? don’t ask me …I have no idea why!) for $21 U.S. + $5 postage to anywhere in the world.

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


…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
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.