LSC Smart Dimmer Switch

[Bacto]

Hi,

First I want to thank you for the amazing work done here! I'm super happy to see that we can now use new Tuya devices :)

I have bought a LSC Smart Dimmer Switch (same as https://github.com/openshwprojects/OpenBK7231T_App/issues/218#issuecomment-1265374143). It is a wall switch, working on a battery consisting of:

• A WB3S module
• A Tuya MCU with no reference written
• A rotary switch
• 2 LEDs
  • One that seems RGB (seems connecter to the TuyaMCU)
  • One green (seems to be related to the charge function)
• A power switch
• A reset button
• A 3.7V battery
• A USB C connector use to charge the battery

I'm new at Tuya devices, OpenBekenIOT and never used Tasmota before. So all of this is new to me :)

I have flashed the WB3S module with no issue. Now I'm trying to use the rotary switch but having found how to do it.

After loading the Tuya MCU (with startDriver TuyaMCU), I have some interesting logs:

• When pushing the rotary button, I have one of these 2 messages (alternating one of the other):

  Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 FF 01 00 05 
  Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes
  Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 FF 01 01 06 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

• When rotating down:

  
  Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 05 01 24 02 01 0A 39 
  Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 12 bytes
  Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 01 09 00 0F Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

- When rotating up:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 05 01 24 01 01 0A 38 Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 12 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 01 09 01 10 Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

- When not using the devices for some seconds:

Info:TuyaMCU:Consumed 255 unwanted non-header byte in Tuya MCU buffer

Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Reset button seems do not trigger TuyaMCU logs. Pushing it for few seconds make the RGB LED blink RED but nothing more.

I tried to find some informations before openning this issue but I'm in a dead end because I have not so much informations.
I suppose that the current TuyaMCU driver doesn't support these data format for now?

Time now for some questions:
- How I can configure OpenBekenIOT to make the rotary switch work? Can I do on my side or does it requires a firmware code update?
- Is it possible to use the RGB led (which is connected to the TuyaMCU) from the WB3S?
- Any leads to get the battery status?
- When on battery, the WB3S is powered up for only 5 seconds when moving the rotary switch. Seems the logic is in the TuyaMCU. Any luck we can change this?
- How to manage deep sleep?

Thanks :)
Adrien

[miyoyo]

Beautiful! This is the important part: [01-01 18:12:15 TUYA Notice][ffc_app.c:239] ffc auzkey key -> VYuuiEV9sSyf13AfCYwcpIBgtexZnMck

This Authentication key is the Tuya-provided Auth key, it's also what is used to make the md5 hash that is used to encrypt the communications.

Also tells us that switches have an unique authentication key, the previously dumped switch is: s7IabMZ0Rl61RysZGBHHICZyaqaWfpjL

I've only managed to pair it to some devices (including the smart plug and one smart bulb), to do so, it has to be paired to an app, and either pair it to the switch right after it's paired to the app, or toggle the power to the smart device (unplug then replug, not just power cycle through the app) and then trigger a pair.

Additionally, I'm not sure what 0xcb 0x4e 0x3e 0xa4 0x0 0x30 0x9d 0xab 0x65 0x6d 0x8d 0xbf 0xe4 0xb9 0x3f 0x35 is, but it's dumped by both devices as-is

Bind Key =

    uni_md5_init(&md5);
    uni_md5_update(&md5,"6xg0Qo9Cxi85oooA",0x10);
    uni_md5_final(&md5,master->bind_key);

Control Key =

    uni_md5_init(&md5);
    uni_md5_update(&md5,master->cfg->mac,6);
    puVar6 = master->cfg->auzkey;
    sVar2 = strlen((char *)puVar6);
    uni_md5_update(&md5,puVar6,sVar2);
    uni_md5_final(&md5,master->ctrl_key);

[miyoyo]

Additionally @HumbleDeer I forgot to mention how to read the source easily:

https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/master/sdk/lib/libtuya_iot.a contains unstripped code that can be split out back into object files, ghidra can do it automatically.

It's ARMv8/Thumb 32 bit LE

[HumbleDeer]

@miyoyo You may also be interested in the work @fust has done.. https://github.com/fust/LSC_SmartDimmer

[miyoyo]

@miyoyo You may also be interested in the work @fust has done.. https://github.com/fust/LSC_SmartDimmer

I've already used it before (see my original post about key derivation), it appears that the smart dimmer is basically just something that reads commands and forwards them through FFC, which means that 99% of the relevant code is in libtuya.

I'm not sure there's much I can learn in there, but I'll look around a second time

[HumbleDeer]

It has the logs you wanted that I was attempting to gather.

On Sat, 24 Dec 2022, 4:02 pm miyoyo, @.***> wrote:

@miyoyo https://github.com/miyoyo You may also be interested in the work @fust https://github.com/fust has done.. https://github.com/fust/LSC_SmartDimmer

I've already used it before (see my original post about key derivation), it appears that the smart dimmer is basically just something that reads commands and forwards them through FFC, which means that 99% of the relevant code is in libtuya.

I'm not sure there's much I can learn in there, but I'll look around a second time

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1364542372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6E4TACO5YB76C6PNPTWO4GAHANCNFSM6AAAAAARGJYFJY . You are receiving this because you were mentioned.Message ID: @.***>

[fearek]

anyone made progress on this? I would love to have this switch in my home assistant app and be able to customize it

[miyoyo]

