I have ordered the last from Youmile with Sop8 Test Clip so i hopefully dont need burning my fingers and its being delivered on friday or monday (company delivering so not on weekend).

I think the Xiaomi GW is having one other WiFi chip then the Tuya is using (RTL8197EU) but if possible installing OpenWRT its no problem installing ser2net and using it as one "Zigbee2Net" device.

Im being in as root !!!

tuya-linux login: root
Password: 

Tuya Linux version 1.0
Jan  1 12:03:30 login[1004]: root login on 'console'
# 
ls
bin   etc   init  mnt   root  sys   tuya  var
dev   home  lib   proc  sbin  tmp   usr
# 
ls -la
drwxrwxr-x   14 1000     1000          186 Jun 20  2020 .
drwxrwxr-x   14 1000     1000          186 Jun 20  2020 ..
drwxrwxr-x    2 1000     1000         1117 Jun 20  2020 bin
drwxr-xr-x    4 root     0               0 Jan  1 00:00 dev
drwxrwxr-x    4 1000     1000          189 Jun 20  2020 etc
drwxrwxr-x    2 1000     1000           33 Jun 20  2020 home
lrwxrwxrwx    1 1000     1000            8 Jun 20  2020 init -> bin/init
drwxrwxr-x    2 1000     1000          997 Jun 20  2020 lib
drwxrwxr-x    2 1000     1000            3 Jun 20  2020 mnt
dr-xr-xr-x   66 root     0               0 Jan  1 00:00 proc
lrwxrwxrwx    1 1000     1000            9 Jun 20  2020 root -> /var/root
drwxrwxr-x    2 1000     1000            3 Jun 20  2020 sbin
dr-xr-xr-x   11 root     0               0 Jan  1 00:00 sys
lrwxrwxrwx    1 1000     1000            8 Jun 20  2020 tmp -> /var/tmp
drwxr-xr-x    7 root     0               0 Jan  1 00:00 tuya
drwxrwxr-x    3 1000     1000           26 Jun 20  2020 usr
drwxr-xr-x   10 root     0               0 Jan  1 00:00 var
#

In Win 10 install python 3.9 in from windows store.
Open one power-shell and install pycryptodome.
python.exe -m pip install pycryptodome

Cutting the spaces from the 3 strings you have getting from readings in the boot loader.
Run the python script and you is getting you beloved password.

Open your terminal to the tasmota ZB.
Hit enter in your terminal and write root and enter and the your new password and enter.

