[BK7231N/CB2S] KMC 30153 smart mini plug, detailed flashing guide

This is my experience with flashing OpenBK firmware onto a KMC smart plug.

The Device

KMC 30153. A "smart mini plug" rated for 15A 125VAC 60Hz. Not so mini however. Plugged into a standard US double socket outlet, would not allow using the other socket with a three prong (grounded) plug. A two prong one would fit.

Purchased from Amazon.
Product page: https://kmc.co/products/smart-plug-mini.

Teardown

Fairly easy to do. There are two straight line segments on the perimeter of the back cap. I used a utility knife into those to pry the back cap a bit. Then a sharp small flat screwdriver popped the cap without much resistance. The cap is held with glue. The internals slide out effortlessly. The ground pin is just a pass through. Does not connect to the board.

!!! Caution !!!
The cap must be glued back. Otherwise pulling the plug from the wall socket leaves you with the empty shell in hand and exposed hot guts on the socket. Dangerous.
A very good reason to prefer the wireless tuya-cloudcutter flashing (if/until available) over disassembly for wired flashing.
I glued the cap back with "Loctite Super Glue Ultra Gel Minis." Left it 24 hours to cure. Tested the plug on a few sockets, and it held together. For now.

Hardware Found
Chip: Beken BK7231N
Board: CB2S
Firmware: 1.1.8, as reported by the Smart Life app.






Flashing

A quick overview of my steps.
1. Prepared a rig to flash device over serial.
2. Didn't work. While troubleshooting...
3. Came across tuya-cloudcutter. That worked.

1. Flashing over serial setup.

Soldered breadboard wires to the CB2S module. On the photo:
* Red - 3V3
* White - GND
* Green - RX1
* Blue - TX1

I had an orange grounded wire which I used to reset the chip for programming.

I am using SparkFun FT231X, which I've used before with ESP chips. The board provides 3.3V power.



2. Unsuccessful flashing attempts.

I was using the uartprogram tool. For the first 20 attempts I figured my reset timing was off. After I did some 40 more attempts, I decided to investigate.

The issue is that the lonely button on the device is wired to the TX1 pin on the CB2S. In this way:



Effectively the TX1 is being pulled up, and this would prevent any proper serial communication. The fix would be to disconnect the TX1 pin from the switch. My plan was to cut the trace marked in orange in the photo below, which corresponds to the orange connection in the circuit diagram above. After flashing I would've reconnected the two points with a piece of wire to restore the button functionality.



Again, I didn't do the above, because I found tuya-cloudcutter.

3. Flashing with tuya-cloudcutter.

This tool worked great for me. It's based on exploiting a vulnerability. The details are an excellent read - recommended. This of course means that newer firmware may have the vulnerability fixed, and this tool won't work any more.

While running the tool it will ask for the target device. I could not find a match for the KMC plug. My selections (identified with the > sign) to the prompts were:

Quote:

Loading options, please wait...
[?] How do you want to choose the device?:
By manufacturer/device name
> By firmware version and name
From device-profiles (i.e. custom profile)

[?] Select the firmware version and name:
1.1.71 - BK7231T / bk7231t_common_user_config_ty
> 1.1.8 - BK7231N / oem_bk7231n_plug
1.1.8 - BK7231T / oem_bk7231s_rnd_switch
1.1.80 - BK7231T / bk7231t_common_user_config_ty

[?] Select the brand of your device:
Atarm
Aubess
Baytion
Nous
QNCX
Topgreener
> Tuya Generic

[?] Select the article number of your device:
BSD48 16A UK Smart Plug
> LSPA7 Plug

Selected Device Slug: tuya-generic-lspa7-plug
Selected Profile: oem-bk7231n-plug-1.1.8-sdk-2.3.1-40.00

I picked LSPA7 based on images from the net that looked like the KMC plug. The LSPA7 is already covered here. It's a UK plug, and it's not using the BK7231N chip. Nevertheless, the above choices worked on my KMC plug.

