Aidan is in the process of having an old farmhouse (in an olive grove in Spain) rebuilt and, because there are no mains services (electricity or water) available, has embarked on what, to most of us, would be the non-trivial project of providing enough solar (and possibly wind) power and enough battery capacity to provide summer cooling and winter heating without having to resort to the use of a generator during prolonged, adverse weather conditions. His outline plan on how he intends achieve this (along with some impressive floor-plans) are available on his “Off Grid in Spain” blog.

Of more specific interest to ESP aficionados though, is the solar-tracking sub-project he’s put together to ensure that the (MPPT) output from his panels is maximized by adjusting elevation and direction. The tracker controller is an ESP8266-ESP12 of course, but with a novel twist. Instead of using the tried-and-tested optical tracking method (with its inherent problem of “hunting” on overcast days), Aidan has hooked up a GPS receiver to the ESP and uses a combination of the precise time and positional data to compute where the sun should be in the sky at his particular location (whether it’s hidden by clouds, or not). The ESP communicates via MQTT (but also has an embedded web server and an attached OLED display panel), which means that, with additional data from a connected weather station, Aidan can add features such as having the solar panels rotate down to lie flat when the wind speed exceeds a pre-set limit.

Back in July of last year, Jeff King (@wb8wka) noticed that there was a problem with ESP.deepSleep() calls using the ESP8266 Arduino Core. Versions greater than 2.0.0 appear to ignore the WAKE_NO_RFCAL flag and the WiFi calibration routine is run every time the ESP wakes, adding around another 200ms to the total start-up time, as well as a corresponding current spike.

Jeff notes that using the Espressif “system_” calls, rather than the Arduino wrapped calls, results in the expected behaviour (that is, no calibration being run), so the problem does seem to be with the Arduino Core and, as of 2.4.0, it is still an issue. Ivan (@igrr) has acknowledged the problem, but so far there is no fix.

So, if you’re using ESP.deepSleep() and your batteries don’t seem to be lasting as long as they used to, you might want to go back to Arduino Core 2.0.0 for building your battery-powered projects.

Here’s something which seems as though it might be of interest to a few people …Rust on the ESP8266. “emosenkis” (Eitan Mosenkis) has put together a script to install the toolchain on a Linux machine, enabling the user to use PlatformIO and the Arduino environment to build Rust projects. I haven’t tried this myself, yet (I don’t know the first thing about Rust), but it is something I’ve seen mentioned on other people’s “wish lists” now and then.

So, Rust enthusiasts, give it a try and report back and let us know how you get on (and why we should all convert …or not).

Continuing with our series of articles on utilizing Theo Arends’ TASMOTA firmware on non-Sonoff boards and devices, in this article we’ll look at using MQTT to interact with the target.

Feel free to skip over the next four paragraphs (between the horizontal delimiters) if you’re already familiar with the way in which MQTT works.

Just in case you’re not familiar with MQTT, I’d like to emphasize here that it is not an interactive mode of communicating with your device in the way that using a serial adapter, console or telnet/ssh connection is. In concept it is more like using radios for verbal communication; you have both a transmitter and a receiver, but they are two separate pieces of equipment. If you transmitted a message, you wouldn’t hear any reply if your receiver wasn’t turned on and tuned to the appropriate frequency. Likewise, without a transmitter (again, tuned to the correct frequency) you would simply be a passive listener to whatever was received. MQTT is similar; you need to know the “frequency” (the topic) which you want to communicate on and you need a transmitter (a publisher), as well as a receiver (a subscriber).

To complicate matters a little further, you are running your radio equipment in a deep valley, surrounded by mountains. In order to use your radio you need to use a repeater station, situated on a nearby summit. The operators of the repeater are very generous and will freely rebroadcast anything they receive on to you , just as long as you tell them which frequencies you want to receive. All of your radio traffic, both outgoing and incoming, needs to go via this repeater. In MQTT terms, the repeater is a “broker” which will listen for messages and rebroadcast them. You can receive and transmit messages at will, as long as you specify a topic.