Attached the Python script with extension txt (take the .txt away and you is getting the .py :

TUYAZBGWROOTPW.PY.TxT

Hitt ESC then booting and you is landing in the boot loader:

Booting...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
@ chip__no chip__id mfr___id dev___id cap___id size_sft dev_size chipSize
@ 0000000h 0c84018h 00000c8h 0000040h 0000018h 0000000h 0000018h 1000000h
@ blk_size blk__cnt sec_size sec__cnt pageSize page_cnt chip_clk chipName
@ 0010000h 0000100h 0001000h 0001000h 0000100h 0000010h 000004eh GD25Q128
@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
DDR1:32MB

---RealTek(RTL8196E)at 2020.06.20-10:26+0800 v3.4T-pre2 [16bit](400MHz)
P0phymode=01, embedded phy
check_image_header  return_addr:05010000 bank_offset:00000000
no sys signature at 00010000!

---Escape booting by user
P0phymode=01, embedded phy

Then by the instruction:

---Ethernet init Okay!
<RealTek>
<RealTek>FLR 80000000 401802 16
Flash read from 00401802 to 80000000 with 00000016 bytes        ?
(Y)es , (N)o ? --> y
Flash Read Successed!
<RealTek>dw 80000000 4
80000000:       11111111        22222222        33333333        44444444
<RealTek>FLR 80000000 402002 32
Flash read from 00402002 to 80000000 with 00000032 bytes        ?
(Y)es , (N)o ? --> y
Flash Read Successed!
<RealTek>dw 80000000 8
80000000:       55555555        66666666        77777777        88888888
80000010:       99999999        AAAAAAAA        BBBBBBBB        CCCCCCCC
<RealTek>   

(With faced strings)

Now cutting the spaces from the 3 strings you have getting from readings in the boot loader:

KEK hex string: 11111111222222223333333344444444

aus-key string line 1: 55555555666666667777777788888888

aus-key string line 2: 99999999AAAAAAAABBBBBBBBCCCCCCCC

Open your power shell and run the python script TUYAZBGWROOTPW.PY and you is getting you beloved password.

PS C:\msys32\home\Mattias> python.exe .\TUYAZBGWROOTPW.PY
Enter KEK hex string line>11111111222222223333333344444444
11111111222222223333333344444444
Encoded aus-key as hex string line 1>55555555666666667777777788888888
55555555666666667777777788888888
Encoded aus-key as hex string line 2>99999999AAAAAAAABBBBBBBBCCCCCCCC
99999999AAAAAAAABBBBBBBBCCCCCCCC
Auskey: b'010101010101010101010101FEDCBA98'
Root password: b'FEDCBA98'
PS C:\msys32\home\Mattias>

Your root password is: FEDCBA98.

Reboot the tuya ZBG and open one terminal.

Hitt enter.
Typing root and hit enter.
Prompt for password.
Typing FEDCBA98 and hit enter.

tuya-linux login: root
Password: 

Tuya Linux version 1.0
Jan  1 12:03:30 login[1004]: root login on 'console'
# 

Next to do is stopping the tuya services and making one socat service for tunneling the EFR32s comport to ZHA.

I think we have getting on better remote EZSP coordinator with Ethernet for ZHA then Sonoff Zigbee Bridge !!!

Now you have the root password you can putting it back in the network without serial cable.
Use your favorite SSH program on port 2333 and login as root with your "founded password".
use tail -f /tmp/tuya.log if you like to see wot your tuya ZBG is doing.

Interesting thing in the log:

[01-31 15:37:43:840 TUYA Debug][tuya_z3.c:21055] process monitor, g_tyz3Globals.permit:0.
[01-31 15:38:43:870 TUYA Debug][tuya_z3.c:21055] process monitor, g_tyz3Globals.permit:0.
[01-31 15:39:43:900 TUYA Debug][tuya_z3.c:21055] process monitor, g_tyz3Globals.permit:0.
[01-31 15:40:43:940 TUYA Debug][tuya_z3.c:21055] process monitor, g_tyz3Globals.permit:0.
[01-31 15:41:43:970 TUYA Debug][tuya_z3.c:21055] process monitor, g_tyz3Globals.permit:0.

Its must being one reason way tuya is sending permit 0 to the NCP every minute !!!

@xromansx I have dumped MTD 0 - 4 with:

dd if=/dev/mtd0 of=/tmp/dmtd0.bin

And uploading it to my PC with tftpd64 as TFTP server with:

tftp -l /tmp/dmtd0.bin  -r dmtd0.bin -p 192.168.2.10

Its one busybox so its having little limited parameters but i can reading the bootloader but its not saying so much. The linux have decompressing kernel: done decompressing kernel. start address: after the kernel section so its looks being OK.

I have uploaded the boot loader it im my private git and you can downloading if you like (I have sending you one inviting to it).

can I get a link to this? I accidentally lost the bootloader on my device. maybe you have a full-dump SPI flash? I do not plan to use the device with Tuya cloud, I am trying to configure it to work in homeassistant.

You might find the sequence here more readable:

https://github.com/walthowd/husbzb-firmware/blob/2802a527eef0a060875e9f12092e1e005587c323/ncp.py#L284

Look at the init function for your EZSP level to reset the stack, then on to init bootloader with 0x8F -- Or you can just add the line:

exit()

On line 292 of the above ncp.py and it will stop when the NCP is in bootloader mode.

I don't know if this will be useful to you, but I looked through the scripts on the device briefly, and the app_upgrade.sh script runs a tool that updates the NCP using a .ota file like this:

if [ -f "/tmp/ota-files/NcpUpgrade.ota" ];then
    /tuya/tuya_user1/debugtool -n
else
    echo "no ncp file"
fi

I think by running debugtool -n, it upgrades the NCP with the .ota file /tmp/ota-files/NcpUpgrade.ota.
Maybe you can upgrade EZSP this way?

Sound like on likely working way. Only downloading the GLB and renaming it and before starting the script killing the socat server so it not interfering with the communication to the module.
I trying it tomorrow after finding one test GLB that is working (but perhaps not 100% OK) so i dont need flashing back my backup i have made.
Its still not known if tuya have securing the firmware form being loaded or not (signed and / or encrypted).

And one large thanks for the hint !!!

Parses and validates fine for me. Didn't need any correction to parse either:

$ ipython
In [1]: import pathlib

In [2]: from zigpy.ota.image import parse_ota_image

In [3]: from zigpy.ota.validators import validate_ota_image

In [4]: data = pathlib.Path('~/Downloads/NcpUpgrade.ota').expanduser().read_bytes()

In [5]: image, rest = parse_ota_image(data)

In [6]: rest  # no trailing data
Out[6]: b''

In [7]: image.header
Out[7]: OTAImageHeader(upgrade_file_id=200208670, header_version=256, header_length=56, field_control=<FieldControl.0: 0>, manufacturer_id=1, image_type=1, file_version=65544, stack_version=2, header_string='TYZS4 115200 1.0.8  MFTEST', image_size=194230)

In [8]: validate_ota_image(image)  # it validates and the firmware is parsed properly
Out[8]: <ValidationResult.VALID: 1>

In [9]: image.serialize() == data  # no correction was applied, it serializes to the original file
Out[9]: True

In [10]: pathlib.Path('~/Downloads/NcpUpgrade.bin').expanduser().write_bytes(image.subelements[0].data)  # extract the actual firmware file
Out[10]: 194168

It's a GBL image:

$ git clone https://github.com/dac-gmbh/gbl
$ cd gbl
$ cargo run dump ~/Downloads/NcpUpgrade.bin
    Finished dev [unoptimized + debuginfo] target(s) in 0.37s
     Running `target/debug/gbl dump ~/Downloads/NcpUpgrade.bin`
Gbl {
    enc: NotEncrypted {
        app_info: AppInfo {
            type_: 1,
            version: 0,
            capabilities: 0,
            product_id: 00000000-0000-0000-0000-000000000000,
        },
        sections: [
            ProgramData {
                flash_addr: 16384,
                data: (172 bytes) [60, 4C, 00, 20, D1, D7, 00, 00, 91, BE, 00, 00, 95, BE, 00, 00, A7, 0A, 0A, 01, 00, 42, 00, 00, 04, 18, 0F, AC, 00, 65, BC, 00, ...],
            },
            ProgramData {
                flash_addr: 16896,
                data: (193908 bytes) [60, 4C, 00, 20, D1, D7, 00, 00, 91, BE, 00, 00, 95, BE, 00, 00, 9D, BE, 00, 00, 99, BE, 00, 00, A1, BE, 00, 00, CD, D7, 00, 00, ...],
            },
        ],
    },
    sig: NotSigned,
}

Thanks very much then then i can trying with one normal OTA file (GBL) and see if the module is accepting it.
The problems i have not funding any force bootlader pin so if its not communicating OK I must flashing it with SWD then cant sending reboot in bootloader mode.

One more time thanks !!

Not encrypted and only signed = JACKPOT !!!!!!!

Great thanks !!!

The problem with the original socat its blocking the Zigbee module for communicating then hardware pins is being in blocking mode and the original bottloader and NCP is have HW flow control.
Also connecting one USB-TTL serial is being blocking sending to the module with the original socat.

I trying it out if i can recovering my "bricking" with it after writing one request for new firmware and one new bootloader with SW :-)).

