Adding a cheap Ethernet Port to your ESP (revisited)

Update @ Sat 17th Feb — The source code for this project is now available from my GitHub repository.

Update @ 8th Mar 2018 —  Currently the DHCP option doesn’t work (timeouts/WDT-resets).  The IP address of the W5500 will need to be set manually in the code (thanks to “1rabbit” for the heads-up on this issue).

A few months back I pointed readers to an article by Frank Sautter on adding an Ethernet port to the ESP32 which I found quite interesting.  It reminded me that I’d been playing around with a Wiznet wiz820io board a while back on an older PIC-based project, so I pulled it out of the parts drawer and started fiddling with trying to get it working with an ESP8266 module.  There were some signs of life, but it was so flaky that I really didn’t quite know whether I had dodgy hardware or whether my graft of the ESP8266 code from the W5100 library to the W5200 library was just crap (the latter being a very strong possibility).  It had whetted my appetite though, as I was looking for a means to interface an ESP module to my LAN as an ESP-Now gateway.  Top view of W5500 boardSo I ended up getting one of the (cheap) newer W5500 modules (the one with the yellow pin header and the “PWOER” LED label)‡ which are popping up all over the place at the moment at about $4 shipped (click on the picture on the right to see the full-size image of the board).  The W5500 handles more sockets than the older versions of the chip and is generally recommended for newer designs (it’s a little cheaper, too).

Although the W5500 needed a little tweaking to get going, there weren’t any serious issues with either the hardware or the software and it didn’t take too long to get it working.  One issue (which is actually an ESP problem, not a W5500 one) is that the chip-select for the external SPI is actually routed via GPIO15 and, as we pretty much all know from experience by now, that’s one of the “magic” pins at boot-up/reset which changes the way that the ESP8266 behaves.  In fact there’s a pull-up resistor on the W5500 (and, as far as I know, all of the other Wiznet modules) CS line which will cause the ESP to drop into programming mode if the W5500 CS line is simply connected directly to GPIO15.  The solution to that is quite easy — put a PNP transistor buffer (configured as an emitter follower) between the two.  Emitter-Follower-PNPBecause of the pull-up on the W5500 board, you don’t need an emitter resistor, but you do need to add a base resistor of somewhere in the region of 3k3 between GPIO15 and the transistor’s base (and the collector of the transistor goes directly to ground).  Any small-signal PNP transistor, such as the BC560 or 2N3906 should work in this situation; it’s not that critical.  This fix should work for pretty much any SPI connected peripheral board …but you might have to add the emitter resistor if the target board doesn’t already have a pull-up.

The second hardware requirement is that we need to dedicate another, non-SPI GPIO as a reset driver for the W5500.  On my test board I used GPIO5.  This allows us to hold the W5500 in reset until the ESP has completed it’s own housekeeping and is ready to bring up the network connection.  So, with that addition, the pin connects between an ESP8266 and the  W5500 are:-Pin interconnects between ESP8266 and W5500

The pin numbering for the NodeMCU boards is given on the left, with the standard ESP8266 GPIO numbers in the centre column.  In addition to the data pins shown above, you need to connect ground and either +5v -or- +3v3.  The W5500 board has its own, on-board voltage regulator, so a +5v supply is okay, but sharing a 3v3 supply with the ESP8266 is a more likely scenario in our case (the data pins on the W5500 are 5v tolerant, by the way).

On the software side, I ended up using the Wiznet Ethernet Library for the Arduino 1.5.x IDE.  It hasn’t been updated in a while …but the last updates were to add the ESP8266 hooks into the code.  There are good instructions in the README.md file on how to install and use it, but –don’t– uncomment the “#define WIZ550io_WITH_MACADDRESS” line referred to in those instructions.  The normal, cheap W5500 boards do -not- have a built-in MAC address and you must set one manually in software before you can use them.

All in all, it really was quite easy to get the W5500 ethernet board not just connected to my LAN, but also talking to my MQTT broker to both publish and subscribe. Sometime in the next couple of days I’ll try to get around to sanitizing my code to the point where I can throw it up on GitHub as a simple example, but even before then, I’d say this is a safe enough purchase[¹] for anyone who wants to muck around with a wired connection to their ESP8266; you’re not going to break the bank if it doesn’t work as expected.

 


[¹] – Careful though!  If you’re reading this in mid February, it’s Chinese new year, so everything will be closed down for the next week or so …even longer delays.  😦

