Killer (ESP8266) Apps for the Weekend

Sometimes, while browsing GitHub for ESP8266-related projects, I come across a user’s page which just happens to “push all the right (ESP8266) buttons” for me.  One which I came across recently was from martin-ger and he has several projects which tickle my fancy.

Those three should keep you amused over the weekend and give you a sample of what Martin is capable of.  Definitely a page worth bookmarking!

 

 

Cat successfully skinned!

Regular visitors may remember a mention I made of an ESP8266/433Mhz gateway project a couple of weeks back.  Well, one of the reasons I found it so interesting was that I have a (fairly long-in-the-tooth) Oregon Scientific weather station installation which has always frustrated me with its lack of connectivity.  It does have a 9-pin, D-type serial connector on the bottom, but that assumes that you have an RS232 equipped machine within cable reach of the display unit (and that HID‡ would not object to yet another trailing cable).

I had toyed with the idea of plugging an ESP8266 into that port, with the excellent serial adapter  firmware from JeeLabs, but it doesn’t really address the HID/cable/ugliness issue.

Both of these methods also suffer from a fatal design flaw with this particular model of weather station, in that data isn’t squirted out of the serial port unless all of the sensors which this model was sold with are operational (otherwise you just get an error message along the lines of “Rain sensor not detected” and nothing else).  So I concluded that, by collecting the (433Mhz) transmitted data from the actual sensors (which are remote from the display unit), I could just use the data directly and ignore the base-station/display part of my weather station completely.  Hence my interest in the 433Mhz gateway project.

The final piece of the puzzle to drop into place for one of those light-bulb moments came when I was reading through the comments to one of Pete Scargill’s recent articles on the 433Mz RFLink project.  Commenter Paul gave a link to a GitHub repository called “rtl_433”, which is a 433Mhz decoder for SDR dongles by Benjamin Larsson.  Benjamin’s project is specifically for picking up the data from remote sensors (from many, many manufacturers) which operate in that open, 433Mhz band.

I’d recently bought an SDR dongle from a vendor on Ebay which was advertised as having an R820T tuner chip, suitable for ADS-B monitoring.  It turned out to be a bogus ad, with the actual tuner chip being a 0012, which doesn’t even cover the 1090Mhz ADS-B band.  I threw the useless dongle into the drawer and ordered a decent one directly from the manufacturer (which, incidentally, has worked perfectly from the first moment it was plugged in – Nooelec.com is the place to go), writing off the $10 Ebay one to experience.

Having seen Paul’s post, retrieved and compiled Benjamin’s “rtl_433” package and pulled out the “useless” dongle from the murky depths of the spares drawer, I had direct data from all of the Oregon Scientific sensors published to MQTT in less than five minutes after plugging it in.  One cat neatly skinned in a completely different way to that which I’d originally envisaged.

Just for your reference, here’s the simple pipe to publish your data:-

./rtl_433 -F json   |  mosquitto_pub -l -h hazeltonrig.throgmortons-bottom.org -t sensors/rtl_433

The “-F json” argument to rtl_433 is to force the data to be output in JSON format.  It will also accept “csv” (comma separated values) and “kv” (key:value pair) format arguments.

And here are a few lines of sample data from the various sensors:-

{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "THGR968", "id" : 204, "channel" : 1, "battery" : "OK", "temperature_C" : 8.300, "humidity" : 49}
{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:25", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:26", "brand" : "OS", "model" : "WGR968", "id" : 183, "channel" : 0, "battery" : "OK", "gust" : 1.400, "average" : 1.400, "direction" : 902.000}

Note that the “direction” readings are meant to be in degrees, so 902.000 (last line) doesn’t make much sense. Looking at the code and at the actual weather station display, it seems like there’s a nibble ordering issue with the decoding of the raw data and that should actually read “290”, instead (the fix is tested here and is now working its way backup the line).


‡  “Her InDoors”

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.

 

 

Simple demo for the “Yellow” board

