Gosund/Ghome SW2 [BK7231T] wifi dimmer switch - subsystem identification

Following from the excellent SW5 teardown and template which works well for me, I am now struggling with the Gosund / Ghome SW2.
It's a dimmer with both a traditional US Decora style press-button but also a touch front panel with a row of LEDs. Generally a high-quality product, as with all Ghome I've seen so far. Purchased from Amazon, also sold direct, $15-$20.
FCC ID 2APUZ-SW2 UL listed ES09666 Model SW2 Date 05/2022. 120 V 4 A.



It contains FOUR PCBs connected by thin flex cables:
- Main switch/relay/psu/dimmer board, including a mysterious IC "GK1DD8S003F3P6" which must do the dimming.
- CPU board containing the BK7231T (module) and the seven LEDs
- Touch board with an APTchip "32S1028H8S6" microcontroller.
- 2.4 GHz antenna with coax and U.FL or IPEX

Stock firmware offers on/off, dimming by touch / sliding finger, bar graph of LEDs, very nice.
But it needs to run OpenBK and talk to HA.

Questions:
Does anyone have experience with these peripherals?
Are there any libraries that might work?
I can flash the BK7321 fine, but there is firmware on the other parts, which it would be best to use as-is.
Is the next step to power it up with isolated 120 V, sniff the I2C between the boards and attempt to reverse-engineer the protocols? Urgh!
Does the S in the APTchip indicate that it has no flash, needs to be programmed on power-up?
I guess it would be OK to just have dimming, bar graph and wifi, ignore the touch board.

Any other pointers or suggestions would be welcome. Am I biting off too much here?
I'd also be happy to ship my one in pieces to a real expert...

Thanks!


Touch board IC:


Dimmer board IC:


CPU board (nice programming pads)


General assembly:

Hello, why do you think this device uses I2C?

I'd rather think it's just yet another TuyaMCU device, which should be easily supportable by OpenBeken, altough flashing may be a bit hard due to the UART1 port being used for both programming and TuyaMCU communication. It also may be required to do the UART packets capture first, and it must be done in a safe manner. They can be later analyzed in https://github.com/openshwprojects/TuyaMCUAnalyzer

Or maybe we could just skip the UART analysis part, just make firmware backup (just in case) and then try to flash OBK and just try to query dpIDs from device and try to guess their meaning... TuyaMCU dimmers are not usually very complicated, they are often using the same dpIDs in many different models.

Thank you!! This pointed me in the right direction. After much investigation about TuyaMCU...

With the stock firmware, I have found serial communications at 115200 to/from the BK7231, but not TuyaMCU packets.
Also I2C between various things on the boards, not yet sure which parts are talking.

A bunch of information that doesn't yet completely make sense (all values are hex)

1) I2C seems to control the bargraph LEDs.
Evidence: When pressing the microswitch for On, when the light was previously at full brightness, apart from the relay click, the bargraph lights run up in sequence 1 to 7. I2C packets are (writing to address A6): 00 01, then 00 03, 00 07, 00 0F, 00 1F 00 3F 00 7F.
Turning off, they just drop instantly to a single dot, with a matching packet.

2) Serial seems to control the dimmer.
Evidence: When touching the dimmer touch board, with the light in the On state, apart from the LED I2C packets, now we get:
- I2C write address A6: 01 A7
- I2C read address A7: 00
- BK serial RX: 24 00 01 5D 23
-repeat- I2C write address A6: 01 A7
-repeat- I2C read address A7: 00
-repeat- BK serial RX: 24 00 01 5D 23
- BK serial TX 0x41
- BK serial TX 0x81
- I2C write A6: 00 01 [the LED command]

3) More serial dimming - when running a finger UP the dimmer slider:

I2C LEDs	I2C (dimmer control?)	Serial RX on BK (Dimmer?)
write:A6: 00 03	read:A7: 3E	24 3E 01 5C 23
write:A6: 00 07	read:A7: 43	24 43 01 5C 23
write:A6: 00 0F	read:A7: 4F	24 4F 01 5C 23

3) When the relay is OFF, there are no I2C packets (because the LEDs don't change)
But also no serial packets, so I assume whatever is Transmitting the serial dimming command is not bothering while the relay is off.

4) The BK7231 is also sending single serial bytes at 115200, not obviously synchronised with any of the other packets, but only happening when there's some action. They're in pairs, brightness increasing:
41 81
41 89
41 92
41 98
42 9E
42 A3
42 A4
42 AA
43 AE
...
46 DA
46 DE
47 E4
Maybe this could be: (0x40+number_of_LEDs_4bits 0x80+True_brightness_7bits)

5) There's no heartbeat at all. The LED and other commands are sometimes sent a second time, 100 ms later.

6) there's no packet on either bus associated with the relay click

7) BUT once while flashing the BK7231 with an external serial port, forgetting the other boards connected, the relay started clicking randomly as though it was receiving a command.


Next Steps:


1) take one for the team and install the smart home app, send some commands that way

2) disconnect the boards one at a time and see who is still talking to whom

3) probe the three microcontrollers actual pins looking for these signals, to see which ones even get the various messages.


Any other suggestions or ideas?

I've finished decoding most of it now.

tl;dr is it worth trying to get OpenBeken to speak to this dimmer?
It's definitely not the usual TuyaMCU protocol. Is it fairly simple to write something that receives and sends these messages, updates its internal dimming state etc? The LEDs and Button are easy, but how would it parse the 5-byte serial messages to get the touch input, and send the serial dimmer and LED commands?

Have you seen a device like this before? Shall I flash it with OBK and try sending some of these commands? Thank you!

---

The gory details:

TouchController (APTchip) - reads the touch, controls the 7 LED bargraph.

PowerDevice controls the relay and the Triac.

PowerDevice and TouchController speak by I2C - one message A6 00 bb is the LED mask. The other A6 01 A7 tt is the touch position.
Also an INT line for APTchip to tell PowerDevice it's been touched
And a WAKE line for PowerDevice to tell TouchController to listen to I2C.

The BK7231-relevant parts are as follows:
- Physical button connected to the BK module
- WifiLED and PowerLED connected to BK
- Serial TX from BK to PowerDevice is to turn relay on and off, and set dimmer (via I2C eventually).
- Serial RX from PowerDevice is to tell BK the touch state.
- BK not connected to I2C

The BK sends only these bytes, 115200bps:
OFF: 0b 0000 0aaa where aaa is 1 to 7 depending on the brightness before turning off
ON: 0b 1ddd dddd where ddd dddd is the dimmer setting, 0-100 (percent)
LED: 0b 0100 0ggg where ggg is the LED bargraph 1 to 7.

It's usually sent as a two-byte message, first the LEDs then the Dimmer.
14 ms apart. Sometimes repeated after 20-100 ms or longer, but if you're sliding the brightness on the app, it keeps sending new values, no duplicates. I don't think the timing order of the bytes is useful information, they're decoded separately.

The reason the OFF message also contains the brightness 1-7 is so the PowerDevice can tell the TouchController to leave that single LED on, indicating how bright it will be when switched on again.

the BK receives the touch position from PowerDevice by serial, 115200, with this 5-byte packet:
0x24 0xTT 0x01 0x69 0x23 where TT is the touch position, approximately 0x01 to 0x96
It then usually sends out a new dimmer setting and LED bargraph (which is then relayed by i2c...)

At startup the PowerDevice says this 9 times on the serial port:
Packet 1, 37 bytes: 74 6F 75 63 68 20 61 64 64 72 20 6E 6F 74 20 61 63 6B 20 77 68 65 6E 20 74 78 20 77 72 69 74 65 20 63 6D 64 21
in english, it's saying: touch addr not ack when tx write cmd!

