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.





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, with TASMOTA using the One Wire library 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).

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


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.






Hackaday Coin-Cell Challenge

One of the entries in the Hackaday Coin-Cell Challenge piqued my interest, initially because it featured an ESP, but then because of the beautiful display.  The project goes by the name of “Badgy” and is basically just another WiFi enabled, conference-style badge.  I was surprised that it used an ESP8266, because the whole point of the Coin-Cell Challenge was to eke out the maximum amount of life from a coin cell battery …and the ESP8266 is certainly not known for it’s low power consumption.  "Badgy" e-Paper Display As it turns out, the project’s creator, W4ilun, gives a whopping 35-day run-time for the device …but only when it’s in deep-sleep mode; with “normal” use that figure tumbles to around 21-hours (Ouch!).

Still, the thing that hooked me about the project was the beautiful display.  Checkout W4ilun’s gallery pages to see more examples of this stunning little e-Paper module.

The two things which have put me off these displays in the past are the complicated interface/support requirements and the prices.  This little module seems to have (almost!) nailed those two drawbacks.  The price is very competitive with current OLED modules (once you manage to find the supplier, anyway) and the weird voltage requirements which e-Paper displays have, is mostly handled on-module by the device itself, apart from a requirement for a simple, MOSFET boost circuit to generate the positive and negative gate drive voltages (this is driven from the display module, but the user needs to implement the circuit discretely …and no, I don’t know why it isn’t included on the display module, either.  See page 50 of the manufacturer’s data sheet if you’re interested). The down side on the interface side is that it has a super-tiny 24-pin connector which your average, ageing through-hole-component constructor (with shaky hands) just isn’t going to be able to hack (so, even though W4ilun is offering the bare boards on Tindie, I’d like to suggest that he also sells a board-plus-display option, too).

If it wasn’t for that horrible connector, I would have ordered a couple of these displays already.  As it is, I’ll be waiting for someone to produce an old-git-friendly version (preferably for about $8, including worldwide postage 😉  ).

Anyway, many thanks to W4ilun for all of the work he’s put in on this project and many congratulations to him on getting into the winner’s circle on Hackaday.

W4ilun’s GitHub repository for this project can be found here.

ArduinoDIY Blog Added

This morning(Merry Xmas!!) I’ve added the “ArduinoDIY” blog to the list of reading materials that might interest you (see the bottom of the right-hand panel).  The blog is written by the scarily named “Yersinia” (so please wash your hands after viewing) and, despite the “Arduino” part of the name, does have a lot of very interesting ESP8266 related content.  In addition to the ESP stuff, there’s a whole boat-load of other, more general electronics and programming stuff which will undoubtedly tickle your fancy (especially if you’re looking to get away from the goggle-box for an hour or two this holiday season).


Today’s (short) “duh!” story

I was going to try experimenting with ESP-Now (Espressif’s lightweight wireless protocol which uses a minimal networking stack to provide minimal, point-to-point communications between ESP modules), as it promises a very much faster start-up and delivery for short messages for things like dedicated battery-powered sensors which only send very limited amounts of data.  There are a few examples out there; the most notable probably being HarringayMakerSpace’s ESP-Now Examples repository by Anthony (TornTrousers) Elder, which I promptly downloaded.

I’m using PlatformIO as my build environment, mainly because I feel more comfortable using the command line, but also because it generally just works.  So, I created a new project directory with the BME sensor example and confidently connected up an ESP module to USB, ready to flash.  Uh-uh!  ’twas not to be.  The compile went merrily along until it hit the linker section and then fell over in a messy heap, with:-

