Using oddball ESP boards with TASMOTA

Theo Arends continues to fix, improve and expand TASMOTA at a rate that, as a mere mortal, I find incredible.  One of the areas which has seen a lot of activity is the list of supported modules and devices.  When you connect to the web server on your device and select the configuration menu, the top item on the list is “Configure Module”.  This allows you to select your specific hardware (currently, with release 5.11.1, ranging from the original ITead Sonoff Basic, all the way through to the Arilux LC06 RGB LED controller) to enable device-specific features in TASMOTA.

While there are 40-odd entries in the module list, the question is, are you out of luck if your hardware isn’t yet included?  The answer, I’m glad to report, is a resounding “Heck, no!”.  Theo has included a couple of devices in the list which make it relatively easy to drop TASMOTA onto pretty much anything which has an ESP8266 device on-board and have it work,not only with the basic relay switching function, but also with a whole load of other, custom goodies connected.  Here’s an example.

Yellow Serial Development Board

I usually have a couple of the “Yellow Dev Boards” to hand, mainly because they’re so easy to press into service without having to jump through too many hoops.  They have plenty of nice LEDs, an on-board, low quiescent current voltage regulator and an attached battery holder (making for an easy, remote sensor platform), an LDR already wired to the ADC input, all driven by an ESP12 variant (the version has varied over time).

TASMOTA doesn’t have a configuration entry for the Yellow Dev Board specifically, but because the board has an ESP12, most of the entries on the list will work to some degree or other.  Okay, so why don’t we just go with the default “Sonoff Basic” then?  Because the Basic only has a limited number of GPIOs available (and some of them are inverted via MOSFET drivers), it doesn’t lend itself too well to customization.  You can load your own board with the Basic and successfully connect to the TASMOTA web server, but then you really need to look through the hardware available in the “Configure Modules” list and find something which is closer to your specific hardware.

Module_Select-IIf you’re using a Witty Cloud board (rather than the Yellow), for instance, you’re in luck; entry #32 in the modules list is for that specific board.  If you have a Wemos D1 Mini, that’s also included at number #18.  It’s worth scanning the list to see whether your specific board might have been added recently.Module_Select-II

As you can see from the screenshots, the entries in the list aren’t sorted, so searching for an entry can be a little difficult.

As it turns out, the WeMos D1 entry is a good choice when you’re using an ESP12 series ESP8266 and this is the one I’ve chosen in the screenshot examples (the grey entry at the very top).  After selecting (and saving!) this module type, you’ll find that the GPIO options are greatly expanded, compared to the Sonoff Basic.

Sonoff-BasicWeMos-D1

 

 

 

Note that the WeMos D1 parameter list includes the WeMos pin nomenclature to the left of the GPIO names and the Sonoff default assignations to the right.  This looks a little confusing at first glance, but is actually quite useful when deciding where to connect peripheral devices on your own ESP module (for instance, assigning your relay/SSR to GPIO12 and LED to GPIO13 will still leave your device working if the module type is changed back to Sonoff Basic at any time in the future).

The drop-down selection box to the right of each GPIO (currently showing “00 None”) allows you to select what function or peripheral you’d like to have assigned to that pin.  Again, choosing the WeMos D1 module type enables a wide range of options for each individual GPIO (as of version 5.11.1 of TASMOTA, there are 64 different switches, buttons, LEDs, sensors, busses, relays and functions available, including some which I assume are device specific — what’s a “PZEM Tx”?? — and others which look like a future project in the making — do “IRrecv” or “BkLight” sound interesting to anyone other than me?).

So, going back to our Yellow Dev board, we have an RGB LED, as well as a bunch of boring old red LEDs across the top of the board (see the picture, above).  In this particular application, we’re going to add a DS18B20 temperature sensor to GPIO5 and a small, solid-state relay (SSR) to GPIO12 (the default Sonoff relay pin).  This is going to allow us to switch an incandescent light bulb on (as a low power heater) when the DS18B20 indicates that the temperature has dropped below freezing.  As it’s no fun at all to do this sort of thing without blinkenlights, we’re also going to use the RGB LED to indicate freezing temperatures (blue flashes), above freezing (red flashes) and, for bonus points with those people who aren’t as colour-blind as I am, hovering around freezing point (purple flashes).  We’re also going to add a button to GPIO0 which will provide the standard Sonoff/TASMOTA functions of toggle (for the relay/SSR), as well as the ESP8266 default of forcing the module into programming mode when pressed at power-on.

