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.

Disclaimer

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 https://github.com/ct-Open-Source/tuya-convert

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

cd tuya-convert/files
wget https://github.com/fashberg/WThermostatBeca/releases/download/v1.16.beta5-fas/wthermostat-1.16.beta5-fas.bin
cd ..

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

./install_prereq.sh

Flash the Device

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

./start_flash.sh

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.

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.

• 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.

• Download the Zigbee module firmware and then use the Tasmota GUI to flash this to the Zigbee module.

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).

Part Selection

The final parts list is as below:

• BH1750 light sensor
• AM312 PIR sensor (anything else seemed to produce false triggers)
• NodeMCU v1 (Amica, not Lolin version)
• Red LED (used to show PIR triggered)
• 470 ohm resistor
• DHT22 Temperature/ Humidity Sensor
• Header wires
• USB Power Supply
• 3D Printed Case (I used 3D Hubs to print this)

I tested several sensors in arriving at the specification outlined above:

• RCWL-0516 (this was *far* too sensitive, would pickup movement in another room/ behind a wall/ door and even outside the house itself)
• TEMT6000 (poor low-light performance)
• LDR (poor low-light performance)
• Various PIR sensors (all of which generated false positives on a regular basis, likely wireless interference)
• NodeMCU Lolin boards (these will not fit in the case!)

The Case

Different electronics demanded a (slightly) different case, I also found the original case to be somewhat “cosy” – it was a real squeeze getting everything into the 3D printed case. I ended up iterating on Ben’s design, modifying it to be taller, with a cut out for the BH1750 to sit on top. You can see/ download the revised design at Thingiverse.

Software

My initial goal was to use the PIR as a trigger for a Node-RED-based automation that would switch the MQTT-enabled lights *OFF* in a room where there had been no movement for some time. The sensors, and modified code worked well for this purpose, however I started to run into issues as I expand the use of the devices, namely:

• When collecting data in InfluxDB, measurements would sometimes come through as zero, despite previous/ next being nothing close
• Occasional hanging/ freezing, requiring power reset

Tasmota to the rescue! I’ve been using Tasmota-powered MQTT/ Wifi light switches throughout my house for a while and it hadn’t dawned on my that I could use the same software in my multi-sensors.

Using the configuration below, with the device set to “Generic (18)” I was able to get like-for-like performance/ functionality (including the PIR triggering the red LED on motion) without the hanging/ zero-value measurement issues:

Wiring diagram below for reference:

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.

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.

Check your Wiring

Always switch off the mains when removing face-plates or performing any work on your light switches.

Wiring standards in the UK are also a real issue for Smart Switches. I’m lucky enough to live in a new home (<5 years old at time of writing), meaning I have neutral (red arrow in image below) wires at the switch, along with common (light blue arrow) and switched live (purple arrow) plus earth. Wherever you are located, before you start down the path of smart light switches check your wiring! This may considerably limit your choices.

Flashing the T1 with Tasmota

Never try to open or connect your FTDI/ jumper cables to a Sonoff devices whilst it has mains power attached. You could be severely injured and/ or die.

I’ve flashed a number of these devices now, using the process outlined below every time. Before you proceed:

• Download Tasmota  from GitHub and extract to a folder on your device – we need to change a couple of files before we flash the Sonoff T1.
• Download and Install Visual Studio Code and install the Platform IO extension.

Open the Device and Connect FTDI Adaptor

First, you’ll need to purchase an FTDI adaptor, I use a CP2102 device purchased from eBay (I have no affiliation with the seller, buy whichever FTDI adaptor you want!). Ensure that you install the driver(s) required for your FTDI adaptor before proceeding.

The Sonoff T1 is easy to get into, simply use a small flat-headed screwdriver to pry open where the red arrows indicate. Be careful not to slip as you can easily scratch the paint on the inside of the glass front.

You can remove the ESP board by simply getting your fingernail under one of the corners (red arrows) and applying a small amount of leverage.

Connect your FTDI adaptor as shown below (last pin is not used) – ensure your FTDI adaptor is not connected to your computer yet. Note you should only use 3.3v, not 5v, when connecting your FTDI adaptor, should you accidentally use 5v you’ll need to order another T1 device!

I found that I could simply wrap the jumper cables around the device in order to maintain a sufficiently good connection: no need to solder anything.

The hardware is all set to flash! Time to get our Tasmota customisations ready.

Prepare Tasmota User Config

I opt to pre-set all of the wireless, MQTT, web interface username and password via a user_config_override.h file. You can find the configuration I use on GitHub.

Copy the user_config_override.h file under the “sonoff” folder in your extracted Tasmota folder. You’ll also need to modify user_config.h to enable the use of the override file – find this line in modify user_config.h and uncomment:

//#define USE_CONFIG_OVERRIDE                      // Uncomment to use user_config_override.h file. See README.md

The final change required before we can flash Tasmota is to modify the platformio.ini file – specifically

• Find the [platformio] section near the top of the file and uncomment (remove the semi-colon) the line “env_default = sonoff” – ensure all other lines (firmware-varients) are commented.
• Next. find the [common] section and uncomment “platform = [email protected]” – ensure all other platforms are commented
• Finally, find the line that specifies upload_port and set to the correct COM port of your FTDI adaptor.

Boot your Sonoff T1 into Flash Mode

This is a little like a game of twister:

1. plug-in your FTDI adapater whilst holding the Reset Button
2. press and release Touch Pad 1 (only button on a one-gang model, or left-most button on a two/ three-gang).

The top LED will not be lit and BOTH touch pads will be very dimly lit.

