Smart Home

Hack your Wi-Fi Thermostat | No Cloud | MQTT

You’re probably wondering why do I want to use a hacked firmware with my thermostat? The primary use case is offline/ non eWelink/ cloud connected usage, as-in leveraging the smart capabilities of the thermostat without having to leverage the cloud to drive it. This also enables you to choose the home automation platform that you use ther thermostat with, for example you can use Home Assistant.

Where to Buy

You can purchase these devices on eBay, AliExpress, Bangood and other auction sites, I’ve also seen them available at some US retailers. These units typically sell for anything between 20-30 Pounds, or about 40 USD at time of writing. With a little time invested you can great ‘big-brand’-like capabilities for a comparatively small outlay.

Look out for:

  • Beca BHT1000, BHT3000, BHT6000 (ensure you get a ‘W’ model that has Wi-Fi support!). These are also re-badged as THP-1000, THP-3000, THP-6000.
  • Moes House

It’s worth noting that you’ll need both a live and neutral connection to power your thermostat. Unfortunately if you don’t have a neutral you won’t be able to use these devices.

Kit List

To hack your Wi-Fi thermostat you’re going to need:

  • A Raspberry Pi 3/4 (this just makes the process easy as you need both Wifi and Ethernet connectivity), running Raspberry Pi OS
  • An RJ45 patch cable, connecting your Rasperry Pi to an Internet connection
  • A Tuya-based thermostat

We’ll be using the awesome firmware created by Klaus Ahrenberg, well actually a fork of it created by Folke Ashberg, links to the associated repositories are in the description below. In case you’re wondering, the drivers for using Folke’s fork is that there is support for custom NTP configuration and Home Assistant automatic discovery.


At this stage I should probably remind you that flashing modified firmware to your device will void any remaining warranty. I’ll also add that any wiring should be completed by a competent and qualified electrician (note these two can be mutually exclusive), you potentially risk your life and /or your home, and that’s on you, not me.

Flashing Time

So with the disclaimer out of the way let’s get hacking… actually you can put the soldering iron away, unless you’re a gluten for punishment and then follow the link and stop watching this video! The simplest way to hack your thermostat is to use Tuya Covert, you’ll also find a link to this in the description below.

We’re going to run Tuya Convert on the Raspberry Pi, that by now you hopefully have setup running Raspberry Pi OS. In all honesty any laptop, or other Linux distribution, within reason, will likely work without issue.

Prepare Thermostat

First you need to get the Thermostat into flashing mode, you can do this by powering off the device using the front panel, then holding the ‘down arrow’ for approx. 10 seconds. You’ll know it’s working when the screen / wifi-symbol starts flashing – the Thermostat is now ready/ waiting for instructions.

Install Tuya Convert

Next we’ll move on to installing Tuya Convert on the Raspberry Pi. You’ll find the commands I use in this part of the video in the description below.

We download the latest Tuya-Convert source files using git.

git clone

Next we download the hacked firmware image, ready for flashing to the Thermostat.

cd tuya-convert/files
cd ..

Now we install the pre-requisites for Tuya Covert to run.


Flash the Device

Now, finally(!), we can flash the hacked firmware to the Thermostat itself. Kick-off the flashing process by executing the script.


When prompted, press Enter to proceed with the flashing process.

It make take a minute or so to progress beyond the Smart Config stage, so just be patient.

Once the Smart Config stage has completed, Tuya Convert will backup the existing firmware, just wait it out, you may be greatful for this back-up in future.

Now the backup has completed we’re presented with firmware images to flash to the Thermostat. Enter the number associated with the image downloaded earlier, for me it was simply a case of entering #3 and pressing enter.

So you’re finally here… the point of no return (well, not quite, but you’ll potentially be soldering). Hit ‘Y’ to continue with the firmware flash, then wait for it to finish.

When the flashing process has completed, you’ll be asked if you want to flash another device… only you know the answer to that question. I did not, so entered ‘N’ and Tuya-Convert cleaned itself up and closed.

Configure the Thermostat

At this point there should be a new Thermostat SSID being broadcast, if not power off the Thermostat as before, hold down the ‘down arrow’ and wait for the backlight/ wifi icon to start flashing.