I keep you informed of the progress if its positive or negative !!

One Australian firmware request is sent from one Swed in Austria with help from Denmark :-)))

And now from docker CLI:

/config # bellows -d socket://192.168.2.60:8888 info
[58:8e:81:ff:fe:d5:92:9c]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=1e:0f:02:81:45:16:0b:80, panId=0xd337, radioTxPower=13, radioChannel=15, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=58:8e:81:ff:fe:d5:92:9c)]
Manufacturer:
Board name:
EmberZNet version: 6.7.8.0 build 373
/config #

And ZHA is saying:

2021-02-14 15:29:47 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer:
2021-02-14 15:29:47 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name:
2021-02-14 15:29:47 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

So My tuya ZBGW is not bricked only little degraded to software flow control !!

YIPPPPPY !!!

With new Gary EZSP i getting:

2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: 
2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: 
2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

Attached firmware if some one is brave :-))
Tuya_ZBGW_NCP678.ZIP

Credit for the firmware: our master firmware cooker Gary and the downloading to @Ordspilleren ! ! !

I was trying flashing back the NcpUpgrade.ota but the bootloader was not liking it but i should trying it one more time so knowing if its possible restoring the Zigbee module without activating the tuya app.
And also interesting wot is the tuya app doing then being activated after the "soft hack".
It can being god if its working normal so i cant doing update of my Revolt TRVs that i was getting in the "family pack".