The most common MQTT broker for home use is Mosquitto, which comes with a couple of command-line utilities, “mosquitto_sub”, a subscriber (or receiver) and “mosquitto_pub”, a publisher (or transmitter). You would run Mosquitto on one of the machines on your home LAN (say, perhaps a Raspberry-Pi or a dedicated NAS or back-up system which is running 24/7). The Mosquitto daemon provides a fully functional MQTT “broker”, but you can also install the mosquitto-clients package on your desktop or laptop to make the mosquitto_sub/pub utilities available, without the overhead of the full daemon.

Anyway, enough of the radio analogy. The important things to remember with MQTT are that:-

You won’t automatically get any response from a “pub” message sent to your ESP, unless you are also listening to the correct topic with a “sub”.

MQTT is a distributed protocol, in the sense that your subscribers will usually be on a different physical machine than the publishers and probably neither of them will be on the same machine as the broker.

On the ESP8266 side, there are a few libraries available which give moderately pain-free access to MQTT from your program. Currently I’ve been favouring Nick O’Leary’s PubSubClient library and, luckily, Theo includes it by default in TASMOTA, so you don’t need to do anything extra; MQTT capability is built-in.

However, before we jump into the commands themselves, I’d recommend that you bring up two separate windows on your display to allow you input “transmissions” in one window while simultaneously being able to see received messages in the other (if you’re using a full-screen terminal window on some modern version of Un*x, you can also use the “screen” utility to split your single window into top and bottom halves, using “CONTROL-A S”, followed by “CONTROL-A TAB” to swap between the new, top and bottom windows and then “CONTROL-A c” to create a new shell in the bottom window [¹]).

In your top window, start a “receiver” process to monitor the output on TASMOTA’s “stat” (status) topic. This is where you’ll see the messages which TASMOTA is sending back to the MQTT broker. Your command will look something like this:-

mosquitto_sub -h mybroker.mylan.com -t “stat/sonoff/#”

…where “mybroker.mylan.com” is the machine where the main mosquitto daemon is running (your “broker”) and “sonoff” is the “friendly name” you’ve given your module in TASMOTA. The “#” character at the end of the topic string (“stat/sonoff/#”) is the MQTT wildcard character and, in this case, tells the mosquitto_sub command that we want to see all messages that match the “stat/sonoff/” string, whether they be the result of command execution or specific subsystem (ie:- memory) informational messages.

If your broker process is running on a separate machine, the commands which you type in can get quite long, so I’d also recommend building up a couple of aliases for the mosquitto_sub and mosquitto_pub commands (I covered this in an earlier MQTT how-to article).

[ NOTE:- From this point onwards I will use the aliases “mqp” for mosquitto_pub and “mqs” for mosquitto_sub to try and limit the example commands to a single line. ]