[‡] – Link provided as a convenience.  This is where I bought mine.  I have no relationship with this seller, other than being a satisfied customer.

Advertisements

Using oddball ESP boards with TASMOTA – Part II (Console)

I’m not going to go too deeply into the specific hardware I used for my own project, but instead just give a couple of tips on using the Yellow board as a base for your own creations.  First of all there’s that row of red LEDs.  While they make for a neat “running light” display, there aren’t that many projects (ESP-based VU meter, anyone?) where they’d be truly useful.  In addition to sucking the life out of your battery, they can also interfere with some peripheral connections by providing a pull-up path on the GPIO pins (the single RGB LED is a common-cathode device, by the way, so those GPIOs are pulled down).  Sometimes the red LEDs are beneficial; for instance, I2C requires pull-ups and the LEDs also handily show activity on the bus, which can be an aid to troubleshooting.  However, in general, we don’t want them there, especially on a battery-powered projects.  I usually disable the red LEDs by removing the 470Ω current limiting resistors with a hot iron (why the resistors? …because I don’t have to try and figure out the correct polarity when replacing them, if I want to re-enable any of the LEDs).

If you’re mounting the Yellow board in an enclosure of some sort, you may want to desolder the RGB LED and mount in the lid,so it can be seen externally.  Be warned, because of the four leads (with the one which is the common cathode soldered to ground), this is a bit of a beast to remove, but it can be done with a big enough iron and some patience.  If you are mounting the LED to the lid, it makes sense to add a momentary switch across the boot/program select jumper (GPIO0) and mount it in the lid, too.  That will give you access to all of the Sonoff switch functionality built into TASMOTA.

Whichever way you’re powering the Yellow board, from batteries or a mains adapter of some sort, it never hurts to add a nice chunky electrolytic capacitor on the 3v3 supply line (I generally use a 470µF).  The existing SMD capacitor close to the edge of the board by the boot/program select jumper has the pads oriented just right to allow the leads of the electrolytic to be soldered on, with the body of the capacitor hanging over the edge of the PCB.  A 5v supply from something like a phone charger works well with the Holtek regulator on the Yellow board (which has rather a low maximum input voltage rating, compared with some of the more commonly available 3v3 regulators).

Using the configuration information from the previous article as a guide, you can now connect up the Yellow board GPIOs to the devices you need for your project.  The important ones for TASMOTA compatibility are:-

  • GPIO0   – Button1
  • GPIO12 – Relay1
  • GPIO13 – LED1 (the Sonoff basic uses “LED1i”)

In my particular application, GPIO13 (LED1) is connected to the green anode of the RGB LED and I also have three additional connections:-

  • GPIO5   – DS18x20 (two DS18B20 temperature sensors)
  • GPIO14 – PWM1 (the blue anode of the RGB LED)
  • GPIO15 – PWM2 (the red anode of the RGB LED)

With the current version of TASMOTA (5.11.1), the one-wire bus for DS18x20 sensors is limited to a single GPIO.  You can have multiple sensors on that GPIO, but you can’t have (for instance) one DS18B20 on GPIO4 and another on GPIO5; only one of them will show up.  If you want to have more than one sensor on your one-wire bus, you should use Theo’s specially crafted sonoff-ds18x20 binary (or define USE_DS18x20 in the user_config.h file when building your own).

The “PWM” designations for GPIO14 and GPIO15 allow us to control the brightness of the LEDs attached to those pins.  We could just as easily have assigned them as “LED2” and “LED3” to use simple on/off switching, instead.

Now, to test the operation of our newly updated ESP8266, we have basically three options:-

  • The serial port on the ESP itself.
  • The web server provided by TASMOTA
  • MQTT

DO NOT use the serial port method with a mains-powered project unless you remove external power and use the serial adapter to provide DC to the ESP.  I’d recommend that you program the ESP with the serial adapter before fitting it to any mains-powered project and from that point onwards limit yourself to OTA upgrades and using the Web and MQTT methods for configuration and testing.  Note that using a serial adapter generally doesn’t supply enough current to reliably drive multiple LEDs and a relay, so I wouldn’t recommend this method, anyway.

For either of the remaining methods, the essential reference guide is the “Commands” page of the Sonoff-TASMOTA wiki.  You should keep that guide open in your browser while you experiment.