Edit: Added both HW and SW version of the EZSP 6.7.8.0 in the zip file.

I agree with you @Ordspilleren the HW flow control its better then its already in the hardware design of the PCB and its have zero impact of the speed on the lines (that SW can doing some %).
Also is making the communication more stability on the board but on the other side of Socat is ZHA is only using SW flow control but its looks like Socat is manager it OK with HW on one side and SW on the other.

I was little of focus then going thru the hardware pin / pads / ports :-((

You have god eyes and brilliant brain have you finding some hint if tuya have implanting one force bottloader pin / pad / port to the module in the software and hardware ?

I have only finding the 4 comport lines and the "2 | FRC_DCLK | I/O | packet trace interface (PTI) | PB11" that looks going to the SOC but is not making any thing then resting the module.

Most bootloaaders is configurated without flow control then the NCP is using soft or hardware like the USB stick HUSBZB-1 that is using HW and 57k6 in the EZSP firmware and the normal shipped bootloader is without flow control.

As i was saying before the bootloader is not flashing on downloaded firmware if the CRC and header is OK so its only re transmitting the file if its being wrong and the xmodem is also doing checks so its very safe mechanism.

How is it initiating the network key update? Will it update the network key even if we only run serialgateway on the device?
Since we have root access, it should be quite simple to disable this behavior.

I think the spec is saying first sending the new key (broad or unicast) and waiting before sending "updating network key" that is doing the roiling and updating the network key cuter.

Lasse its the tuya app that is trying doing "its things" and its complete disabled then running the Socat.

For information 6.7.0.0 and newer EZSP is not backwards compatible then the frames format (ASH v8) is changed and cant "talking" the old (ASH v7) frame format (exception is the reset and initiating commands).

If the tuya ZBGW is roiling the network key its shall not being any problems going back to ZHA then all devices have (hopefully) getting the new one and its transparent to ZHA.

Great. So if you only run serialgateway, then the network key update will not take place.
My gateway is only being used for ZHA, so it won't be a problem for me at least.

The network key saved in the simulated NVRAM in the flash and its the application that is manager it so if not using the "tuya app" (= disabled then starting the Socat) its only ZHA that can doing it (and very likely loosing all Xiaomi devices) but the devs dont like implanting it then its getting to much problems with "some" devices.

I was thinking doing one zip or tar file with Socat, HW and SW and the new startup file and Xmodem and the EZSP firmware downloaded to the /tmp and then extracted in the right directorys and the right rights from the script. More or less one "all in one" package.

Great find! I have updated the script, and it now works without bellows.

Great !!
I must trying it out !!!

I was trying converting the dumped bin file from the "app" to one GBL file and i can downloading it but the module is rebooting to the bootloader = cant run the APP.

Was taking one look on Garys git and hi have adding one 6.5.1.0 and its working booting and enabling tuyas "APP". Its writing little things but is not complaining and i can steering my LIDL LED stripes = working.

I shall doing more testing with it and see that it can rebooting and adding and deleting device OK before saying its working 100%.

Perhaps i can catching the network key rolling (by "cating" the log but very unlikely not with on real sniffing).

By the way nice change in the updating script Lasse !!

Tuya dont like updating the NCP i think they is only comparing the mayor version of the NCP.

# ./debugtool

*********************************
Build time: May 15 2020 15:48:16
Support cmd:
    0:   get net info.
    1:   update zigbee coo.
    2:   plugin counters printf.
    3:   set tx radio power.
    4:   start RF test mode.
    5:   stop RF test.
    6:   install code.
    7:   create a specified zigbee network.
    8:   set max deveice cnt.
    q/Q: quit debug.
*********************************

******Input cmd:0
rev msg, type: 0x3003.
nodeEuiStr = 588e81fffed5929c.
nodeId = 0x0000.
panId = 0xd337.
channel = 0x0f.
ver = 3.9.3.
netStatus = 0x03.

Bad news for network key rolling is planed before the time is synced so its not being for some years.

So, with this archive, can I?

• upload EZSP 6.7.8 to my TYGWZ1
• update with debugtool
• still have tuya and everything working as before
• rollback to 6.5.0 if I encounter any issue

I don't want to remove tuya for now, just have a more recent FW version for unsupported devices...

If you like staying tuya cloud dont hack the ZBGW or only extract the root password !!
Supported devices is mots one thing in the application (tuya ZBGW and its cloud / ZHA / Z2M) but the zigbee module can help with communicating problems for tricky devices but with tuya cloud you cant use the updated firmware on the Zigbee module then tuya cant communicating with it (it have newer serial protocol v8).

I have 2 tuya ZBGW (one LIIDL and one no named) and both hacked and one restored with the EZSP 6.5.1 and its working OK with tuya cloud then i testing tuya devices if they have getting firmware updates.
It shall being possible doing firmware downgrade the same way as upgrade only using the parameters for protocol V8 for getting the module in bootloader mode.

If you is getting problem it can being you must using SWD probe flashing the firmware but i have not hearing users have needing it.

In fact here the manufacturer of the switch states that to get the power measures, you must have at least 6.7 FW on the gateway...
What's the most recent firmware using the V7 protocol?

EZSP 6.6.X if i remember right.
Its possible implanting V8 / V9 using framing for V7 but it must being done in the host system (tuya ZBGW firmware not the Zigbee module) like ZHA have done.

It can being that tuya have rolling out updates for some customers but they have not doing it on all devices (ZBGW) then i have not seen report of it and for Matter they is using one newer hardware version that is certificated for some weeks ago.

One Billy RCP as leader OTBR with one tuya / LIDL ZS3L module RCP as second OTBR and its having one LIDL E14 RGBWW light on the Zigbee network :-)))