Using a mobile phone, or other wireless device, connect to this new wireless network, using the password ‘12345678’ – if using an Android device you should be prompted to ‘sign-in’ to the network which will then present the configuration page for the Thermostat.

Hit the ‘Configure Network’ button and then enter your wireless SSID and password.

Enter your wireless network SSID and password. At this stage I’d also suggest disabling MQTT Support, we’ll come to that once we have the device connected to your network. Hit ‘Save Configuration’ and the device will restart, hopefully connecting to your specified network.

You’ll need to identify the IP Address that is provided to the Thermostat as it joins your network. How to do this varies (significantly) by network, so I’ll leave you to figure that out before proceeding.

Once you have the IP address for the device, open a browser on any device connected to the same network, and browse to http://.

Now you’re back to the configuration page return to the ‘Configure Network’ page and enable MQTT support and complete the server/ credentials configuration to match your environment. At this point you can also choose to enable support for Home Assistant Autodiscovery.

Note that if you are using an ACL file on your MQTT server you’ll need to configure this appropraitely.

Hit ‘Save Configuration’ to again restart the Thermostat.

You’re done, and now can integrate the thermostat into your Smart Home platform such as Node-RED (be sure to check out the Alexa and Google Home integration for Node-RED), Home Assistant, OpenHAB etc.

Smart Home

Sonoff Zigbee Bridge | Why Zigbee | How to Flash Tasmota

I’ll start by saying that I’m a huge advocate for the Wi-Fi Smart Home. Wireless is ubiquitous and thus the barriers to entry are low. For a good proportion of automation scenarios it is simply “good enough.”

Why Zigbee?

So you’re probably wondering where Zigbee fits then… well for me Zigbee offers flexibility. I’m able to place Zigbee sensors (for example motion sensors or contact sensors) where I have no means to power them, and where Wi-Fi would drain batteries in days or a few weeks at a push (Wi-Fi simply needs more power than Zigbee does).

It’s not about Wi-Fi VS. Zigbee, Wi-Fi OR Zigbee, it’s about Wi-Fi AND ZigBee, and that is where the Sonoff Zigbee bridge comes in.

Sonoff Zigbee Bridge

You can pickup a Sonoff Zigbee Bridge for around £10-£15, or $15-$20 at time of writing. eBay, Aliexpress, Bangood all have the device available. ZigBee sensors are also good value, I was able to find Zigbee motion sensors for £6/ $8 and contact sensors for similar money, so in reality you can get up and running without breaking the bank.

The Sonoff Zigbee Bridge connects to your Wi-Fi and enables you to control Sonoff and other vendors’ Zigbee devices with the eWeLink App and Cloud, alongside other Sonoff/ eWelink compatible Wi-Fi devices. You can also use Zigbee devices to trigger/ interact with your Wi-Fi devices – so the possibilities here are really interesting.

Why Tasmota?

The next big question is ‘why Tasmota?’ Reducing complexity in systems makes them easier to maintain in the long-run.

Complex systems, comprised of many different components and the software or services required to support become harder and hader to maintain as they grow. The greater the variation, the greater the complexity.

I use Tasmota across virtually all of the Wi-Fi equipment in my smart home. This means that I’m able to have one update process, and primarily need to know the ins and outs of one solution, instead of several to keep my smart home running.

Flashing Tasmota

Flashing the Zigbee Bridge is pretty simple, thanks to the Open Source Communities behind Tasmota, Tasmotizer and Zigbee2Tasmota.

  • First, pull away the rubber feet on the rear of the bridge, revealing the four screws. Remove the screws to open the bridge, then gently free the PCB.
  • Turn the PCB over and identify the location of the ETX, ERX, IO0, GND and 3v3 connection points. You can push breadboard cables through the connection points, meaning this is a solder-free flashing process. Note that dupont cables will not fit.
  • When ready, connect the FTDI adapter to you PC/ laptop, ready to flash Tasmota.
  • Next. download the specific Zigbee Bridge Tasmota binary and flash with Tasmotizer.
ZbBridgeFTDI Adapter
  • Once completed the bridge will restart and a new Tasmota Wi-Fi network will available. Connect to this network using your phone and configure the bridge with your Wi-Fi network SSID and password.

Before proceeding you’ll need to identify the IP address of the Zigbee bridge, likely provided by your router. Once identified, on a device connected to the same network open a browser session and browse to the IP address of the Zigbee bridge.

