I will present here an analysis of the interior and a short reverse engineering of the UART protocol of another Tuya dimmer, this time based on a rather unusual LMB54 (BK7231N) module and two HC32F003 microcontrollers. I will fully describe here how it can be programmed and added its OpenBeken support using the scripting language offered by these firmwares. The presented dimmer will be quite unusual, because it does not use the TuyaMCU protocol as discussed products before , only from a slightly different, simpler UART communication, which in this case is unidirectional.
Purchase WXDM2
The dimmer gave me a reader (along with a set of other gadgets) to upload OpenBeken to them, as I wrote in the previous part. The purchase of the dimmer itself took place on the Polish auction site:
The dimmer cost PLN 80, which is quite a lot, but at least it supports two light bulbs and two switches.
Description from seller:
Important note - in the original firmware it dims by pressing the button, so the monostable button is preferred:
assembly diagram:
But beware, the product shipped has the N and L places swapped, you should follow the markings on its housing, they have the "last word"
Received set
This seller doesn't even provide mounting screws or tape in the kit...
WXDM2 interior, module pins and PCB analysis
Just pry the cover:
The parts of the dimmer I analyzed. Here you can see a 3.3V LDO regulator, an optocoupler, a MOSFET (7N65C), 8 S3M diodes and a PN8016 converter controller.
We look further - the WiFi module is not signed, it is not WB3S:
Let's desolder the upper PCB:
Here is the second MOSFET, 7N65C... and a large capacitor, but I haven't analyzed its role.
On the bottom of the PCB with the WiFi module, there are up to two HC32F003 microcontrollers - could it be a product from TuyaMCU? But how is it two? One per dimming channel?
Now you need to unsolder the screen from the WiFi module to see what's inside.
BK7231N! There are chances to change the firmware. But where is the RX and TX?
Let's desolder the WiFi module to check its pinout description.
Hot air is essential here.
Finally, I developed a sketch:
Explains:
- 3.3V and GND is known, power supply
- S1 and S2 are button inputs, they are connected to the WiFi module
- RX and TX from the WiFi module is led outside
- TX from WiFi module goes to both HC32F003
- R1 and R2 are dimmer outputs, each supports one HC32F003
- ZC is zero detection so that the dimmer knows when to start conducting (it is connected through a transistor, to both HC)
I also tried eavesdropping on UART communication. Only on the TX from the WiFi system something is happening.
Collected data as text:
FF 55 01 3F 59 00 00 0A
FF 55 02 3F 3F 00 00 0A
FF 55 01 59 3F 00 00 0A
FF 55 02 59 59 00 00 0A
FF 55 01 3F 59 00 00 0A
FF 55 02 3F 3F 00 00 0A
FF 55 01 59 3F 00 00 0A
FF 55 02 59 59 00 00 0A
00
FF 55 01 FF 00 05 DC 0A
0A FF 55 02 FF FF 05 DC 0A
00 FF 55 01 FF 00 05 DC 0A FF 55 02 FF FF 05 DC 0A
FF
55 01 FF 00 05 DC 0A FF 55 02 FF FF 05 DC 0A
Byte 0x55 looks like TuyaMCU protocol, but TuyaMCU is not.
0x01 and 0x02 look like identifiers which dimmer we are setting.
I decided to upload OpenBeken and check if I am able to send the UART packet controlling the dimmer myself.
Uploading the firmware and the first tests of control
However, it quickly turned out that all the fun with the soldering was unnecessary - in fact, only the WiFI module "talks" to the UART here, so it can be programmed in the system. Nothing will disturb us in the MCU. I marked the pads in the previous paragraph. Here is the connection of the programmer:
I uploaded the batch via:
https://github.com/openshwprojects/BK7231GUIFlashTool
according to the instructions on the page above.
then in OpenBeken I used the uartSendHex command to test sending various packets to the dimmers. I wanted to simulate the operation of the original firmware. This is necessary to control these dimmers.
After some testing, I've come to the conclusion that the following package works:
uartSendHex 0A FF 55 02 00 9F 00 00 0A
And 9F is the brightness level value, from 0 to 255, one byte. There is no checksum here. I don't know what the rest of the bytes are, except for 0x02 which is the ID of which of the two dimmers on board we are controlling.
Proof of concept - test script
I already have a suspicion of how it works. So I can prepare a simple OpenBeken script that changes the brightness of the lamp in a loop. Will the script work as expected?
again:
addChannel 10 1 0 255 1
delay_ms 100
uartSendHex 0A FF 55 02 00 $CH10$ 00 00 0A
goto again
The script above operates on OpenBeken channel 10. It gradually increases it, after reaching 255 it loops from 0. The value of channel 10 is used as the byte value in the sent packet.
OBK commands documentation:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
The script works:
The final example - the bar and mapping its changes to the UART value
OpenBeken offers the ability to set the type of channels, i.e. the way they are displayed. The Dimmer256 type is a dimmer strip with a range of 0 to 255, so it's as found here. In combination with the script below, we can get the dimmer control on the web panel:
addEventHandler OnChannelChange 0 uartSendHex 0A FF 55 02 00 $CH0$ 00 00 0A
When channel 0 is changed, a given message will be sent to the UART. This is enough to have real control over this dimmer..
Result:
Summary
It was quite an unusual product. I have not met a dimmer from Tuya before, but without TuyaMCU, using instead a simplified, "one-way" UART protocol (i.e. here only the WiFi module sends information, it does not receive anything). This "unidirectionality" is a bit justified for me, however, because there are separate MCUs inside to dim each channel. Both are connected to one TX1 line from BK7231N and they only select packets intended for them by their content (one of the bytes is 0x01 or 0x02). The dimmer is already working in OpenBeken, although it could be improved a bit and, for example, remembering the dimmer state (at the moment there is only one variable, so turning off the lamp is equivalent to setting the dimmer to 0). All this is possible to do by OBK scripts, so I consider the dimmer to be anyway supported and in the future I will give a separate topic about the already mentioned scripts.
Cool? Ranking DIY
