Flashing Tasmota over serial

In my previous post on Tasmota I was able to make use of tuya-convert which supports over the air (OTA) updating a ‘smart wifi’ device to the Tasmota firmware. Tuya-convert relies on exploiting a defect in the firmware, Tuya has patched this bug and some (many) device manufacturers have started to ship updated versions of the software – and in some cases new, non-ESP based hardware. Thankfully many devices are still based on ESP hardware and many of the circuit boards even have test points exposed that make hooking up a serial adapter possible for someone comfortable with a soldering iron.

The Tasmota doc is a great place to start. The device I’m working on is a Gosund Smart Light Switch SW5. I did try tuya-convert on this and got the id2 response which indicates that there is a newer firmware. Opening up the lightswitch was easy, but you will need T6 torx screwdriver. Once the circuit board was out I could take a close look.

We can see that the chip is an ESP-8285, that will let me find the data sheet and figure out the pin outs. We can also use the Tasmota doc on pin outs as a reference. Right at the top of the image you can see test / solder pads on the edge, these are going to be useful.

I’ve annotated the chip diagram to show the pins I’ll need to flash the device. It’s hard to tell from the photos I’ve shown so far the scale of the chip, but I can tell you that I don’t have the skills to solder directly to the pins of the chip – I’ll need to use the break out pads on the side of the circuit board. Even those solder pads are very small.

I confirmed based on the data sheet that the break out pads mapped to the pins I had identified on the chip using a multi-meter. The pins on the chip are very small and I was working by feel mostly, but it gave me enough confidence that I could use the break out pads to do the connection.

It is very important to only power the ESP-8285 with 3.3V. If you use 5V you are very likely to break things permanently. Off to eBay I went to pick up what I thought was one of the recommended CH340G serial adapter boards. I later learned that the one I bought did not have a voltage regulator making it unable to supply enough power for the ESP-8285.

You can see that while this board supports 3.3V or 5V – you must modify the board to break the solder bridge to the 5V and add one to the 3.3V. I was able to verify the voltage was 3.3V after my modification with a multi-meter.

At first I had decided because the break out pads were evenly spaced and about the same spacing as a pin header. I did try this – but got stumped by the fact that if I did hook it up correctly the LED on the CH340G adapter would go out and things didn’t work. This turned out to be due to the fact that this adapter would not supply enough power to the ESP-8285. This approach might work, but soldering to the pads was easy enough and that’s the path I ended up taking.

I decided to use Linux and the esptool to do the flashing. It turns out that I could just use pip to install the esptool.

On Linux, if you haven’t modified your user to be in the right group you may not be able to use the /dev/ttyUSB0 device. There may also be additional things you need to do in order for the adapter to be recognized by the OS. I’ll leave these challenges up to the reader to overcome with some creative use of a search engine.

Here are the results of my soldering job – along with a micro-SD card for a sense of scale. This is very small but it’s not too difficult if you use a few tricks. Solder paste on the pads applied with a toothpick are a big help to get the solder to flow. Pre-tinning the wires helps. Working under magnification helped my aging eyes. Make sure the soldering iron is completely warmed up. Also add a little solder to the tip of the iron (pre-tin the tip). With these preparation steps, it should be easy to just touch the iron and the wire to the pad and the solder will flow and you’re good.

Initially I had wanted to avoid soldering, but it turned out to be very quick and easy to do. The reliability of the connection is also superior to trying to press fit the wires – and creating a jig would take a lot more time. In future when I need to flash over serial I’ll just go warm up the soldering iron.

I then decided the correct wiring to perform. Note that TX/RX are swapped. IO0 is pulled to ground to force the ESP into programming mode.

It was here where I ran completely into the wall trying to use my cheap eBay CH340G adapter. I did find someone else who’d succeeded flashing the SW5, which gave me hope that I could succeed. It turns out there is a friendly community you can connect with on Discord to talk about Tasmota things. I started a conversation in the #flashing-issues channel and after a short while got some helpful advice.

Now it turns out, I’d been hasty. If I’d done more research I would have found that having a stable 3.3V power supply wasn’t a given for all of the adapters. While the golden CH340G can be had for a few dollars – many of the CH340G adapters do not have a voltage regulator on them and will not work with the ESP devices. Once the Discord folks had kindly educated me on this – I created a pull request to add some additional warnings to the doc (which has been merged).

