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


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


esp-link revisited

Regular readers may remember my article on hardware implementation (and my associated balls-up) for a serial console using an ESP8266 and JeeLabs’ excellent esp-link firmware.  Well this weekend I had cause to revisit it.  Another fairly ancient, headless server (a Soekris box this time) was in dire need of an update, so I reached for my trusty console adapter.

Except (there’s always an “except”, or a “but” nowadays …have you noticed?) that the Soekris has a console which, at boot-up, defaults to a (very useful and quite speedy, for the time) baud rate of 19,200  …and my v2.0-beta version of esp-link didn’t handle that as one of the selectable baud rates.  No problem!  One of the nice features of JeeLabs’ package (which I mentioned in the original article) is that you don’t even have to compile the code; they very conveniently provide the pre-compiled binaries on their site and, because I already have esp-link running on my ESP, I don’t even need to reach for the USB cable and FDTI adapter,  I can just flash over the air using the built-in utility.  Except…

Instead of doing a “make flash”, I decided to download the new firmware package, which consists of the binary files you need, as well as a little shell-script called “wiflash”.  Wiflash is a little helper script which basically wraps “curl” to do the heavy lifting.  You just give your ESP’s hostname (or IP address) and it’ll go off and do the actual programming for you.  Except that in my case it came back with an error message (from curl):-

HTTP server doesn't seem to support byte ranges. Cannot resume.

…which seemed a little strange, as at that particular point, all it was doing was fetching a 9-byte long file, /flash/next, which contained the plain-text name of the area to program this time round, “user2.bin”, and I wasn’t requesting, or expecting it to have to resume anything.

The curl manual page doesn’t seem to elaborate on whether the -C (–continue-at) option is a default or not, but it does say that prefixing option names with “no-” will disable them, so it seemed worth trying as a quick fix (remembering that today’s objective is to upgrade a system, not debug curl or the esp-link web server), so I simply modified line #82 in wiflash from:-

next=`curl -m 10 $v -s "http://$hostname/flash/next"`


next=`curl --no-continue-at -m 10 $v -s "http://$hostname/flash/next"`

…and blindly hoped that all of the other calls to curl in the script would just work.

As it turned out, work they did and that one simple change was all that was needed (a quick trip to the “issues” tab on the esp-link git page confirmed that I’m the only one, so far, to have seen this issue, so I’m willing to  believe it’s just a quirk of my fairly ancient OS combined with the old, original v2.0-beta version of esp-link already on the device).

Anyway, a minor problem solved and a nice, shiny, new version of esp-link installed on the ESP, with lots of new features and (almost! ‡) all of the baud rates you could ask for.

Screen shot of esp-link v3 console page

Note that the baud-rate and parity/stop configurations are now on nice, drop-down menus and there’s a separate console input box, as well as selectable history for all of your previous commands.

In addition, on the side panel we have new pages for “WiFi Station”, “WiFi Soft AP”, “Services”, “Upgrade Firmware” and “Web Server”.  While some of that information was available with older builds, the new pages give an uncluttered, neater feel to the application and, for most of the pages, there are new additions to the existing configuration options, giving you, for example, the option to set up a server and timezone for SNTP services.

All in all, a worthwhile update for a very useful utility and, while we’re here, I notice that JeeLabs and Thorsten von Eicken have created a tiny (and much neater) hardware solution than mine, specifically for programming one of their new products.  Neat!


‡ 74880 anyone?  (Yes, it’s that annoyingly non-standard squirt of debug info at ESP power-on)

Another Sonoff Family Member…

…and another Open Source package to run it.

I only recently noticed that ITEAD Studios have added a light switch to their Sonoff line-up.  Sonoff Touch from ITEADThe switch comes in either EU or US single-gang switch-plate sizes and has a glass front panel with a capacitive touch switch.  Inside there’s an ESP8285 module providing remote services via ITEAD’s EweLink cloud application.

There aren’t too many hardware details available on the Sonoff Touch at the moment (what sort of PSU is utilized, or even whether it’s a relay or a triac based device), but people have already started hacking it (no doubt spurred on by a statement in the comments section of the product page that this device “can’t be reprogrammed”).  David Pye seems to be first out of the gate with his (PubSubClient) MQTT implementation; not just identifying GPIO0 as the pin connected to the touch-switch, but also providing short write-ups (with photos) on how to prepare the device for programming, configuration and usage, but also providing bonus “long-touch” and “short-touch” modes in his firmware.

Note that, unsurprisingly, the Sonoff Touch requires that a neutral lead be available in the existing switch box, as well as the switched live lead.  This is something you need to check‡ before ordering a bunch of these (it’s very common for only the live lead to be available).