Flashing the Zigbee Module

At this pont you’d normally be done if this was a traditional Wi-Fi-only module, however we now have to flash the Zigbee module within the bridge.

Tasmota Configuration

You’re now set to configure the device as you would any other Tasmota Wi-Fi device – at the very least set the MQTT server/ credential configuration, friendly name and MQTT topic for your environment.

Zigbee Device Pairing

To pair Zigbee devices, you need set the bridge into pairing mode using the ‘ZbPermitJoin 1‘ Tasmota console command. This will allow pairing for 60 seconds.

Now, on a device such as the Sonoff Zigbee Motion sensor, press and hold the pairing button, then watch the cosole for more pairing confirmation.

And with that we’re done. The bridge is ready, and your Zigbee sensors or devices are paired. It’s time to building your automation(s).

Home Entertainment

Deploying JellyFin via Docker on Ubuntu 18.04 LTS

As a long-time Plex Pass user I had become increasingly frustrated with three core issues:

  • The abysmal Amazon FireStick App – namely the need to constantly switch off the ‘new’ player due to its inability to play certain content.
  • The Docker containers insatiable appetite for memory, and its recent second course of /tmp storage to boot.
  • Content, that I don’t want and isn’t young kid friendly, especially when I’m paying for the platform.

Couple the above with a couple of ‘epic’ failures in consuming synchronized content offline (imagine a 3 year old, getting onto an 11 hour flight unable to access *anything*)… it’s safe to say I was ready to move on to pastures new.

I’d come across Jellyfin 12+ months back, but has dismissed it because there was no FireStick App, and with a young family ease of use is a must. Well… all that changed at some point in the last year as there is now an ‘approved’ FireStick app. After a couple of months of use, I’m pleased to have made the move, experiencing only a couple of minor niggles.

I opted to deploy Jellyfin using Docker, so the steps below assume you are already running Docker CE on your host/ media server. I also chose to enable Hardware Accelerated Encoding, using VAAPI.

First, create required directories, note, you may want to adjust for your environment.

mkdir -p ~/jellyfin/config
mkdir -p ~/jellyfin/cache
mkdir -p ~/jellyfin/transcode

sudo chown -R 1000:44 ~/jellyfin/

Now create the docker-compose.yml:

vi ~/jellyfin/docker-compose.yml

Paste contents as below, ensure you update volumes to reflect locations of your media:

version: '3.2'

    user: 1000:44
    image: jellyfin/jellyfin
    container_name: jellyfin
    network_mode: "host"
        max-size: "10m"
        max-file: "5"
    restart: unless-stopped

    - /mnt/media:/media:shared:ro

      # VAAPI Devices
      - /dev/dri/renderD128:/dev/dri/renderD128
      - /dev/dri/card0:/dev/dri/card0

Note that user 1000:44 enables access to the VAAPI devices required for Hardware Accelerated Encoding.

You can now bring-up your Jellyfin environment:

sudo docker-compose up -d

Finally, browse to http://<server-name/IP>:8096 to access your Jellyfin instance.

You can enable Hardware Acceleration by browsing to Dashboard | Playback (tested on Intel QuickSync-enabled CPU):


Setting up Prometheus on Ubuntu 18.04 LTS

I recently set out to get Prometheus setup, capturing metrics across ‘traditional’ VM (Ubuntu 18.04) and containerised workloads whilst enabling visibility of captured metrics in Grafana. The steps captured below outlines the approach/ configuration I used to get Prometheus, Node-Exporter and cAdvsor up and running. I’ll follow-up with the Grafan Integration/ Configuration in a separate post.

Note this guide assumes you have Docker CE running on the machine you intend to deploy and run Prometheus.

First, create the required user accounts:

sudo useradd -rs /bin/false prometheus
sudo useradd -rs /bin/false node_exporter

Make a note of the ‘prometheus’ account user and group id’s from /etc/passwd, you’ll need these later:

cat /etc/passwd | grep prometheus

Create the required directory structure, in order to ensure configuration and metric data persists container redeployment:

mkdir -p ~/prometheus/config
mkdir -p ~/prometheus/data

Create Prometheus configuration file:

sudo vi ~/prometheus/config/prometheus.yml

Contents (note that ‘localhost’ is used for targets):

# A scrape configuration scraping a Node Exporter and the Prometheus server
# itself.
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Scrape Prometheus itself every 5 seconds.
  - job_name: 'prometheus'
    scrape_interval: 5s
      - targets: 
        - 'localhost:9090'

  - job_name: 'node'
    scrape_interval: 5s
      - targets:
        - 'localhost:9100'

  - job_name: 'cadvisor'
    scrape_interval: 5s
      - targets:
        - 'localhost:9080'

Set required filesystem permissions:

sudo chown -R prometheus:prometheus ~/prometheus/

Create docker-compose.yaml:

vi ~/prometheus/docker-compose.yaml

Contents as below, remember to set the correct user id and group id for the ‘prometheus’ user , as captured earlier:

version: '3.2'

    user: 999:998
    image: prom/prometheus:latest
    container_name: prometheus
        max-size: "10m"
        max-file: "5"
    restart: unless-stopped
    - 9090:9090
    - --config.file=/etc/prometheus/prometheus.yml
    - --storage.tsdb.path="/data/prometheus" 
    - ./config/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    - ./data:/data/prometheus:rw
    - cadvisor

    image: google/cadvisor:latest
    container_name: cadvisor
        max-size: "10m"
        max-file: "5"
    restart: unless-stopped
    - 8080:8080
    - /:/rootfs:ro
    - /var/run:/var/run:rw
    - /sys:/sys:ro
    - /var/lib/docker/:/var/lib/docker:ro
    - redis

    image: redis:latest
    container_name: redis
        max-size: "10m"
        max-file: "5"
    restart: unless-stopped
    - 6379:6379

I ran into issues with the containerised version of node-exporter, where instances in Grafana would persistently show ‘N/A’ or no-data, despite metrics being captured as expected in Prometheus itself.

Moving to a ‘natively’ installed node-exporter fixed these issues.

Download and extract the latest version of node-exporter, this is an X66_64 example:

cd ~


tar -xvf node_exporter-1.0.0.linux-amd64.tar.gz
cd node_exporter-1.0.0.linux-amd64

Copy the node-exporter binary to /usr/sbin:

sudo mv node_exporter /usr/sbin/

Create systemd service:

sudo touch /etc/systemd/system/node_exporter.service

sudo tee -a /etc/systemd/system/node_exporter.service > /dev/null <<EOT
Description=Node Exporter

ExecStart=/usr/sbin/node_exporter $OPTIONS


sudo mkdir -p /etc/sysconfig
sudo touch /etc/sysconfig/node_exporter

sudo tee -a /etc/sysconfig/node_exporter > /dev/null <<EOT
OPTIONS=" /var/lib/node_exporter/textfile_collector"

Create required folder structure for node-exporter, note the use of the ‘node_exporter’ account we created earlier:

sudo mkdir -p /var/lib/node_exporter/textfile_collector
sudo chown node_exporter:node_exporter /var/lib/node_exporter/textfile_collector

Reload systemd daemons and start node-exporter:

sudo systemctl daemon-reload

sudo systemctl enable node_exporter

sudo systemctl start node_exporter

You should now be able to view node-exporter metrics via: https://localhost:9100

Now, we can start Prometheus and cAdvisor, as defined in our Docker Compose file:

cd ~/prometheus
sudo docker-compose up -d

You should now be able to browse Promethus itself via: http://localhost:9090

Browse to http://localhost:9090/targets and ensure that cAdvisor, Node and Prometheus show as ‘1/1 up’ – assuming that they do, you have a working Promethus installation.

Adding new nodes to Node-Exporter is as simple as deploying Node-Exporter as above, on each required ‘target’ or node you wise to monitor, then editing the prometheus.yml file to include the new ‘target’ – for example:


  - job_name: 'node'
    scrape_interval: 5s
      - targets:
        - 'localhost:9100'
        - 'newserver:9100'


Add additional targets to the ‘node’ job (rather than creating new jobs for each host) as this will make viewing the data in Grafana easier.

Once you have updated and saved the configuration file, restart Prometheus:

cd ~/prometheus
sudo docker-compose restart

Raspberry Pi

Raspberry Pi PoE Hat