As promised in the previous post, we’re going to explore a simple application for the Yellow Development Board this time round.  The one thing that this board has plenty of is LEDs.Yellow Serial Development Board  There are half-a-dozen red LEDs and one blue across the bottom of the board, as well as a 5mm RGB LED.  So, not surprisingly, we’re going for the “Blinkenlights” option as the first demo.  You won’t need an MQTT server or even a working access-point to have this demo work, but the display does get a bit boring quite quickly.

If you have modified your board with the addition of the latching power switch described in the hardware article, this demo will turn itself off after three minutes of run time.  If you haven’t added the switch, you’ll have to remove power by pulling one of the batteries out, otherwise it will just keep on running until the batteries are completely depleted.

The code for this first demo is available (with the other demos) in the GitHub repository.  The filename is Initial_Power+LEDs.ino.  My preferred environment for compiling ESP8266 programs nowadays is PlatformIO (if you haven’t tried it yet, you should give it a go); it makes compiling programs for multiple different architectures a breeze and you don’t have to worry about shoehorning things in, it just does the right thing.  Anyway, the demo programs are basically Arduino-IDE format for the ESP8266, so whether your preferred  environment is PlatformIO or Arduino-IDE, they should just work for you (if you’re still in the dark ages, using Espressif’s SDK, you’re on your own!).

In addition to the base demo itself, Over-The-Air update functionality is also built in to each program, so assuming that you have a working network and access point, you should only need to upload to your ESP8266 by serial the very first time, after that you can use the normal Arduino or PlatformIO OTA commands to upload a new demo file.

Note that all of the demos are set up to use a static IP address, netmask, gateway and DNS server.  This is to ensure that the ESP starts up as quickly as possible in a real “button” application.  The WiFi channel number is also specified, again as part of a fast, robust start-up procedure.

Before compiling any of the demos, you need to go through the user_config.h file and change all of the default settings in there to match your local network.  The specific settings you should be interested in are:-

  • LOCATION   [optional]  Setting this to your general region may help you to find your own results when using a public MQTT server for the later demos.
  • STA_SSID  [required]  Set this to the SSID (name) of your Access Point.
  • STA_PASS  [required]  Set this to the (WiFi network) password requested by your Access Point when connecting.
  • WIFI_IPADDR  [required]  Set this to be the IP address which you want this specific ESP module to use (it is assumed that you know your own network …DO NOT simply choose a random IP).
  • WIFI_NETMASK  [required]  This should be set to use your network specific addressing scheme.  Generally, if your IP addresses begin with “192.” you should be okay to leave this as “255.255.255.0”, but if you don’t know, please ask someone who does.
  • WIFI_GATEWY  [required]  This should be set to the IP address of your gateway router.
  • WIFI_DNSSRV  [required]  This should be set to the IP address of your local DNS server.
  • WIFI_CHANNEL [required]  This is the number of the WiFi channel which your access point is using (and can be between 1 and 14, depending upon where in the world you are).
  • MQTT_HOST  [required for later demos]  See later explanation for this option.

If you don’t know the answer to any of the “WIFI_*” settings, you need to find someone with a better knowledge of your local network and ask them;  DO NOT just guess.  You could effectively cripple the whole of your local network with a wrong answer to some of these questions.

If you have a good, robust working DHCP server and you don’t care about start-up speed, you might want to convert these programs to use DHCP instead.  As this is by far the most common option in ESP8266 programs generally available on the ‘net, I will leave this conversion as an exercise for the reader (it’s quite a bit shorter and simpler than the static address variation used here).

Although MQTT isn’t required for this first demo, I’m going to mention it here anyway, just so you know what some of the options in the user_config.h file are.  The default setting for MQTT_HOST in that file is “broker.hivemq.com”, which is a publicly accessible server in Germany which HiveMQ very kindly make available for testing.  HiveMQ also provide a whole bunch of MQTT related resources and services, so please do send any business you can in their direction.  Please DO NOT bug them with support requests for these demos; those requests should come to me.  Please also note that the HiveMQ server gets -very- busy (it’s not unusual to see in excess of 1,000 concurrently connected clients), so it can be quite difficult to see any output from your specific device on their web dashboard.  Please resist the temptation to increase your publishing rate; the server is already busy enough.

