This 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

1. Switcheroo at the Switch
2. ESPHome Device Configuration
3. Auto Discovery of ESPHome Devices in Domoticz
4. ESPHome Device Configuration for Domoticz
5. Installing ESPHome on Linux Mint

Switcheroo at the Switch

This is a switch which has been in production for a long time as model SS01S. The plastic shell created in 2019 is still being used as far as I can make out. The LED board, on which the Wi-Fi module is also soldered, is just as old and it's still being used. 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 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). Furthermore, when the LED board was revealed after opening the switch following the instructions in the TreatLife Intertek teardown & programming tutorial - WB3S/BK7231 - 100% local Home Assistant control video, the Wi-Fi module had a CB3S silkscreened label.

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 in its single pole Wi-Fi switch.

While CB3S is silk screened on the circuit board, 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 (10 July 2026).

ESPHome Device Configuration

Here is 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.

Wish I could say that these BK7238 GPIO numbers were obtained with the LibreTiny PinScan example. Unfortunately, I could not get that project to work and the pins were identified by trial and error. Initially it seemed that the LED and relay pins were the same as with the BK7231 on the CB3S board, so only two pins needed to be found. Later on I realized that the white LED and the relay pins were backward but luckily; even with that error, it was possible to get the relay to work while the white LED could not be controlled.

Here 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 CB3S-V200/BK7238 module, the only difference with the original configuration file is the addition of the web server component.

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.

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.

To compile and upload the firmware to the device use the run command instead of compile. As can be seen, upload was done over a serial link similar to what was shown in the Elektroda video.

That is done by pressing the small K1 tactile push-button switch below the main button and LED on the LED board.

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. In the next section, I'll show the YAML configuration files that made it possible to install multiple Treatlife SS02S switches in Domoticz.

Auto Discovery of ESPHome Devices in Domoticz

When an ESPHome device operates in a Home Assistant environment, communication between the device and the home automation application is through a native API component. Because Domoticz does not support this network protocol, the ubiquitous MQTT protocol is used. This is done by removing the API component in the YAML configuration file of the device and adding the MQTT client component.

Instead of specifying the IP address of the MQTT broker, its host name can be given as in broker: domserver.local. The username and password configuration variables can be set to the empty string ("") or omitted entirely if the MQTT broker does not require authentication. The magic here is the Home Assistant discovery. Enabling that when both the MQTT Client Gateway with LAN interface and MQTT Auto Discovery Client Gateway with LAN hardware interfaces are running in Domoticz means that the switch will be discovered automatically by the home automation system and handled without any futher configuration. The documentation seems to indicate that just the MQTT Auto Discovery Client Gateway could be sufficient on its own. That seems to be the case for handling the Treatlife switches as explained here. However, our numerous Tasmota devices require that the MQTT Client Gateway remains on line.

The one thing that caused a bit of a problem was the last configuration variable, discovery_unique_id_generator. Its default value is legacy which did not work. With that setting, every Treatlife SS02S switch was given the same unique identifier ("uniq_id":"ESPswitchrelay"), which clearly defeats the purpose and consequently confused the Domoticz MQTT auto discovery client. Only a single virtual switch was created by the client and it could only communication with the device discovered last. When the unique id generator is set to mac each switch has a different identifier based on its MAC address (such as "uniq_id":"d8fc92443322-switch-565177c4"). The Domoticz MQTT auto discovery client was able to distinguish between the real devices and create a distinct virtual switch in the Domoticz database for each device. Here are the configuration topics and payloads that two switches sent to the MQTT broker who then passed them on to the Domoticz MQTT auto discovery client.

The switches were correctly discovered by Domoticz and two distinct virtual Light/Switch devices were created.

These virtual devices work exactly as desired; they can turn on or off the real device and their state is updated whenever the real devices are turned on or off manually or with their Web interface.

ESPHome Device Configuration for Domoticz

The usual warning applies here. This is my first encounter with ESPHome which strongly suggests that the following should not be construed as a recommendation. All that is being done here is documenting the current configuration of two of the Treatlife switches that have been added to our Domoticz home automation system. That way, it should be easier to improve the configuration later on as I get a better understanding of the ESPHome environment.

Each Treatlife SS02S switch has its own YAML file such as ss02s-112233.yaml. I use the last 3 digits of the Wi-Fi MAC address to create unique file names for each device and elsewhere when it is important to distinguish between the switches.

That file is very short. It assigns a unique device name to the switch, it reads the devices array from the secrets.yaml file and then it reads in the common configuration for all the Truelife SS02S switches called tl-ss02s-base.yaml. That's where most of the configuration is done. Here is what the secrets configuration file looks like.

Finally here is the common configuration file.

The text sensor component identifying the libretiny version was not included. It was useful in the beginning for debugging purposes, but it does add unnecessary auto discovery messages.

Installing ESPHome on Linux Mint

Intalling ESPHome in a Python virtual environment on my up-to-date Linux Mint system was straightforward which pleased me because I prefer that approach to Docker installations. However it was not possible to compile any configuration for a Beken chip. The problem was a mismatch in the Python versions of the virtual environment I created for ESPHome and Python version created automatically in the installation of libretiny in PlatformIO.

There was a quick and dirty work around using a symbolic link, but ultimately the much better solution was to delete the virtual environment manually created for ESPHome and recreating it with the version of Python used for the libretiny virtual environment in PlatformIO. This will be explained in more detail hopefully within in a few days.