The big Q is what shall i doing with the Thered network then i have not finding any devices and host system for it ???

I have Billy RCP up and running on one WeMis D1 Mini clone with ESPHome with serial server running on it and using the new implanted network attached RCP and its working OK.

I need testing if i can doing firmware updates of EZSP and RCP with software commands safely then i can cooking one RCP for tuya ZBGW with hardware flow control and testing aas is being done in Garys firmware we is using in our ZBGWs.

i tryed multple solutions but nothing seem to work. 3 different PC's en 3 different USB serial port adapters . I must be doing something wrong because i can not intercept the bootloader with the ESC key I use termite on windows 7 and windows 10 . Pressing ESC on the keyboard at different times intervals on the PC keyboard has no effect whatsoever. I am very frustrated and feel very stupid. I dont understand what i am doing wrong......

Your terminal can receiving from the ZBGW = very good !!
Let the box booting and hitting enter and you shall getting one login prompt and can writing root as user and enter and one password plus enter. If you is getting feed bacl all the way is the sending commands from your PC working OK.
If not working its some problems with sending (TX) lines.
Also you need have flow control disabled (= non in most program and not soft or hardware) or the terminal is waitinng for getting one ACK before sending anything and the bootloader is not making that..

I finally succeeded in stoping the boatloader. HOREE.... I now used a fdti233 chip usb controller and i took a Linux Mint machine and installed minicom. ESC aping was very easy now! That DID the TRICK!
Now i am stuck in decoding the root password
when i use [lidl_auskey_decode.py](https://github.com/banksy-git/lidl-gateway-freedom/blob/master/scripts/lidl_auskey_decode.py)
i get an error UnicodeDecodeError: 'ascii' codec can't decode byte 0x9b in position 0: ordinal not in range(128)

When i use TUYAZBGWROOTPW.PY i get
Auskey: b'\xd0\x0e\xb8\xa9\xcd\x8cj.\x84I\xbd\xccl\xaeo\xbd\xb7\x7f82j4\x08\xe3\t\x8c\xf5\xb4\xab\x18\x1c\xac'
Root password: b'\t\x8c\xf5\xb4\xab\x18\x1c\xac'

Can you help me please?

You printout looks little different then i was doing it but it was very early in the hacking process.
Look in my post #650 (reply in thread) but the updated script is looking little different but you shall getting the same readings (but different codes) that i was getting from the bootloader.

Great work dune brave user !!!

Is it possible for you to decode my KEK and AUSKEY ?. Is it oke if i send you my 3 lines of code? (may i have other python setting then you?)
Do i understand correctly that there is an updated script of "TUYAZBGWROOTPW.PY"

Thank you very much in your efforts to help me....

Sorry @mihsu81 i dont have interest doing it then the hardware is not made for that purposes.
If you like trying and have one SWD / J-Tag probe you can using the GSDK and compiling one.
https://github.com/SiliconLabs/gecko_sdk

Information of the module pins and so on you can finding on me git.
https://github.com/MattWestb/EFR32-FW/tree/main/TUYA_ZBGW

I can recommending IKEAs Signal Repeater is working OK if you like having one USB powered device that have being around for long time.
tuya Mini / micro repeater have one OK chip but very bad antenna so not working so good in the reality.

Normally its the best adding some good routers in the network for getting it extended (i using IKEA Power outlets as "back bone"for my production network) so all your end devices can connecting to them and not need for having them connected direct to the coordinator then its normally one very lazy router (its being one normal router but is doing the coordinator things that is higher priority).

Hoera! i retryed and this time a got different KEK en AUSKEY.
This time i used python 3 on Linux Mint and.........GOT the pasword !!!
Again i i lost now ....How do i proceed.....What do i need to do now?
Thanks!

Sorry was missing your lat post the doing dinner :-))
Great then you have getting one real password !!