If, on the other hand, you have a local MQTT broker (server‡), then you should change the MQTT_HOST option in user_config.h to point to it specifically from the very start (if you don’t yet have an MQTT server set up, I would recommend the Mosquitto package; it comes with the broker and with two command-line utilities, mosquitto_pub and mosquitto_sub, which allow you to easily publish or subscribe to topics on either your local broker, or any other publicly accessible broker service on the ‘net.  Mosquitto is available as an optional package for most Linux variants through the software manager and there’s also a binary package available for Windows).

The MQTT_CLIENT_ID is a symbolic ID used by your ESP8266 when talking to the server.  It enables the MQTT broker to differentiate between the dozens of ESP8266 modules which you have connected to your network.  The string “ESP8266_%06X” is automatically replaced at run time with a six-digit number created from the unique ESP8266 chip-ID, to provide something like “ESP8266_09C721”.  This prevents potential clashes where two (or more) ESPs sharing the same ID would cause each other to be disconnected from the MQTT broker when a new request comes from a different address.  This means that if 500 of my closest friends all decide to build the MQTT demo and use the default, publicly addressable HiveMQ server, they should all work perfectly, without trampling over one another.

Finally, note that our ESP client can handle three different topics (only two are defined by default).  TOPIC1 is defined as “timestamp” and we become a subscriber to that topic (the HiveMQ broker currently publishes a timestamp every few seconds).  TOPIC2 is defined as “Yellow/LDR” and our MQTT demo program will publish regular updates to it.  The data published to that topic is the ADC value of the ESP8266 pin with the LDR attached (so the value depends upon the ambient light level).

All of the demo programs, including the non-MQTT version, will print out info to the serial port, including regular LDR value updates.

The mood-light display mode on the Yellow is based on code by “Mike Mc” (Mike McRoberts, author of “Beginning Arduino”).  The code uses a 256 entry look-up table to compensate for our weird vision and produce what looks like a linear fade to our eyes.  Kudos to Mike for writing such a durable routine, which works very well on the ESP, despite its proclivity for running off and doing WiFi-ish stuff at unpredictable intervals.

Speaking of the need to service WiFi requests and other housekeeping, the reader will notice that there are calls to yield() sprinkled liberally throughout the code and that there is also an added function, Ydelay(), which is simply a call to the normal delay function with an additional call to yield() thrown in.  It seems like you can’t call yield() often enough in any ESP code that could get itself caught in a tight loop.

 


‡ I use the terms “broker” and “server” interchangeably, but strictly speaking, the “broker” is the MQTT process running on what we loosely refer to as a (hardware) server.  Your client devices all connect to and exchange messages with this server.  You’re not confused, are you?!?!

Simple projects with the Yellow Dev board

A few months back I wrote an article on the “Yellow Development Board” from Ai-Thinker.  At the time it was, I admit, an attempt to add a little balance to the blog after my lambasting of their “Black Board T5”.  However, after a few months of using these little beasties, I suddenly realized that it had become my go-to board for new, ESP8266-based projects.   My experience with electronics dates back way beyond transistors, let alone integrated circuits or microcontrollers, so one of the tools I still have in my kit is a wire-wrap pen, which turned out to be quite handy with the “Yellow Development Board” (and that is way too much of a mouthful, so from here onwards I’ll refer to it simply as “Yellow”).

Wire-wrapping is just what it sounds like… it was a technique used extensively in the early days of computer manufacturing to provide interconnects between components.  Typically, individual chips would be plugged into ic-sockets with long, chunky pins with a square profile.  Wire-wrap wire is single core, so the “pen” enabled you to strip the insulation off the end of your wire and then wrap it tightly around the pin (the square profile ensuring that the electrical connection was good, as the corners bit into the wire).