We’re going to use two methods to drive the LEDs; simple on/off for the green LED (because it’s the Sonoff default power LED, as the handy cross-reference in the Module Type menu, above right, shows us) and PWM drive for the red LED (GPIO14) and blue LED (GPIO15).

One point to note about the green LED is that the xref text shows it as “Led1i”.  That trailing “i” indicates that, on the Sonoff, the ESP output is inverted, because the LED is actually driven via a dedicated MOSFET.  On our Yellow board there’s no driver MOSFET, so we choose the non-inverting “Led1” when assigning a device to GPIO13.

GPIO14 and GPIO15 are LEDs, but because we want to vary the intensity and mix the colours (it’s that chunky, though-hole RGB LED at the top right of the Yellow board, remember), we’re going to assign types PWM1 and PWM2 to them.

The SSR is assigned type “Relay1” on the Sonoff default GPIO12 and we assign type “DS18B20” to GPIO5.  The sensor assign does neat stuff, using Theo’s modified version the One Wire code to communicate on the designated pin (you must add a 4k7 resistor between the 3v3 pin and the data pin to have this work correctly and, if you’re using a sensor on long, unshielded leads, I’d recommend that you place the resistor at the outer, DS18B20 end, rather than on the GPIO end and add a 0.1µf between the DS18B20 ground and 3v3 pins).

Here’s what the module configuration panel looks like with all of those changes made:-

Module_GPIOs

When you hit “Save”, the module will be restarted with your new configuration implemented.  At this point it would be a good idea to go back into the main configuration menu and select “Backup Configuration” to save all of those changes to a file on your local machine.

In the second part of this post, we’ll look at some minor hacking of the Yellow board hardware to make a functional device, as well as going over the web and MQTT commands to get the peripherals working.

 

 

 

 

Simple demo for the “Yellow” board

As promised in the previous post, we’re going to explore a simple application for the Yellow Development Board this time round.  The one thing that this board has plenty of is LEDs.Yellow Serial Development Board  There are half-a-dozen red LEDs and one blue across the bottom of the board, as well as a 5mm RGB LED.  So, not surprisingly, we’re going for the “Blinkenlights” option as the first demo.  You won’t need an MQTT server or even a working access-point to have this demo work, but the display does get a bit boring quite quickly.

If you have modified your board with the addition of the latching power switch described in the hardware article, this demo will turn itself off after three minutes of run time.  If you haven’t added the switch, you’ll have to remove power by pulling one of the batteries out, otherwise it will just keep on running until the batteries are completely depleted.

The code for this first demo is available (with the other demos) in the GitHub repository.  The filename is Initial_Power+LEDs.ino.  My preferred environment for compiling ESP8266 programs nowadays is PlatformIO (if you haven’t tried it yet, you should give it a go); it makes compiling programs for multiple different architectures a breeze and you don’t have to worry about shoehorning things in, it just does the right thing.  Anyway, the demo programs are basically Arduino-IDE format for the ESP8266, so whether your preferred  environment is PlatformIO or Arduino-IDE, they should just work for you (if you’re still in the dark ages, using Espressif’s SDK, you’re on your own!).

In addition to the base demo itself, Over-The-Air update functionality is also built in to each program, so assuming that you have a working network and access point, you should only need to upload to your ESP8266 by serial the very first time, after that you can use the normal Arduino or PlatformIO OTA commands to upload a new demo file.

Note that all of the demos are set up to use a static IP address, netmask, gateway and DNS server.  This is to ensure that the ESP starts up as quickly as possible in a real “button” application.  The WiFi channel number is also specified, again as part of a fast, robust start-up procedure.

Before compiling any of the demos, you need to go through the user_config.h file and change all of the default settings in there to match your local network.  The specific settings you should be interested in are:-

  • LOCATION   [optional]  Setting this to your general region may help you to find your own results when using a public MQTT server for the later demos.
  • STA_SSID  [required]  Set this to the SSID (name) of your Access Point.
  • STA_PASS  [required]  Set this to the (WiFi network) password requested by your Access Point when connecting.
  • WIFI_IPADDR  [required]  Set this to be the IP address which you want this specific ESP module to use (it is assumed that you know your own network …DO NOT simply choose a random IP).
  • WIFI_NETMASK  [required]  This should be set to use your network specific addressing scheme.  Generally, if your IP addresses begin with “192.” you should be okay to leave this as “255.255.255.0”, but if you don’t know, please ask someone who does.
  • WIFI_GATEWY  [required]  This should be set to the IP address of your gateway router.
  • WIFI_DNSSRV  [required]  This should be set to the IP address of your local DNS server.
  • WIFI_CHANNEL [required]  This is the number of the WiFi channel which your access point is using (and can be between 1 and 14, depending upon where in the world you are).
  • MQTT_HOST  [required for later demos]  See later explanation for this option.

