TYZS4 Module (LIDL Hub) Pinout

[froloffw7]

Hello,

Can you please check if the pinout below is correct.
Also it seems that this module has different pad numbers as per table 2-1 from Tuya V2.0.0.
Can you also provide connections between TYZS4 pads and RTL8196E CPU.

Thank you.

[MattWestb]

Nop !!
The pins for SWD and reset is fixed so shall not being any problem.
RX and TX was traced by some user and we was doing one firmware with software flow control and it was working. Also one bootloader is being made (not using flow control) and its working with this TX and TX pins.
Then some hackers was like having hardware flow control firmware and we was not finding the information for the TYS4 but i was finding the standard ones in the IPEX version https://developer.tuya.com/en/docs/iot/tyzs4ipex-zigbee-module-datasheet?id=K9m7tuum62gwb#title-5-Pin%20definition (Last Updated on : 2022-09-08 08:01:59). Our community firmware cooker was doing one firmware with HW and it was working well = i amusing the pads is the right.
We have not user complaining having problem communicating the the NCP so its more then likely the right pads we is using.
I is running one test system with my self cooked EZSP 6.10.3.0 and is using the pin outs and its working and is stable and in the HA log is looks line this:

2022-12-31 09:12:19.943 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.10.3.0 build 297

And the hardware settings for the UART is looking like this in Simplicity studio with SDK 3.2.3:

    <property object="USART0" propertyId="USART.BSP_USART_CTS.PIN" value="PA5"/>
    <property object="USART0" propertyId="USART.BSP_USART_MISO.PIN" value="PA1"/>
    <property object="USART0" propertyId="USART.BSP_USART_MOSI.PIN" value="PA0"/>
    <property object="USART0" propertyId="USART.BSP_USART_RTS.PIN" value="PA4"/>
    <property object="USART0" propertyId="USART.BSP_USART_RX.PIN" value="PA1"/>
    <property object="USART0" propertyId="USART.BSP_USART_TX.PIN" value="PA0"/>
    <property object="USART0" propertyId="USART.HAL_USART_FLOW_CONTROL.ENUM" value="HAL_USART_FLOW_CONTROL_HWUART"/>

The PTI i have in my test firmware but i have not my standard connection for it and its useless for normal user then you need one original Silabs WSTK for using it.

The pinout of the comport i think you can finding in the RTL8196E data papers but the hacker have using the default comport tuya is using with the same setting found in the original Linux installed on the device.

I cant guarantee that the HA flow control pins / pads is right but its looks working OK but if you is finding its wrong pleas info my and i making one updated firmware with the new settings.

For the devs that was hacking the ZBGW it was not interesting digging deeper then needed and we have getting it working and if tuya have doing updated version of the TYZS4 is still pin and firmware compatible with the original one or we have getting complains form user that have not getting it working and need one J-Link for de-bricking there device.

[froloffw7]

Sorry for possible confusion, I'm sure that your pin assignment is CORRECT.

I'm trying to rebuild the TYZS4 FW with the latest V8 Zigbee stack. Seems this is GSDK 4.0.x (EZSP 7.0.0), so I have to set this pins in the project. Also I traced the PAD connections using photos from different documents and now have the assignment as below.
You have BLP assigned to PA2 (PWM2), but in another project EFR32MG1B-256k/NCP it assigned to PB11. Is it used for FW update?
I would like to port Z3Gateway app to RTL8196E mips. Unfortunately in last GSDKs, SL made building it with MQTT plugins hard (if ever possible).
Thank you for your support..

[MattWestb]

Its depend witch SDK you is making the project you is getting one force bootloader pin and its possible deleting but then you must doing more steps for getting the firmware being build OK and ZBGW is not having one hardware for using it so i have left it one one "dummy pin". If you have the box open you can using it by shorting it to ground for getting in the bootloader if the comport is not working for rebooting the NCP in bootloader mode but i think you dont need it then you is very likely having one WSDK that can debricking the chip is hard soft braking it.

Mos support for MG1X is taking away or broken in GSDK 4.0.x (EZSP 7.0.0) and higher only RCP for OTR and software on host EZSP is working. I have building one RCP 4.2 for ZBGW but i have not testing it then using it for EZSP for one of my test system.

HA log Billy (MG1P) running RCP and have EZSP on thehostaddon:

2023-01-03 18:24:59.524 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 7.2.0.0 build 0

And looks working great with Zigbee and Open Thread Broader router :-)))

My experience with Billy EZSP is the last working is 6.10.3.X and likely is the last that is getting some bug fixes (6.7.11 shall coming but its older in generations).

