One to make you smile…

This one just popped up on

“What is it?” I hear you ask.  This is Mark’s ethernet enabled ESP8266. Mark's ethernet-enabled ESP8266 Mark (aka Cicero on the ESP8266 forum) decided that what the ESP really needed was more connectivity and good, solid, reliable wired connectivity at that.  This is the result.  He has connected up an ESP8266 to an ENC28J60 and apparently now has it spitting data down the wires.  The idea was first floated on the forum more than a year ago by a user going by the name “April1” (which probably hints at how serious his intentions were at the time).  Mark entered the fray back in November of last year when he announced his intention to give it a go.  There was a brief pause (presumably while the ENC28J60 made its way from the Middle Kingdom to South Africa) and, at the beginning of January he announced that he’d succeeded in getting the two-headed micro-monster to talk to the outside world over copper.

Mark says he wrote a separate stack for the ENC based on original work here:- and has MQTT and the HTTPD functioning on it already.

Why?  Well you’ll have to ask Mark that; the thread is here:-

I’m holding out for the GbE-POE version, though.

[Follow-Up Article]

[Wiz5500 Version]


ITEAD Studio delivery

Well, I can confirm that, for Japan anyway, delivery from ITEAD Studio is much faster than the normal Middle Kingdom standard (wait, wait, wait some more, then wait).  I ordered some bits and pieces from them on Monday (which was the first normal work day for them after their new year’s holiday) and the parcel arrived on my doorstep here in deepest, darkest Nagano at lunchtime on Saturday.  I had to sit down and have another cup of tea.

I was pleasantly surprised by the fast delivery and also fairly happy with the contents of the parcel.  I’d ordered a few of their AC to DC isolated switching supplies based on the iW1700 chip, along with a “Sonoff” ESP8266-based WiFi mains switch module (the non-RF version …it doesn’t have the optional 433Mhz card or a key-fob remote control).  I expected the PSUs to be small and I wasn’t disappointed, but what did surprise me was how tiny the Sonoff unit was.

Small hand, smaller Sonoff
Sonoff is tiny!

I’ve got very small hands, by the way (and probably none to clean either, come to think of it), so just image that it’s about one third smaller than the impression you’re getting from the photo.  The screws in the mains connectors are too small for a general-usage small bladed screwdriver and need a smaller “precision” type.  The box which the Sonoff came in was actually smaller than the boxes for the (tiny) switching PSUs, which had me thinking that they’d mixed up my order quantities, until I opened them.

I haven’t used either the Sonoff or any of the PSUs yet, so this is very much just first impressions.  So first, here are the PSU photos (click on them for larger images):-

From the top you can see the switching transistor nestled between the transformer and the 400v electrolytic capacitors.  The pins closest to the camera are the output side, with the middle connection labelled as 3v3.  However, there is actually no pin in that position and, although there are pads for a regulator on the bottom of the board, it isn’t populated either.  It looks as though it would be fairly easy to add a regulator in there, but as there are no pads for capacitors, it would be just as easy to put the regulator and caps on the target PCB instead.

On the photograph of the bottom side you can clearly see the slot underneath the transformer between the primary and secondary side which also runs across almost the full width of the board, providing galvanic isolation between the mains input and 5v output.  The iW1700 is the six-pin chip you can see underneath the transformer,  but on the primary side of the isolating slot.  It gets current feedback from a sense resistor connected to the emitter of the switching transistor and voltage feedback from a separate primary-side winding on the transformer; there is no feedback path from the secondary.  The two larger resistors at the extreme right of the photo are marked “155” (that’s 15 + five zeros, or 1.5 megohms) and they’re wired in series to give a very high impedance “bootstrap” supply to the iW1700 (this one of the area where the ITEAD design differs from the reference design – the reference uses a smaller limiting resistor and a “normally on” depletion mode MOSFET connected to the “active start-up” pin of the iW1700, so that once the power supply has bootstrapped itself the power flowing through the bootstrap resistor can be turned off).  The big, square, four-pin block next to the input pins is the bridge rectifier.

This isn’t a particularly efficient supply for a switcher (running, according to the design sheet, at roughly 75 to 80%, depending upon the combination of input and output voltages), but it does have a remarkably low quiescent current under no-load conditions, so is pretty good for something like a phone charger where the load will suddenly drop off (at full charge), but where the unit itself may remain connected to the mains supply for long periods.  Similar conditions might be found when providing the supply to  an ESP8266 which operates normally for a while and then drops into sleep mode, so it’s no huge surprise to find that ITEAD use virtually the same circuit in their “Sonoff”, ESP8266-based WiFi mains switch.  Looking at the photos of the (shockingly naked) Sonoff we see some very familiar components (again, click for larger sized images):-

Looking at the bottom side of the board, you can see the square block of the bridge rectifier at the top, left-hand corner and then slightly below and to the left our familiar “155” resistors (labelled R16 and R17) with the 6-pin  iW1700 chip sitting over to the left and slightly higher, labelled as U12.  The right hand side of the board is almost entirely given over to the ESP8266 (note the antenna at the extreme top right) and the tinned bus bars connecting the output screw-down connector to the relay and input side.  The empty row of holes slightly to the right of centre bottom are where the 433Mhz RF module sits (in the more expensive remote control “RF” version).  Over on the photo of the top side of the board the same row of empty holes can be seen slightly right of centre closer to the top edge of the board.  Just below them is an unpopulated pad for a QFP chip, labelled as U5.  That’s for the 8051-based “Busy-Bee-1” chip, which appears to handle the control of the 433Mhz module on the “RF” version.

Further down at the bottom of the photo and further to the left of centre is the (yellow) transformer for the power supply and you can clearly see the switching transistor sitting just to the left of it.  The big black box with the white paper label is the relay which switches the output load.

