[BK7231N/CB2S ] Andeli 2 Gang Smart Switch with RF: TuyaMCU configuration, baud rate

Name: [BK7231N/CB2S ] Andeli 2 Gang Smart Switch with RF: TuyaMCU configuration, baud rate
Uploaded: 2023-05-21T12:49:39+02:00
Description: Hello, I flashed this 2 gang smart switch, got wifi connection and opened webapp page. I expected getting the GPIO configuration from the Tuya firmware, unfortunately I got the message that getting GPIO was not possible as firmware was either custom or TuyaMCU. So it turned out to be more...

Question

Hello, I flashed this 2 gang smart switch, got wifi connection and opened webapp page. I expected getting the GPIO configuration from the Tuya firmware, unfortunately I got the message that getting GPIO was not possible as firmware was either custom or TuyaMCU. So it turned out to be more...

p.kaczmarek2 · Accepted Answer

Hello, first of all, remember, you can always try this method to get GPIO settings on any non-TuyaMCU devices:

cadseubi wrote:

The device still works even without any configuration (pushing buttons actuates the relays). The switch can be actuated with a remote and even that is still working, I paired and actuated it with the RF remote control.

This means it's TuyaMCU

Your config seems good but maybe you need to set baud? Here's modified version:


startDriver TuyaMCU
tuyaMcu_setBaudRate 115200

setChannelType 1 toggle
setChannelType 2 toggle
setChannelType 16 toggle

setChannelType 7 TextField
setChannelType 8 TextField
setChannelType 14 TextField

linkTuyaMCUOutputToChannel 1 1 1
linkTuyaMCUOutputToChannel 2 1 2

linkTuyaMCUOutputToChannel 7 2 7
linkTuyaMCUOutputToChannel 8 2 8

linkTuyaMCUOutputToChannel 14 2 14
linkTuyaMCUOutputToChannel 16 1 16

See more examples at:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md

cadseubi wrote:
I applied it but didn't work, so I deleted it and rebooted. But now I still have six buttons on the app that haven't gone away (why?).

This is because channel types stay in memory, you can see them in Web App:

You can set them back to none

cadseubi wrote:

How can I know if mine is a TuyaMCU device?

Create a simple autoexec.bat, first with default baud, and check if it works (try to control single relay), then if it's not working, try high speed baud and check again. You can also look for log messages in OBK Web App Log to know if TuyaMCU responds to Heartbeat ping.
You could also use TuyaMCU analyzer (without flashing obk) if you know how to capture UART packets in a safe way:
https://www.elektroda.com/rtvforum/topic3970199.html#20528459

cadseubi wrote:

I see that some people are able to get information as "TuyaMCU: T1616-N TH 2720E (ATTINY1616)" How can they get it?

For me it just looks like they have read the marking from the PCB and/or from the chip.

cadseubi wrote:

I see that there are also other drivers. I wonder if you could give me some direction on how to proceed. Thanks in advance.
I am attaching some pictures and files, got from Tuya iot or created by myself.

I can help you step by step, if you have other devices, just create separate topics for them. Also, when we will finish working on your current device, I will add this topic link to our template list: https://openbekeniot.github.io/webapp/devicesList.html so if you have some further information on your device (where was it bought? maybe model name?) please add it in the next post

cadseubi wrote:

I connected to wifi and MQTT but I could not connect to homeassitant, I guess because the device is not configured

In the past the HASS discovery was not working for TuyaMCU, but for now, it should work as long as you set something like:


setChannelType 1 Toggle

This should be enough to get channel to show up in HA via Discovery. Of course, you first must set type to Toggle (via script or WebApp), then do Home Assistant Discovery:

Added after 1 [hours] 59 [minutes]:

Btw, I just tested (and described) TuyaMCU Dimmer (Toggle channel + Dimmer channel )discovery test here:
https://www.elektroda.com/rtvforum/topic3898502-30.html#20588750
It seems to work correctly, so everything should be ok.

p.kaczmarek2 · Accepted Answer

