Recent Updates (20th Oct 2018)

esp-go  –  Pete Scargill’s re-badged “Hackitt & Bodgitt” code for a universal i2c Nano peripheral extender for the ESP8266.

Pete has mainly been updating the documentation for his code over the past couple of weeks.  In the latest release, the name has changed to “esp-go.doc” to reflect the re-branding.

 

badgy  –  SQFMI’s “Swiss Army” e-Ink badge,based on the ESP-12F.

SQFMI has updated the code to work with the latest version (3.0) of the GxEPD library.

 

mobile-rr  –  idolpx’s ESP8266 Mobile Rick-Roll Captive Portal.

idolpx has added some images to the documentation to help novice ESP8266 users get a better grasp of what they’re doing, as well as updating the code to add DNS overrides and improve the WiFi scan filtering.

 

Sonoff-Tasmota  –  Theo Arends’ all-purpose replacement for Sonoff firmware.

Theo has been steadily updating and improving the 6.2.1 version of his firmware with (in no particular order):-

  • A change to a non-blocking MQTT library as the default.
  • Add support for the DS3231 RTC.
  • Add TasmotaModbus library.
  • Add support for the HX711 load cell.
  • Add support for Pzem energy monitors.

…as well as various fixes.

 

IRremoteESP8266  –  A library to enable IR send and receive on the ESP8266.

Mark has updated the package to support Disney’s “Made With Magic” protocol.

 

 

 

Advertisements

Recent Updates

JLed – a library to provide painless control of LED blinking, breathing and fading effects.

Jan Delgado has updated his JLed library a couple of times over the past week.  The first update was a change specific to the ESP8266 to improve the 8-bit to 10-bit scaling, so that LEDs now reach full brightness.  The second change is the addition of a boolean return value to the Update() function to indicate whether the target effect is still active, or has completed.

OpenMQTTGateway – Bidirectional gateway for the integration of 433MHz, BLE and IR devices with MQTT.

Florian has made a small change to his OpenMQTTGateway to make the “TRACE” function compile-time selectable, in order to reduce the overall code size for those who don’t use it.

IRremoteESP8266 – A library to enable IR send and receive on the ESP8266.

Mark and his various contributors (including “crankyoldgit”) have added initial support for Elektra, Samsung and Whirlpool air-conditioners and experimental support for  Coolix and Lutron.  There are also additional fixes for Mitsubishi A/C and the IRMQTTServer code.

Esparto – A rapid development framework for ESP8266

Phil Bowles has added MQTT username & password functionality to his (relatively new) rev-2 version of Esparto, as well as fixing a couple of minor bugs.

 

esp8266-weather-station-color – An ESP8266 and ILI9341/XPT2046 based weather display.

Daniel and Marcel continue to update the colour weather-station display, with fixes for some I18N and WiFi issues.

A non-trivial ESP8266 project

If the name Aidan Ruff rings bells with you, it’s probably because of the frequent mentions he receives on Pete Scargill’s blog and for his designs of their “Hackitt & Bodgitt” series of ESP-based hardware (Aidan’s board designs, such as "Hackitt & Bodgitt" Nextion Display Boardthis ESP12 board aimed at supporting a Nextion display, are especially useful for general purpose ESP8266 development and he makes the files freely available on-line).

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.

The initial prototyping and testing of the two-axis, linear actuator based tracker is already completed and Aidan has put up his board and mechanical design files and a couple of videos on a Hackaday I/O project page.  Unfortunately, at the time of writing, the ESP code doesn’t seem to be available either on that page or from Aidan’s GitHub repository, but despite that, it’s definitely a project worth watching (tracking?).

Battery not lasting as long as it used to?

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.


Ref: esp8266/Arduino issue #3408

TASMOTA Update

Over the past weekend, Theo pushed out another fairly big update to TASMOTA with some interesting new additions.

  • Language file support for:-
    • Portuguese
    • Czech
    • Bulgarian
    • Russian
    • Hungarian
    • Greek
  • Addition of  “rules”, to enable local, logical control of devices based on various inputs (so, for instance, a self-contained thermostat application can now be implemented internally on the Sonoff module, without requiring support via MQTT or other external methods).
  • Addition of KNX UDP protocol support to enable integration of Sonoffs into building automation projects.
  • The re-addition of variable support for MQTT client/topic values, using the ESP chip-ID.
  • Addition of a new, optional OTA upgrade method to allow for a PlatformIO-type “push” of large binaries (up to ~700kB) without requiring the use of a local web server.
  • Addition of support for hardware and software serial bridging (text only).
  • Addition of support for the Zengge ZJ-WF017-A PWM LED strip controller (ESP12S based).
  • Addition of support for the SGP30 air quality sensor.
  • Addition of sunrise/sunset option for scheduling (by geographical location).

As well as all of these new additions, there are a whole host of fixes and updates to existing features.  Definitely worth checking this one out!

 

Rust on the ESP8266

Here’s something which seems as though it might be of interest to a few people …Rust on the ESP8266. Rust logo “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).

 

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.