I mention this not because of a sudden burst of nostalgia, but because the header pins on the Yellow board reminded me of wire-wrap as soon as I saw them and one of the really good things about wire wrap (and there were plenty of bad things, as anyone who had to troubleshoot a wire-wrapped system will tell you) is that it was, and still is, one of the fastest ways to prototype a new circuit.  You don’t have to wait for a soldering iron to heat up and you don’t lose half of your connections if you accidentally knock your breadboard onto the floor.  Yellow dev board with i2c RTC attachedSo wire-wrapping seemed like a natural step for quickly connecting up the Yellow board to some peripherals when building a project.  The header pins are not ideal (they’re a little too skinny and definitely not long enough), but they’re more than good enough for prototyping.  It was only a few minutes work to connect up a DS3231 i2c RTC board (+ve, gnd, clock and data) and only another couple of minutes to add yet another board (this time a custom i2c slave built from a PIC16F1825) for more fun and experimentation (I should add that the RTC was something which I already knew was working and was just a test connection to ensure that i2c still worked with the red LEDs on the Yellow board with i2c RTC and custom PIC boardYellow board’s i2c lines still in place; the PIC board was/is the intended target for that particular project).

The point here is that it proved to be incredibly easy to integrate an ESP8266 into a project using the Yellow board.  It even had the added advantages of having LEDs on virtually all of the available pins, so there was some visual debug capability thrown in for free.

Shortly after this initial foray into i2c, I came across Cicero’s Ethernet-for-the-ESP8266 project and wrote up an entry here on the process of connecting the Yellow board to an ENC28J60 ethernet module to enable hard-wired ethernet to the ESP (on a side note, keep an eye open for an update from Cicero for a Linux-specific version of this project, coming soon).

So, over the months the awkwardly named “Yellow Development Board” has earned a place in my ESP8266 arsenal as a versatile and well-equipped prototyping tool and in the next post, I’ll look in a little more detail at a doorbell/dash type button project and how it interfaces with MQTT.

[Where to get these boards …I don’t generally give links to specific merchants, but the “Yellow” doesn’t seem to be quite so universally available as it once was.  When I was searching for a new supplier earlier I came across this eBay store selling them at a very good price.  The store has a feedback rating of 99.8% on over 20,000 sales, so they must be doing something right, but I should emphasize that, although I have ordered from them today, I haven’t ever used them before, so this is a “find”, but in no way an endorsement.]

 

Headless Server Worth Having

I use Unix™-like systems everywhere (I’m not going to get into a religious argument about this …I’ve been using various sorts of Unix for dang-near 40 years now and I just never quite got the hang of the GUI paradigm, so call me an old fart if you like; the moniker fits quite well 🙂 ).  Recently I’ve replaced a few of the bigger, more power-hungry boxen around the house with ARM boards, which are inexpensive to buy and very cheap to run.  Some of the Linux offerings (Armbian, Debian, Ubuntu-core and the various siblings, family and friends) are doing an amazing job of keeping up with the ever-changing, disparate array of hardware coming out of the Middle Kingdom (and FreeBSD isn’t far behind), so using these tiny boards as headless servers is quite viable nowadays.

Recently I bought a Nano-Pi M1 (plus 3D printed case) from the FriendlyARM on-line shop, with the intention of pressing it into service as a 24×7 web-cam support machine and general anything-else-I-can-get-to-run-on-it server.  As an ESP8266 user, MQTT was one of the leading candidates in the “anything-else” category.  Well, the good news is that it’s really not that difficult to get a distribution to run on one of these $11 boards.  FriendlyARM do a lot better than some of the other manufacturers in making relatively up-to-date releases available from their web site and again, unlike some of the others, the choice of working distributions is actually greater than just one.

While I still haven’t got the web-cam up and running (anyone want to recommend a decent, cheap camera with reasonable resolution for landscape shots?), I have had a lot of fun playing about with this small board and trying out the various flavours of Linux available for it.

Having mentioned the Nano-Pi M1, I have to say that it is not the subject of this post, though.  While browsing my normal favourite collection of sites over breakfast this morning I came upon this little beauty (courtesy of CNX-Software …one of the better sites for cutting-edge info on embedded systems).Nano-Pi Neo board imageThis is the new, NanoPi NEO from FriendlyARM; the latest stable-mate to the NanoPi M1 (and for that reason, I have a quite reasonable expectation that this board will have good support from day-1 …and as my mouse hovers over the “Add to Cart” button, I hope that FriendlyARM won’t prove me wrong).

