Tasmota

Blog posts about the custom Tasmota firmware for Espressif ESP devices.

Tasmota firmware upgrade failing due to lack of storage space

by
A screenshot of the Tasmota firmware upgrade screen on the web interface

Once you’ve switched your ESP devices from the stock proprietary firmware to Tasmota, the good news is that future firmware upgrades to newer Tasmota versions should be straightforward. You just need to open your device’s web interface, and do an over-the-air (OTA) upgrade, or use something like TasmoAdmin to bulk-upgrade multiple devices. At least, that’s how it works in theory.

What you may find is that the update fails, due to a lack of storage space. So today, I’m going to outline four possible workarounds that you could try if your Tasmota firmware upgrades fail.

Why is there a lack of storage space?

Firstly, a bit about why this happens. You’re most likely to encounter this error with devices that use the ESP8266 chip. Some of these chips come with as little as one single megabyte of flash memory storage, and the standard build of Tasmota is 656 kilobytes (as of version 15.0.1 which is the latest at the time of writing). There simply isn’t enough space for both the current firmware and the new firmware to sit side-by-side ahead of the update process.

Now that we understand why the problem occurs, we can try some solutions.

Solution 1: gzipped binaries

As long as you’re upgrading from a version newer than Tasmota 8.2 (which came out over five years ago now), you can use the smaller gzipped binaries. This reduces the standard Tasmota 15.0.1 release binary down to 469 kilobytes.

However, on some of my devices, that was still too big – 656 plus 469 is more than 1024 kilobytes and exceeds the capacity of the 1 MB flash storage.

Solution 2: install tasmota-minimal first

There are a couple of slimmed down versions of Tasmota:

  • tasmota-lite – a cut-down version of Tasmota without many of the sensors or drivers included
  • tasmota-minimal – the bare-minimum of Tasmota which can’t do anything apart from be upgraded to the full firmware

What you can do is install the latest version of tasmota-minimal first, and then the latest standard version of Tasmota. tasmota-minimal is only 265 kilobytes, and so it’s small enough to fit alongside the standard firmware. Once installed, there’s then space for the full version to be installed.

When you do an OTA upgrade, this is the process that should happen – tasmota-minimal gets installed first, and then the full version. But if it doesn’t, you can do this manually yourself. Your device settings, such as the GPIO mappings and MQTT settings, will be retained during the process.

Solution 3: tethered firmware update

A tethered update is where you use another device, such as a PC, to update the firmware. This means physically connecting the device to the PC. It gets around the storage limitation as the firmware doesn’t need to be downloaded to the device running Tasmota first.

How easy this will be will depend on the device, and where it is. If you’re running Tasmota on a development board, such as a Wemos D1 or m5stack Atom, then you can plug in into your PC with a standard USB cable (as long as it’s a data and power cable). However, if your device is buried away somewhere inaccessible, or is a consumer device that requires disassembly and a USB to UART converter, then you may not want to do this every time a new version is released.

Solution 4: Compile Tasmota yourself

The standard builds of Tasmota cover most common use cases. However, as Tasmota is open source, you can compile it yourself. That way, you can create a smaller, customised build for your device that doesn’t include any extra functions that aren’t needed. There are tools available to do this, but this is really only for advanced users – especially as you’ll need to recompile the binaries for each release.

Solution 5: Switch to a different firmware

As I mentioned last month, Tasmota is not the only game in town. If you also use Home Assistant, then consider replacing Tasmota with ESPHome.

ESPHome has a higher learning curve, due to its use of YAML configuration files. But, once this is set up, it’s easier to compile new binaries each time a new version of ESPHome is released. And, if you’re lucky, you’ll be able to download a pre-built YAML file from the ESPHome Device Repository. Just be aware that it’s not as extensive as the Tasmota Supported Devices Repository – the ESPHome repository has details of around 600 devices compared to almost 3000 for Tasmota. I wasn’t able to find an exact match for ESPHome for my smart plugs, for example.

ESPHome has some other advantages. For example, you can edit the YAML configuration to tell Home Assistant what type of device is plugged in, say a light. That means it’ll appear in Home Assistant as a light, rather than a switch, without needing to use the Change device type of a switch helper.

As with solution four, having a smaller firmware binary will make future OTA updates easier, and these updates can be managed through Home Assistant.

TasmoAdmin: manage multiple Tasmota devices

by
A screenshot of the TasmoAdmin interface