The “console” option of the web interface provides a very versatile method of monitoring output, as well as enabling input and, together with the previously discussed configuration menus, is pretty much all you need to get your ESP project up and running.  You can input commands by selecting “Console” from the main TASMOTA menu and typing them into the input box displayed at the bottom of the screen.  The results will be displayed in the main console window.

Console command window detail

In the above example (click image for full-size version), you can see that the console was displaying occasional status messages until (at 23:56) I entered the commands:-

  • ledpower
  • ledpower on
  • ledpower off
  • ledpower

…to check the current status of the green LED (LED1), then turn the green LED on, turn it off again and finally check the status to verify that it was off (note that the final “ledpower” command was entirely spurious, as the device had already echoed an “MQT” status message in the main console window to indicate that the LED was “OFF”).

The commands to control the relay are similar.  We simply replace the “ledpower” with just “power”.  Typing in “power” on its own will return the current status, while “power on” and “power off” do exactly what you’d expect and also return a confirmation message, just as the “ledpower” command did.

Controlling the PWM drive to the red and blue LEDs is only very slightly more complicated.   Entering “pwm” gives us the status (of both PWM1 and PWM2), while entering “pwm1” or “pwm2” followed by a numeric value between 0 and 1023 will produce an output brightness in proportion to the value entered (and, as before, the console will show a message confirming that the action has been completed).

00:24:15 CMD: pwm
00:24:15 MQT: stat/Plug1/RESULT = {"PWM":{"PWM1":0,"PWM2":0}}
00:24:21 CMD: pwm1 350
00:24:21 MQT: stat/Plug1/RESULT = {"PWM":{"PWM1":350,"PWM2":0}}
00:24:35 CMD: pwm2 799
00:24:35 MQT: stat/Plug1/RESULT = {"PWM":{"PWM1":350,"PWM2":799}}
00:24:38 CMD: pwm
00:24:38 MQT: stat/Plug1/RESULT = {"PWM":{"PWM1":350,"PWM2":799}

Reading the one-wire sensors is even easier still.  As long as there are no hardware or Main menu, showing temperature readouts.configuration issues, the temperature(s) will always be displayed at the very top of the TASMOTA main menu.

Using the console command line is slightly more obtuse, though.  The temperature readouts are a part of the TASMOTA status group, so you could type in the command “status 0” to get a full display of all possible status items.  However, if you do that, you will see an extremely verbose listing of 10 separate lines of status, with the temperature data being displayed as status line “STATUS10…StatusSNS…”.  Luckily that line hints at the command we need to use to get just the temperatures and nothing else.  The magic incantation is “status 10” and typing that into the console input box will return just that single “StatusSNS” line with our sensor data, including the sensor’s unique serial number and an indication of whether it is reporting in Fahrenheit or Celsius, as well as the temperature value itself.

00:55:11 CMD: status 10
00:55:11 MQT: stat/Plug1/STATUS10 = {"StatusSNS":{"Time":"2018-02-01T00:55:11","DS18B20-1":{"Id":"011590E534FF","Temperature":2.87},"DS18B20-2":{"Id":"031590A618FF","Temperature":1.87},"TempUnit":"C"}}

There are a number of “setoption” commands in the TASMOTA toolbox and, for those who might need it, the command “setoption8” will change the temperature display units.

setoption8 0 – sets the units to Celsius

setoption8 1 – sets the units to Fahrenheit

That’s it for the console commands for now.  Next time we’ll look at doing the same thing again, but utilizing MQTT from a remote machine, instead.

 

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.

 

 

 

 

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.

ESPurna updated to 1.9.4.

Tinkerman (Xose Pérez) has just updated his ESPurna package (an alternative to Theo’s TASMOTA) to version 1.9.4.  The change log shows additions for the Huacanxing H802 LED controller and the V9261F and ECH1560 energy metering ICs as well as fixes to ensure that all ESP8285 based devices are forced to use esp01_1m  (limited memory) and updates to MQTT handling.

If you’re using any version less than 1.9.0, it’s probably worth upgrading anyway, as that was the last major update, where Xose added support for a whole bunch of newer Sonoff products (including the RF Bridge, T1 light switch and 4CH Pro).

If you haven’t visited Xose’s site yet, it’s definitely worth checking out his recent RF Bridge article, as well as his tutorial on how to secure your IOT communications with an nginx reverse proxy and Let’s Encrypt certificates, both of which are very good reads.