Your autoexec.bat looks suprisingly good. I would say you had it well done, but okay, let's do it different way.
1. set that autoexec.bat:


startDriver TuyaMCU

2. reboot
3. open Web App -> Logs
4. press buttons on switch, so relay changes, look at the log and copy it here - are there any TuyaMCU packets received?
5. If not, then modify autoexec.bat:


startDriver TuyaMCU
tuyaMcu_setBaudRate 115200

6. save, reboot
7. press buttons on switch, so relay changes, look at the log and copy it here - are there any TuyaMCU packets received?

In 99% cases, you should get TuyaMCU logs in one of the two combinations I said (default baud or high speed 115200).

cadseubi wrote:

Also, after flashing the wifi light on the device has always been blinking. I thought it was not important to report

This is the WiFi state indicator. It's showing that TuyaMCU <-> Wifi Configuration is not ready. OpenBeken can set it to "configured" state, once you got communication working. By default, OpenBeken will only report "configured" state to TuyaMCU when it has MQTT connection, but you can override it by adding this line to autoexec.bat:


tuyaMcu_defWiFiState 4

More information here: https://www.elektroda.com/rtvforum/topic3963972.html#20483899

Added after 9 [minutes]:

You can also do that operation:

and post here binary file, I can try extracting baud rate settings from that.
Here is example:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

p.kaczmarek2 · Accepted Answer

The MCU that controls everything is marked U1 on your board. Buttons, relays and LEDs are connected to U1. I can see a marking on your photo, but it is too blurry to read it.

TuyaMCU is a communication protocol used to exchange data between WiFi module and that MCU via UART.

cadseubi wrote:
Power, ground,

They are most likely working, as firmware runs.

cadseubi wrote:
RX and TX must be working for sure

It actually looks like they are not working, because you got no TuyaMCU communication at 9600 baud. You don't even receive a heartbeat, not at 9600 and neither at 115200.

Please take a look at this topic:
https://www.elektroda.com/rtvforum/topic3971440.html
That user also had a light switch with TuyaMCU protocol. He just used that autoexec.bat:


startDriver TuyaMCU

and that was enough for him to get TuyaMCU logs in Web App Log, when pressing buttons.
That topic may be hard to follow because he has edited first post after my autoexec.bat request but you should get the main idea that it is working....

If it's still not working for you, we can try debug the issue with soldering USB to UART converter to the first TX<->RX and then RX<->Tx lanes on the PCB and try to capture the packets - check if OpenBeken is sending something and is that something really reaching TuyaMCU.

You can also try checking with multimeter (but with soldered CB2S it would be hard?), are the TX/RX pads going to the MCU on the board, and to which pins?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

cadseubi · Answer

Thank you very much for your speed-light reply!!
Made the change, it still doesn't work
I am also able of making OTA updates, don't know why I cant get at least switch buttons or backlight working
The only maybe meaningful message that I was able to get up to now is:
"ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0"
Also, after flashing the wifi light on the device has always been blinking. I thought it was not important to report
I wrote the autoexec blindly, without any knowledge. maybe I should put into it something more than Tuya dpids only? I have to investigate and learn more to get a better understanding of what I am doing. Thank you also for all the links that you have sent to me yesterday.

Edit - There is also a message of "boot incompletes 1" in the app page. Also I see that some people uses "bool" or "var" as data types instead of numbers, but I have not been able of cross-referencing/find the list of data types

cadseubi · Answer

Changing the baudrate didn't help.
The only message from Tuya is this one:
"ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0"
Am I correct in thinking that this could mean invalid heartbeat, invalid product information, self processing the device without connection, invalid wifi_state? TuyaMCU does not respond to Heartbeat ping? (by the way, where is Heartbeat ping coming from?)
No messages when I toggle the switches.
I also see a message of "boot incompletes 1" in the app page, but I don't know if it is meaningful. Log messages at startup seem Ok, TuyaMCU driver is activated
I made the extraction of the GPIO/template but EasyGuiFlasher could not decode it (same as already happened while flashing). I am attaching the file. I looked at the content but I could not get anything.
Just to check if I got it right, into the command "linkTuyaMCUOutputToChannel x y z" x is the dpid, y is the variable type (1=bool, 2=val, 3=???, 4=enum, 5=....???) and z is some channel of our choice, an arbitrary number in the range 1-32 ?

