Using oddball ESP boards with TASMOTA – Part III (MQTT)

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.

So, lets get started with MQTT.  As suggested in the previous article, I’d recommend opening up the wiki page describing TASMOTA commands and using it as a handy reference while you’re playing with this.

Example of "screen" with top and bottom window splitHowever, 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):-

{"StatusSNS":{"Time":"2018-02-14T09:46:58","DS18B20-1":{"Id":"011590E534FF","Temperature":1.50},"DS18B20-2":{"Id":"031590A618FF","Temperature":35.25},"TempUnit":"C"}}

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:-

{"SetOption8":"ON"}

{"StatusSNS":{"Time":"2018-02-14T09:47:38","DS18B20-1":{"Id":"011590E534FF","Temperature":35.04},"DS18B20-2":{"Id":"031590A618FF","Temperature":83.97},"TempUnit":"F"}}

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.

Advertisements

e-Ink/e-Paper Displays

As you may have read in a recent post, I’ve become enamoured of the newer versions of the e-Ink or e-Paper displays to hit the hobby market.  They look great and (apparently) aren’t too difficult to drive, plus their inherent ability to maintain the display when “off” looks to be a major plus for any battery-powered projects.  Waveshare 1.54" Display (courtesy of Waveshare)Unfortunately, there isn’t a whole lot of good, solid information out there yet on using these screens.  That is changing though, as the prices start to drop enough so that people can afford to buy one or two to play with, even if they’re not entirely sure that they’ll work in a given project.  One of those brave early adopters is David Watts and he’s put together a very informative video on how to interface a Waveshare 1.54″ display to an ESP8266, along with details on connections, graphics libraries to use and even a design for a 3D printed desktop stand for the completed project.  It’s well worth a look.

On the subject of the screens themselves, it’s also worth noting that versions with an attached driver/interface card (which is much easier to use) are popping up on all of Waveshare SPI I/F (courtesy of Waveshare)the usual on-line bazaars, so it’s worth taking a few minutes to check whether you’re about to buy a bare screen (with a tiny, 24-pin, flex cable connector) or the former, driver/interface card equipped version.  Confusingly, both are advertised as being “SPI” interfaces and only a check of the photos of the unit for sale will confirm whether you have a usable 8-pin socket, or just a flapping flex-cable.   One of the cheaper options is one of the Raspberry Pi “HAT” displays,  They all seem to come with a standard RPi header connector, as well as the 8-pin connector (or at least the solder pads for it) and, presumably because they’re quite popular, seem to be quite cheap, too.

 

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.

 

Save power by (reliably) switching the ESP WiFi on and off

-Update Oct 2017-  Doug Elliot very kindly submitted a comment (see below) to let me know that the redoubtable Erik Bakke has done a much better job at both troubleshooting and writing up this issue in a series of articles on his blog.  Rather than wasting your time with my half-hearted fumbling around, I’ll point you directly to the first article in Erik’s series.  Stay with it and read the whole bunch right through to the end; he keeps on coming up with new tweaks as he goes along.  There are a couple of extra articles (one on eliminating network scan at start-up and another on solar power for the ESP8266) which are part of the series, so don’t miss them, either.


I have an ongoing project to add an ESP8266 to a solar trickle charger for a lead-acid battery.  Really, the only set-in-concrete requirement is that the controller must switch off the feed from the solar panel before the battery voltage gets to dangerous (“gassing”) levels, but it would be nice to have remote data logging of voltages (battery and solar) and temperature, as well as some control over the load (a small impeller pump in an external sump well, used for orchard irrigation during the summer and autumn).

Because the target battery is a standard (wet plate) car battery, I have quite a bit of capacity to play with, but even so, my back-of-the-envelope calculations show that the ESP8266 is quite capable of completely discharging the battery in under a week (assuming no sunshine and an ESP8266 module with WiFi enabled and transmitting on a more or less continuous basis), so I’d been looking for a reliable way to save power, but still have the ESP8266 do real time monitoring of the battery and solar voltages and interrupt the charge process when the battery was already fully charged (I should probably note that we get a lot of sunshine here during the summer and autumn months and our usage of the pump is only very intermittent, so despite having a mere 300mA output from the solar panel, it is possible to overcharge the battery over time).

I didn’t want to use deep-sleep mode (although it’s the least power hungry), because I want the ESP to be the actual charge controller and it can’t do that if it’s off in la-la land for the best part of its day.  I still want to use the WiFi capability (otherwise there’d be little point in using the ESP over a PIC), but I don’t need to have 24/7 connectivity.  Turning the WiFi on and off has always been a bit of a hit and miss business for me, though (and with quite a few other people too, judging by the number of hits a web search on the subject generates).  So I was pleasantly surprised to find some answers in a GitHub “issue” raised against the ESP8266/Arduino project.  The thread contained some excellent answers and testing experiences from some of the well known members of the ESP8266 community (thanks guys!), so I felt fairly sure I was onto a winner, but there were one or two twists along the way.  So here is a brief rundown on how I’m doing it with those kinks ironed out and here is a program which will demonstrate the practicality and reliability of using the “Issue 644” method.