David’s additional switch handling looks like it might open up quite a few possibilities:-

  • Add an on-time limit for specific lights.
  • Control actual on/off based on time of day.
  • Control on/off by ambient light level (assuming you have MQTT capable sensors).
  • Put unit into OTA mode (ie:- limit reprogramming to those with physical access).
  • Use “long-press” to signal MQTT to switch all controllable lights in room on/off.
  • Additional ten-second press mode for all controllable lights in house on/off.

Seems like you could have tons of fun with this.  Nice one, David!


Hint – Don’t check a bathroom or toilet light switch and assume that all of the other switches in your house will be the same!

A wee bit late for Xmas, but…

Here’s a very seasonal item, courtesy of Hackaday  …Sean Hodgins’ ESP8266-enabled Xmas ornaments.  They’re worth checking out for the really neat, multi-coloured PCBs (although I’d probably decide to do without the piezo speaker if I were to build any).

Sean Hodgins' Xmas Ornaments

No word yet on where Sean sourced the PCBs, or on what the battery life is like (even with deepSleep(), not long, I’d guess).

Sean’s GitHub repository has all of the code, if you fancy knocking a couple of these together on Xmas morning.

Z83-II Mini-PC (Quad core 8350)

Another departure from the ESP8266, but for something that ESP8266-hackers might find interesting.

Over the past couple of years I’ve been ditching most of the big, ugly, power-hungry desk-top and server machines which used to run my mighty empire (aka “the house”) and replacing them with machines that are a lot smaller and a great deal less power-hungry.  I’ve got a few SBCs of various sorts; all ARM based, mostly multi-core and almost all still shamefully naked and gathering dust, even though they’re alive and kicking and running various essential services on our home network.  In addition to the lack of a case, almost all of them have other drawbacks of some sort (not well supported by the operating systems which I prefer to run, missing critical hardware, etc), so I keep looking for the perfect mini system.

I thought I’d found it a while back when I splashed out on a SolidRun CuBox-i4.  It’s small (very small, in fact), has a quad-core processor, 2GB of memory, GbE, USB ports, HDMI and (a major plus) comes in a diddy little black-plastic case.  Unfortunately, it turned out to be a major pain in the proverbial trying to install and run a reasonable operating system and lots of hoops needed to be jumped through (in the correct order) to even start the OS installation.  It has been running FreeBSD for quite some time now, but it suffers greatly from the lack of a real-time-clock (and unlike a Raspberry-Pi, for instance, it’s not easy to add one), has limited USB functionality and tends to fall over in a messy heap at reboots if the moon happens to be full or the wind is coming from the east.

So the quest goes on for a truly great (cheap) mini system and, right in the middle of the purple Thursday (or was it cerise Saturday?) sales, I found a new system on GearBest that seemed too good to miss.  Because it was on sale, it was a few dollars more expensive than normal (???) , but it was still a pretty good price, given the specs.

ZX83-II Z8350-based mini-pc

It’s an Intel quad-core Atom X5-Z8350 based system, with 2GB of main memory and 32GB of eMMC.  It has GbE, two USB-2.0 ports and one USB-3.0 port.  There’s also an SD-card slot and an HDMI video connector.  For those who care (and I don’t), it also comes pre-loaded with Windows-10 (don’t ask me for more details on what specific version, because I don’t know).  It’s a 64-bit system (but read on for the limitation on that) and it also comes with built in Bluetooth and a/b/g/n/ac WiFi (neither of which I’ve used).  More importantly for me, it’s also a fanless system.  It is advertised as coming with an “English User Manual”, but you can save yourself a few seconds of “I don’t believe this crap!” frustration by throwing said “manual” straight into the bin; there is nothing in it which is even remotely useful.  It does come with a fairly substantial looking mounting bracket (to attach it to a monitor, or wall) and two HDMI cables — one short and one long(er).  A power adapter is also included (but you need to make sure that you order the correct version for your particular country).  The shipping box is also very sturdy and should hold up well if a passing elephant accidentally treads on it.

I would have been quite happy to boot into some sensible operating system and immediately wipe Windows from the disk (eMMC), but it was not to be.  The one, big gotcha with this system is the BIOS.  At first glance, the BIOS menus are very sparse indeed and you’re not going to get very far at all with this system unless you know the magic incantations (it may also help to have a spare chicken to sacrifice …I haven’t actually tried this yet, though).  I did get through quite a few blank CDs and DVDs while trying to get various distributions to boot from a USB-connected DVD.  No matter what I did though, the dang machine just kept on booting into Windows (which was quite disconcerting at first, as I couldn’t see how to shut it down).  Some ‘net searches turned up suggestions for adding BIOS passwords (there are two in the version of BIOS which my machine has) to trigger extra BIOS menu items — Nope, doesn’t work.  You can forget that.  There was also one quite long diversion where some folks (seemingly correctly) noted that some functions which affect BIOS start-up are only available from within Windows, despite how stupidly chicken-and-egg-ish this seems to be (for those who want to try it, you need to select the shutdown function from the start menu and then hold down the shift key while selecting “shutdown”.  This will bring up a whole scad of extra menus which will change the UEFI boot settings …and then it will just merrily boot straight back up into Windows again).