Backing up just a little bit, you’ll note that I said I was “fairly” (not “ecstatically”) happy about the contents of the parcel and the photo of the bottom of the Sonoff board shows why.  If you compare the photo of the PSU board and the PSU section of the Sonoff board you’ll notice a couple of things.  First, the PSU PCB has an isolating slot between the primary and secondary sides of the transformer, while the Sonoff doesn’t.  Second, the iW1700 chip is under the transformer, but on the primary side of the slot on the PSU PCB and, while it’s in the same approximate place on the Sonoff, it has been rotated 90° so that the tracks from the pins now come out towards the secondary pins.  Mmmm, not so good.

Don’t get me wrong.  This is still an isolated supply (the transformer and the winding on the relay both provide isolation to the ESP8266 circuitry), but I don’t believe that the “Sonoff” would pass regulatory inspection in the U.S. or in Europe (the fact that it has screw-down terminals instead of a molded-in power outlet probably makes the PSU issue a moot point, anyway).

Would I use the Sonoff myself?  Heck yes!  I’ll probably buy some more of them, too.  I’ve built much worse things myself (think full-wave rectified 240-volt mains with thyristors on stripboard and run away, screaming), although admittedly, I didn’t sell them as products.  The Sonoff will enable people with minimal knowledge or experience to put together an IoT set-up relatively safely (without having to resort to the horrible mix of stripboard and mains) and, whatever its faults, it is orders of magnitude better than any of the duct-tape-and-hot-glue IoT instructables out there.  Going back to my initial impression, it’s also small.  There are lots of places where a Sonoff would fit in unobtrusively (behind your TV, in an equipment cabinet) where it would save the trouble of needing to be physically there to simply power-cycle some errant piece of electronics.  It looks like a winner to me and that’s even before you factor in the ability of most ESP-aware folks (that’s you) of being able to reprogram the on-board chip to talk MQTT.

Update – See the newer post “No-Phone Sonoff stuff” for more information on loading an MQTT capable package onto the Sonoff.


Yet another offering from AI-Thinker

Well, like just about everyone else in the world, I’ve been waiting for the Middle Kingdom new year’s holiday to get itself over with so that we can get back to ordering stuff in the hope that it’ll turn up in just a couple of weeks, rather than a month or so.  Much to my surprise though, the postie dropped off a little package for me today which I had pretty much assumed hadn’t made it out of the starting gate before the beginning of the holiday.  My second surprise was that the boards in the packet actually worked, right off the bat, without the involvement of soldering iron, boot or hammer.  I was so shocked I had to sit down and settle my nerves with a little drink (luckily the teapot was already warmed, as we’re right out of Scotch).

I’d taken a chance and ordered another couple of AI-Thinker boards, working on the principal that nothing could be as abysmal as the initial experience of the “T5” and, as before, based on the fact that the cost of each board was significantly less that the cost of the components if I were to buy them separately.  These boards are generally referred to as the

Yellow Serial Development Board
AI-Thinker “Yellow Dev Board”

“Yellow Development Board” (or sometimes, “Plate”) and have been available for quite some time (longer than the “T5”, I think).  They come with an assortment of LEDs (most of them tiny little surface-mount parts, but also one ginormous, RGB, through-the-hole jobbie, too), a CDS light sensor (tacked onto the ADC pin), an on-board HT7333 low-quiescent-current voltage regulator, a battery box (3 x AA cells), a jumper to enable programming mode and an ESP8266-ESP12.  One of the neat points of this board is the fact that all  of the ESP8266 pins are available on header pins on the top side of the board and there’s also a separate programming header (which, unfortunately, seems to be incorrectly labelled on the silk screen, with the TX and RX pins reversed when compared to the ESP8266 header pins).

The board comes pre-loaded with a demo which does actually seem to work.  If you have an Android based phone or tablet you can download AI-Thinker’s app to control and mix the colour balance on the RGB LED and to switch the other LEDs on and off.  All very much better than the “T5”.  There are a couple of reviews out there already (here’s Marco’s short video review).  One of the better ones was written by Squix, way back in January of 2015 (I told you this one has been around for a while), including a very nice labelled photo which shows the correct pins on the programming header.

So, why the interest in an old board?  Well, first off, after my bashing of the newer “T5”, I wanted to be able to recommend an AI-Thinker board which is actually functional and good value.  This board is still readily available from lots of sellers and is a cheap way to get your hands on an ESP12 .  As it stands, it is a functional, nifty demonstration of what can be done with a single ESP8266 and a couple of AA batteries.  It is also readily reprogrammable via the 3-pin header to run your own firmware (how about a novelty night-light toy for a child …run a simple light display for a while, sleep for a random amount of time, display, sleep, display…).  Anyway, it seems as though the board would make an excellent platform for hacking into more useful devices, especially as all of the I/Os are split out already.  Adding a few sensors and MQTT functionality should be fairly easy …and that’s what I’ll get into next time.

Update:-  Just to show that you don’t need huge amounts of work to get a small project working …here’s one of these boards with an ENC28J60 module simply wirewrapped to the existing pins (8 connections in all), serving web pages, courtesy of Cicero and Sprite_tm.

I before E, except after C

Working away with the hardware and software for the modified AI-Thinker T5 board, I decided that it was time to shoehorn the thing into a project case and throw it outside, to measure our night-time lows.  Following this line of thought along, I decided I’d have a go at implementing OTA (Over-The-Air) updates, as it would start to get difficult to do updates if I had to climb a ladder with a screwdriver in one hand and the laptop in the other (following the thought even further along, I realised that it was going to be pretty tough to do an OTA update on a device that sits in deep-sleep mode for 99% of the time …but we’ll cross that particular bridge if we ever get to it).  Now anyone who’s worked with any of the ESP8266 toolchains over the past year or so can probably guess what I’m going to say next.  When you change anything with the ESP, you always run into, not just another problem, but a whole extended family (including in-laws) of problems.  I haven’t found any exceptions to this rule to date and I didn’t this time, either.