Flashing Time!

Use the upload button at the bottom of the Visual Stuido Code/ Platform IO window to upload Tasmota to your Sonoff T1.  

Once the process is completed check your router/ AP for the IP address given to the device. Browse to the device IP and login using the credentials you set in the user_config_override.h file.   The final tasks here are:

• Set the module type, browse to Configuration | Configure Module | Set Type to “Sonoff T1 <# of Channels>” – the Sonoff T1 will reboot and will then show the correct power button options.
• Configure SetOpition13 to speed-up capacitive button response time. Browse to the console of the device and enter the command:

SetOption13 1

MQTT Integration, Node-RED and Home Assistant

More to follow on this, when I finish the posts on Mosquitto MQTT setup and Node-RED setup I’ll update this guide. For now, this post assumes you have both of these up and running, and that by configuring the MQTT device ID in the user_config_override.h file, you know how to integrate the Sonoff T1 into your environment.

Note, that if you are using Home Assistant, the supplied  user_config_override.h file enables automatic discovery of the Sonoff T1 in your environment – enjoy!

Closing Thoughts

Pros

• The device itself looks sleek/ modern when fitted. Whether this is a good or bad thing will, of course, vary based on your decor.
• Quality-wise, I have nothing bad to say after three months use. Software-wise I’m not getting any random reboots/ commands that are ignored, but that said if I was it wouldn’t be down to the Sonoff T1 (I’m running custom firmware now remember!). Hardware wise, the Sonoff T1 seems well built – only time will tell here!
• The capabilities a smart switch offers. In terms of integration with Alexa, MQTT and the multi-sensors that trigger power events based on motion/ no motion and or light levels is, frankly, awesome. This definitely passes the wife test, and actually drove a faster adoption of the Sonoff T1 around the house.

Cons

• This isn’t a consumer-grade solution or product. Firmware flashing, Node-RED flows, MQTT deployment etc, it’s not going to be for everyone (or even most!). The Sonoff T1 has CE certification but for many this will not be enough for them to trust the device in their home. Will all of that said, you really don’t need to be a rocket scientist to get this stuff working!
• The capacitive buttons aren’t great – you have to be quite precise with your presses, and as there is nothing to “feel” this can be a pain. As we are using voice/ senor driven switching primarily this is not a huge problem for me.
• There is no Sonoff dimmer available (at time of writing). For now I am using one of these Tuya dimmers in the two rooms where I needed dimming. These units will also takes a slightly modified version of the  the Tasmota firmware and thus integrates into Node-RED flows/ the Node Red Alexa Smart Skill v3 Bridge. I’ll be sharing a shorter version of this post on the device in the near future.

• Playback controls (Play, pause, stop)
• Input changing (such as HDMI1, Audio1)
• Volume (in steps)
• Power (on /off)
• Brightness (in %)
• Colour (Red, Green, Blue etc)
• Colour temperature (in Kelvin or warm-white through to daylight)
• Temperature (in °C or °F)

Hopefully this means you’re now able to use commands that are more “natural” to interact with Node-RED flows that control your Smart Devices.

To further the usability of the service it is now possible (required!) to set minimum and maximum values on thermostats (in °C or °F) and smart bulbs (in Kelvin).  Any commands that fall “out of range” will not be processed by the bridge and you will get the appropriate feedback from Alexa. Again, hopefully this makes interaction with the service more intuitive.

Finally, I’ve simplified the response node. Use logic in your flows to return a “true” or “false” value as an input to this node. Any flow that starts with a Node-RED Alexa v3 node should return a payload of “true” where the command/ request is processed successfully and “false” where it is not.

I’ll be updating the documentation with more flow examples in the coming week.

Want to get involved, contribute or start testing the service as outlined in the documentation!

• purchased a variety of sensors and electronic components, Fresnel lenses and NodeMCU boards from China
• designed/ modified circuits, learnt to solder (badly!)
• written firmware for NodeMCU based multi-sensors
• modified 3D designs in TinkerCAD
• printed 3D models via 3D Hubs
• flashed firmware of wi-fi light switches
• (re)written a NodeJS/ MQTT and Amazon Lambda function that drive a Node-RED Alexa add-on

Lots more posts to come, but I wanted to share the latter of these activities with you first.

In my quest to enable voice control over a variety of devices I came across a Ben Hardill’s Node Red Alexa Home Skill Bridge. Ben created a Node-RED Alexa Smart Home  Skill API version 2 add-on that enables Alexa interaction with flows. No sooner had I found this and started to use it I wanted more… ! This is where the Smart Home Skill API version 3 comes in – it allows for a swathe of new voice commands to control playback, volume, inputs and other devices that version 2 did not cater for.

Unfortunately (for me at least) the API syntax has fundamentally changed. This meant figuring out Ben’s service and re-writing elements of it to work with the new API. Whilst I was at it I also updated the web interface to Bootstrap 4, and remediated some NodeJS/ Mongoose functions that were no longer supported in the original service.

The net result… My wife and kids love the fact they can turn on/ off the TV, pause, play and stop video, increase/  decrease and mute volume as well as control the lights with their voice. Couple the lighting control with Alexa “room awareness” and the whole system becomes very user friendly – i.e. “Alexa, turn on the lights.” The multi-sensors add some additional functionality/ capabilities, but I’ll save that for another day.

At this point the skill is in “Dev” – meaning it is not a publicly available Alexa Skill – however, get in touch and I can add you to the list of people able to test the service out.

You can read the intricate detail about the service on GitHub, or request access and get testing.