p.kaczmarek2 · Answer

The file you have attached indicates 9600 baud usage:

which is the default baud value of TuyaMCU:

linkTuyaMCUOutputToChannel doc can be found here: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

This line:


heartbeat_valid = 0,

should show 1 for correct config.

Incomplete boots can be ignored, it just means that you did a quick power off/on of the device. Five quick power on/offs of the device will enable AP/Safe mode.

How did you flash device? Didn't you sever the connection between TuyaMCU and WiFI module? Did you fix back the traces after detaching TuyaMCU temporarily?

Can you post a photo of your PCB?

cadseubi · Answer

I just desoldered the CB2S module with hot air, flashed and soldered it again. It is easily done, there are six big pads only. Power, ground, RX and TX must be working for sure, otherwise I couldn't have got access to app, connected to web, to MQTT etc.

Edit I also flashed OTA several times
TuyaMCU is only a protocol coded into the CB2S module, it is not a separate device, am I wrong?

cadseubi · Answer

TuyaMCU is Holtek BS86D12C. There is TX/RX continuity on pins 22-23. When I send TuyaMCU commands from the web console, I get confirmation; apparently messages are sent, but not answered. I wonder, maybe we should also sniff untampered Tuya firmware and see what it is sending as first messages, if Tuya made changes. Or maybe I am making some trivial error somewhere, so big and so near to me that I cannot see. Or maybe you are right, it is the new firmware not sending or not correctly receiving, for some reason. But now I have a lot to read, you sent me a huge amount of information.

p.kaczmarek2 · Answer

You can restore CB2S firmware backup (if you have one) or use another switch to do packet capture. Just power it from 3.3V (or 5V through AMS1117 3.3V LDO) and starts packet capture in RealTerm, start pressing buttons, etc. You can then also view and decode TuyaMCU packets in our TuyaMCUAnalyzer:
https://www.elektroda.com/rtvforum/topic3970199.html#20528459

cadseubi · Answer

Hi,Sorry for being so late, I have been busy with other things.You were right, it was just a soldering problem. Now it works fine.I saw that only the boolean channels are published by MQTT HA discovery. I can ignore the HA discovery and create all the devices with a script in HA (see attached script, tested and working on my HA instance). However, there are some issues with this approach, such as the fact that changes in device data are not automatically corrected in HA (sw version for instance, but also IP, device id...). Is there a way for us to access and write our own MQTT config data directly inside the devices, something as a script file, so that we can customize the HA discovery?I have more than thirty of these switches to flash and also other issues to address, so I will go ahead slowly. However, if you agree, at the end I may try to put all orderly together in a summary with photos, links etc (as I have seen others doing that).

p.kaczmarek2 · Answer

You are correct, only the switches (boolean) channels from your TuyaMCU device are currently handled in Home Assistant Discovery:


{
  "result": {
    "category": "kg",
    "functions": [
      {
        "code": "switch_1",
        "dp_id": 1,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "switch_2",
        "dp_id": 2,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "countdown_1",
        "dp_id": 7,
        "type": "Integer",
        "values": "{\"unit\":\"s\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "countdown_2",
        "dp_id": 8,
        "type": "Integer",
        "values": "{\"unit\":\"s\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "relay_status",
        "dp_id": 14,
        "type": "Enum",
        "values": "{\"range\":[\"power_on\",\"power_off\",\"last\"]}"
      },
      {
        "code": "switch_backlight",
        "dp_id": 16,
        "type": "Boolean",
        "values": "{}"
      }
    ],
    "status": [
      {
        "code": "switch_1",
        "dp_id": 1,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "switch_2",
        "dp_id": 2,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "countdown_1",
        "dp_id": 7,
        "type": "Integer",
        "values": "{\"unit\":\"s\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "countdown_2",
        "dp_id": 8,
        "type": "Integer",
        "values": "{\"unit\":\"s\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "relay_status",
        "dp_id": 14,
        "type": "Enum",
        "values": "{\"range\":[\"power_on\",\"power_off\",\"last\"]}"
      },
      {
        "code": "switch_backlight",
        "dp_id": 16,
        "type": "Boolean",
        "values": "{}"
      }
    ]
  },
  "success": true,
  "t": 1684579900243,
  "tid": "4cfb670ff6fc11edb8e6f637b158923e"
}