Now that I have multiple Tasmota devices, I went to look for a tool to manage them collectively, and found TasmoAdmin. It’s a web-based app that can monitor the status of your Tasmota devices.

The easiest way to install it is with Docker, and it’s also available as a Home Assistant addon. You can also install it manually on an existing local web server with PHP available. Once installed, you’ll need to create a user account, and then you can start adding your devices by IP address.

Once all your devices are in there, you’ll get a nice list, with their IP address and their current version of the Tasmota firmware. You can then jump quickly into the standard Tasmota configuration for your device, but you can also configure many settings from within the TasmoAdmin interface. This includes things like the MQTT and Wi-Fi settings.

You can also use TasmoAdmin to perform bulk actions on multiple devices at once. For example, you can trigger backups or firmware updates in bulk. The ‘Start’ page in TasmoAdmin also lets you, for example, turn all of your switches on or off at once.

It’s a handy tool. Bear in mind that if you run TasmoAdmin as a Home Assistant addon, it doesn’t currently support ‘ingress’ and so you can’t open it within the Home Assistant interface. This also means that you might not be able to access the dashboard remotely. TasmoAdmin may also work with OpenBeken devices, but I haven’t tried this myself.

Tuya-Cloudcutter

by
A Tuya IR and RF bridge that has been flashed with new firmware using tuya-cloudconverter

Last year, I wrote about a tool called ‘tuya-convert’ which exploits a vulnerability in ESP-based Tuya devices to install custom firmware such as Tasmota. But not all Tuya devices use ESP chips, and that’s where tuya-cloudcutter comes in.

I have one such device, an ‘S11’ RF and IR bridge (pictured above) that I picked up cheaply from AliExpress last year. Instead of one of Espressif’s ESP chips, it comes with a Beken BK7231N chip. Having disassembled its case, I also didn’t find any obvious pins for the UART bus. So I was relieved to come across tuya-cloudcutter, as it doesn’t require any soldering or disassembly. tuya-cloudcutter should work with any devices that use the BK7231T and BK7231N chips.

Like tuya-convert, tuya-cloudcutter exploits a vulnerability. This was responsibly disclosed to Tuya (the bug bounty was donated to charity), and newer devices are shipped without this vulnerability. However, there’s no firmware update for my S11 device to fix the issue, which is perhaps poor from a security perspective but suits my needs right now.

Running tuya-cloudcutter on a Raspberry Pi

You’ll need to run tuya-cloudcutter on a Linux device, and a Raspberry Pi is perfect for this. Indeed, there’s a detailed tutorial to follow. You’ll need Python, Docker, Git and NetworkManager installed and enabled, and there are a couple of configuration files to edit before you start. Everything is done using a command prompt, so you could do it over SSH using a Windows machine with Putty if you wanted to.

A note: I first tried this on my nine-year-old’s Raspberry Pi 400, and it didn’t work, whereas it did on my Raspberry Pi 4. I believe it was an issue with the specific Wi-Fi adaptor in the Raspberry Pi 400.

You may find that it’s easier to have the device already set up in the Tuya or Smart Life app, as you’ll be able to find the existing firmware version. You’ll need this when running the tuya-cloudcutter tool.

Detaching and flashing

tuya-cloudcutter offers two modes:

  1. Detach – this leaves the Tuya firmware intact on the device, but detaches it from the Tuya cloud. You can then use the LocalTuya or TuyaLocal custom Home Assistant integrations from HACS to control your device, but the official Tuya and Smart Life apps won’t work anymore.
  2. Flash – this also flashes new firmware onto the device.

In terms of firmware choices, by default you get:

  • OpenBeken – a Tasmota-like firmware where you can configure the device
  • ESPHome Kickstart – a minimal version of ESPHome, which can be updated later.

You can also add your own firmware, although be careful as you may brick your device if the firmware isn’t configured correctly.

If you choose to flash new firmware, then when the tool has run correctly, you’ll see a new Wi-Fi network appear for you to connect to. The Hotspot login page should open automatically, but if not, go to http://192.168.4.1/ to proceed. You can then configure the firmware to connect to your Wi-Fi network.

Switching firmware later

For my device, I tried OpenBeken first, but found that it wasn’t able to use the RF capabilities of the device. Instead, I built an ESPHome configuration, using the tuya_rf custom component, and flashed that, using OpenBeken’s OTA firmware updater. Because once you’ve used tuya-cloudcutter to install new firmware on a device, you don’t need to use it again – you can switch from OpenBeken to ESPHome and vice versa quite easily.