I was already using v1.6.6 of the Arduino-IDE, but the ArduinoOTA program for the ESP requires v1.6.7 so, not without a little trepidation, I dutifully upgraded.  There were no massive problems.  The IDE fired up again straight away and recompiled my existing application code with n’er a murmur.  I started to get suspicious.  Where were the big red flashing warnings?  Why hadn’t my cat spontaneously combusted?  It’s too quiet!

Moving cautiously on with the plan, I opened the demo application, BasicOTA.ino, in the IDE, compiled it (successfully, again) and then, still using the USB serial adapter, squirted it to the ESP8266 on the T5.  A few seconds afterwards I saw the “Ready” message and an IP address for the board appear in the IDE serial console window.  At this point I had to heave a fairly major sigh of relief …I’d finally hit a problem …all was as it should be in the ESP world.  It was a very, very minor problem, though.  The newly minted IP address for the ESP should have shown up in the Arduino-IDE “Tools” menu as an available programmer, but it didn’t.  However, the OTA documentation warns that this might happen and suggests simply restarting the IDE, which works just fine.  After the restart, I was able to load the original DHT_Test.ino firmware to the ESP8266, hands free.  No holding down the program switch while restarting; just choose the newly available network device as the “programmer”, hit the button and away it goes.  It’s fast, too!  The OTA update only took roughly half the time of the USB method (and I’m not even counting “fiddling with switches” time).

Okay, next step.  We need (according to the documentation) to put the code for the OTA functionality into the target application itself, because the OTA code doesn’t sit in some separate, compartmentalized box somewhere in the ESP memory space, it just gets mixed right in there with everything else (so when I programmed my original DHT_Test code in that previous step as a test of the OTA functionality, it overwrote the OTA which was in memory and I lost the ability to do OTA updates again.  Duh!).

The documentation suggests that we should take the BasicOTA.ino code and just pop it into the target application, giving a fairly easy-to-follow layout, too.  So, we need to add a couple of extra includes.  Nothing too exciting there.  And then we need to add the OTA callbacks into the setup() section of the code.  This looks a bit weird to me.  I’m worried that the code in the example may have been corrupted by the markdown editor, because there are far too many square-brackets and parentheses in there.  However, the code looks the same as the BasicOTA.ino code and I know that worked, so I just quickly check with Oogleg and, having found the identical code in another tutorial, do a quick cut-and-paste.  Having dropped it into what looks approximately like the right-ish area, I save the file and, out of habit, run indent on it.  Oops! very bad move.  Indent says, “There’s far too many square-brackets and parentheses in there.  It’s given me a right headache and I’m going to puke all over your shoes.”, which it promptly did (figuratively, anyway).  After cleaning up the mess (not that difficult when you have a dog an automatic back-up file), I went back in and inserted those magic, indent incantations, /* *INDENT-OFF* */ and /* *INDENT-ON* */ above and below the weird OTA code and ran indent again, without a problem this time.

Now then, I need to put an ArduinoOTA-handle() call into the loop() section of the code.  Oh dear!  The only thing in my loop is a needlessly sarcastic comment and a call to ESP.restart(), just in case the program ever somehow, mistakenly drops through into it. Bugrit! Never mind, I’ll just try a quick compile to see whether what I already have blows anything up. Tra-la-la, IDE, reload, compile, BLAM! Futtocks! Now what?  Maybe indent was right after all!

I’m staring at a simple error message which tells me that I have an error in my lambda function (Wow! Kinky!  I don’t think I’ve ever knowingly used a lambda before) and that OTA_RECEIVE isn’t defined in this scope.  Eh?  I check that I have ArduinoOTA.h included.  I quickly check the include file itself and note that there’s an error enum define which looks okay to me.  I check the order of the includes and lose some more time re-compiling with different combinations of includes, all to no avail.  I’m just about to do what I should have done in the first place (copy the whole BasicOTA.ino file into my code and use the sections verbatim) when I got the urge to fire up “screen” and use the side-by-side mode (CTL-a followed by the pipe “|” character, if yuz didn’t already knaa) to check those small sections of code directly.  Whaddyaknow!  My cut-and-paste code, “RECEIVE”.  BasicOTA.ino, “RECIEVE”.  Bugrit!  I go back and take a closer look at the include file.  Same spelling error.  Rats!  I fire up GitHub, go to the ESP8266/Arduino/libraries/ArduinoOTA …and find that Stavros Korokithakis has already fixed it a couple of months back (thanks for that, Stavros.  The tiny ESP8266 breakout board looks great, by the way).

Onwards and upwards!  So, I fire up the library manager in my squeaky new 1.6.7 Arduino-IDE and have it update da-woyks!  I restart the IDE, fire up another compile and find that the OTA_RECEIVE error is magically gone …to be replaced by the much more verbose:-

/tmp/build319.tmp/libraries/esp-mqtt/mqtt/mqtt.c.o:(.bss.default_private_key_len+0x0): multiple definition of `default_private_key_len'
/tmp/build319.tmp/libraries/ESP8266WiFi/WiFiClientSecure.cpp.o:(.bss.default_private_key_len+0x0): first defined here
/tmp/build319.tmp/libraries/esp-mqtt/mqtt/mqtt.c.o:(.bss.default_certificate_len+0x0): multiple definition of `default_certificate_len'
/tmp/build319.tmp/libraries/ESP8266WiFi/WiFiClientSecure.cpp.o:(.bss.default_certificate_len+0x0): first defined here
collect2: error: ld returned 1 exit status