Only reboot the ZBGW and hitting enter then have booting OK and you is getting on login prompt:

tuya-linux login: root
Password: 

Tuya Linux version 1.0
Jan  1 12:03:30 login[1004]: root login on 'console'
# 

put root as user and enter and the the password you have decode and you shall being inside the tuya Linux.
Then you can start looking around and making one backup of the system if you like.

Hi Matt,
I have been successful in walking through the Hack of the Silvercrest ZG. I think i was also succesfull in upgrading the EZSP Version to 6.7.8.0. But i am not sure. I have no way/script/command to test if these actions where al succesfull. Do you have any help to check/test?
Since i am using Openhab 3.2.0 ( on docker) i can not test the EZSP. I dont understand how to make a binding on OH and can not publish a serial port /dev/ttyzbbrige. I think i came very far, but can not implement the hacked ( properly done?) Zigbee gateway to my favorite system OH.

Im dont knowing OH so i cant guiding you with it.
If you is not having HA running you can installing it in one docker container its being easy testing and also reversing / deleting the test setup without braking your OH system.
In HA adding ZHA and putting in ezsp as radio type and socket://192.168.2.60:8888 (with your IP and port to your ZBGW) and 115200 as baudrate. If getting ZHA connected you is getting the version of the firmware in the log.
You can also open one command prompt in the HA container and using bellows with command info for getting information from the coordinator but its little more advanced.