but I am not sure, what else would you like to be supported there? Do you need Tuya countdowns in Home Assistant? Can you elaborate, because I am not sure what are you trying to do.

I can try to add Discovery support for the channel type you are missing.

A detailed writeup about that switches would be great!

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

cadseubi · Answer

Well, I am OK with what is already available.
I was just thinking that maybe you would consider adding to the autoexec.bat another file, something as an "mqtt.cfg" file that users might fill with their own data.
On one side, you cannot provide support for the thousands of different devices that are coming ang going on the market.
On the other side, Home Assistant has several MQTT platforms and new ones are going to be added over time, so supporting all of them would be time consuming and of little interest to you (MQTT platforms mainly handle how data are formatted and processed by HA).
The idea is that we as users could take care of that - we could fill the mqtt.cfg file located by you inside the device and get full control on HA MQTT configuration. Data such as device ID, IP, SW version would not be provided by users but made available by the firmware as variables, so that changes/updates of the device would be automatically made available to HA discovery. But all other data would be filled by the users, as it is already happening for the autoexec.bat file
Just an idea.

I flashed several of my ANDELI switches without desoldering them, soldering only the four hairwires to the PCB without making any change on the PCBs and it worked, until...
I just flashed the last one several times this morning. Flashing successfull, CRC matches 0xBF21E437! , but ... This time no hotspot!!!
I am doubtful about desoldering the CB2S - it is time-consuming and there is the risk that it would not solve the issue (CRC is matched, so what else? Shouldn't the problem be somewhere else?) Would it help/be risky to try Restore RF part or Erase all?
Many thanks again for your help and advice

EDIT - issue solved. I am doing all configuration when the PCB is still connected to the hair wires. Hotspot appears when I disconnect RX/TX wires.

EDIT 2 - Canceled

cadseubi · Answer

Hi,The countdown timers of my switches are no longer working with software releases higher than 1.17.161!!!Until now, the value entered in the textbox triggered the switch after the corresponding number of seconds.Now, with releases higher than 161, when I enter a value in the textbox, the countdown doesn't start anymore and it returns 16777216 for 1, 33554432 for 2, 50331648 for 3...Have you changed data types or formatting in the textbox?Here is an example of an autoexec file that works with 1.17.161 but not with 1.17.162. Should I change something?startDriver TuyaMCU// let channel 1 & 2 be dpid1 & dpid2 - switch 1 & 2 on/off - BooleansetChannelType 1 togglesetChannelType 2 toggle// let channel 16 be dpid16 - backlight - BooleansetChannelType 16 toggle// let channel 7 & 8 be dpid7 & dpid8 - timer 7 & 8 - can be 0 to 86400 sec - IntegersetChannelType 7 TextFieldsetChannelType 8 TextField// let channel 14 be dpid14 - on-off-memory - Enum setChannelType 14 TextFieldlinkTuyaMCUOutputToChannel 1 bool 1linkTuyaMCUOutputToChannel 2 bool 2linkTuyaMCUOutputToChannel 16 bool 16linkTuyaMCUOutputToChannel 7 val 7linkTuyaMCUOutputToChannel 8 val 8linkTuyaMCUOutputToChannel 14 enum 14

p.kaczmarek2 · Answer

Thank you for reporting. There must have been an error slipped in this commit: I will investigate and push a fix. Added after 1 [minutes]:Huh, I think I know what may have happened. Added after 25 [minutes]:@cadseubi can you check please this build?

[BK7231N/CB2S ] Andeli 2 Gang Smart Switch with RF: TuyaMCU configuration, baud rate

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Topic summary