Weekend Reads [2016/5/28]

Another eclectic electric collection for your delectation.

One of Theo’s more recent updates is to add a couple of photos to the README.md for the Sonoff-MQTT-OTA-Arduino project (scroll down to the bottom of the page) of a (broken) Kaku 433Mhz mains switch which he has gutted and replaced with an ESP8266 to make a Sonoff look-alike.  I can’t find any further details of the project, but from what we can see from the photograph (click to enlarge) and what we already know of the Sonoff, it should be relatively easy to duplicate this if you have any of these older Kaku units gathering dust.

Using Theo Arends’ Sonoff/MQTT Package [“TASMOTA”]

PREFACE – Theo has put a lot of hard work into TASMOTA and continues to update and improve the package at a quite incredible rate.  For instance, Theo changed the major revision number from “4” to “5” on the 25th of April, 2017.  Between then and the time of adding this note (19th of July, 2017), he has made 92 updates that warranted an entry in the release notes and 42 of those changes were additions.

This article first appeared in April of 2016, so it is fairly ancient.  The basic information here (such as the three main methods for interacting with your Sonoff) is still correct, but you need to realize that any references to menu items or MQTT commands have very probably changed since it was first written.  I just can’t keep up with Theo.  🙂

Please do have a quick look at the “_releasenotes.ino” file in the sonoff subdirectory of the Sonoff-Tasmota package to get an idea of what recent changes there are, as well as checking the package README.md for the major news (ie:- Theo has recently added Alexa support to Sonoff).

Having said that, I hope these articles will help you to become more familiar with TASMOTA and with the Sonoff devices themselves.  Please read on…


 

This is a continuation to the previous post on updating your Sonoff to use Theo Arends’ Sonoff-MQTT-OTA-Arduino package.  Theo’s package has so many features that it takes a little time to get familiar with it.  I’ve always found that a couple of examples are worth more than a scad of explanation (would that the Unix manual pages had made an “EXAMPLES” section mandatory), so rather than leave everyone floundering around on their own, I thought I’d note down some of the examples which I’ve found to work so far.

Before we start, you should realize that there are three main ways to interact with the device:-  the button/LED pair,  the serial interface (which we used to upload the firmware in the previous post) and MQTT.  All of these interfaces interact with each  other to some extent.  So, for instance, pressing the button to toggle the state of the relay will flash the LED to indicate a successful update and automatically generate output to the serial port as well as an MQTT message.  Sending the unit an MQTT command to toggle the relay will also generate a state-change message to the serial port and flash the LED.  Using the serial port to toggle the state of the relay will automatically generate an MQTT state-change message and flash the LED.  So we effectively have three input/output channels with the input from any one of them producing status output to all three.

The simplest of the input methods is the button.  A change in the number of sequential button presses, or in the duration of the press, will produce a limited number of state changes.

  • Pressing the button one will toggle the relay state.
  • Pressing the button twice in a row will toggle the relay state twice.  🙂
  • Pressing the button thrice in a row will initiate Smart-Config mode for 100-seconds (to allow for more complex configuration changes to be made from an Android device).
  • Pressing the button four times in a row will initiate  an over-the-air (OTA) update from a previously configured source.
  • Finally, pressing the button and holding it down for more than 4-seconds will reset the Sonoff configuration to the compiled-in defaults and initiate a restart of the device.

The most versatile input method is actually the serial console, but to activate the console you need to disconnect the device from the mains and take off the covers to gain access to the serial header (programming) pins.  Obviously this is most useful with a new device when doing the initial configuration;  it’s not really practicable once the device has been reassembled and is in use.  Having said that, this is the method I’d recommend  for doing your own initial exploration of the Sonoff-MQTT-OTA-Arduino firmware.  Once you’ve completed the initial installation of the firmware, take a few minutes while the USB<->TTL converter is still connected and use the Arduino-IDE “Serial Monitor” (under the “Tools” pull-down menu) to interact with your Sonoff.  Make sure that the serial monitor window has focus and that the cursor is flashing in the input sub-window at the top.

I’m going to emphasize here once again that there shouldn’t be anything at all, other than the serial connector leads from the USB<->TTL converter, plugged into your Sonoff at this point.

When your Sonoff first boots into Theo Arends’ Sonoff-MQTT-OTA-Arduino firmware (hereafter referred to as “TASMOTA”) you’ll see a very brief status message something like this:-