Hmmm!  I suppose that the OTA_RECEIVE was just a second cousin (think extended families).  This one is definitely a wicked uncle-Ernie, fiddling about (insert air guitar here …only old codgers need apply).

I don’t have much of a clue on where to start with this one, other than the obvious MQTT library.  Unfortunately, that particular library hasn’t been updated for a few months and definitely wasn’t changed by my library update.  I’m starting to run out of patience with the extended family though, so after some more “fiddling about” of my own, I take the path of least resistance and comment out the defines in mqtt.c.  Why that file and not the ESP8266WiFi stuff?  Well, ESP8266WiFi is core and if the lengths are defined there, they’ll get carried through to any other lib in a project which depends upon them (that might not be true in Arduino land, where you need a separate bit of hardware for networking, but I’m fairly sure I’ll be using wireless in everything I do with the ESP …and definitely if I’m using MQTT).

And finally, a clean compile.

It still doesn’t work, of course (no call to the ArduinoOTA-handle() routine), but I’ve had enough for one day and decide to end the evening on a relatively high point.


Sonoff and Slampher – Crowdfunding for an existing product?

The last few articles that I’ve posted have been all about reworking the AI-Thinker T5 board to get it functioning with the on-board ESP-13 module.  You may also have noted that I chose to remove the relay and screw-down terminal, as I didn’t want anyone connecting AC mains voltage to something which obviously wasn’t designed for it, despite the promotional images showing a light-bulb.  Well, here’s another product out of the Middle Kingdom which is not only cheaper than the T5, but apparently a good deal more functional (not too difficult, I know) and safer, too.

Itead Studio is probably a familiar name to most of us, having made a name for themselves producing hobby boards and modules and providing a low-cost PCB service to boot.

Sonoff IoT Switch

They have a new pair of products, going by the not-very-snappy names of Sonoff and Slampher.  They are of interest to us because both contain an ESP8266 chip and provide WiFi control of mains powered devices.  I don’t have either of these units myself (yet), but from all that has appeared so far, they do seem to be quite special.  Sonoff is an in-line, relay based switch for small to medium sized appliances with a 10A rating.

Itead IoT Light Switch

Slampher is a screw-in base connector for light bulbs (it screws into the original socket and then the bulb screws into it) with an SSR which is rated at a more modest 2A.

They are cheap!  Basically a single unit is being sold for around $5 at the moment.  What’s more, they seem to be of quite decent quality, especially considering the price.  From the tear-downs and information I’ve seen elsewhere so far, there’s a switching power supply built in to provide the low voltage DC supply to the logic, there are routed cut-outs on the PCB (on the Sonoff, anyway) to provide physical isolation between the AC mains side and the low-voltage DC side and the single user-input button has a long plastic stem to provide further insulation between the user and the PCB.  The one area where the Sonoff may run afoul of regulatory requirements are the screw-down terminals for input and output connections, but otherwise both units look to be in a completely different league to most other offerings out there in the $10 range.

The units are basically switches, but in addition to the ESP8266 for WiFi, they also have a built in 433Mhz receiver and come with a tiny, key-fob sized 433Mhz remote control.  So you have that long-stemmed switch on each unit which can be used to manually toggle the (mains) device under control on and off, or to configure individual Sonoffs or Slamphers to respond to one (of the four) channels on the remote control (so one remote can control four S&S switches).  In addition to the manual and remote-control modes, the ESP8266 provides connectivity to enable remote switching from your network and Itead provide a free app and “cloud” service, so that your device could be switched on and off from a smart-phone anywhere in the world (no word on security yet, so it’s probably not a good idea to hook up anyone’s life-support system to one of these).  Importantly though, the app does provide feedback for the current state of the switched device (even if it has been manually toggled using the switch on the Sonoff or Slampher), so you can always see if someone else has turned your office coffee-maker on at 03:00 (if you happen to be awake and watching the status on you smart phone at that time of the morning).

Pete Scargill has already been at work with a screwdriver and a USB adapter and apparently has reflashed one of the units he has to use MQTT (which opens the door to local monitoring and control of devices, without the need to utilize Itead’s cloud system).

Peter Oakes has produced a couple of nice videos, the first showing the operation of both units and how to set up the cloud interface and the second is a teardown of both units.

Now the strange thing is, these units first came to my attention because of an on-going fund-raiser on Indiegogo.Sonoff Indiegogo  I liked what I saw (and the price) enough to subscribe for a couple of units (my first crowdfunding effort), but after signing up I discovered that similar units are already on sale in the Itead on-line shop.  Strange!  Why would Itead run a campaign for units which are already in production?  Well, it turns out that one reason is that the units available in their shop are earlier versions, which don’t have the 433Mhz remote control capability, so maybe they’re using Indiegogo not just to fund the production run of the newer models, but also to provide a little bit of extra “visibility” to their sales campaign?  I don’t really know the answer, but I still like the products and the price enough that I’m in for a couple of Sonoffs and am seriously considering whether to buy in for a couple of the Slamphers (despite the awful name), too.  As of the the time this article was penned, we both have twelve days left to decide.

Update – Not about the crowdfunding, but about the devices themselves …I’ve been trawling through the available documentation and it looks as though these devices “do the right thing”  when it comes to power and insulation/isolation.  The schematic shows that the Sonoff uses an iWatt iW1700 switcher chip to provide the low voltage supply to the ESP8266.  This is a really nice little chip which, according to the datasheet, changes modes between PWM (pulse-width-modulation)

iW1700 Typical Application
iW1700 circuit, courtesy of Dialog

and PFM (pulse-frequency-modulation) depending upon the load requirements.  It also has an exceptionally low stand-by current draw.  Regulation is based on current sensing through the drive transistor and voltage sensing through the auxiliary primary winding of the isolating transformer, so there are no opto-isolators required between the secondary and the chip.  At any rate, the supply and design provide “galvanic isolation” between the mains supply and the low-voltage electronics.  Definitely a good thing.

