Author: Roo

LIRC vs ir-keytool

Related to my recent IoT hacking, what started me down this path is the long term annoyance of my X10 lighting being unreliable. X10 has always been problematic due to it’s use of power line communication, this has gotten worse as we add more and more noisy electronic devices that cause additional feedback onto the house wiring.

With the X10 light switch I had an IR-543 which mapped IR (infra red) and the rest of my home theater gear is all IR controlled, so a single remote could control everything including the lights. Another nice feature of the X10 light switch I had was soft on / soft off – meaning that when you turned the lights off they would dim down to off, and the same for on. At the start of a movie this is pretty nice.

Of course with a wifi enabled light switch, how do I get IR control? This seemed like a good reason to DIY a solution and build an IR controller / repeater based on a Raspberry Pi. I found that it’s relatively easy to control Tasmota devices with curl, so I was able to easily turn the lights on or off using a simple program. I was pleased to discover that the new light switch also had the soft on / soft off behaviour.

To build an IR device on Linux, I first thought of LIRC as I’ve used this in the past. As I dug deeper, it seems the LIRC project is quite dormant and I was fighting with a lot of stale tooling. I was succeeding in getting something working with the various remotes I wanted to use but it felt like it was a lot of work. Then a friend mentioned ir-keytable to me which led me to the more modern IR control in Linux solution.

The short version of the story is that the ir-keytable support is in a similar state as the LIRC work. I believe this boils down to the fact that IR control is still very niche, and there are lots of hardware variables due to many different remote controls. If you want to do something simple: receive IR input to control a linux machine, then ir-keytable is the way to go. More complex situations may require LIRC. Both approaches have their challenges but ir-keytable is the more modern solution.

The rest of this article will be about getting ir-keytable going on Raspberry Pi OS with a TSOP4838 IR receiver. For my application I have a more complex set of requirements so I’ll be continuing with an LIRC based solution, but more on that another time.

Continue reading “LIRC vs ir-keytool”

Wireguard – self hosted VPN

After my recent adventures setting up IoT devices with local only access, I now needed to sometimes be able to talk to those devices when I’m not home. There are plenty of solutions, including setting up SSH tunnels which I’ve done in the past. Wireguard seems like a nice solution and it was high time I had VPN access to my home network.

The linuxserver.io folks have a nicely curated wireguard container with documentation. There are also plenty of good tutorials on installing wireguard. You can even go deeper and build your own, or explore alternatives.

Here is a makefile – based on my template for docker makefiles.

Once you create this – go pull the .png files for the QR codes from the config directory. This will make it trivial to setup your phone.

On mobile data – this just works. The local only Tasmota devices I can now control when away from home and it’s super easy. What doesn’t work with this setup is accessing other docker containers on the same host as the wireguard container.

I explored a few options to solve this, but it boils down to the problem of containers not easily being able to see each other. This bugs me, because while I can appreciate the security of containers being isolated from each other – if I expose a port on the host to a container – then other containers should be able to see that same port – but they can’t. This means that containers actually have less visibility into the host than an external machine – that seems wrong.

You can solve the network visibility problem by giving the container a unique IP address. Here is a brief recap of creating a macvlan docker network – details can be found in my previous post on this topic

Now from the makefile above, all we need to do is add --network myNewNet to the docker flags and update the container and we’re good to go.

It’s interesting that the docker ps command seems to not show as much about the container when it is run in this mode (No port information – but yes, ports are exposed).

One thing to keep in mind, if you first setup the container just on the docker host without macvlan you may need to adjust your port mapping to account for the new IP.

If I want the docker host machine to be able to see this container on the new IP we will need to use that --aux-address to build a network path. This is optional, but useful so it’s worth doing.

The version of Ubuntu I’m using doesn’t ship with rc.local enabled. I started down the path of enabling rc.local, but the further I got the more it seemed this was the wrong answer. This post talking about rc.local, pointed me at cron’s ability to execute on commands on reboot. The cron @reboot capability seems like the easy path here, the other choice being to create a systemd service which is effectively what the rc.local solution is.

Let’s create a script in /usr/local/bin/macvlansetup, making sure it’s executable.

Then we’ll edit root’s crontab to call this on reboot

Adding the new job

Now we’re set. The wireguard container has a unique IP address and no visibility problems to any of my other containers on the same host. The IoT devices can also be seen just fine when I am remote and enable the VPN. The one trade-off is a slightly more complicated networking setup.

With the default wireguard settings, this acts like a full tunnel VPN – meaning all of the network traffic runs over the tunnel. This is useful as a security measure if I’m on an untrusted wifi network – all the traffic will flow securely from my device to my home network then back out again to the internet. In my case with my pi-hole configured as the DNS server, I get ad-blocking over the VPN.

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.