This tiny board (40mm x 40mm) has 100Mb ethernet, a USB-2 port (with two more ports available on header pins), a micro-USB socket for power and data, a Micro-SD card socket, a 36-pin header for GPIO (which includes I2C, UART, SPI and general I/O pins) all driven by a quad-core Cortex A7 running at 1.2GHz and 256MB of DDR3 RAM (512MB of RAM for an extra $2).

So how much is it?  $7.99 for the 256MB version.

Before I get screamed at, I need to qualify that price and tell you that the last time I bought anything  (the M1) from FriendlyARM, the postage was $10 (via DHL to most of the world,  so reasonably speedy), so you need to add that into your budget.  As far as I can see, there’s no case available yet (Update:- Just heard back from FriendlyARM that the case is in the works and should be available towards the end of this month …July 2016).

Update:-  It looks as though FriendlyARM have changed their shipping options.  When I went to “checkout” this time, the cheapest option was plain old “China Post”, with Fedex just a couple of dollars extra and the DHL/TNT option a few dollars more.

Update:- I mentioned in the original version of this post that it might be worth adding FriendlyARM’s $1 heat-sink to your order.  Better hold off on that for the time being.  The processor on the NEO is on the bottom of the board and we still have no  idea of what the case is going to look like.  Oops!

It’s going to be hard to beat this as an off-the-shelf, ethernet-connected, low power (as in watts used, not computing power) MQTT/DHCP/DNS server for your ESP8266 network.

Last word… for GUI-centric people, please do note that there is no video output connector on this board; it’s serial-console only.

Update (Aug 8th 2016):-  As of today, the printed case for the NEO is now  available for sale on the FriendlyArm site.  There’s also a fairly chunky heat-sink.  Both are priced at $2.99.  The pricing is a little bit of a downer, as together they bump up the total cost of the unit by a fairly hefty margin.  The other downer is the colour …do you really want a neon-pink case sitting anywhere around your house?

 

NanoPi NEO layout and specs

 

 

Using “TASMOTA” [Part – 2, MQTT]

[Apologies for those of you have been checking back in regularly for this second article on using Theo Arends’ Sonoff-MQTT-OTA-Arduino package.  Not only has Real Life™ been getting in the way, but I’ve purposely been delaying hitting the big, red “publish” button until I could sort out a nagging little problem I’ve been having (more on that later).  Anyway, here we go with part two…]

In the previous article, we looked at how to access some of the features of TASMOTA (Theo Arends’ Sonoff-MQTT-OTA-Arduino package) using the button/LED and serial-console interfaces.  In this article we’ll take a look at controlling the unit using MQTT.

[…and if you don’t really know what MQTT is, or what it does, Elliot Williams has recently published a clear, easy to read and easy to understand article on Hackaday which is worth looking at…]

The main selling point (other than the extraordinarily low price) of the Sonoff is the fact that it is controllable across the ‘net.  Unfortunately, ITEAD Studios have tied control of the device to their own cloud service which, while it may be great for most people, doesn’t work for those of us who are still using “dumb” phones and who don’t have the option of using a service such as Oogleg’s “voice” to get around that limitation.  Theo’s firmware implements MQTT on the Sonoff which, while it doesn’t help my “dumb” phone, does mean that I can use existing devices on my own network to control it.  I already have a couple of MQTT servers on the local network providing time services to various battery-powered, ESP8266 enabled sensors and collecting data (temperature, humidity, barometric pressure, battery voltage) from them.  It would be a trivial matter to have the internal MQTT servers push that data to one of the free data aggregation services out on the ‘net and only a little more work to make the MQTT interface available through the firewall for external access when we’re away from home (Okay, a lot more work to do it properly 🙂 ).  In my case, the need for MQTT is purely pragmatic; it’s a neat device, but I need MQTT to get it to work without a smart-phone.  For others, there may be a reluctance to entrust data access and control to a cloud service which might disappear at some time in the future.  Whichever it happens to be, Theo’s package “hits the spot” and broadens the possible usage window for the Sonoff (which, long term, is good for ITEAD’s sales, too).