Update – Well, the campaign kinda’ fizzled, which is what I hope the products themselves won’t do, either figuratively or literally.  However, because I was so impressed with the iW1700 and because it matches the requirements of the ESP8266 so well (ultra-low power when the ESP is in sleep mode), I decided to order a bunch of the stand-alone AC supplies (which are available for just $2.50 each directly from ITEAD) as well as a single Sonoff (the version without the 433MHz remote control) just to play around with.  ITEAD obviously ships more promptly than some Middle Kingdom suppliers and everything arrived on my doorstep just six days after ordering.  I still haven’t had time to actually play with anything, but some photos and descriptions are in a newer post.

Reworking the AI Thinker T5 – Part VI – Blinkenlights!

Okay, now we get to the bit that everyone’s been waiting for; we’re going to connect up the LEDs.  Yay!

If you remember back to the original description of the board, I mentioned that there were three LEDs (next to the ESP8266 module) which, with their current-limiting resistors, were arranged in a vaguely spoked shape (and as there are only three spokes, it’s more like an old-fashioned water valve than a bicycle wheel).  Unfortunately, the folks who designed the board put the LEDs on the inside of the spokes (with the resistors on the outside), which kinda’ spoils the effect …and also makes them a little more difficult to wire up, as the cathodes are all so close together.  In an earlier instalment, I added a short jumper wire between GPIO5 of the ESP8266 and the cathode of the blue LED (which is the one closest to the ESP8266), simply so that I could have some indication that the module was powered on and operational.  As with most quick-and-dirty hacks, it has become permanent and, despite the fact that it’s butt-ugly, I’m not planning to change it.  That leaves the two others.

GPIO0 and GPIO2 connections

Going back to the photo of the wiring to switch K1, you can see the short jumper to the blue LED quite clearly.  The spoke pointing directly at switch K2 is a green LED and the one pointing  directly at the edge of the board is a red LED.  It’s also clear from the photo that soldering wires to the cathodes of the two other LEDs would be quite challenging.  Luckily, the drive for all three LEDs came from the QFP 8051 chip, so the cathodes of all three are wired to the pads where that unlucky device used to sit.  Equally luckily (for my shaky-handed soldering), the pad for the blue LED is between the other two and, as the blue is already connected, it gives us a little bit of extra clearance to play with when soldering wires onto the green and red pads.  The original schematic didn’t identify which LED was which, but our updated (ie:- scribbled on) version has them labelled.Annotated schematic As you can see, the drive for the red LED is wired to pad 26 and the green to pad 28, so all we need to do is run wires from spare GPIOs on the ESP to those pads and update our test progam to use them.  We’re going to use the adjacent GPIO14 and GPIO12 as our drive pins (GPIO4, on the other side of the module, is also still free, but we’re going to use that later for the connection to switch K2).  For GPIO14 and GPIO12, we’ll run the wires around the rather bulky (and, for us, badly placed) smoothing cap sited between the ESP module and the edge of the board, under the DHT11 sensor and directly to the QFP pads (which are on the DHT11 side of the footprint).  Again, use super-glue or tiny bits of hot-glue stick, melted with the soldering iron, to hold these (quite long) wires down to the PCB.

After completion, here’s what my board looked like.Red & Green LED Wiring It’s starting to get a little bit crowded around that SMD capacitor, but there’s only one spare GPIO left on that side of the board anyway, so we’re not going to be adding too many more wires.

Updated code is available from the GitHub repository.  The new file is named DHT11_Test_Blinken.ino and, in normal Arduino style, must be moved into a directory named DHT11_Test_Blinken to enable compilation.  Note that the user_config.h file needs to be available in the same directory and that configuration changes specific to your network must be made in that file prior to compilation (ie:- your access-point SSID and password, your MQTTserver hostname and port-number, etc).

Note that if you’ve already completed the previous rework to connect switch K1 to GPIO0, you can now initiate programming mode on your T5 by turning off the power, holding down K1 and the switching the power back on again.  You should be able to release K1 as soon as the board has powered up.

After programming with the “Blinken” code, the coloured LEDs will display a very brief “spinning wheel” at power-on and at all subsequent deep-sleep wake-ups.

The next instalment will cover adding K2 as a “mode control” switch, to change the function of the board at power-up time.

Reworking the AI Thinker T5 – Part V

For this instalment of the rework series, we’re going to keep things simple and only do one, relatively straightforward modification.  Although there’s only one goal, it’s a relatively important one; we’re going to update one of the switches on the T5 board to provide “program” functionality for the ESP8266.  In other words, holding down the switch when you power on the board will put the module into programming mode.

The switches on the board are labelled as “K1” and “K2”.  It turns out that, after a little probing with a meter, the schematic provided for the board is incorrect, in that it shows K1 as being connected to pin-4 of the QFP chip and K2 as being connected to pin-5.  This is actually the reverse of the physical connections on the board, which actually has K1 connecting to pin-5 and K2 connecting to pin-4.   While this is immaterial in the context of this rework, it might be useful information for anyone (AI Thinker?) still trying to struggle along with the original QFP 8051 chip (I should probably add here that, despite all of my AI Thinker “bashing” in this series of posts, the vast majority of the ESP8266 modules which I own were manufactured by AI Thinker and the vast majority of them are actually great products …it’s only this one that turned out to be a stinker).

When you look at the T5 board, one of the things which is very noticeable is that there are some tiny vias and traces on the board which are signals and there are other, much larger, vias and traces which are dedicated to the power rails.  This is standard practice and it also simplifies the work of tracing signals and connections.

“K1” Switch Wiring