As when using the console commands earlier, we’ll start with some simple commands to manipulate the green LED. Here’s where a simple rule will help out — IF YOU’RE SENDING A REQUEST OF ANY SORT, YOU NEED TO USE THE “cmnd/*” TOPIC. In this particular instance, it may seem intuitive to use the “stat/*” topic, because we want to see some status, but you need to remember that we’re not using an interactive terminal session; we’re using the transmit and receive functionality of MQTT, so we must send any request as a command. This takes a little bit of getting used to, but will become second nature very quickly. So in this case, the command you send to your module will look something like this:-

mqp -t cmnd/sonoff/LedPower -n

The “-n” tells mosquitto_pub that there is no message part to this particular command.

Once sent, you won’t see any other output in your “transmit” window (unless you’ve made a typo), but over in the window where you left the mosquitto_sub command running in background, you should see the response:-

{"LedPower":"OFF"}

…or possibly “ON”, of course.

Controlling the LED is more intuitive than just getting the status:-

mqp -t cmnd/sonoff/LedPower -m "on"

We’re using the same basic command, with exactly the same topic (“cmnd/sonoff/LedPower”), but a different message (the ‘-m “on”‘ part) and, as you’d expect, this turns on the LED on your remote module and, in addition, TASMOTA automatically sends a status update message, so your mosquitto_sub (receiver) window will display:-

{"LedPower":"ON"}

Then use:-

mqp -t cmnd/sonoff/LedPower -m "off"

…to turn it back off again (hopefully your ESP8266 module is somewhere within sight, so that you can visually check that these commands are indeed working).

The next step is to simply replace “LedPower” with just “Power” and verify that the relay on your ESP8266 is also responding to on/off commands. The output in the mosquitto_sub window will change to:-

{"POWER":"ON"} and {"POWER":"OFF"}

Our next command will return the status (the current pwm count between 0 and 1023) for each of our previously assigned PWM drive pins (the red and blue LED segments of the RGB LED on the Yellow Dev board).

mqp -t cmnd/sonoff/pwm -n

Note that we’re again using the “-n” to tell mosquitto_pub that there’s no message part to this topic. The output on the mosquitto_sub screen will probably look something like this:-

{"PWM":{"PWM1":0,"PWM2":0}}

The output is just a little more complex, as there are now two separate GPIOs in the overall PWM status report. I’m sure that by now you don’t need me to tell you that using those PWM1 and PWM2 ids, you can now control your red and blue LEDs in the same way as we did from the console, but using the message part of the MQTT command to vary the PWM drive output:-

mqp -t cmnd/sonoff/pwm1 -m "750"

…returns:- {"PWM":{"PWM1":750,"PWM2":0}}

mqp -t cmnd/sonoff/pwm2 -m "350"

…returns:- {"PWM":{"PWM1":750,"PWM2":350}}

Note that the response status from the command still includes all of the defined PWM pins, even though our command lines only change one GPIO pin at a time.

Following along from the examples we went through previously in the “Console” tutorial, we’ll now request TASMOTA to send us the status (including the data) from our on-board temperature sensors. If you remember, we needed to send the command “status 10” from the console, which translates into another command string for mosquitto_pub.

mqp -t cmnd/sonoff/status -m "10"

…and the response this time (in the mosquitto_sub window) is much longer (this would all be on one line on your screen):-

Anyone who has played around with IOT data in the past few years will recognize this (and the previous examples) as JSON formatted data. Here we can see that the overall encapsulation is “StatusSNS” and within that we have several different types of data returned. The first is a timestamp which needs no explanation, but the following two blobs of data:-

"DS18B20-1":{"Id":"011590E534FF","Temperature":1.50},

and

"DS18B20-2":{"Id":"031590A618FF","Temperature":35.25},

…are more interesting. The strings “DS18B20-1” and “DS18B20-2” are arbitrary identifiers used by TASMOTA to identify individual one-wire temperature sensors. The “Id” numbers are the actual serial numbers of the DS18B20s themselves (each sensor has a unique serial number burned into its ROM when manufactured). “Temperature” is again obvious, but just in case of ambiguity, the last part of the StatusSNS data (above) is a specifier for the temperature unit being used (in this case, Celsius).

We can change the temperture reporting units to Fahrenheit using the “SetOption8 1” command:-

mqp -t cmnd/sonoff/setoption8 -m "1"

…and the next time we get a temperature status report, the figures are quite different:-

Okay, we’ve covered the same commands as we did in the “Console” article and reached the point where TASMOTA and MQTT are delivering a bunch of useful data back to us from our project board. In the next part I’ll look at creating a shell script to automatically generate and handle that (JSON) data, so that you can actually control the relay based on temperatures.

[¹] – Commands for manipulating virtual windows from within “screen” all start with a CONTROL-A character, so to create a new virtual window you would input the sequence “CONTROL-A c”, to change the current view to the next window would be “CONTROL-A n” and to change back to the previous window would be “CONTROL-A p”, and so on. Use man screen for more details.

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. So 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. Because 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:-

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

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.

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.

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

Reading the one-wire sensors is even easier still. As long as there are no hardware or 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.