Fellow Canadians might be able to grab one of these CH340G adapters from Amazon, it has the required voltage regulator. In my case I dug through my pile of electronic projects and  came up with a Circuit Playground Express, it has an onboard voltage regulator and will easily deliver the ~150mA that the ESP needs (as long as I’m not trying to drive the onboard LEDs).

This changes my wiring diagram. I’ve abbreviated Circuit Playground Express (CPE).

By connecting all the GND lines together I ensure both devices are using the same reference. I’m pulling the 3.3V from the CPE, but the CH340G adapter is being used for the programming. This worked like a charm, but was a mess of wires.

Now that I have stable power, I can follow the steps.

1. Backup firmware

Unplug the connections and do them again – (power cycles the setup)

2. Erase flash

Again, reset the world

3. Upload tasmota.bin – make sure you get the right firmware.

Now you can test your work by providing only power (GND and 3.3v) to the SW5 device to see if the Tasmota firmware starts up ok and offers a WiFi access point (tasmota_XXXXXX-####). You can even go through the initial setup and get it connected to your network.

After I’d gotten my SW5 running Tasmota, I then re-assembled the actual light switch. I found that you had to carefully tighten the screws to avoid binding the switching action. I then temporarily wired this to house wiring to confirm that all of the functions worked as expected. Once things were good, I could permanently install this in my desired location.

I’d referenced flashing Tasmota over serial as the ‘hard way’ – but as long as you can disassemble the device to get to the circuit board, and there are test points you can solder to – it isn’t all that hard. You do need to be comfortable with a soldering iron, and have the right gear to program 3.3V serial.

Ubuntu adding a 2nd data drive as a mirror (RAID1)

Over the years I’ve had the expected number of hard drive failures. Some have been more catastrophic to me as I didn’t have a good backup strategy in place, others felt avoidable if I’d paid attention the warning signs.

My current setup for data duplication is based on Snapraid, a non-traditional RAID solution. It allows mixed sizes of drives, and the replication is done via regularly running the sync operation. Mine is done daily, files are sync’d across the drives and a data validation is done from time to time as well. This means while I might lose up to 24hrs of data if the primary drive fails, I have lower usage of the main parity drive and I get the assurance that file corruption hasn’t happened.

Snapraid is very bad when you have either: many small files, frequently changing files. It is ideal for backing up media like photos or movies. To deal with the more rapidly changing data I’ve got a SSD drive for storage. I haven’t yet had a SSD fail on me, but that is assured to happen at one point. Backblaze is already seeing some failure rate information that is concerning. Couple this with the fact that my storage SSD started throwing errors the other day and only a full power cycle of the machine brought it back  – it’s fine now, but for how long? Time to setup a mirror.

For this storage I’m going back to traditional RAID. The SSD is a 480GB drive, and thankfully the price of them has dropped to easily under $70. This additional drive now fills all 6 of the SATA ports on my motherboard, the next upgrade will need to be an SATA port expansion card. I’ve written about RAID a few times here.

I’ve moved away from specifying drives as /dev/sdbX because these values can change. Even this new SSD caused the drive that was at /dev/sdf to move to /dev/sdg allowing the new drive to use /dev/sdf. My /etc/fstab is now setup using /dev/disk/by-id/xxx because these are persistent. Most of the disk utilities understand this format just fine as you an see with this example with fdisk.

Granted, working with /dev/disk/by-id is a lot more verbose – but that id will not change if you re-organize the SATA cables.

Let’s get going on setting up the new drive as a mirror for the existing one. Here’s the basic set of steps

  1. Partition the new drive so it is identical to the existing one
  2. Create a RAID1 array in degraded state
  3. Format and mount the array
  4. Copy the data from the existing drive to the new array
  5. Un-mount both the array and the original drive
  6. Mount the array where the original drive was mounted
  7. Make sure things are good – the next step is destructive
  8. Add the original drive to the degraded RAID1 array making it whole

It may seems like a lot of steps, and some of them are scary – but on the other side we’ll have a software RAID protecting the data. The remainder of this post will be the details of those steps above.

Continue reading “Ubuntu adding a 2nd data drive as a mirror (RAID1)”

Tasmota firmware (pwn your IoT)

Long gone are the days where X10 rules the Smart Home devices space and with ubiquitous WiFi and cheap ESP hardware we’re seeing IoT devices that connect to WiFi. The problem is that almost all of them want to call home and talk to some service in the cloud. Sure you bought the device, but do you really own it?

When I needed a WiFi controlled outlet, I headed off to the Tasmota Supported Devices Repository to determine which one I should buy. Tasmota is one of the options for alternative firmware for ESP devices. This gives you control over the software running on the IoT device, and most importantly the ability to use it without any cloud server that you don’t control. This is still annoyingly difficult, we really need the tech industry to adopt a better way to give people easy to use devices and software without insisting they give up all control.

Buying from Amazon, I didn’t have to wait long to get a cheap WiFi outlet. It is thanks to Michael Steigerwald and his talk “Smart home – Smart hack”  that we have a way to over the air update some of the devices running the Tyua firmware. Unfortunately, to my dismay, I discovered that many of the Tuya based devices ship with a newer and more secure firmware preventing this hack from always working.

The tuya-convert project is pretty comprehensive, but still requires a fairly deep technical understanding to pull off. I tried a couple of ways to run the software before giving up and using a RaspberryPi. Once I decided to go with the Pi things were much easier.

I got lucky as the Moko YX-WS01A appears to ship with old firmware, my next purchase may be more carefully researched. I was very careful to not connect it to the recommended software (smartapp.tyua.com) as that was likely to cause a firmware update. I really didn’t want to have to crack this thing open and hook up to the ESP physically. Maybe the Moko outlets will continue to ship the older, exploitable, firmware – but buyer beware.

Once I had the very basic Tasmota firmware installed, a tasmota_XXXXXX-#### network access point was available (where XXXXXX is a string derived from the device’s MAC address and #### is a number). I can now connect to this access point and configure the device to one of my WiFi networks by opening a browser on 192.168.4.1. Take care, if you mess up the WiFi password you may have trouble recovering the device.

This screen is different than the Tasmota instructions, I suspect this is because the binary provided as part of tuya-convert is stripped down and does not have any specific hardware configured.

Once you configure a connection to a WiFi network, you’ll lose the access point connection, but you will be able to locate the device on the network you connected it to. It will appear with the device name tasmota_XXXXXX-####.

Before we go further, we’ll perform a reset 5 as advised on this page. It may not be needed, but it sounds like a good idea. This is easy to do with the Console provided on the web UI.

We can see that we’re back on version 9.2.0 – so next we’re going to update the firmware. Which firmware should we pick? This page provides a good overview of the various options. There are many ways to perform the upgrade – I’ve elected to download the .gz binary an provide that file to the web UI. I’ve also picked the default and recommended tasmota.bin.gz file. This will update me to version 10.0.0.

The performance of the web UI seemed quite slow, I have to keep reminding myself this is a very basic microcontroller that costs a few dollars. It’s pretty amazing it works. Post firmware upgrade the web performance does seem quite a bit better.

At this point I can hit the Toggle button and see the LED on the outlet turn off an on, but I don’t seem to be triggering the outlet itself. More configuration is needed.

From the web UI, choosing Configure then Configure Module I can see that this is setup as a generic device with only 4 GPIO pins. Using this template as a guide, I select Generic (18) and set the GPIO pins as indicated. This works great, and I can now toggle the outlet on an off via the Web UI.

A word of warning. Back when the device was acting as an access point – you can only attach one device to it, attempts to connect a second client will fail. I also had some weirdness configuring the module, but I think this was because I had multiple browsers / apps pointed at the one device. Go slow, and do one thing at a time.

As for app based control, there are several Android apps which will bypass the need for a MQTT setup and work directly against the HTTP endpoint. I tried several, but decided for my simple needs Tasmota HomeSwitch was a good match.

Using the app seems to mostly work, but has some latency at times depending where the device is at in terms of responding to the HTTP requests. I notice the same type of latency using the web app, but this represents itself more as slowness to load the page vs. waiting for a button press on the app to take effect.

Bonus – the device appears to persist it’s state (on/off) even if you unplug it from power. This is pretty useful as it means that if there a power failure, it will return to the previous state.

Sure it only supports up to 10A, but wifi control over power and I can keep it entirely on my own network is pretty slick.