It also gives another couple of options when trying to formulate a rework plan (how best to physically connect and route wires and place components) to give us the least amount of work for what we want to achieve.  I this particular case, a via provides a useful connection to the 3v3 supply line on the top (component) side of the board in a location which is almost ideally placed; very close to the K1 and K2 switches.  For this modification, we’re going to provide a pull-up resistor on the GPIO0 line and connect it to the K1 switch, which will become our “Program Mode” switch.  Because the via is so well placed, we’re actually going to use it to provide a second pull-up for K2 as well, but we’ll leave the actual implementation of that second switch for a later article (K2 will become the “User” switch).  So the first part of our rework modification is to add a couple of 22K resistors (this value isn’t critical, but 22K is a good compromise between stability and current draw) between VCC and the switches K1 and K2 (the other side already being connected to ground).  Looking at the photograph above, the ground connections are one the two pins of the switches furthest from the edge of the board (the pencil drawing to the left of the board shows these connected together in a continuous line).  The logic signal connections go to the two pins on each switch closest to the edge of the board.

Pull-ups first …grab two, 1/8 watt 22K resistors, hold them side by side and wrap a couple of turns of one lead from one resistor around the (still straight) lead of the other.  Solder the wrapped joint and trim back the bent lead to make it tidy.  Locate the VCC via on the board between switch K1 and the QFP pads (click on the photo above to see a larger version).  The via has a trace running to pin-10 of the QFP, so it’s easily identified.  Scrape the via clean (if needed), so that the copper is visible (a small, cross-point “plus” driver will work for this).  Bend the soldered leg of the resistor pair to a 90-degree angle, push it through the via and solder in place.  On the resistor which is closest to switch K1, cut the lead short (about 4mm), bend it into a “U” and solder it to the adjacent pin on K1 (again, see photo for details).  The long lead on the remaining resistor should be neatly bent clear of the metal casing of K1, parallel with the edge of the board and soldered to the same pin on switch K2.  You now have pull-ups on both switches.

That was the easy part.  The next bit is a little fiddly (which is why we’re only doing one).  Take some thin, single strand wire (insulated wire-wrap wire is a good choice, you might want to try varnished bell/coil wire if you’re confident that you can get the varnish coating off to tin the end reliably).

“K1” Switch Wiring

We’re going to join switch K1 to GPIO0, so you need to solder one end of the wire to the second pin in on the corner of the ESP8266 next to the DHT11 sensor (I take issue with the pin numbering on these modules …if it was an IC and the antenna was the notched end, then it would be pin number 8.  If that doesn’t make any sense to you, just check the photo instead).  Note that we’ve already, in a previous posting, connected the adjacent pin, GPIO2, to the DHT11 data pin, so you  should now have two wires next to each other.  Route your new, GPIO0 wire under the DHT11, down along the side of the jumperblock and then solder it to the pin on K1 which is opposite the pin where you connected the pull-up resistor earlier.  Tack your wiring down with a couple of small drops of “Super-Glue” (if they sell it where you live …in my country of residence it’s actually an illegal substance — dunno why* — so I use toe-nail** pairings from a hot-glue gun stick, melted with the soldering iron onto the wire***).  Check your work with a meter and hopefully you’re good to go.

Why didn’t we wire up K2 as a “reset” switch?  Well, there’s already a slide switch in the supply line on the T5, so we can save switch K2 for use as a user-defined input device (yup, a “switch”).  To use your new program switch, simply turn off the power to the T5 using the slide switch; hold down switch K1 and then slide the power switch back to the “on” position.  You can let go of K1 pretty much immediately.  That’s it, you’re in program mode …you can throw away those fiddly jumpers now.

For our next instalment, we’ll be adding long jumper wires (now that you’ve got the hang of it) to connect up the green and red LEDs and updating our program to implement a spinning colour wheel.  Whee!  Blinkenlights!


  • – Perhaps the powers-that-be are scared that people will glue all of the politicians’ mouths shut.  🙂
  • Don’t use real toe-nails!
  • Don’t breathe in the fumes.  Do clean the tip of the iron ASAP.

Reworking the AI Thinker T5 – Part IV.V

The board should now be capable of running a somewhat useful program.  I’ve used the Arduino-ESP8266 core to bang this together, not because I’m an Arduino enthusiast (I’m not …I’ve never owned one, borrowed one or even stolen one), but because I found it the easiest environment to program in, given my cack-handed use of C and preference for the “vi” editor.  It just happens to handle libraries and compile code in a way which is easy to install, use and understand and it fits things into the ESP8266’s overly-complex memory footprint without requiring the user to edit SDK files.  It’s just a pity that the IDE sucks so much. 🙂

Any-hoo (see, I can speak Canadian, too!), this mini project uses the ESP8266 to interrogate the DHT11 sensor for temperature and humidity and then spits those readings out, together with a VCC voltage reading and a unique module ID, to MQTT.  After the MQTT publish is confirmed, the ESP8266 will drop into deep-sleep mode, waking itself up (assuming you remembered to connect GPIO16 to the RESET pin) after 10 minutes to start the whole process over again.

The code contains a ton of Serial.print’s, surrounded by #ifdef DEBUG #endif’s.  So as long as you have “DEBUG” defined to something in user_config.h, you’ll also see all of the data on the serial output, too.

Also in the user_config.h file are a few other settings which you must configure for your specific environment.  They include the SSID and password for your WiFi access point and static IP addresses for the ESP8266, gateway and DNS servers, as well as your MQTT server hostname, port number and topic IDs.  Everything else in that file can be tweaked too, but the items mentioned above are pretty much essential changes to get the ESP into operational mode on your specific network.

The code is available from GitHub:- PuceBaboon/ESP8266-AIT-T5