NAME = Sonoff switch
VERSION = 1.0.6
FALLBACKTOPIC = DVES_0CB0CB

Where the version number is the version of TASMOTA and the fallback-topic is the “if-everything-else-fails” way of addressing this specific module from MQTT.  We’ll touch on that latter function again briefly, later on.

You should now be able to type in commands in the serial monitor window and see the results displayed there directly.  A simple carriage return will produce a “usage” message with all of the possible commands listed (in l single line which, unfortunately, will scroll off the side of the serial monitor window):-

SYNTAX = Status, Upgrade, Otaurl, Restart, Reset, Smartconfig, SSId, Password, Host, GroupTopic, Topic, Timezone, Light, Power

Theo has a couple of nice tables in the README of his GitHub repository which explain each of these, so I’m going to limit myself to a couple of the more useful ones here.

Status

This command does what you would expect, giving you some information about the current state of your Sonoff module.  This command takes options though, so you get different results depending upon whether you run the command without any options at all, or with the different options “1” or “2”.

status
STATUS = 1.0.6, sonoff, POWER, 0, 9


status 1
STATUS = sonoffs, DVES_0CB0CB, http://Your-OTA-Server.And.Domain:80/api/arduino/sonoff.ino.bin, Your-SSID, Your-Passwd, Your-MQTT-Server.And.Domain, 1, 11

status 2
STATUS = Version 1.0.6, Boot 4, SDK 1.5.1(e67da894)

As you can see, “status” without any options is succinct.  It shows the TASMOTA version, the current addressable topic name (for this module when using MQTT) which defaults to “sonoff”, the sub-topic name (in this case “POWER”), the relay status (0 = off) and the current timezone (9 = JST/Tokyo).

Status with the “1” option gives us verbose output on the current configuration of the unit.  It shows the current addressable group-topic (“sonoffs”).  The group-topic is used to address all Sonoffs on the local network to send an MQTT command or request which all of the active devices will execute (again, more on this later).  Next comes the fall-back module name for MQTT addressing, next the full URL for the OTA server, the SSID for your access point, the password for your access point, the hostname for the MQTT server.  The last two numbers on the end are the heartbeat count and the configuration save count.

Status with the “2”  option is somewhat less verbose and provides revision information for TASMOTA itself (1.0.6),  the ESP8266 boot version (4) and the ESP8266 SDK version (1.5.1).

Light & Power

The “light” and “power” commands are synonymous and do exactly the same thing – control the relay.  The commands can be used with or without options.  Used without an option they will display the current status of the relay:-

power
POWER = Off

Used with an option of “0” they will switch the relay off:-

light 0
LIGHT = Off

Used with an option of “1” they will switch the relay on:-

power 1
POWER = On

…and with an option of “2”they will toggle the state of the relay :-

light 2
LIGHT = Off

Topic

The use of “topic” as a command name is a slight misnomer, as this command only shows or changes the part of the MQTT topic which is used too address individual Sonoff units.  For instance, when using the “power” command from MQTT, your command line might look something like this:-

cmnd/sonoff/power 2              -- Toggle the state of the relay.

The “cmnd” specifies that the topic is a command.  The “power” specifies that the command is specific to relay control.  The “sonoff” part of the topic string specifies the actual address of the Sonoff unit (and Theo uses “sonoff” as the default, compiled in,  address).  You can also think of this as being the name assigned to each individual unit.

The useful part of this is that the address can be changed, using the “topic” command, so all of your Sonoff units can be addressed individually (it wouldn’t be too useful if they couldn’t be).  So, going back to our serial console and the command line, we can display the current addressable name using:-

topic
TOPIC = sonoff

…and to assign a new addressable name to this specific unit, use the topic command with an argument:-

topic 2F-toilet-gas-sensor
TOPIC = 2F-toilet-gas-sensor

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

Project sonoff (Topic 2F-toilet-gas-sensor, Fallback DVES_0CB0CB, GroupTopic sonoffs) Version 1.0.6 (Boot 4, SDK 1.5.1(e67da894))
NAME = Sonoff switch
VERSION = 1.0.6
FALLBACKTOPIC = DVES_0CB0CB