Tribute to Matt!
I installed HA on a docker and after choosing EZSP en socket://gateway.ip:port
I got this !!!!!!
Device info
EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis
by ZHA
Zigbee info
IEEE: xx:xx:xx:xx:xx:xx:xx:xx
Nwk: 0x0000
Device Type: Coordinator
LQI: 255
RSSI: Unknown
Last Seen: 2022-05-13T16:21:42
Power Source: Mains
Quirk: bellows.zigbee.application.EZSPCoordinator

I am happy! Thanks to Matt for all his fantastic support !
Now i can get on in finding the way to integrate under OH. ( but I now kown i have a correctly hacked Lidl Silvercest Zigbee Gateway!
THANKS to Matt

THAT IS GREAT !!!

I like brave users that is doing advance things and getting more knowledge :-)))

If you looking in the HA -> Settings -> System -> Logs and clinking on load full log you can see all what was happening then HA was started and one line shall telling the version of the coordinator you is running like this:

2022-05-12 22:17:48 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: 
2022-05-12 22:17:48 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: 
2022-05-12 22:17:48 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

And the version of the EmberZNet must being 6.7.0.0 or higher for running other systems then ZHA then they have not implanting the old versions of the protocol but i think you is on 6.7.8.X so shall being OK for Z2M and other systems that is supporting EZSP coordinators.
The tuya ZBGW is original running EZSP 6.5.X.X and is working (but not good) with ZHA and not at all with Z2M and other systems.

And you can trying adding some device in ZHA and see how its working before "converting" all your nice device to OH ;-)

Hi Matt, how cam I use the MG21LD in HA?
Flash with programmer RCP
"Addnig one working rcp for the ZS3L.
Pinout is standard tuya so RX = PA06 and TX = PA05.
Use socket://192.168.2.64:9999 (with your HAS IP address) and 115200 baud in the addon."
How do I connect the MG21LD to HA, Via serial?

I got 4 of them, and since i use 2 controllers with 2 led stripes each, i got 2 left...
could i put them in my Lidl Gateway?
Thank for helping

I was getting 2 of them and using the LED stripes on one controller so one i have modded.
Pin out of the module you finding here https://developer.tuya.com/en/docs/iot/zs3l?id=K97r37j19f496.
You need 3V3,, GND, RX and TX for communicating with the host but put RTC. CTS and the debug / SWD plus reset t the same time then you can needing them but bootloader pin is nearly never used.
My used pin out you finding here https://github.com/MattWestb/EFR32-FW/tree/main/tuya_ZS3L#tuya-zs3l.
I was starting with flashing bootloasder and then EZSP / NCP for testing that communicating is OK then its easier testing the RCP.
Then having the com working with EZSP you can using https://github.com/NabuCasa/universal-silabs-flasher for flashing RCP / NCP and you can using it also with only bootloader so very good for testing.

Your settings for Silabs Addon looks OK only need adding the network port in the config (9999) so it starts the socat port OK. Before it was problems setting it up if ZHA was not having any working Zigbee network (time outs) but it shall being fixed not but i have not testing it. If timing out load EZSP and adding it in ZHA with normal comport and forming the network. Then take sown ZHA and changing the config (in the HA .config folder) to the addon and starting it and it shall working.

If you getting it working you can putting one in the LIDL ZBGW but i think the pinout is not the same but all can being patched with think cables soldered.

My controller is for the moment running Open Thread Full future device with CLI connected to the OTBRs network for testing the commissioning devices.

Ask more if you need help for getting it working !!

I have this stuff (Smart Wired Gateway Pro / THP10-Z-X)

Thanks for your hard work and my tygwz-01 works very well. I use " ./firmware_upgrade.sh [gateway_ip] 22 V7 NCP_UHW_MG1B232_678_PA0-PA1-PB11_PA5-PA4.gbl " to upgrade zigbee firmware where V7 is the ezsp version. I want to know if I want to upgrade to 6.10.30, Is there still be V7 or V8? The firmware_upgrade.sh only support V7 and V8. Tks!

Best is using the Pauls guid if its online but the next step is installing the serial server and getting it auto starting be renaming the tuya starting script and maning one that starting the serial server.

This one help me on my Ubuntu.
Try to set options for ssh command:
ssh -oHostKeyAlgorithms=+ssh-dss root@your-ip -p2333