A Beken BK7231T Device In DomoticzThis time, I did my homework and made sure that it would be possible to change the firmware of the Treatlife Single Pole Wi-Fi switch before buying anything. The results from the search on the web were so promising that I felt confident that it would be possible to create the desired firmware with ESPHome. Consequently, I purchased a package containing four of the switches.
Of course, things didn't go quite as smoothly as hoped because the product received did not match what was described by tinkerers on the Web. However after some struggles, the light switch works completely locally in our Domoticz based home automation system. Indeed, once the new firmware was installed on the switch, it was automatically integrated into Domoticz in what was perhaps the quickest and easiest procedure I have ever experienced. Presumably Home Assistant users would have a similar experience.
Table of Content
- Switcheroo at the Switch
- AKA Tuya T1-3S Module
- ESPHome Device Configuration
- Uploading the ESPHome Firmware
Switcheroo at the Switch
The first surprise when the switches were delivered was the label on the back of the device. The model was identified as an SS02S and not a bosma-171 as advertised on the seller's web site. That was comforting because the ESPHome devices repository has a YAML configuration file for that model: Treatlife SS02S 2-Way Wall Switch (2-way is American for single pole). I then easily opened the switch following the instructions in the TreatLife Intertek teardown & programming tutorial - WB3S/BK7231 - 100% local Home Assistant control video which was one of the sources which lead me to believe that the firmware of the device could be replaced. As before, the electronics were divided between two printed circuit boards. These are no longer connected with a ribbon cable which required relatively expensive connectors on each board. Instead there is a 5 pin header on the board screwed to the front plate of the switch that plugs into a female header on the board labelled SS02S_POWER_V4.1. There is no need to do anything with that board which contains the power supply and the relay.
To reprogram the Wi-Fi chip which is on the PCB screwed to the face plate, four screws have to be removed and carefully set aside along with a short spring that keeps the momentary push button in the open position most of the time.
This is a switch which has been in production for a long time as model SS01S. The LED board, on which the Wi-Fi module is soldered, has been in use since the start of 2019. The initial wireless module (an esp01_1m see Blakadder templates, ESPHome Devices respository) was based on the ESP8266. Since then, the wireless module has been replaced twice with devices based on Beken microcontrollers.
The second surprise came after successfully compiling and flashing the ESPHome firmware using the CB3S version of the YAML configuration file from the device repository. Frustratingly, the switch could be turned on or off with the virtual switch on the web server, but the main switch button was ineffective. Tracing the circuit for the button confirmed that it was connected to pin 7 of the module. Then I verified with a VOM that when the button was pressed, pin 7 was brought down to ground and that, otherwise, it was pulled up to 3.3 volts through an external resistor.
The penny dropped when the Beken chip used was identified with the ltchiptool utility installed in a Python virtual environment called ve_ltchiptool.
Once again, Treatlife has switched the wireless module on the SS02 LED board of its single pole Wi-Fi switch. While CB3S is silk screened just under the PCB antenna, the module is identified as a CB3S-V200 on the paper label affixed to the RF shield. This seems to be the current norm for modules containing a BK7238 chip. Support for that chip was added to LibreTiny version 1.13.0 in late June 2026 (see Commit 428eb9e). Unfortunately, there is no CB3S-V200 board definition at this time (August 6, 2026).
However...
AKA Tuya T1-3S Module
After getting to know the LibreTiny environment and using some pretty basic tools, I was able to work out the pad definitions of the Wi-Fi module.
As the commit history of my CB3S-V200-BK7238 GitHub repository amply shows, it took a while and some effort to get to that definition. Then in late July, I had the brilliant idea of checking all LibreTiny definitions of boards based on the BK7238. I was pleased to find out that there was a compatible board definition, namely, the Tuya T1-3S Wi-Fi Module.
Note:
The repository contains a PlatformIO project whose purpose is to verify the pad definition shown on the diagram. If the platformio.ini configuration file is examined, it will be obvious that the generic-bk7238 board definition could be used. If the array of untested GPIO ports had been defined as
in main.cpp, the project would not compile using the t1-3s board. The generic board definition is, not surprisingly, a superset of the t1-3s definition. For that reason it is better to use the more restrictive t1-3s board definition.
That array of untested GPIO pins is used to verify that pads 21 and 22 of the Wi-Fi module are not connected to any of the GPIO pins of the microcontroller. See function TestUnknownPad(). That is basically the way I went about identifying the connections between the module pads and the microcontroller GPIO pins. I started with almost all GPIO pins in the untested array and almost all entries in the gpios array set to NC. The exceptions were pads 15 and 16 which I knew were connected to GPIO 10 and 11 (RX1 and TX1) and, of course, pads 1, 3, 8 and 9. As the GPIO pin connected to a pad was identified, the GPIO pin number was moved out of the untested array and the NC value was changed to the found GPIO pin in the gpios array.
PinScan
I would probably have had an easier time if I had used the LibreTiny PinScan example. Unfortunately, I had some problem getting that utility running and once it did run on the BK7238, I did not understand the output. I attached too much significance to the deprecation notice and didn't realise that the displayed D1, D2 , etc., values displayed by PinScan were the Aduino I/O numbers of the GPIO ports.
Here is how I modified the setup() function of PinScan to get it to work.
The important part of the changes is that stream is set to Serial1 and not Serial as in the original source. I spent too much time trying to figure out the chained UART macros to get Serial mapped to Serial1. In the end, I just gave up and just imposed the mapping in the ugly hack seen above. But at least it works.
ESPHome Device Configuration
Given the CB3S-V200 (aka T1-3S) pin definition and the LibreTiny T1-3S board definition (version 1.13.0 or newer), it is a simple thing to add support for the newest hardware version of the smart switch in the ESPHome Treatlife SS02S 2-Way Wall Switch YAML configuration. First let's update the GPIO Pinout table for Treatlife WiFi switches with the I/O pin numbers for the CB3S-V200 module in addition to the older WB3S and CB3S modules.
| Function | WB3S Pins | CB3S Pins | CB3S-V200 Pins |
|---|---|---|---|
| White LED (Power Sensor) | P9 | P8 | P24 |
| Status LED | P8 | P7 | P26 |
| Relay 1 | P24 | P24 | P8 |
| Button 1 | P6 | P6 | P9 |
Below the Basic Configuration from the ESPHome devices repository is modified to support switches with the new C3BS-V200 module by default. Settings for the older Beken based modules are preserved as comments. The YAML configuration file was saved as tlcb3s-v200.yaml in a Python virtual environment for ESPHome called ve_esphome to make compilation very easy.
Aside from the additions to handle the BK7238 Wi-Fi module, the only differences with the original configuration file are the inclusion of the informative LibreTiny Text Sensor and the web server component which simplified testing the new firmware when Home Assistant is not used.
A secrets.yaml file must be in the same directory as the switch's YAML configuration file. Here is a sample. Of course, the correct Wi-Fi credentials must be provided or else the smart properties of the switch will not be evident at all.
The api_encryption_key, needed for integration of the switch into Home Assistant and which must be unique for each device, was easily generated.
!secret references for passwords and top-level components such as api: and ota:. It seems to that the aim is to include only hardware configuration elements in the example files on the site. While that aim is understandable, it is a bit of a shame because I found the original basic configuration very useful in trying to understand how ESPHome works and I will be sorry to see the smaller configuration if my pull request is ever accepted! It does not look as there is a need to worry about that.
The configuration can be verified before trying to compile the firmware.
The configuration files will compile with esphome version 2026.6.5 against release 1.13.0 or newer of the LibreTiny platform.
Uploading the ESPHome Firmware
The next logical step is to upload the firmware to the BK7238 microcontroller. Compiling and uploading the firmware to the device can be done with the esphome run command. So I soldered the RX1 and TX1 pads of the CBS module on the LED board to Tx and RX pins of USB-serial adapter and the 3.3V and GND pins on the CN1 connector to the corresponding 3.3 volts and GND pins of the USB-serial adapter.
From experience with other microcontrollers, I think that the BK7238 based Wifi-module could be flashed successfully with the following connection with a good Serial-Usb adapter.
Pressing the push button when prompted to short CEN to ground should put the BK7238 in upload mode. This has not been tested, because I do not have a bare CB3S-V200 module. Since the K1 push-button on the LED board does short the CEN and RST pins to ground, I thought that it would work with a CB3S-V200 module soldered to the LED board. Unfortunately, that failed. On looking at the LED board restart circuit (assuming I did not make a mistake when trying to work it out), it looks as if K1 does not just ground CEN when pressed, it actually shorts the 3.3 volt and ground rails.
As a consequence, the serial-USB adapter's 3.3 volts and ground pins are shorted when K1 is pressed, which can't be good for the adapter. I assume that it is knocked out while K1 is depressed which means that the serial device (/dev/ttyUSB0 on my Linux system) on the computer disappears with the effect that the connection to the BK7238 is lost. The following configuration with an additional independent power supply works.
Not much is required from the additional power supply; a common breadboard power supply connected to a cheap 5 volt wall wart AC adapter was enough to power the LED board while uploading the firwmare.
On pressing K1 just long enough after prompted by esphome, the latter was able to connect to the BK7238 and complete the firmware upload.
After a while it was possible to open the Web interface at http://treatlifeswitch.local/
Presumably, this is a valid configuration when the home automation system is Home Assistant. I can't vouch for that because we use Domoticz.