Note that the unit has not only accepted the new addressable name, but it has also automatically rebooted and the reboot header information shows the new name, the fall-back name and also the group name. Now this Sonoff unit will only respond to commands and requests which include the addressable name “2F-toilet-gas-sensor” in the topic string.  It will always respond to the “fallback” name of “DVES_0CB0CB” (derived from the unit’s MAC address) and will also respond to the current group addressable name of “sonoffs” (along with all of the other Sonoffs on the local network which have the same GroupTopic setting).

GroupTopic

As just noted, the “GroupTopic” is a special, common addressible name to which all Sonoffs with the same GroupTopic setting will respond.  The GroupTopic can be displayed and set in exactly the same way as the Topic:-

grouptopic
GROUPTOPIC = sonoffs

grouptopic calling-all-units
GROUPTOPIC = calling-all-units

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))
NAME = Sonoff switch
VERSION = 1.0.6
FALLBACKTOPIC = DVES_0CB0CB

Again, calling grouptopic with no argument will display the current setting, while calling it with an argument will set the new group addressable name and automatically reboot the unit.  In the scenario shown above our unit will now respond to the unique address of “2F-toilet-gas-sensor” and also to the common group address of “calling-all-units”.

Next …in the next article we’ll delve into the MQTT command structure for TASMOTA.

 

No-Phone Sonoff stuff…

Sonoff with 3v3 USB programming adapter attachedI’m still quite enamoured of the Sonoff, from ITEAD Studios, despite the fact that I can’t get their eWelink to work with a tablet (the app refuses to register you unless you have a phone number — which my tablet doesn’t have, of course — and the excellent suggestion from Jon Chandler in the support forum, “use Oogleg Voice” may well work, but only for ‘merkins living in merika).  Sniffle.  I really shouldn’t be surprised, though; previous experience has shown that anything connected to female sheep usually leaves me with a cold, wet arm or a body to bury (occasionally both).

Anyway, playing around with the unmodified device showed it as coming up on an IP address of 10.10.7.1 and happily assigning my laptop 10.10.7.2, but that’s as far as I got. All attempts to connect to it from the laptop failed miserably and I was also unable to get the Android “Smartconfig” app to do anything with it (if you’ve had success with any other method of getting the Sonoff to work with an Android tablet, please do leave a note in the comments section below).

So, I disconnected the wee beastie, ripped it apart and set about adding some pins to the existing programming header. A couple of warnings are in order here before I go any further, though:-

  • Your warranty is null and void if you start screwing around with your hardware (but you knew that already, right!?!)
  • You need to switch the unit off, unplug it from the mains and remove any cables connected to it before you start work (hopefully you knew that, too …if you didn’t, give yourself a sharp rap across the knuckles with wooden ruler and stop reading this right now!).
  • You should let the unit stand for half an hour or so to let the capacitors on the mains side of the PSU discharge before taking the top off.
  • DO NOT under any circumstances, touch any part of the PCB or component with a finger, soldering iron or USB-to-TTL adapter until all of the above instructions have been complied with.

ITEAD Studios have designed the board of the Sonoff with a socket for a programming header.

ITEAD Studios' Sonoff, with no clothes onAs it ships on the current version that header is unpopulated (this is ITEAD Studios telling you and me not to mess with their board …which is very sound advice).

The available schematic and the board itself don’t quite match up.  The schematic shows this as a five-pin header, but the PCB very obviously only has four holes.  What are we going to be connecting?  Well, we need pins for ground, receive data, transmit data and +3v3.  We need the latter simply because we do not want to attempt connecting another device (PC/Laptop/UFO-anti-gravity-generator, or whatever) to something which is already connected to the mains (do NOT do that!   I mean it!).  At any rate, four pins is all we need and four pins is what we’ve got.  We also need something that I’d been missing for a while …a 3v3 compatible USB<->TTL adapter (I finally gave in and ordered a couple a while back).

Adding the pins is fairly straightforward, but you should note that the ground pin is the one closest to the camera in the shot above, not the one with the squared-off hole.  The squared-off hole is the 3v3 connection.  Close-up shot of the unpopulated programming headerIf in doubt, get your meter out and test.  Before you put the pin header in place it’s also fairly easy to see the “star” connections from the ground connector to the ground plane around it.  The pin on the opposite end of the connector (next to the “J1” label and the big switch) is the 3v3 connector.

The long row of holes across the bottom of the picture is the connector for the 433MHz remote control board which is fitted to the Sonoff “RF” models, but missing on the base model.