You must setting DC-DC pass thru in the hardware setting or the chip is not booting OK for ZBGW as i have doing with Billy.

For the moment is Silabs Simplicity Studio and GSDK very one large inferno with much things not working OK or at all. My Markus project cant building (MGM210LA22JNF2) then the comport is broken but the EZSP is starting on the chip and allocating NVM in the end of the flash. They is also changing the architecture from old "ember" to SL prefixing and also streamlining it with Open thread for making it easy making cross platforms projects.

Some user is hacking one hub that looks using one old version of Z3Gateway with MQTT in it zigpy/zigpy#796 and its using one MG1B chip but we have not getting the pins it using so no updated EZSP to 6.10.3.X.

If you like having one good Zigbee module for your ZBGW put in one ZS3L its having one MG21 and i can building all projects on it and its working great only need some soldering and i think the pins is not fitting but its not large problem :-)))

[froloffw7]

Thank you for the detailed answer.
FW update shouldn't be a problem. I can update it using STLink2 stick.
I'm not able to find ZS3L on Aliexpress. Also it seems that in order to get access to EmberZnet EZSP 6.10.x SDK, I have to buy some of their starter kits.
Probably it would be better to switch to some TI CC2652P based module. Seems this is the best module in Zigbee world this time and SDK from TI is free of charge. I have very good impression of work with TI CodeComposerStudio DSP software.

[MattWestb]

I think tuya is not selling them "over the desk".
I have one LIDL RGBW controller and have hocking it up with some pins and can dumping and flashing it easy. The problem is not that tuya is staring using Telink chips and you is not knowing what is inside then you is baying one product from tuya.

If you is having IKEA in the near all new devices is having one nice MG21 module but its not well supported in GSDK4 so i cant recommend it but i have baying some bulbs for 9€ for getting the module and is working good with registered WSDK for getting the Zigbee stack for EZSP 6.10.3.0.

Before it was one SiLabs Thunderboard Sense 2 for 10$ ans was getting license for Zigbee / EZSP SDK but is discontinued and cant getting it longer.

What i knowing is the TI Zigbee stack not completely free (is it the toolchange ?) but if you can using it then its very OK.
And i think Silabs MG2X chips with 20 dB is having very good receiver and is not having so much bugs as the later TI Zigbee stacks.
Z2M is still having problems with there NCP with memory leaks and cant paring real Zigbee 3 end devices direct to the coordinator. And the last big things is Sonoff new products is using latest TI chips and is having large problems.

Its depend what you like to do cooking NCP / RCP firmware or making custom devices and deploying.

If you like getting NCP / RCP firmware for MG1B and you is knowing the pinout / settings i can cooking them for you if need pre EZSP 7.0. Its looks RCP (Open Thread / Zigbee RCP) can being done and its working on my Billy with MG1P but all normal Zigbee example is away in latest GSDK for them :-((

[froloffw7]

May I ask you to create for me Unix (linux64 makefile) Z3Gateway project with MQTT plugin as described on p21 and share the project directory.
The SL studio v5 only contain basic Z3Gateway example, while all required MQTT/cJSON source codes are included in the SDK.
Thank you in advance.

[MattWestb]

Witch GSDK is you interested of ?
GSDK 2.7.10 = EZSP 6.7.10.0 (SS4) or GSDK 3.2 = EZSP 6.10.3.0 (SS5)
GSDK 4.0.2 = EZSP 7.0.2.0 is on GitHub but it have not all MG1X device support deleted.

[froloffw7]

I would like to build Z3Gateway host application to work with coordinator via UART. I already flash TYZS4 with your 6.10.3 fw build. I believe it is GSDK 3.2.
On the next step I will try your RCP 4.2 build with cpcd.
PS Latest GSDK available on SL github is 4.2.0, EZSP 7.2.0.

[MattWestb]

GSDK 7.1 and newer is more cleaned and remakes so more incompatible with MG1X devices. With luck is 7.0 having the MQTT in place i have not looking.
My RCP is not tested so be sure having one WSD probe and reading / dumping the main flash for you flashing it !!!
The 6.10.3 is working great and shall not being any problems

Edit: The Host is still in 4.0 with UART https://github.com/SiliconLabs/gecko_sdk/tree/gsdk_4.0/protocol/zigbee/app/ezsp-host with MQTT source.
The 4.1 have CPC = for RCP firmware.

[MattWestb]

Have you looking on https://github.com/SiliconLabs/Unify_HomeAssistant ??
Silabs have putting together most things they can in one package for PI4 and HA for companies that like making one Unified GW.

[froloffw7]

Can't see MQTT in 4.0.0, may be you mean ASH?

[froloffw7]

Didn't have time yet, to look deep into Unify Host SDK. This could be another option with RCP fw.

[MattWestb]

Early versions of Unify is using UART / EZSP = working with EZSP 6.10.3.0 and newer CPC / RCP.

[froloffw7]

I almost finish the build. Few unresolved names left. Those should be implemented in files
v3.2/protocol/zigbee/app/framework/util/af-main-host.c
and
v3.2/protocol/zigbee/app/util/serial/command-interpreter2.c
Only header files included in GSDK 4.x.y.

[MattWestb]

That sounds great !!
And you have remapping all handles that is changed in the updated SDK ?

:-))