Do you need a T5 board to use this code?  Heck, no!  You can use just about any of the ESP modules out there, from the ESP-03, ESP-07, ESP-12 through to the WROOM-02.  The ESP-03 (and some of the other, older modules) may give you a bit of trouble when it comes to connecting GPIO16 to RESET, but it is doable.  The original ESP-01 is just about the only module I can’t recommend for this project.  You’ll need a DHT11 (or DHT22) and an LED to replicate the original T5 project, but all in all it’s probably easier going with a new ESP-12 than trying to rework the actual T5 board.

Libraries – The code makes use of the Adafruit DHT library and the “esp-mqtt” library from Ingo Randolf, which is a version of TuanPM’s library modded for the Arduino-ESP environment.  You’ll need to add those to your local, Arduino “libraries” directory to be able to compile the code.

A big “Thank you!” to all of those folks above for making their work available to the ESP community.

In the next instalment, we’ll do a simple update to convert one of the switches to a “program” switch (hold it down while powering on to put the ESP into programming mode) instead of having to fiddle with that jumper every time.


Reworking the AI Thinker T5 board – Part IV

I noted last time round that I wasn’t too happy with either the relay, or the red LED on our modified board, so this time we’ll take a look at the simple butchery updates needed to eliminate those particular issues, as well as updating the the hardware and the software to do something a little more useful with the board (and noting another couple of issues which cropped up along the way).

First, it’s time to heat up the soldering iron and get out the de-soldering pump again.  That relay and the associated screw-down terminal block have got to come off (the more I look at this thing, the more the idea of someone being tempted to connect mains up to it for an IoT lightbulb gives me the screaming heebie-jeebies).  The red LED is fairly inoffensive, but seeing as it sucks battery power, it’s “off with its head!” there, too.

Red LED – There it was, gone!

While the LED just needs some gentle coaxing with a hot, small-tipped iron, the relay and the screw-down block do need some serious heat to de-solder the pins, so don’t expect to do the job with a 15w Antex (nice though they are) and some pre-used solder braid.  If you have one of those neat, refillable gas irons (the ones which have a catalytic heating element and run on butane lighter fuel), this is exactly the sort of job you bought it for (but a 60w rated electric iron will work, too).  Use some flux if you have it, or a tiny bit of cored solder if you don’t, so that the joints are well “wetted” before applying the de-soldering pump.  In this case (as we’re not planning on replacing, or ever using those components), it’s also acceptable to use a flat-bladed screwdriver to apply some mechanical force to the de-soldered pins to pry them away from the side of the hole (this can break the through-plating on pin holes, so don’t ever use this technique when replacing components on multi-layer boards).  When in doubt with this particular board, brute-force and ignorance are the order of the day (just remember that incessant beeping and act accordingly).

Relay/screw-down removed

The end result of these mods is some extra space on the board and a drop in current consumption, too.

Keen-eyed readers will already have noticed the ugly, short yellow wire visible top-centre in this photo.  It’s a quick link I added between GPIO5 on the ESP8266 and the blue LED on the board, just to give me some extra debugging and a visible indication that the board is powered (the code in the previous article already has a few lines in there to give this LED a very quick multiple flash when power is first applied and a single short flash when the DHT11 is accessed).  Note that in the photo above, the DHT11 is now standing up vertically on the board.  This is because the heat from the ESP8266  was adding about 3C to the DHT11 readings after a few minutes of continuous use (no wonder the batteries weren’t lasting long …we were powering a space heater!).  The second part of the fix for this issue was to add another, short jumper (not visible in the photo above) between GPIO16 and the reset pin on the ESP, to enable wake from deep-sleep.  Now we can have the ESP wake itself up, take a temperature reading, then connect via WiFi to send the data to an MQTT server before going back to sleep.  Wow, something useful!

Before getting to the software, I should mention the second issue I found with the hardware (the first was the poor positioning of the DHT11 right next to the warm ESP8266).  While I was levering junk off the board with a crowbar and blowtorch, I also did some preliminary investigations into the feasibility of using the tact switches, “K1” and “K2” as reset and program buttons for the ESP.  I was looking at whether either of them had tracks or vias which were close enough to the ESP to make wiring them up quick and simple (the quick and simple answer to that is “No”).  It turns out that the silkscreen on the board and the schematic do not match.  Switch K1 is shown on the schematic as connecting to pin-4 of the QFP chip and K2 to pin-5.  In fact (on my board, anyway), it’s the other way around; K2 connects to pin-4 and K1 connects to pin-5.  That information might be useful if you’re planning to do something with K1/K2 in the future (or if you’ve got an original board which, for some obscure reason, you haven’t butchered or stamped-into-the-ground, yet).

Here’s the link to the next (short) article in the series, with the software description.


Reworking the AI Thinker T5 – Part III

In the previous post, we did some simple, straightforward modifications to get the “Black board T5” working using the ESP8266 alone.  In this part, we’ll go over a very simple application to demonstrate that the ESP8266 is alive and kicking and will download a program as normal (in program mode) and will also run that program (Duh!) and communicate with the DHT11 temperature/humidity sensor.

But first, as I mentioned in Part-II, if you have (as I do) a 5v-only USB to serial converter, you’ll need to add a 5v-to-3v3 voltage converter for the TX and RX pins, otherwise there’s a good possibility that the magic smoke will escape from your ESP8266 module.  I’m using the tried and tested MOSFET conversion method, which uses a single, N-Channel MOSFET (and two resistors) in each line to do the conversion.  You can buy these as 4-way converters on eBay for about $1 each, but the circuit is so simple that I tend to throw mine together on odd scraps of stripboard whenever I need one. For the T5 board, there’s some hardware already available which makes the stripboard method even easier.

As you’ll have noticed, there’s a nice, 5-pin connector off to one side of the board which was apparently intended as a camera port.  There aren’tOLYMPUS DIGITAL CAMERA