With the pin headers in place, it’s not very easy to see either the silk-screen around pin 1 or the “J1” label, so it might be a good idea to label the ground pin using something like an indelible marker Programming socket populated with pinspen so that you’ll know which way round to connect the USB<->TTL converter leads the next time you take the top off.

Now that we have the header pins in place, we need some firmware to burn to the ESP8266 on the board.  I’d like to point you towards Theo Arends’ Sonoff-MQTT-OTA-Arduino package on GitHub.  It’s a drop in replacement which has a very versatile interface, allowing control of the relay, as well as status reporting and some configuration, from both MQTT and from the Arduino-IDE serial console window.  In addition, the button on the Sonoff will also provide manual control of the relay, start SmartConfig mode, start OTA update mode and force a reset to defaults, depending upon how many presses or how long you hold it down.  Changes to the relay state triggered by the button also automatically generate an MQTT state-change message, so your application should always be able to track state of external switch events.  Neat!  Theo also maintains a non-Arduino version if any of you masochists out there prefer fiddling with the SDK.

To update your Sonoff, make sure that no mains cables are attached, plug your 3v3 USB<->TTL converter cables onto the newly installed header pins (+3v3 to the pin next to the switch, ground to the pin next to the row of holes for the 433MHz module) and then hold down the switch button while plugging the USB connector into your computer.  Burn Theo’s firmware to the board using whichever method you are familiar with.

Note that the USB converters don’t usually supply enough current to run the ESP8266 when it fires up the radio (and it definitely won’t supply enough current to power the relay coil), so don’t be surprised if you see a couple of start-up messages followed by a crash or watchdog reset; just disconnect your USB cable and put the unit back together again (including all of the covers), before applying mains power.  Once it’s all back in one piece and powered on, you can check basic functionality by pressing the button.  A single press should produce an audible click from the Sonoff as the relay toggles state, followed by two brief flashes of the LED.  If you have “mosquitto_sub” available (or one of the Android MQTT monitor apps), you can fire it up and monitor the topic “stat/#” to see output from your newly updated Sonoff (assuming that you set up your own MQTT server details in the firmware defaults).  The mosquitto_sub command would be:-

mosquitto_sub -h Your.MQTT.Server -t sub/#

Use mosquitto_pub to publish an MQTT message to the cmnd/sonoff topic to have your Sonoff toggle the state of the relay:-

mosquitto_pub -h Your.MQTT.Server -t cmnd/sonoff/power -m "toggle"

Hopefully you’re now in business and your Sonoff is happily clicking away as you play with MQTT.

Update –  If you’re having trouble compiling Theo’s package (CFG_Default not defined, etc), I’ve put together a very slightly modified package with the function prototypes broken out into separate header files which should compile cleanly for most people.  It also has a minor pre-processor tweak which will reset the MQTT_MAX_PACKET_SIZE and MQTT_KEEPALIVE values to Theo’s recommended settings of 1024 and 120, without the need to modify the original PubSub library file.

Next …the next article in this series is a tutorial on using Theo’s new firmware.

Reworking the AI Thinker T5 – Part IV.V

The board should now be capable of running a somewhat useful program.  I’ve used the Arduino-ESP8266 core to bang this together, not because I’m an Arduino enthusiast (I’m not …I’ve never owned one, borrowed one or even stolen one), but because I found it the easiest environment to program in, given my cack-handed use of C and preference for the “vi” editor.  It just happens to handle libraries and compile code in a way which is easy to install, use and understand and it fits things into the ESP8266’s overly-complex memory footprint without requiring the user to edit SDK files.  It’s just a pity that the IDE sucks so much. 🙂

Any-hoo (see, I can speak Canadian, too!), this mini project uses the ESP8266 to interrogate the DHT11 sensor for temperature and humidity and then spits those readings out, together with a VCC voltage reading and a unique module ID, to MQTT.  After the MQTT publish is confirmed, the ESP8266 will drop into deep-sleep mode, waking itself up (assuming you remembered to connect GPIO16 to the RESET pin) after 10 minutes to start the whole process over again.

The code contains a ton of Serial.print’s, surrounded by #ifdef DEBUG #endif’s.  So as long as you have “DEBUG” defined to something in user_config.h, you’ll also see all of the data on the serial output, too.