I was really excited (sad… I know) to get my Raspberry Pi PoE Hat in the post. My intention here was to de-clutter power cables and make my home automation setup more “wife friendly.”

Fitting the thing was surprisingly easy – ensure you attach the standoffs prior to fitting, you risk damaging the PoE hat each time you remove it. Once fitted I connected the network cable into my PoE switch and everything worked as expected – you’d expect it to be simple to be fair! Then came the noise!

If you’re looking to run this anywhere that noise could be an issue, don’t bother buying the PoE Hat. Even in the cool / early UK Spring I found the fan to run regularly and for extended periods. It’s a small fan so when it gets going it is noisy! Definitely not wife friendly… even less so than the cables!

I’d be interested to hear if your experiences are different!

Raspberry Pi

Raspberry Pi Router on a Stick

Updated June 2020 to allow NTP via iptables when VPN not established.

I recently setup a new SSID to enable quick and easy access to a VPN protected network when I needed it, also making this easily accessible for family members who are not computer-savvy.

I used a Raspberry Pi 3 for the task, as a router on a stick. This guide shares the configuration/ commands used to set this up so that:

  • All traffic sent to the Raspberry Pi (from devices using it as their default gateway) will be routed via the VPN
  • DNS requests sent to the Raspberry Pi (again, where clients are set to use it as DNS server) will be routed via the VPN
  • When the VPN disconnects all traffic, including DNS is dropped until such time as the VPN reconnects
Smart Home

A Wi-Fi MQTT Multi-Sensor

Old but gold, I came across the Bruh Automation Multi-sensor video about 12 months ago. Intrigued, I set forth and built a couple of these Wi-Fi devices. Over the year I have iterated on the design and software – getting to a place where the sensors themselves are reliable for use in environment monitoring and automation flows.

Smart Home

Node-RED Smart Home Control Update Q1 2019

It’s been a while since I’ve posted anything about the Node-RED Smart Home Control device bridge. In fact, my last update was inOctober. That said, there has been ongoing effort to develop and add new features, some of which I want to share.

Whilst the service is still “in development” the most significant updates for Q1 include:

  • Google Home support added. You can now use the same devices across both smart home platforms (some device type restrictions apply).
  • Service branding/ name changed to “Node-RED Smart Home Control.” URLs and service endpoints updated to reflect multi-platform nature of the service.
  • Device state is retrievable in the Alexa and Google Home App, both Apps reflect real-time state changes fro either platform.
  • You can now send “out-of-band” state updates to the service (i.e. from an MQTT subscription node). Changes sent will then update state in Alexa and Google Home app.
  • New device types and capabilities added. You can find a full break-down in the GitHub Wiki.

If you’d like access to the service, in order to help with testing, or to simply try it out, follow these instructions.


TP-Link EAP225 v3 Experience

I’ve done a 180 on the TP-Link EAP225 v3, going from loving it to loathing it after just a few days. My issues (and decision to return the AP) all spur from introducing IPv6 into my network. However, the issues experienced, I believe, point to a fault in the AP’s firmware that is not specific to IPv6. I thought I’d share my experience as, based on recent reviews/ tests of this device and its price-point, it seemed like the better choice over the UAP-AC-LITE. No doubt others will be considering a similar purchase in future.

Smart Home

Sonoff T1 Wireless Wall Switch

I’ve spent recent weeks (months even!) looking at how I can bring simple automation and voice control to my home. In my quest to create a “Smart Home” I came across the Sonoff T1 UK-specification wall switch. At just ~£15 and when coupled with Tasmota, an Open Source firmware (from what I have read, I wouldn’t consider using the native firmware) that is suitable for a variety of ESP powered devices, this wi-fi connected switch becomes a very compelling product.

I’ve now got a bunch of these around the house, integrated with the Node Red Alexa Smart Skill v3 Bridge. Over the last three months these have proven to be very reliable (faultless actually) and very effective when paired with the custom multi-sensors I have built using ESP8266 NodeMCU boards to drive automation. I figured I would share my experience/ how I got them up and running.

Note that this guide assumes you have a secure MQTT server available for use, and Node-RED deployed should you want to take advantage of the Node Red Alexa Smart Skill v3 Bridge. If you’ve not got either of these in-place watch this space – further guides to follow.