too many details available on what camera, or what the intended use actually was, but the important point (for us) is that pin-1 on the connector is GND and pin-5 is 3v3, with the three middle pins now free (as we’ve already removed the STC QFP micro to which those pins were connected).  By a happy coincidence, we need just exactly that number of pins to attach our 5v-to-3v3 converter (TX, RX and 5v, in addition to the existing GND and 3v3).

I’m going to show you how I implemented this connection, but as always, there are several different options available to you and you should choose whichever one is the easiest or the best match to your particular circumstances.  Some of the options you might want to consider:-

  • Find a matching plug for the camera socket and use it.
  • Remove the camera socket and replace it with pins or flying leads.
  • Ignore the socket and solder flying leads directly to existing pads.
  • Butcher the socket, because we just enjoy inflicting damage on this board (insert mandatory evil chuckle here).

Of course, I chose the last option (but in the interests of completeness I should also mention that I removed the socket from the board first,

Nekkid camera socket

thinking that I would replace it with straight pins, before realizing that that was extra work and not so much fun!).  I should also mention that removing the socket is quite difficult, so I wouldn’t recommend that particular option.  Note the odd silkscreen pin descriptions which were hidden under the socket.  It seems that “CG”, “CT”, “CR” and “CV” probably stand for “Camera Ground”, “Camera Transmit”, “Camera Receive” and “Camera Volts”, respectively.

Anyway,  after consuming about twenty odd cups of tea, I had a rare flash of inspiration (in addition to the ten odd flushes) and realized that  I could just snip the top and side plastic shielding away from the existing plug and solder the chunk of stripboard with the voltage converter circuit directly to the pins (you can do this without removing the socket from the board).  Then, on the reverse side of the T5 PCB, I simply jumpered the TX and RX pins for the ESP8266 to the “WIFI_TX” and “WIFI_RX” jumper pins (described in Part-II).  The advantages of this method are, further sadistic butchery of the T5, no flying leads and the converter board is always attached to the place we want it (rather than having to search through piles of junk other projects to find it each time we want to reprogram the board).



The circuit for the MOSFET voltage converter can easily be found on-line by doing an Oogleg search for “MOSFET voltage level converter”.  Neither the MOSFET type nor resistor values are particularly critical in this particular application.

Okay, so we now have a board which we can program, so we need to write some software to drive it.  I’m using the Arduino-ESP core, simply because I find that it works reliably at fitting programs into the limited memory of the ESP8266 without too much faffing around on my part.  I’m not an Arduino guy (don’t own any boards, or chips) and I’m definitely not keen on the Arduino IDE, but the rest of the set up just works reliably for programming ESP8266 modules.

Here’s some code which is just a tiny bit longer than the absolute minimum to get you going with your newly modified T5 board:-

* $Id: DHT_Test.ino,v 1.3 2015/12/11 02:09:02 anoncvs Exp $
* Test program for the AI Thinker "Black board T5", after
* modification to remove the 8051-based QFP micro and wire
* the DHT11 sensor and blue LED directly to the ESP8266.
#include "DHT.h" // We're using the Adafruit version.

// DHT dht;
#define LDELAY 10 * 1000 // Loop delay (10 seconds).
#define DHTPIN 2 // DHT11 sensor on GPIO2.
ADC_MODE(ADC_VCC); // Required for correct operation of 3v3 measurement.
int BLED = 5; // Our WiFi debug LED is on GPIO5.
float temperature = 0;
float humidity = 0;

DHT dht(DHTPIN, DHT11, 15);

* Turn on the blue WiFi debug LED for a short
* flash. Note that on the T5 board the LED is
* driven by a low-side switch.
void BFlash() {
digitalWrite(BLED, LOW);
digitalWrite(BLED, HIGH);

* Try to get a valid reading from the DHT11 sensor
* (not always easy).
void getSensorData() {
temperature = dht.readTemperature();
humidity = dht.readHumidity();
while ((isnan(temperature) || isnan(humidity))
|| (temperature == 0 && humidity == 0)) {
temperature = dht.readTemperature();
humidity = dht.readHumidity();

void setup() {
delay(500); // Pause for boot-up crap.
pinMode(BLED, OUTPUT); // Ensure our blue LED driver pin is an output.
Serial.println(“Status\tHumidity (%)\tTemperature (C)”);

void loop() {
float vdd = ESP.getVcc() / 1000.0;


Serial.print(“Temperature: “);
Serial.print(“c – Humidity: “);
Serial.print(“% – Voltage: “);
Serial.println(“v “);

Note that this code uses the Adafruit DHT library (please send them some of your custom  — if you happen to live on a favoured continent, you can get an Adafruit ESP8266 “Huzzah” for just about the same as you’d spend on the POJ T5 board).  This simple program doesn’t use the wireless capability of the ESP8266 at all; it just sits in a loop and squirts the temperature and humidity readings from the sensor out to the serial port every ten seconds (it also displays the current 3v3 line voltage as an added extra).

Because the T5 uses the DHT11, there’s also a while() loop in the getSensorData() function which will basically discard the (fairly frequent) bad readings returned by this particular sensor.

While we’re on the subject of the DHT11, you’ll notice when you fire up your board and start using it, that the sensor starts to read high after a few minutes.  This is because of the heat generated by the ESP8266 (which the DHT11, by a poor design choice, is sitting right next to).  You can alleviate the effects somewhat by lifting the DHT11 from its flat-on-the-board position to standing vertically, instead.  It will still read a little high (because this simple program doesn’t put the ESP8266 to sleep), but it will be noticeably better than before.

Finally, again, because the ESP8266 doesn’t sleep with this simple program and because the red, power LED is always on, the batteries will last barely 24-hours if you leave your module switched on permanently.  We’ll do something about that next time.