@fearek I haven't touched it much since, basically, to make it work, you only need an esp32 (or equivalent) listening for stray packets, and forwarding these packets to your own server.

The packets are idempotent, and the switch actually does not really care about the devices it pairs with, the pairing process is more for the devices themselves, so they can listen for a specific switch.

You could just have a training phase in your receiver that assigns commands to different packets, without decoding them.

However, you would be better served by buying an actually well built product that doesn't require all that work, you can get battery operated Zigbee (or probably also BLE, although I haven't looked) switches for the same price.

In my experience with real Tuya devices, this switch is unreliable (sometimes requires pressing the button up to SEVEN times to make it work) and slow (button turning inputs are batched, which means that you can sometimes spin for a few seconds with no changes, then the lamps go fullbright with zero intervals, but sometimes it works well)

[EpicLPer]

Heya,

a few days ago I picked up this LSC switch again, bought 2 just for the sake of experiments. Managed to flash ESPHome on one of them so far and currently trying to figure the serial communication out from the unnamed chich to the WB3S board.
I see you guys got quite far already and have way more experience than I do here ^^ Has anyone figured something further out meanwhile?

As much as people are saying this switch is "cheap crap" I'd still somehow want to get something working on it at least, more as a proof of concept than anything by now :) Even if it requires another ESP as a "Tuya receiver" of sorts to make it work, as it seems to work better via direct WiFi connections than first having to establish a connection to a WiFi network, then ESPHome API, then Home Assistant and so on.

EDIT: What is the baudrate of that unnamed chip to the WB3S board btw? I've tried a few different ones just logging them directly to the ESPHome console, but so far only really got gibberish I couldn't decipher...

[miyoyo]

@EpicLPer No clue what the protocol itself is, but it's speaking 9600 Baud UART

There's a capture over at this repo https://github.com/fust/LSC_SmartDimmer , you can open it with PulseView, add the UART decoder and set it to 9600, it decodes fine.

it seems to work better via direct WiFi connections than first having to establish a connection to a WiFi network, then ESPHome API, then Home Assistant and so on.

It frankly does not, I've been using FFC as-intended for over a year now, and I can confirm that:

• It's slow, like, really fuckin slow, it can take up to 5 seconds to react sometimes.
• Sometimes it doesn't work at all, I need to press the button twice, or three times
• The dial does not work if you rotate it fast, it only works if you do it step by step
• I have had wifi mishaps because of how it broad-spams the channels while screaming it's commands
• The low battery LED is basically impossible to see because of how quick a flash it is

The reason why FFC exists in the first place is that, for battery purposes, the only way to make it reasonably fast without waiting for a wifi handshake is to, well, not use wifi. If only their solution was using Bluetooth instead of fucking around with WiFi.

If you want to make it a viable option, I'd say:

• Check if the unmarked chip is the cause of performance issues
• If it is, hotwire the encoder/switch to the WB3S
  • You may need to hotwire power to the WB3S, because I think that secondary chip turns it off when unused.
  • WiFi is an option here, but be careful about power consumption
• If not, don't bother bypassing it
  • Ditch WiFi, use BLE
• Use a localized control center like HomeAssistant that receives the commands

I do want to repeat that you probably shouldn't bother with direct device communications, they're too rare to be useful (I literally only ever found ONE device out of all tuya devices I bought that works with it), and prone to sleeping/interference, a dedicated control center is not.

[fearek]

I was thinking about making this switch connect via bluetooth to some device like rpi and there be controlled via home assistant but I dont know why is it so slow to respond, it needs many clicks sometimes to respond like mentioned before any big brain able to make this mod? or even design a new pcb that will fit there and reuse as many components inside as possible

[miyoyo]

It's slow because it needs to boot everytime you press the button, the little chip next to the WiFi controller acts as a power switch.

You'd need to rewire the pcb to keep it on all the time.

[fearek]

It's slow because it needs to boot everytime you press the button, the little chip next to the WiFi controller acts as a power switch.

You'd need to rewire the pcb to keep it on all the time.

how bad would it be in power usage if we kept the chip running on BLE?

[miyoyo]

Can't say exactly, however, I assume not that good if the chip was on 24/7, as even as it is now, the battery lasts about 4 months for me.

However, BLE does not require a permanent link, you can just configure ble once, and send packets whenever, going into deep sleep between uses. This is how most BLE remotes are able to function for months to years on coin cell batteries.

I would say maybe 1 to 2 months total?

[fearek]

well then what would be stopping us from writing new firmware for it to use BLE and keep the chip sleeping in new firmware I mean drop all tuya stuff and just send the raw stuff like rotations and clicks to home assistant or something

[EpicLPer]

well then what would be stopping us from writing new firmware for it to use BLE and keep the chip sleeping in new firmware I mean drop all tuya stuff and just send the raw stuff like rotations and clicks to home assistant or something

This would sadly still require a hardware hack to connect the rotary encoder directly to the "brains". So far the rotary encoder is connected to a second chip, when you rotate it that tiny chip wakes up the "big brother" and sends its data via serial to the big one. This way the small chip can stay powered on 24/7 and use virtually no power, while waking up the big one to send data.

However the small one is, from reports here and other sources I read, very unreliable and drops a lot of rotary inputs at times for no reason. So it wouldn't be reliable at all... hence the mod to connect it directly somehow and detect when a rotation happens, then wake the big chip up.