Also in the user_config.h file are a few other settings which you must configure for your specific environment.  They include the SSID and password for your WiFi access point and static IP addresses for the ESP8266, gateway and DNS servers, as well as your MQTT server hostname, port number and topic IDs.  Everything else in that file can be tweaked too, but the items mentioned above are pretty much essential changes to get the ESP into operational mode on your specific network.

The code is available from GitHub:- PuceBaboon/ESP8266-AIT-T5

Do you need a T5 board to use this code?  Heck, no!  You can use just about any of the ESP modules out there, from the ESP-03, ESP-07, ESP-12 through to the WROOM-02.  The ESP-03 (and some of the other, older modules) may give you a bit of trouble when it comes to connecting GPIO16 to RESET, but it is doable.  The original ESP-01 is just about the only module I can’t recommend for this project.  You’ll need a DHT11 (or DHT22) and an LED to replicate the original T5 project, but all in all it’s probably easier going with a new ESP-12 than trying to rework the actual T5 board.

Libraries – The code makes use of the Adafruit DHT library and the “esp-mqtt” library from Ingo Randolf, which is a version of TuanPM’s library modded for the Arduino-ESP environment.  You’ll need to add those to your local, Arduino “libraries” directory to be able to compile the code.

A big “Thank you!” to all of those folks above for making their work available to the ESP community.

In the next instalment, we’ll do a simple update to convert one of the switches to a “program” switch (hold it down while powering on to put the ESP into programming mode) instead of having to fiddle with that jumper every time.

 

More SDK Strangeness

Recently I read a post on the ESP8266 forum where the author was attempting to use the powf() function call, but running out of memory during compile.  That sounded very familiar to me, as I’ve been experimenting with the DS3231 RTC clock module recently (inside an MQTT application) and found that if I tried to use any of the standard “time.h” library functions, such as gmtime() or localtime(), my compile would also bomb with the infamous “iram1_0_seg” out-of-memory errors.  This would happen no matter how many struct tm‘s worth of memory I freed up in the code, to the point where using time.h calls from within MQTT seemed to be an unworkable combination, even with the eagle.app.v6.ld modifications for .literal. and .text. storage.

I don’t have a “silver bullet” answer to this problem (and, so far, according to the thread referenced above, neither does anyone else), but the latest SDK (V1.2 as of the time of writing) does seem to help, although not enough for most people, including me (see page 2 of the thread).  In the end I modified a cut-down version of an Arduino C++ time.h lookalike (mem’s Arduino Playground Time.h) to add the functionality I wanted and still have memory left over for other things.

Kudos to mem for the original Arduino Time.h and my apologies for the terrible,  slash-and-burn mess I’ve made of it.  Gomen-ne!  My exceedingly ugly versions are available here for anyone who is really, really desperate:-  ESP8266/time.h_hacks

 

 

Mosquitto “invalid protocol MQTT in CONNECT” errors (and ESP8266 continuously trying to reconnect to broker service, without success)

[Edit: See “Stop Press” note at bottom of article before embarking on this fix]

This is a problem which is common to Ubuntu based Linux systems running the “mosquitto” broker.

Unfortunately, the default MQTT package available from the Ubuntu Software Centre is an ancient revision, v0.15, which equally unfortunately, shows up as being “3.1/3.1.1 compatible” …when it isn’t.

For us ESP8266 esp_mqtt users, that translates to a constant stream of “reconnecting…” messages on the ESP8266 console and “Invalid protocol MQTT” messages in the broker’s log (probably /var/log/syslog on your system, but check your mosquitto.conf file to verify).  The end result is that the ESP8266 fails to establish an MQTT session with the broker and is therefore unable to publish or subscribe.

What changed and why did it suddenly stop working?  Well, when Tuan (who has done an absolutely fantastic job on producing this package and on responding to issues, including this one) updated esp_mqtt to run with the nodemca LUA package, he updated (as I understand it) esp_mqtt to be fully 3.1.1 compliant.  Unfortunately, because the stock Ubuntu package is so long in the tooth, this bit most Ubuntu users (and users of Ubuntu derived distributions, such as ElementaryOS) in the arse (so blame the Ubuntu package maintainers, not Tuan).