Linking .pioenvs/nodemcuv2/firmware.elf
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o:(.text.setup+0x1c): undefined reference to `esp_now_init'
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o:(.text.setup+0x20): undefined reference to `esp_now_set_self_role'
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o:(.text.setup+0x24): undefined reference to `esp_now_add_peer'
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o:(.text.setup+0x28): undefined reference to `esp_now_register_send_cb'
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o:(.text.setup+0x2c): undefined reference to `esp_now_send'
.pioenvs/nodemcuv2/src/espnow-sensor-bme280.ino.o: In function `setup':
espnow-sensor-bme280.ino.cpp:(.text.setup+0xa6): undefined reference to `esp_now_init'
espnow-sensor-bme280.ino.cpp:(.text.setup+0xbc): undefined reference to `esp_now_set_self_role'
espnow-sensor-bme280.ino.cpp:(.text.setup+0xce): undefined reference to `esp_now_add_peer'
espnow-sensor-bme280.ino.cpp:(.text.setup+0xd7): undefined reference to `esp_now_register_send_cb'
espnow-sensor-bme280.ino.cpp:(.text.setup+0xff): undefined reference to `esp_now_send'
collect2: error: ld returned 1 exit status

In other words, it couldn’t find the ESP-Now library.  This seemed pretty strange to me, as it’s and Espressif library, not a contributed, external library and, as such, I would have expected it to be automatically linked in.

I tried a lot of things (most of which were quite silly), to no avail.  A little bit of investigation showed that the ESP-Now library did indeed exist under:-


…with the espnow.h sitting in the include subdir and the libespnow.a in the lib subdir.

A little bit of Oogleg’ing brought up a hit where an Arduino user was having the same problem, where the suggested (and tested) fix was to add “-lespnow” to the compiler.c.elf.libs line in the relevant platform.txt file, but unfortunately that didn’t seem to make any difference for PlatformIO.  I kept on thinking that it really shouldn’t be that difficult (most things aren’t with PlatformIO) and finally had a small flash of inspiration.

I went back to the project directory and simply added:-

build_flags = -lespnow

…into the [env:……] section of my platformio.ini file.

Clean compile; no errors.

Duh!  KISS!!

Special message for someone with more time on his hands than he actually wants and is probably scouring the ‘net for anything readable with ESP8266 in it.

Take it easy Pete and listen to what the Doc’ (and HID) says.  Let me know if you want some green tea (seriously!).  All the best!


Sonoff-TASMOTA Updates

Theo has (as usual) been very busy with TASMOTA and has pushed out two releases in the last couple of weeks.  The first, at the very end of October (the “Halloween-een” 5.9.0 release) was a fairly massive update, with portions of the code being updated to follow Google’s C++ style guide as well as rewrites of some of the code to use command look-up tables and JavaScript.  In addition to those, there are seventy-odd other fixes, changes and additions.  Phew!  A couple of the notable items are:-

  • Addition of support for the Arilux AL-LC01 RGB LED controller.
  • Addition of support for the Magic Home RGBW LED controller.
  • Addition of support for the KMC 70011 Power Monitoring Smart Plug.
  • Addition of support for the VEML6070 I2C Ultra Violet sensor.
  • Addition of support for ‘inverted’ PWM.
  • Addition of support for the Luani HVIO (230v dual power control) board.
  • Addition of sea-level pressure calculation and a new ‘altitude’ command.
  • Addition of support for up to 8 relays (possible new product hint?).
  • Fixes for timezone and southern hemisphere STD/DST times.
  • Fix for a large flash erase issue.
  • Fix for ‘all-off’ issue when SaveState is inactive.
  • Fix for a pressure calculation issue with some BMP sensors.

…and lots more (check out the _releasenotes.ino file in the sonoff directory for the full listing).

The second release, 5.9.1, on the 7th of Nov, doesn’t have quite so many updates, but does add functionality to make addition of external sensors even easier and also adds support for the ADS1115 I2C AtoD chip, which a lot of people are going to find very useful.

That’s just a short round-up (I have no idea where Theo gets the time to do all of this magic …he must type at the speed of light) and, as already mentioned above, there are a lot more changes and fixes in there, so I’d recommend that you stroll over to GitHub and pull the latest version (it’s almost guaranteed to have even newer additions by the time you get there).



A Bluetooth LE upgrade to OpenMQTTGateway

Florian Robert has been making regular additions to his OpenMQTTGateway package over the past few months.

OpenMQTTGateway is, as the name suggests, a bi-directional gateway between MQTT and other hardware and/or protocols that may be running in or around your smart home.  It supports most of the ESP8266 range of hardware, as well as an Arduino equipped with a Wiz W5100 ethernet adapter.  The basic idea is that your ESP (or Arduino) interfaces with MQTT on the main network and provides seamless communications with (for instance) 433MHz or IR devices which otherwise are not directly connected.

A while back Florian made the package easily upgradeable by adding module support, where contributors can add support for other hardware and protocols by adding additional module files, rather than having to mess with the core functionality.  This usually comes down to adding a single “ZgatewayXX.ino” or “ZsensorXX.ino” file (where “XX” is a unique identifier) and possibly an additional .h file, depending upon how complex your Z file is.

The latest addition is for a Bluetooth Low Energy based plant sensor (the Mi Flora) and provides a useful example of interfacing to BLE devices.

Automatic OTA Updates

Most OTA schemes just allow you to push an update to your ESP8266, but Xose Pérez’s latest offering, “NoFUSS”,  is a plug-in for your ESP8266 project which enables your ESP8266 to regularly check in with a specified server and automatically download an update if there’s one  available.  Neat!

In addition to the simple update functionality, NoFuss allows you to configure whether updates will be offered to specific groups of ESPs (for instance, temperature sensors which might all use the BME280 module) and to configure a specific load sequence (so that the SPIFFS filesystem on the target ESP might be updated before the actual project firmware).

The requirements for implementing this on your home network are fairly simple.  The server side requires a web-server capable of supporting PHP.  The ESP side requires that you add Xose’s NoFUSSClient library to your ESP project.  The configuration for both sides is explained in Xose’s original article and the git repository for the project is available here.