The tool can be used without opening the device, and no wires, soldering, or cutting. I already had it open, and in the rig, so I had just power to the CB2S from the FT231X. Normally you'd have it plugged into a wall socket, and it's all done wirelessly/OTA. On the other hand you may need to do some tweaks to your environment to make the tool run. See DNS hiccup.

Flashing notes
Some notes about my process after I did all four plugs that I have.

(1) AP mode.
The tuya-cloudcutter requires putting the plug in AP mode. It offers two ways of of doing it, and I used this one:

Quote:

Long press the power/reset button on the device until it starts fast-blinking, then releasing, and then holding the power/reset button again until the device starts slow-blinking.

In my case, for this plug, in "fast-blinking" the LED goes brighter, and blinks about 2 times per second. (Initially I thought that was the "slow" blink.). For "slow" blinking the plug doesn't blink at all. With that my process of putting the plug in AP mode was:
- Power off.
- Wait 5 seconds.
- Power on.
- Wait 5 seconds.
- Press and hold button (for about 10 seconds) until LED blinks brightly 3 - 4 times.
- Release button.
- Press and hold button (for about 10 seconds) until LED stops blinking.

(2) Power strip.
For the complete flashing of the firmware the tuya-cloudcutter requires putting the plug in AP mode four (4) times. Powering off/on the plug is easier when it's plugged into a power strip with an on/off switch. The plug is held pretty securely in my wall outlet. At some point I was concerned I'll separate the shell off the plug's back plate exposing its guts. They should've used screws for the back plate, or made the back one piece with the shell, and have the front be a glued on cap.

(3) Device profile.
To fully flash the OpenBK firmware the tool needs to be run twice. (Each time doing the AP mode twice.) The first run was:

Quote:

sudo ./tuya-cloudcutter.sh -s my-home-ssid secret-word-for-ssid

This will make the device flashable with custom firmware.
And then the second run to flash the firmware:

Quote:

sudo ./tuya-cloudcutter.sh

The very first time I ran the script I went through the device selection described earlier. The script will save those choices in a profile. On subsequent runs of the script I just use that profile whenever prompted. An example:

Quote:

[?] How do you want to choose the device?:
By manufacturer/device name
By firmware version and name
> From device-profiles (i.e. custom profile)

[?] Select device profile:
> tuya-generic-lspa7-plug

Selected Device Slug: tuya-generic-lspa7-plug
Selected Profile: oem-bk7231n-plug-1.1.8-sdk-2.3.1-40.00

(4) Firmware file.
That part is in the documentation. But because I messed up the first time, I'll write it here for my future me.
tuya-cloudcutter works with a UG type bin file. It says so under the Assets table. It's identified as CCtr usage.
I took the (then current) OpenBK7231N_UG_1.15.485.bin and put it in my local /git/tuya-cloudcutter/custom-firmare folder. On the second (parameter-less) run the script picks it from there, and its prompts look like this:

Quote:

Successfully built docker image
1) Detach from the cloud and run Tuya firmware locally
2) Flash 3rd Party Firmware
[?] Select your desired operation [1/2]: 2
Loading options, please wait...

[?] Select your custom firmware file:
> OpenBK7231N_UG_1.15.485.bin

[?] How do you want to choose the device?:
By manufacturer/device name
By firmware version and name
> From device-profiles (i.e. custom profile)

[?] Select device profile:
> tuya-generic-lspa7-plug

Selected Device Slug: tuya-generic-lspa7-plug
Selected Profile: oem-bk7231n-plug-1.1.8-sdk-2.3.1-40.00
Selected Firmware: /work/custom-firmware/OpenBK7231N_UG_1.15.485.bin

(5) Docker, DNS, WiFi
Minor stuff that could very well be idiosyncrasies of my laptop (Lenovo Ideapad) or OS (Linux Mint 20).

Docker images expire. When docker detects so, it will rebuild, and the script will take longer to run. Doing multiple devices one after the other will most likely reuse the image, and things to quickly.

See the previously mentioned DNS hiccup. This is certainly OS dependent.

After every run of the script my laptop was left disconnected from WiFi.

Pin connections identified
TX1 - Button
P26 - Relay
P08 - LED

tjk