Because there hasn’t been an update to the official Ubuntu package for so long, Roger Light, the author and maintainer of the mosquitto package, has gone to the trouble of providing a local repository for the package which the Ubuntu Update Manager can be configured to poll and download from (it will show up in the Update Manager just the same as any other third-party package, such as the Google “Chrome” browser).  You can configure the Update Manager to use Roger’s repository (and to automatically update your stock, outdated version of mosquitto) in just a few simple steps.  Please note that these steps, described below, add a non-Canonical repository to your Update Manager, which means you are explicitly giving Roger Light and the mosquitto development team permission to change package contents on your system; if you are uncomfortable with this then you should not follow these instructions and should probably remove the existing (now useless) mosquitto package, too (your call).

Okay, now we’ve got the small-print out of the way, lets get going.  Before starting the upgrade, you should stop your existing mosquitto daemon:-

  service mosquitto stop

and back-up your existing mosquitto.conf file:-

  cp /etc/mosquitto/mosquitto.conf /etc/mosquitto/mosquitto.conf_ORIG

and then start the Update Manager (icon, menu, cli, whatever your particular Ubuntu variant uses).  Leave the Update Manager to sort itself out (it takes a few seconds to start up) and go back to your web-browser and go to Roger’s excellent update page, at:-

https://launchpad.net/~mosquitto-dev/+archive/ubuntu/mosquitto-ppa

(it will open in a new tab).  Click on the green “Technical details about this PPA” close to the top of the page.  This will expose a pull-down menu,  “Choose your Ubuntu version”.  Once you’ve selected your version, say 12.04, the text box below will change to display the package manager entry for that specific version of Ubuntu.  Two lines will be displayed.  One starting with just “deb”, which is the main package repository and the other starting with “deb-src” which is (duh!) the package source-code repository.  We need to use these addresses to configure the Update Manager to use Roger’s repository, so select the first, “deb” line and then swap back from the browser to the Update Manager window.

In the Update Manager window, click on the “settings” button to bring up the configuration window and select the “Other Software” tab.  Near the bottom of the settings window you should now see an “add” button and clicking on that will bring up another window with the natty heading “Enter the complete APT line of the repository that you want to add as source“.  Paste the “deb” line into the text box, making sure there are no trailing characters after the last word, “main” and then hit the “Add Source” button to add it.  Optionally, you can now go back and repeat the same procedure with the “deb-src” line, if you want to download the source-code, too (again, your call).

Going back once again to Roger’s page, take a note of the number displayed in the “Signing key” line.  Flip back to the Update Manager settings window and select the “authentication” tab.  Scroll down the list of Trusted Software Suppliers and somewhere close to the bottom you should find an entry for “Launchpad mosquitto“.  Check that it is the same key number as the one you just noted.  The Update Manager will automatically download the public key specified by this number from Roger’s site to enable secure updates.

Okay, we’re done with the heavy lifting.  You can now close the “Software Sources” (settings) window.  If your mosquitto update has been successful, the close will trigger an automatic update of the available software cache (so click the “reload” button, when prompted).  The Update Manager should (again, automatically) go off and check for new software and find the newly available mosquitto package.  Select the package in the normal way and click “Install Updates” to have the Update Manager remove the old version of mosquitto and install the latest available version from Roger’s site.

One thing you need to be aware of is that the current version (as of Feb 2015) of the mosquitto package has a very minimal configuration file, so before starting the new daemon you should check your original mosquitto.conf file for settings specific to your site and import them into that new file.  A simple method for pulling those settings out of your old file (you did back it up, didn’t you!?!) is to use this command pipe:-

grep -v "^#" /etc/mosquitto/mosquitto.conf_ORIG | cat -s

The `-v “^#”‘ sequence tells grep not to match any comment lines and the “cat -s” suppresses multiple blank output lines.

Make sure you put the settings from the old configuration file into the new, minimal file (especially any “user” or authentication settings) before you restart the new daemon.  You can use man mosquitto.conf to get help with the available settings.

Stop Press: Literally a few minutes before I pressed the “publish” button on this missive, Tuan rolled out an update (told you he was good :-)) to esp_mqtt, adding a protocol define option to the include/user_config.h file:-

#define PROTOCOL_NAMEv31      /* MQTT version 3.1 compatible with Mosquitto v0.15 */
//#define PROTOCOL_NAMEv311   /* MQTT version 3.11 compatible with Paho & Mosquitto > v0.15 */

…so now you don’t have to upgrade if you don’t want to.  Yay!