First, let me assure the nervous reader that, despite what follows, we are not putting the ESP to sleep at all, we do not need to use an interrupt or a reset to restart the WiFi and we also do not need to make any hardware changes to the ESP module for this method to work.

The crux of this method is to use WiFi.forceSleepBegin() to put the ESP into “modem sleep” mode.  It’s important to realize that this does not put the core into any form of sleep; it simply turns the modem (radio) off.  There are some other incantations in there to ensure that WiFi is shut down in  an orderly fashion:-


bool WiFi_Off() {
WiFi.disconnect();
WiFi.mode(WIFI_OFF);
WiFi.forceSleepBegin();

One of the issues at this point though, is that the WiFi can take a finite, but variable time to shut down after the final forceSleepBegin() call, so at this point I’ve just added a timeout loop, checking the status of the connection until it goes down (returning without an error) or times out (returning with an error):-


while ((WiFi.status() == WL_CONNECTED)
&& (conn_tries++ < WIFI_RETRIES)) {
delay(100);
#ifdef DEBUG
Serial.print(".");
#endif
}
if (WiFi.status() != WL_CONNECTED)
return (true);
else
return (false);

The default timeout of 3 seconds is more than enough for the WiFi_Off() function.

The WiFi_On() function is pretty much a reversal of the “off” code:-


bool WiFi_On() {
conn_tries = 0;

WiFi.forceSleepWake();
WiFi.mode(WIFI_STA);
wifi_station_connect();
WiFi.begin(STA_SSID, STA_PASS, WIFI_CHANNEL, NULL);

while ((WiFi.status() != WL_CONNECTED)
&& (conn_tries++ < WIFI_RETRIES)) {
delay(100);
#ifdef DEBUG
Serial.print(“.”);
#endif
}
if (WiFi.status() == WL_CONNECTED)
return (true);
else
return (false);
}

The call to “wifi_station_connect()” seems to be the equivalent of a sacrificial chicken for most people, though. Without it, the restart of the WiFi doesn’t always work; with it, everything is hunky-dory (whatever that means).

Unfortunately, actually getting the call to wifi_station_connect() to compile turned out to be a bit problematic for me (from within the PlatformIO build environment). Just where the heck is it? Well, some searching found a define for it in the user_interface.h file in Espressif’s SDK. Adding a simple:-

#include "user_interface.h"

…in the header of my ESP_Power_Save.ino file got me past the initial “not found” messages, but then, at the last stage, the linker failed with “undefined reference” errors. Grrrr! The magic sauce for that though, is simply to let the C++ compiler know that it’s looking for a plain C function (buried deep in the nether regions of the Espressif SDK, in this case) by modifying that include to be:-

extern "C" {
#include "user_interface.h"
}

Finally, it compiled …and worked, too.

Before you flash ESP_Power_Save.ino to your ESP8266, you’ll need to configure the IP addresses, access-point SSID and password in the user_config.h file.

After flashing, connect to the ESP8266 console as normal and you’ll find yourself in a mini test environment where you can use a few simple, single character commands:-

  • “w” — to toggle the state of the WiFi between on and off.
  • “s” — to display the current state of the WiFi connection.
  • “c” — to display a simple count on the console, just to prove that the ESP core is still operational.

I’d recommend opening a second window and using it to ping the ESP’s IP address, to verify whether it is up or not as you toggle the WiFi.

Finally, a word of caution …If you try to connect to a non-existent access-point, or one which is out of range, or you use an incorrect password, then the WiFi will not turn off. That seems pretty counter-intuitive to me and I haven’t yet worked out why it happens. At any rate, it’s obviously worth doing some testing (I use a hand-held ESP8266 rig running on three AA batteries) to make sure that you have connectivity before deploying this power-save code to your remote units.


Update — The latest version of the code now includes a cut-down version of the “FSWebServer” example (from the ESP8266WebServer library) which will server up a 750kB JPEG file from SPIFFS on the ESP.  It takes a non-trivial amount of time for the little ESP to retrieve such a substantial file from SPIFFS, chunk it up and push it out across the network, which hopefully will give you adequate time to measure the current consumption of your module while busy transmitting, for comparison with when the WiFi is toggled to the “off” state.


Update #2 –  Real world testing has brought some interesting “features” to light.  Most problematical is that the WiFi doesn’t seem to always switch off completely, which is peculiar.

First, you need to know that the ESP8266 returns its current status when interrogated with the WiFi.printDiag() request.  When running normally, the results look something like this:-


Mode: STA
PHY mode: N
Channel: 11
AP id: 0
Status: 5
Auto connect: 1
SSID (9): Mainwaring
Passphrase (10): D0ntPan1c!
BSSID set: 0

The two most important indicators are the Mode and Status lines (although the SSID and Passphrase entries will also change when the WiFi is disabled).

The current draw on  my test module is generally in the area of 75ma when WiFi is enabled, with very brief peaks when actually transmitting (so brief that they’re impossible to measure with an ordinary digital multimeter).  That value drops off to 20ma when the WiFi is disabled and at the same time, WiFi.printDiag() changes to show “Mode: NULL” and “Status: 255” (and the module stops servicing web requests or even  a simple “ping”).

Frequently, toggling the WiFi (with the “w” command) will give the same result in terms of connectivity (ie:- the unit stops responding to web requests or pings) and the result of a WiFi.printDiag() is still “Mode: NULL” and “Status: 255”, but the current draw remains in the 75ma region.  I suspected that the auto-connect or auto-reconnect settings may have been responsible, but after further testing that doesn’t seem to be the case.

So, after using the word “reliably” in the title of this post (which, admittedly, referred specifically to being able to turn WiFi back on after a modem sleep), I now find that the current reduction isn’t reliable at all.  Does anyone have any ideas?

ESP8266 Overclocking & Speedometer

A few days ago I posted the code for a(n almost unusable) version of Zork (or actually, the Zmachine) for the ESP8266.  It was (and is) really, really slow.  The main problem appears to be that it constantly re-writes the Zmachine stack back to SPIFFS which, in addition to causing the running-through-chest-deep-molasses effect, will also wear-out your flash in double-quick time.  The fix for this (obviously) is to shoehorn the whole thing into main memory (which is a work-in-progress), but while trying to squeeze enough performance out of the ESP8266 to make this early cut at least somewhat playable, I thought I’d take the easy option first and run the ESP at 160MHz instead of the default 80MHz.  I should warn you right now that as far as making Zork playable went, it was a total failure, but I was pleasantly surprised at just how easy the speed selection is when using PlatformIO.  I didn’t even have to sacrifice a chicken.

Here’s the simple incantation, which you just need to add to the bottom of your platformio.ini file in the project directory (the comment line is optional):-

; Set the ESP8266 clock frequency to 160MHz
board_f_cpu = 160000000L

…and then just recompile (and, because you’ve just made a change to the platformio.ini file, PlatformIO itself is smart enough to know that it needs to do a complete rebuild, not a partial).

That’s it …you’re done!


 

NOTE – You can also use the system call “system_update_cpu_freq()” to dynamically update the ESP8266 clock frequency from within the program itself, instead of using the platformio.ini “board_f_cpu” setting.  Using the system call will override the compile-time setting.

CODE – Ray Burnette’s adaptation of the Dhrystone test program is available from my repository in both static and dynamic versions.  The static version simply loops endlessly, reporting the performance of the current module (so effectively the compile-time clock setting from the platformio.ini file).  The dynamic version toggles the clock speed using the system_update_cpu_freq() system call on each iteration and displays the performance for whichever the current setting is.

 

 

Getting started with PlatformIO and the ESP32

Here’s the shortest “Getting Started” you’ve ever seen (disclaimer†  …I’m making the huge assumption that you already use PlatformIO as your development environment for your ESP8266 projects.  If you don’t, you should!).

Add support for the ESP32 with:-

platformio platform install espressif32

Create your new development (project) directory and, in that new directory, initialize the environment for the type of board you have‡  with:-

platformio init --board=esp32dev

Start writing code, as normal, in the newly created src directory and then compile with:-

platformio run

At this point, PlatformIO will go off and automatically download the framework support for your environment (this first time, only) and then compile your code.

You just can’t get any easier than that!


† I don’t actually have an ESP32 board yet.

‡ List the available target boards with “platformio boards

Ψ If you’re tired of typing “platformio” in full each time, you can shorten it to “pio” (“platformio” is used for clarity here).

ω For more information on getting started with PlatformIO, see the full documentation at:- http://docs.platformio.org/

433MHz/IR MQTT Gateway Project

It’s nice to see a project that develops over time and Florian has a good example on his blog.  He started off in the middle of last year by putting together a low-cost, arduino-based sensor for his garden and things seem to have just grown from there :-).  You can follow along on his blog from the initial version of his bidirectional 433MHz, ESP8266-based, MQTT gateway, progressing to the IR enabled version by the end of the year and his OpenMQTTGateway project this year.  It’s a good read and a great little project to follow.