It turns out that the UEFI boot  (which stands for “Unified ‘Effing Firmware Interface, by the way) is the key to all of this.  It’s a versatile system which is replacing the outmoded BIOS of years gone by with an updated and secure method of booting you into Windows …and booting you into Windows …and booting you into Windows (you get the picture), no matter what you actually want to do.   On some systems (and yes, the Z83-II is one of them) it has the added twist of limiting a 64-bit system to booting from 32-bit code (you’d better go back and read that sentence again …I wrote it and I still can’t quite grok  it!).  For some reason (lost in the mists of Redmont),  Windows was/is limited to booting from 32-bit bootloaders, so because everyone-and-his-dog only ever runs Windows, some machines (like the 64-bit, Z83-II) have a UEFI which will –only– handle 32-bit bootloaders.  Now before you start jumping up and down with your hand in  the air shouting “Teacher!  Teacher! I know!  Just  run a 32-bit OS!” you should also note that, because UEFI is new-ish and 32-bit systems are just so last decade, very, very few 32-bit distributions of any sort actually have any UEFI boot capability bundled into them at all.

I know the mantra is “never give up!”, but by this stage my fingers were twitching and the old grey-matter was sending signals to my hand to grab hold of that handy, 3kg lump-hammer and send the Z83-II and its UEFI back to meet its maker in very, very small pieces.  It was only the nagging annoyance of those extra couple of dollars for the maroon Monday “sale” price that held my arm in check.

By this point I’d read so many posts and articles on the UEFI and booting systems that I’d actually stumbled across one piece of related (and essential) information which actually worked with the Z83-II.  I’d discovered already that hitting <ESC> during initial, power-on boot would bring up the BIOS menu, but in a couple of posts related to other mini-pc systems people mentioned that <F7> would bring up the boot-device selection menu.  It worked, too.  Not only did I get a device menu (what the system had detected at boot up, rather than the BIOS preferred-device list), but it also gave a tiny bit of extra information about what the system thought it had detected on each particular device.  For the most part, to begin with anyway, that information was limited to “Windows boot manager” on the eMMC device.  This turned out to useful, though.  It quickly became apparent that having a DVD in the drive with something that the BIOS (and, presumably the UEFI) could read would result in that entry in the <F7> menu changing to give the maker’s name and model, instead of just a vanilla “USB CD/DVD” entry.  Unfortunately, very few of those DVDs would boot successfully, but at least it meant I didn’t have to go through the tedious process of having the system boot into Windows, yet again,  if there was obviously no readable disk in the drive.

I’d read in a couple of places that the latest Debian versions (greater than 8.0) had solved this 32/64-bit problem, so I burned a couple more DVDs and tried them.  I could get the extra info in the <F7> menu, but they wouldn’t boot.  A couple of other mainstream Linux distributions were also flagged (in Distrowatch) as being fixed, but none of the ones I tried actually booted.  Then I came  across a reference to Ian Morrison’s Linuxium site.  Ian obviously spends a lot of time mucking about with set-top boxes, mini-PCs and PC-sticks and has done a ton of work to get Linux booting on those devices.  He has also modded some mainstream distributions to boot on these infamous 32-cum-64 bit devices.  Ian’s modified Ubuntu 16.10 was the first thing that successfully booted on the Z83-II and proved that it could successfully bot and run something other than the dreaded “W” (thanks Ian!).  If you’re looking for a stable Linux distribution you could do a lot worse than to mosey on over to Ian’s page and check out his offerings.

Finally there was light at the end of the tunnel.  The Windows reboot cycle was broken.  I went off to see what I had to do to get OpenBSD or FreeBSD onto the system.  I didn’t have to look very far.  In another one of those “Duh!” moments, it turned out that OpenBSD had also introduced the 32/64 UEFI fix and the latest snapshot (booted from a USB thumb drive this time) not only installed, but also automatically created a dedicated UEFI “i” partition and populated it with the required boot files.  Not only that, but the BIOS now “knew” about the new, bootable drive and I could easily make it the default power-on boot device.  Yay!

So, in summary …at poweron, use <ESC> to get into the BIOS and <F7> to get into the boot device selection menu and use Ian Morrison’s modified versions of Linux, or OpenBSD 6.0 or greater, to prove that you can boot and install something other than “W” on the Z83-II.

…and don’t buy anything during a turquoise Tuesday sale.