[froloffw7]

Most of, I hope :)

[froloffw7]

Seems this will be the hardest part. A lot of changes...

[MattWestb]

I hope you have all you need i cant doint then im not one code warrior !!

[froloffw7]

I managed to adopt the sources and build the Z3Gateway application.
Not sure that everything done correctly, also the code require more polish. At least application can talk with TYZS4 module via serial and register with mosquitto broker.
It seems, that from version 4.0 SL started some big transformation, but till 4.2.0 it is still not in stable state. There is a lot of old code mixed with new interfaces. It is not easy to understand the logic even having full sources. This could explain why many applications are broken.
Please let me know if you want me to share the changed sources.

[froloffw7]

I'm testing your build 6.10.3 with TYZS4. It seems there is some problem with it.
I can't restore settings from backup neither form network.
I tried also with bellows without success. Network forming always finished with timeout error.
Scanning could be fulfilled but in some cases also gives timeout error.
Device start working properly after reflashing to 6.7.8.

[MattWestb]

I was only making one fast test and was also having problems forming network also with bellows CLI and zigpy CLI but was getting it working somehow.
Try flashing the 6.10.3 one more time after you have the network being formed with 6.7.8 and is its going OK its not deleting the NVM but it can being that the new firmware is larger and its being written over some part of it (i was having similar problem going from tuya original FW to Garys 6.7.8).

[froloffw7]

I don't have any devices types like openthread etc
What are the benefits of 6.10.x comparing with 6.7.x regarding zigbee? Does it support BLE?

[MattWestb]

EZSP 6.7.X (latest is 10 in the end but is no real bug fixes) is the most stable version.
Then Silabs was starting rebuilding SS and the next candidate for stable is 6.10.X and all between is very buggy.
Both is working well in production and 6.10.X is on the boarder to much for the old hardware (ram and flash not the CPU or radio).
Next good one is 7.2.X but its not supported on the SOC as you have seen for MG1X device with 256K flash.
The EFR32MG1X chips can doing BT and BT mesh but its not recommended then its need closed SDK and its expensive compared with other cheep chips.

RCP for IEEE 802.15.4 (Thread and Zigbee) is using mush lesser hardware (the radio and sending the frames to the host) also its possible in combination with BT (alpha code) but i think its not going well for MG1X devices.
Then the Zigbee stack is living on the host system as demon (zigbeed) and not on the SOC and then its possible using the MG1X chips with it like the HA Silicon Labs Multiprotocol is getting one network comport with one "normal" EZSP commands to the system.

The EZSP 6.10.3.0 is having more bug fixes so shall being better but im not 110% sure its stable as 6.7.X is.

I getting one Nanoleaf Essentials Smart Bulb (20€) tomorrow and shall try getting it in my open thread network :-))

[froloffw7]

Then, maybe it will be better to spend time on RCP testing, as it seems that NCP is near the end-of-life?

[MattWestb]

As long using SOC / NCP (the zigbee stack on the chip) is no go with 7.X then its not supported.
The latest EZSP 6.7.x is the stable and the 6.10 is the latest supported working for MG1X devices with 256 K flash and is also working.
EZSP 7.0.X is badly working and is not recommended and 7.1.X and newer is all NCP / SOC support taken away.
And yes NCP / EZSP pn SOC is EOL after 7.0.X.

RCP (Zigbee stack on the host system) is working but have some good and bad things.
The good is that the MG1X chip have very good radio and the RCP is only piping the radio frames to and from the host and the hos system is doing all the EZSP things (and Open Thread Boarder Router if installed).

You can trying building one Multi pan RCP for the ZBGW but you need setting the DC-DC to pass thru in the setting for getting the chip booting it.

[froloffw7]

So flashing your RCP build is not sufficient?

[MattWestb]

RCP firmware is using one CPC protocol with the host system and need little more software for working but in the end you is getting one normal EZSP communication handle and one Open Thread Boarder Router in HA.

Little info is here zigpy/zigpy#894

[froloffw7]

Good reading, thank you.