Then it says
Packet 10: 72 65 73 65 74 21 0A 6D 63 75 20 76 65 72 3A 20 76 32 2E 31 2E 32
reset!
mcu ver: v2.1.2

It finally stops complaining once the TouchController ACKs the I2C

BK says nothing on startup.

There are no heartbeats that I've seen, complete radio silence on Serial and I2C unless there's a command on the app, button press or the touch surface is touched.

Very good job, it reminds me of WXDM2 dual dimmer, which also had a custom UART protocol. You can read about it here:
https://www.elektroda.com/rtvforum/topic3985978.html#20631683
Do you need help with getting that into OBK?

Hi, I think I could get the HexSend working, and make it function as a dimmer and indicate its state on the bargraph.
It's easy to flash, because the BK board can be isolated by disconnecting the flex cables. I'll try this tomorrow.

Is there a way to receive the 5-byte packets, to receive the touch input?
Or is that a major rebuild like cloning the TuyaMCU driver?

Also - do you support dimming commands by Hue Emulation? This looks like a fairly messy process I don't yet have a HA server, so it would be useful to control the dimmer like this.

Thanks!

Our Hue is not ready, but we have Wemo.

What about creating a driver directly in C? Maybe this would be easier to support this device.

We are usually using Tasmota apps to control OBK, like Tasmota Control, etc.

Sorry, I'm not up for writing a new driver in C, I'll get lost.

Ha ha if only my internet search was as good as my logic analysis. Blakadder took the SW2 apart and decoded the protocol years ago (when it was still made with an ESP).

Thanks for all your work on OBK, it's doing well on my other switches. I hope this post helps someone else trying to figure out the SW2.
Time to put it back together.

Can you show how you used the Blackadder script to make it work? I assume you translated it to an autoexec.bat file?

I'm not sure if @bkespoke got it working. I could do it for you, but I don't have access to this device, I would need to get one piece for testing.

Hi, sorry I didn't get it working at all.
Blakadder had decoded the serial protocol from the ESP8266 to the other micro(s) in the switch, and written a script for Tasmota. This was back when the SW2 used an ESP, now they're BK7231. I just didn't find it when searching, and did it all again myself.

It might be possible to write an OBK script to send and receive commands to make a SW2 work, but it really needs a new serial port driver and that's beyond me.

You can see all of the commands above and on Blakadder.


I'd be happy to test your script or set up a sandbox for you to work on the SW2. I just can't help much with the code.

Hello! I just got the Shelly Plus wall dimmers, and it uses the exact same chips except for an ESP32 instead of the Beken. I'd love to get this working in ESPhome!

Whoa, you are lucky, how did you get one with ESP32? Which mobile app was it dedicated for, is it for Tuya or something else?

Interesting! Perhaps I'll order one more to see if it's changed back to ESP.


If the internal serial protocol is unchanged, there's a fairly straightforward recipe and script at Blakadder. As the boards are connected with flex PCBs it's easy to separate them so you can flash the ESP by its serial port without interference.

Things to watch out for:

1. Is the protocol the same? Check with a scope or logic analyzer, or even just your FTDI cable before you flash, that it's sending the same messages as I found. Likely to be ok because it was stable between 2021 and 2023. Back up the ESP firmware?

2. The ESP will probably talk to the other micro with some non-standard serial port pins, not its usual Tx and Rx. You'll need to find them by staring at the board. See the blakadder page for the esp8266 version of this.


Don't connect it to mains power and your computer at the same time! It's fairly easy to power the whole switch from 5 V on the relay/PSU board.

>>21025865
It's a Shelly. I got it on Amazon for $15

Added after 3 [minutes]:

>>21025892
Exactly, I found this config for the Gosund here
https://github.com/ab0tj/esphome-devices/blob/master/gosund_sw2.yaml
I'm hoping to map it to the ESP32 pins