OpenBK7231T_App
OpenBK7231T_App copied to clipboard
openshwprojects
LSC Smart Dimmer Switch
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
Hey, I'll look into it right now.
From what I see...
the 00 03 and 00 05 are the byte lengths of data of 0x02 packet, but I am not sure what the data is yet.
You have a batter powered device. It should follow this protocol: https://developer.tuya.com/en/docs/iot/tuyacloudlowpoweruniversalserialaccessprotocol?id=K95afs9h4tjjh but the examples linked above seem to use 0x00 version while your has ver 01.... Another great guide is here: https://images.tuyacn.com/smart/aircondition/Guide-to-Interworking-with-the-Tuya-MCU.pdf
Hmmm are those the only UART commands you get?
I think that even if we don't know the meaning behind the bytes, I could just add a possibility to script a callback for given UART input string....
To answer your question: the 00 00 00 00 000 00 etc etc spam means that MCU just went asleep, it's not a packet, it's a noise.
Regarding other questions... first of all, do I see correctly, the battery and MCU has capability to turn off the wifi module entirely?
Protocol description: https://tasmota.github.io/docs/TuyaMCU/#dpid https://developer.tuya.com/en/docs/iot/mcu-protocol?id=K9hrdpyujeotg dpID must be identified and assigned to function. MCU CONF should list all available DPs.
@valeklubomir the linked example has ver 00 and 03 and the user posted data with ver = 01
I need to get the meaning of those ebytes:
Do you happen to know them, or are you saying that those are DPids or DP roles? The FF, for example?
Not sure right now. I will also add an ability to fire events when a given UART hex string is received, as a flexible work around, at least temporary.
Protocol version 2 is just another version, but structure can identified. dpID: FF seems to by type bool and would represent two transitions PRESSED and RELEASSED. since it was sent from button action dpID: 01 has 2 unknown types 09 and 24. In case of rotary switch: 24 could be direction, 09 step count since last message. Or vice versa.
This would require much more data to processas
I have implemented flowchart behavior from protocol and it will report all features. And it sends command 0x08. Query working status of the MCU. I think there is also command "tuyaMcu_sendQueryState" device should then report current state of all DP. There will be also LEDs. One LED is probably controlled by wifi state, there fore not as DP
Also strange version of TuyaMCU, are really events are processed as MCU CONF? I would presume 0x06 state message.
Thanks to both of you for all these informations :)
@openshwprojects:
Having the ability to fire events depending of UART hex strings received could be great!
About the battery, yes the MCU can turn off the power (VCC) of the WiFi module. It cuts it after ~5 seconds. I suppose there is a command to send to the MCU to keep the power on? I haven't found any information in Tuya documentation about this.
@valeklubomir:
Pressing and releasing sends only one information. When I press one time I have "FF 01 00". The second time "FF 01 01". The third time it is back to "FF 01 00". etc...
About the up/down, it doesn't seem to count. When I go up for example, I only have these 2 packets "01 24 01 01 0A" and "01 09 01". Going up again sends the same data again.
For reference, here is the PCB:
@openshwprojects Button: looks like toggle function. Rotary: Have you tried quick rotate? I presume some kind of logic when rotary is moved more the one tick between UART packets. Some kind of buffered changes........
I am sorry, Since I do not have device I can help only with suggestions
@Bacto , since you seem to have some good quality photos, can you post a teardown article here (info where to buy, how to flash): https://www.elektroda.com/rtvforum/forum507.html , maybe also include the captured packets data, etc, for the sake of reference so we can latest add it to our online devices database: https://openbekeniot.github.io/webapp/examples/devicesListDemo2.html Thanks in advance.
The UART handler was added to code in last commit, but not tested yet. Here is an example: https://github.com/openshwprojects/OpenBK7231T_App/commit/b0f4015bbe5daa18bee9c68401ea0b93b547de20
Regarding the power on question.... it kinda looks like it might be related for what I did for Door sensors: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_tuyaMCUSensor.c the code in this file sends a data to MCU to let the MCU know that we asks for door state and wants to keep alive the device for some time
yea, same, I don't have the device at hand to check well
@valeklubomir I have to check about quick rotation. I'll let you know.
@openshwprojects teardown article posted :) https://www.elektroda.com/rtvforum/viewtopic.php?p=20239100#20239100
Thanks for the code examples. I'll have a look at them!
@valeklubomir & @openshwprojects , I can send you a device if you're in a country where it can be send easily (I'm in France). Would you be interested and if so, in which country are you?
@Bacto I'm in Poland, not that far away. But it would be also nice if you had an original firmware backup so we can sniff the communication from Tuya. It could help a bit. But maybe that's not needed, and we can just set the triggers based on UART content instead of parsing the UART data. By the way, it's the first time I see a WiFi and battery powered dimmer.
But maybe first we could try doing support for that remotely. WB3S is powered only for 5 seconds after turning the knob? Maybe WB3S has to send something to TuyaMCU in order to make TuyaMCU keep it alive a bit longer, so it can at least report values to the cloud (or to HA in our case)...
Have you tried "startDriver tmSensor" in startup command (along with startDriver TuyaMCU)?
I'll probably not have the time for the next 2 weeks to work on it but ASAP I'll try the command "startDriver tmSensor". During this 2 weeks I'll probably go to Action to buy a new one, with the original firmware.
If you're interested I'll send it to you :) Let me know if you are also interested by other LSC products I can find at Action France: https://www.action.com/fr-fr/search/?q=lsc+smart
@Bacto I'm in Slovakia. Found an Action shop in Austria(Kitsee). if I have trip to Bratislava I can make side jump and check. Also I have ordered multiple devices from aliexpress, a lot of hacking to do. At moment I have 4x BK7231N devices to test on and 2x ESP8266 to hack.
But I would still like to see some UART communication.
@valeklubomir I've been doing some research on the similiar Battery Powered Device, but it followed the protocol (version 0) from Tuya docs, it was not a ver 1 like here. Still, I documented it here: https://www.elektroda.com/rtvforum/topic3914412.html
@Bacto i could send you my address on Elektroda PM, but first I'd need to check the Action store in Poland. Shipping cost may be higher than the device cost and there is a chance we also have that one, I don't know.
@valeklubomir welcome to the club, I am ordering new devices all the time to just do the hacking and teardown, and our little list grows: https://openbekeniot.github.io/webapp/examples/devicesListDemo2.html (the list is still not a public version, it's a WIP)
Got some new dimmer switch! I haven't checked the price to send them but if it is reasonable I'll send it to you :) You can send me your postal address on Elektroda if you're still interested.
I have one of these units, and I'm fairly good with this stuff. Any short description of what you need from a stock unit? I have the required tools. @valeklubomir
I managed to get one device also. Continuing with BK7231T device and I will work on it next days.
Okay. Let me know if you need anything from my device. I'll hook mine up to the logic analyzer with the RX/TX 0 & 1 pairs and the serial to the little SOIC chip and just have it capture some of the normal chatter/traffic on the stock firmware. The stock firmware seems to behave a bit odd too.
Unfortunately I made mistake, and without thinking overwriten stock firmware. I'll go and get new dimmer and keep the stock firmware.
No worries! I'll see if I can get the firmware tonight.
Anything special I need to take care of?
On Thu, 3 Nov 2022, 3:03 pm valeklubomir, @.***> wrote:
Unfortunately I made mistake, and without thinking overwriten stock firmware. I'll go and get new dimmer and keep the stock firmware.
— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1302162996, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6EJWN5QARIP5C42VB3WGPA3NANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>
If you could catch any communication between WB3S and IC with with stock firmware, could be helpfull. I will have new device at saturday.
I'm pretty sure the WB3S module's chip, tbe BK chip, has its memory built in?
I also bought one of these devices a couple of days ago and was happy to stumble upon this project and this issue.
Today I dumped and unpackaged the original firmware using uartprogram, if you still need it then please let me know the best way to share the files (original, packaged file is ~1.1MB).
I have also captured some communication between the WB3S and the IC with the stock firmware using PulseView, though I would need to redo them to be able to separate the different actions. I'll try to get some clean captures tomorrow.
Finally I got to do some measurements from LSC Dimmer Switch. I got also new bulb. I paired bulb with LSC SmartApp and then paired dimmer with bulb. Running stock firmware.
- Special IC on the board handles rotary switch and push button. Is connectd to WB3S only by RX1,TX1. Communication with WB3S module is via modified TuyaMCU protocol. It is pretty stripped protocol to minimum commands.
- Button works in toggle principle and sends binary value to WB3S. Paired LED bulb reacts on real value stored in the Special IC. When for example bulb is switched OFF with dimmer and swithed ON by phone application then you need press button twice to switch bulb OFF.
- Rotary switch sends out increments with each movement. In case of quick rotation, a.k.a. multiple increments, these are sent out one by one. Special IC does not sends out block movements in single packet. Each increment is transmitted to bulb. As packets are received by bulb, bulb changes brightness in steps with some delay per step. Steps are the visible. Increment contains also direction bit, but sometimes steps seem to mess little bit, it looked like for split of second brigthness dimming changes direction.
- 2 Extra commands are sent out by Special IC during request for pairing, executed by long pres of 5 secs.
- Some of the received packets are confirmed by MCU. Button togple and rotary increment events.
- When pressing button or rotating switch Special IC switches 3.3V power ON for WB3S and holds it for short period of time. Est. 8-10 sec. During this time WB3S needs to connect to bulb and transmit command. Stock firmware has pretty fast reaction. 100-300 ms.
- Protocol will not be full WiFi. Some kind of proprietary protocol transparent on wifi channels. Received directly by paired bulb. Or may be bluetooth, I do not know if BK7231T can maintain Wifi and Bluetooth communication at same time.
Things to setup when usign OpenBK:
- Firmware must connect to Wifi and MQTT very quickly.
- May be modification of circuit to enable WB3S hold power supply longer, would be neccessary, I am not sure if Special IC support any command to hold power ON longer.
Wow. This dimmer is really quite shit haha. It seems useful to me, to modify this dimmer to handle the rotary button as itself. The only benefit of the current way is power efficiency. That would be sacrificed. 😅
On Sat, 5 Nov 2022, 9:56 pm valeklubomir, @.***> wrote:
@fust https://github.com/fust Can you share original firmware?
— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1304640115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6A2GJRCANTJQDWYR73WG3CXTANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>
I've uploaded all files I mentioned in my previous comment to a Github repo. Unfortunately I don't have any other LSC devices to capture some logs while it is paired, might get an LED lightbulb so I can check out what's going on.
Wow. This dimmer is really quite shit haha. It seems useful to me, to modify this dimmer to handle the rotary button as itself. The only benefit of the current way is power efficiency. That would be sacrificed. 😅 … On Sat, 5 Nov 2022, 9:56 pm valeklubomir, @.> wrote: @fust https://github.com/fust Can you share original firmware? — Reply to this email directly, view it on GitHub <#291 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6A2GJRCANTJQDWYR73WG3CXTANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.>
If we need to do hardware modifications to make this thing work I'd go the route @valeklubomir suggested but with some changes:
- Cut the trace going from Q2 (MOSFET used to switch the WB3S on/off) to the WB3S, power the WB3S directly from 3.3V.
- Solder a wire from the output of Q2 to a GPIO on the WB3S and use it as a trigger to enter/exit low-power mode.
This does of course come at the cost of some power efficiency but less than just powering the module all the time and comes with a couple of advantages:
- It's a very doable change for the majority of people as there are some pretty decent-sized pads which could be used.
- The module is always powered so it doesn't need to connect to WiFi/MQTT in a couple of milliseconds.
- The anonymous IC is still handling the rotary encoder so we only need to handle the UART packets it sends
I might be completely off on this though :)