In the previous article we already saw how to set up the “topic” keyword to give your Sonoff devices individual addresses, as well as using “grouptopic” to set a group address to which all devices will listen.  Before you can use MQTT though, you need to configure the MQTT broker (server) details for your network, too.  The recommended way of doing this (unless you have a gazillion MQTT servers on multiple networks) is to simply compile-in the hostname/IP and port number when you initially build the package.  If you’re using Theo’s original package, edit the user configurable details at the top of the sonoff.ino file and change these lines:-

// MQTT
#define MQTT_HOST "sidnas2"
#define MQTT_PORT 1883

…to point to your own MQTT server address and port (if you’re using the version which I put up on GitHub with the function defines added, these settings broken out into user_config.h instead).

You can still change this setting (along with most others) from the serial console, or from MQTT, later on.  Using the serial console (as per the previous examples), you can see that the Sonoff unit automatically reboots after the change:-

host
HOST = blind.nthld.org

host hazeltonrig.nthld.org
HOST = hazeltonrig.nthld.org

ets Jan 8 2013,rst cause:1, boot mode:(3,7)
chksum 0x42

Project sonoff (Topic 2F-toilet-gas-sensor, Fallback DVES_0CB0CB, GroupTopic calling-all-units) Version 1.0.6 (Boot 4, SDK 1.5.1(e67da894))

First we used the “host” command without arguments to interrogate the unit for the current setting. Secondly, we used the “host hazeltonrig…” command to change the compiled-in default. TASMOTA then automatically saves the new value to non-volatile memory and restarts the ESP8266 using the newly updated parameters.

Mosquitto notes

Before we start using MQTT let’s just take a brief look at Mosquitto and the utilities which come bundled with it, mosquitto_sub and mosquitto_pub.  If you’re not using Mosquitto as your MQTT server, feel free to skip this section.

As you’d expect from the names, mosquitto_sub is a command-line utility which allows you to subscribe to a topic, while mosquitto_pub allows you to publish.  They are invaluable tools when setting-up and debugging MQTT installations, allowing you to send arbitrary data and commands and to monitor the output.

You can also install the Mosquitto package on a desktop or laptop machine to make these applications available when you just want to connect to a remote MQTT server on some other machine (both utilities accept a “-h” option with an argument specifying the hostname to connect to and a “-p” option with a numeric argument to specify the port number).  However, typing in the full command names, plus options and arguments can get tedious very quickly, so I’d suggest adding aliases for both commands.  These can be added to your .bashrc (assuming you’re using the common, Bourne Again SHell) to make your life a little easier. Here’s an example (you need to customize it for your specific installation):-


##
## Aliases for Mosquitto utilities.
##
## Simple alias for server on this machine.
alias mp=/usr/bin/mosquitto_pub;
alias ms=/usr/bin/mosquitto_sub;
##
## Aliases for server on remote machine.
## (You can comment-out this whole section if you
## only use the server running on this machine).
MQTT_SRV="hazeltonrig.nthld.org";
MQTT_PRT=1883;
alias rmp="mp -h ${MQTT_SRV} -p ${MQTT_PRT}";
alias rms="ms -h ${MQTT_SRV} -p ${MQTT_PRT}";
unset MQTT_SRV MQTT_PRT; ## Prevent pollution.
##
## End of Mosquitto aliases.
##

In the .bashrc excerpt above, we are first setting “mp” to be an alias for the full pathname of the mosquitto_pub command and then doing the same for “ms” and mosquitto_sub command.

