Hello all,
I am a community developer, working on a Matter Bridge driver for the home automation system that I use ( Hubitat )
I have some questions related to the Tuya Matter Bridge (sold under different white labels). In particular, there are some issues bridging the Zemismart curtain motors, some temerature/humidity sensors returning wrong data or not updating the attributes, etc..
Is this the right place?
Regards,
Krassimir.
Hi Krassimir
You can describe your issues here. I'll provide help for you. Thanks.
Hi huangxh,
Many thanks for your answer! I have more questions than really issues with the Tuya Matter Bridge, will be glad if you can put some light on them.
The first question is whether there are any differences in regards to the supported Zigbee devices bridged via Matter, depending on the manufacturer of Tuya Matter bridges. Is there any difference between bridges labeled 'Zemismart M1', 'MOES', 'Girier', etc... ? Can you confirm that the Matter bridging functionalities are one and the same, developed by the Tuya engineering team (not by Zemismart, Moes..), and the different brands' gateways are one and the same firmware, just different plastic boxes and different white labels?
One problem is that while some devices of one and the same type (curtain motors as example) are supported by the Bridge, other devices of the same type are not exposed Example : TS0601 _TZE200_cf1sl3tj Curtain Motor labeled Zemismart is supported. _TZE200_68nvbio9 is supported as well. However, TS0601 _TZE200_xuzcvlku (also sold by Zemismart) is not exposed by Tuya GW (not in the BridgeDescriptor 0x001D PartsList attribute 0x0003).
Does whether a Zigbee device is exposed via Matter Gateway depend on Tuya engineering team or on the particular manufacturer? Some Tuya-based temperature and humidity sensors are exposed, others not. Some mmWave sensors are exposed, others unfortunately are not. What does this depend on?
A second question on the implementation of the WindowCovering cluster 0x0102 OperationalStatus attribute (0x000A) - Matter Application CLiser specifications ver 1.2 paragraph 5.3.5.3. OperationalStatusBitmap Type.
Although the OperationalStatus is in the supported AttributesList, the Tuya Bridges does not send any updates when the OperationalStatus changes. The subscription is OK (verified with a Metter GW from another manufacturer - Switchbot).
Is the OperationalStatus implemented in the Tuya Matter GW?
The last question is on the firmware updates. The Smart Life app is showing Main Module V1.9.2 and 'Other type' V3.4.0
Is there a way to get these versions through the Matter GW? It seems like currently softwareVersionString : 2.0.0 is fixed and doesn't change.
Best regards, and thank you in advance!
Hi Krassimir：
Customers are using our solutions; some are OEM, ODM, and some are developed based on the Tuya SDK."
Yes, for some of our pre-developed solutions, we automatically support the bridge. However, for solutions that are not pre-developed, customers need to submit their requirements to Tuya, and then we will provide support.
We determine which functions of our devices are supported by the Tuya platform and place the standard Matter-supported functions on the bridge。
Thanks
Hi huangxh,
Thank you for the reply. I published the integration with the Tuya Smart Wired Gateway Pro in the Hubitat platform last weekend; hopefully, soon, there will be feedback from more users that I can share with you.
At the moment, it seems like the biggest problem is the uncertainty of which devices are exposed via Matter Bridge and which are not. From your previous reply, I understand that many devices manufactured using the Tuya platform were bridged without the knowledge and active participation of the actual OEMs. This is confirmed by the messages I exchanged on the AliExpress platform with several sellers selling Tuya ecosystem devices. With a single exception, the AliExpress sellers have no idea what this Tuya Matter Bridge is. The typical answer is - it works with Smart Life .. 
With a single exception, they can not say whether the Tuya Zigbee devices they sell will be usable via the Tuya Matter bridge interface or not.
Leaving these Tuya Product Management issues aside (this technical forum is probably not the right place to discuss them), can we try to clarify and find a solution for some particular technical/software issues?
We could start with something relatively easy - for several Temperature and Humidity sensors, the temperature is exposed OK, but the relative humidity is not working - it is fixed 40% RH. Of course, the humidity readings are OK in the SmartLife app. This issue is replicated in both Hubitat, SmartThings, and Apple Home.
Please let me know if you have any established procedures for reporting such issues or what your preferred course of action would be.
Regards,
Krassimir.
Hello Krassimir,
The matter bridge of the Tuya gateway can support the zigbee3.0 devices developed on TuyaOS for Zigbee development framework as much as possible. if you find any Zigbee devices can't bridge into Matter devices, please list them here. We'll expose these devices through the Matter bridge ASAP if they are developed on TuyaOS.
Hello Krassimir
You can also provide the Tuya virtual ID and device type for this device, and we will confirm it.
Thanks
I have two ZY-M100 Human presence sensors (High precision breath sensor) connected to my hub that are not showing up in other devices via matter. These are the newer 24 Ghz millimeter wave versions. The virtual ids are listed below
eb183b6d0c5aead22cuzdt
eb5ad71038465c6cf2haza
HI Krassimir：
Your device is rather complex, it is a composite device made up of multiple types of devices, we need to confirm this。
Can the correspondence between an endpoint and a data point (DP) be provided? Thanks
I am on Western America Data Center https://openapi.tuyaus.com
and the data points for this device are
"1":"Switch 1",
"2":"Switch 2",
"7":"Timer 1",
"8":"Timer 2",
"101":"Work Mode",
"102":"Bright Value",
"103":"Temp Value",
"104":"Illuminance Value",
"105":"感应状态",
"106":"运动灵敏度",
"107":"Longest distance",
"109":"target_distence",
"110":"Delay time",
"111":"静止灵敏度",
"112":"有无人状态"