Also, if you read yesterday’s post about the Sonoff RF Bridge, no, this RF bridge didn’t work with my doorbell either.

Portisch firmware on a Sonoff RF Bridge

by
A AZDelivery D1 development board that I've used to flash Portisch firmware on a Sonoff RF Bridge

A couple of weeks ago, I wrote about flashing Tasmota firmware onto some old Tuya smart plugs, using a USB to UART converter and some Dupont jumper cables. I also flashed Tasmota onto a Sonoff RF Bridge, which I’d bought to listen to doorbell presses. This meant that the RF Bridge would work with Home Assistant without needing a HACS integration or addon, and wouldn’t need to rely on cloud services to run.

However, inside every Sonoff RF Bridge there are two wolves chips with firmware. There’s an ESP8266 chip, which handles the Wi-Fi side of things, and an OBS38S003 chip which handles RF communication. I have the latest R2 v2.2 model; older ones have a different RF chip.

The default iTead firmware on the RF chip has been locked down to only support a limited number of RF messages. That’s fine if your device is supported, but my doorbell isn’t. So even with Tasmota installed, pressing the button my doorbell didn’t do anything as the RF firmware was programmed to ignore it.

Portisch RF fimrware

The OBS38S003 RF chip can be flashed with ‘Portisch’ firmware, which allows all RF messages to be received and decoded. However, whereas the ESP9266 chip has UART pins that don’t require any soldering to access, the OBS38S003 doesn’t support a UART bus. There are therefore two ways to get around this:

  1. Modify the board using additional soldered cables and cutting some lines on the board
  2. Using another circuit board, flashing firmware onto that, and then using the flashing board to flash the chip.

I went with option 2 – I don’t have a soldering iron to hand, and didn’t want to make a mistake and damage the board beyond repair. Instead, I bought this AZDelivery D1 NodeMCU Wi-Fi Development Board (sponsored link). There are a number of ‘D1’ boards out there – Wemos make the most well-known – but this was £7 and available from Amazon. Ironically this board also contains an ESP8266 chip.

Flashing the development board

To flash the D1 board, I needed to install two things:

  1. The Arduino IDE
  2. Python

I installed both, and then followed the instructions that came with the AZDelivery D1 board to set it up as a board in the Ardunio IDE. Next, I loaded the OnbrightFlasher into the Ardunio IDE and flashed it onto the D1 board. Make sure that use a micro-USB cable that supports both data and charging – a charging-only cable will power the device, but you won’t be able to connect to the D1.

Next, it was time to connect the D1 board to the Sonoff RF board. From here, it’s best to follow this tutorial from the ‘Erasing the MCU (RF chip) on the PCB‘ heading, with the following notes:

  • I only got a garbage response from the ‘handshake’ command until I amended the baud rate to 115200 in the Arduino IDE.
  • When it comes to running the flashScript.py script, open a command prompt first, and then run the script.
  • For the OBS38S003 firmware, there are 4 different firmware versions that you can flash. I had the most luck with the one called ‘portisch_main_OB38S003_BUCKET_SNIFFING_INCLUDED.hex‘.
  • If you haven’t already flashed Tasmota, make sure that you flash the ‘tasmota-sensors’ version rather than plain vanilla Tasmota.
  • If you have ESPHome on your Sonoff RF Bridge (see here for the YAML configuration), rather than Tasmota, you may have more luck with rcswitch_main_OB38S003.hex (I haven’t tried this myself)

Once the firmware is flashed, you can disconnect everything, put your Sonoff RF Bridge back together.

Testing the Portisch firmware

In Tasmota, open the Console and type in ‘rfraw 1‘ and press enter to enable Portisch. Then type ‘rfraw 192‘, and the device should beep. You can then type ‘rfraw 177′ and the Sonoff RF Bridge will go into ‘bucket sniffing’ mode – this will display the various codes being broadcast on the 433 MHz band. There’s more guidance on the Tasmota device page and RF commands section.

So, is my doorbell smart now?

The bad news is that, despite all this work, I haven’t been able to use the RF Bridge to capture my doorbell’s signals to turn them into actions in Home Assistant. The codes being sent by my doorbell seem to rotate, presumably so that only the receivers in my house respond and not someone else’s. And, the 433 MHz channel is also very noisy – there are lots of codes being sent by other devices like a frustrating game of Numberwang.

Basically, if I want to have a smart doorbell, I’m going to need to just buy an actual smart doorbell, aren’t I? At least I have an ESP development board to play with now.