You only need the second part (from the line “## Aliases for server on remote machine.”) if you are running the MQTT server on a different machine to the one where you’ll be running the mosquitto_pub and  mosquitto_sub commands.  If you do want to use it, you’ll need to change “hazeltonrig.nthld.org” (and possibly the 1883 port number) to point to the MQTT server on your network.  The aliases here build on the “mp” and “ms” aliases which we’ve already defined to provide “rmp” (“r”emote “mp”) and “rms” to access our remote server with minimal typing.

The “unset” command simply deletes the MQTT_SRV and MQTT_PRT variables to prevent any unwanted clashes if those names are used by you later.

At the end of that, you can now simplify and shorten your commands.

From:- /usr/bin/mosquitto_sub -h hazeltonrig.nthld.org -p 1883 -t stat/#

    To:-    rms -t stat/#

 

Using the Mosquitto utilities

Now that we have our server defined and some aliases set up, let’s go ahead and dive into using MQTT with the Sonoff and TASMOTA.  I’m going to assume at this point that, if you already have an MQTT broker (server) set up, you basically know how the publish/subscribe model works.  Let’s also assume that our MQTT server (the machine running Mosquitto) is called “hazeltonrig” (as we saw above) and that we’re actually using a laptop to type in these examples and display the output.

Because our laptop is not the MQTT server, we need to use the remote aliases which we set up above to channel all of our publish and subscribe requests through “hazeltonrig”, because for the most part, we are actually interested in interacting with a third machine, the Sonoff module.  So, just the same as with the serial console, let’s start off by getting the status from the device.  The easiest way to do this is to use an MQTT wildcard and listen in on all status broadcasts from all devices on the network:-

rms -t "stat/#"

Going back to our aliases, we can see that this actually expands to the command:-

/usr/bin/mosquitto_sub -h hazeltonrig.northld.org -p 1883 -t "stat/#"

The word “stat” is the top-level topic used by TASMOTA clients to publish their status data.  The “#” is a wildcard, meaning match-anything-from-here onwards.

What happens when you type in this command?  Well, unless your Sonoff happens to be transmitting some status information at the time you hit <CR>, absolutely nothing.  You won’t get a prompt and you won’t see any text on the screen after the command itself.  Not very exciting, but you have just started a subscriber process which will sit there quite happily and spit out any data that comes along with the “stat/” topic header.

If you power-cycle your Sonoff at this point, you  will see a couple of power-up status messages displayed on your screen; something like:-

Sonoff switch
1.0.6
DVES_0CB0CB

You’ll also notice that, if you still have the serial monitor connected via the USB<->TTL converter, you will start seeing status messages appearing on your screen when you type in virtually any command.  So, if you type “power 1” into the serial monitor, you’ll get output on the serial monitor itself and you’ll also see the word “on” appear in the window where your subscribe command is running (actually, even if you don’t type in commands, the subscribe window will still show messages at power-up, restart or power-down events; for instance, pulling the plug on the Sonoff will produce an “offline” message approximately 10 seconds after the unit is switched off).

You could type a <CTRL>z to put the command into background and carry on typing MQTT commands into the same window where you’ve just started your subscriber process, but that would begin to get a little confusing once that process started to return data, so at this point I’d recommend opening a new window to be able to enter further commands.

Now we need to command the Sonoff to send out some status, so that we can read it with our patiently listening subscriber process.  For this we use our remote publish alias, “rmp”:-

rmp  -t  "cmnd/2f-toilet-gas-sensor/status"  -m  ""

This expands to:-

/usr/bin/mosquitto_pub  -h  hazeltonrig.nthld.org  -p  1883  -t  "cmnd/2f-toilet-gas-sensor/status"  -m  ""

…which means, publish the command “status” (request status) to the device currently known as “2f-toilet-gas-sensor”.  The -m “” part of the command is simply a null argument to keep mosquitto_pub happy, otherwise it will print a usage summary to try and persuade you that you need to use a message (-m) as an argument to any topic (-t).

The output you’ll see in your subscriber window from the status command with a null (-m “”) option will be something like:-

1.0.6, 2f-toilet-gas-sensor, POWER, 0, 9

This is telling you that the Sonoff is running firmware version 1.0.6, has a topic (addressable name) of “2f-toilet-gas-sensor”, that the last sub-command was “POWER” and the status of the relay is off (“0”). The last “9” indicates the timezone which is currently configured (in this case GMT+9 for Tokyo).

Up Next…

This article has been languishing in the deeper recesses of the WordPress draft cloud for far too long, and has a lot of information for the reader to digest, so I’m going to save some of the other MQTT commands for yet another article and push the big, red “publish” button to get this one out into the wild.

In the next part, we’ll use some of the more useful commands which Theo has provided and look at the difference between normal and group commands.