If you don’t know the answer to any of the “WIFI_*” settings, you need to find someone with a better knowledge of your local network and ask them;  DO NOT just guess.  You could effectively cripple the whole of your local network with a wrong answer to some of these questions.

If you have a good, robust working DHCP server and you don’t care about start-up speed, you might want to convert these programs to use DHCP instead.  As this is by far the most common option in ESP8266 programs generally available on the ‘net, I will leave this conversion as an exercise for the reader (it’s quite a bit shorter and simpler than the static address variation used here).

Although MQTT isn’t required for this first demo, I’m going to mention it here anyway, just so you know what some of the options in the user_config.h file are.  The default setting for MQTT_HOST in that file is “broker.hivemq.com”, which is a publicly accessible server in Germany which HiveMQ very kindly make available for testing.  HiveMQ also provide a whole bunch of MQTT related resources and services, so please do send any business you can in their direction.  Please DO NOT bug them with support requests for these demos; those requests should come to me.  Please also note that the HiveMQ server gets -very- busy (it’s not unusual to see in excess of 1,000 concurrently connected clients), so it can be quite difficult to see any output from your specific device on their web dashboard.  Please resist the temptation to increase your publishing rate; the server is already busy enough.

If, on the other hand, you have a local MQTT broker (server‡), then you should change the MQTT_HOST option in user_config.h to point to it specifically from the very start (if you don’t yet have an MQTT server set up, I would recommend the Mosquitto package; it comes with the broker and with two command-line utilities, mosquitto_pub and mosquitto_sub, which allow you to easily publish or subscribe to topics on either your local broker, or any other publicly accessible broker service on the ‘net.  Mosquitto is available as an optional package for most Linux variants through the software manager and there’s also a binary package available for Windows).

The MQTT_CLIENT_ID is a symbolic ID used by your ESP8266 when talking to the server.  It enables the MQTT broker to differentiate between the dozens of ESP8266 modules which you have connected to your network.  The string “ESP8266_%06X” is automatically replaced at run time with a six-digit number created from the unique ESP8266 chip-ID, to provide something like “ESP8266_09C721”.  This prevents potential clashes where two (or more) ESPs sharing the same ID would cause each other to be disconnected from the MQTT broker when a new request comes from a different address.  This means that if 500 of my closest friends all decide to build the MQTT demo and use the default, publicly addressable HiveMQ server, they should all work perfectly, without trampling over one another.

Finally, note that our ESP client can handle three different topics (only two are defined by default).  TOPIC1 is defined as “timestamp” and we become a subscriber to that topic (the HiveMQ broker currently publishes a timestamp every few seconds).  TOPIC2 is defined as “Yellow/LDR” and our MQTT demo program will publish regular updates to it.  The data published to that topic is the ADC value of the ESP8266 pin with the LDR attached (so the value depends upon the ambient light level).

All of the demo programs, including the non-MQTT version, will print out info to the serial port, including regular LDR value updates.

The mood-light display mode on the Yellow is based on code by “Mike Mc” (Mike McRoberts, author of “Beginning Arduino”).  The code uses a 256 entry look-up table to compensate for our weird vision and produce what looks like a linear fade to our eyes.  Kudos to Mike for writing such a durable routine, which works very well on the ESP, despite its proclivity for running off and doing WiFi-ish stuff at unpredictable intervals.

Speaking of the need to service WiFi requests and other housekeeping, the reader will notice that there are calls to yield() sprinkled liberally throughout the code and that there is also an added function, Ydelay(), which is simply a call to the normal delay function with an additional call to yield() thrown in.  It seems like you can’t call yield() often enough in any ESP code that could get itself caught in a tight loop.

 


‡ I use the terms “broker” and “server” interchangeably, but strictly speaking, the “broker” is the MQTT process running on what we loosely refer to as a (hardware) server.  Your client devices all connect to and exchange messages with this server.  You’re not confused, are you?!?!

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.