STM32WB5MM-DK, connecting to Tuya gateway with zigbee, part 2

[eskomj]

Hello,

I have still connection problem to Tuya gateway. Simple OnOff application can connect to Tuya gateway, but when I try to connect STM32WB5MM-DK as a temperature sensor, connection fails.

Connection to Tuya gateway succeeds with STM32WB5MM-DK example OnOff_Server_Coordinator and On/Off button comes visible on SmartLife app. But with temperature sensor application connection won't work. The application things that it has succeed to connect, but nothing comes visible in SmartLife app. Little display shows "Join ok". According to Wireshark logs, temperature sensor won't reply to gateway's read attributes request where it wants to read basic attributes:

Command: Read Attributes (0x00)
Attribute: Manufacturer Name (0x0004)
Attribute: ZCL Version (0x0000)
Attribute: Application Version (0x0001)
Attribute: Model Identifier (0x0005)
Attribute: Power Source (0x0007)
Attribute: Unknown (0xfffe)

OnOff application responds for that, but not quite like should. Anyway connection succeed.

Connection shoud go according to that specification:

【Zigbee Popular Science Series】 - 3 Network Access Process - Tuya Developer Forum (tuyaos.com)

I attached three Wireshark log; WB5MM_OnOff__Server_Coord, WB5MM_TempMeas_Server_Coord and Nedis_capture. In both Server_Coord applications, I changed starttype --> join and also channel change to WPAN_2400MHZ.

I'am not shure is that the reason why connection fail, but this is at least first difference. 

[eskomj]

It looks like handling of basic attribute request hapens in that portion of code:

IPC_CLUSTER_REQ_CALLBACK_FUNC(ZbZclReadReq, MSG_M4TOM0_ZCL_READ_REQ, ZbZclReadReqT, ZbZclReadRspT);

-->

#define IPC_CLUSTER_REQ_CALLBACK_FUNC(name, cmd_id, req_type, rsp_type)

.....

Whole message handling is based on that define construction. Now I am  wandering how I can modify the code so, that I get better loggin. The code  is in zigbee_core_wb.c which is read only. I think, it's not meant to be changed.

[Ouadi]

Hello @eskomj,

From the logs I observe that the device leave the network just after the join, and it may be explained by the fact that the device does not implement the attributes required by the coordinator.

In fact, Zigbee_TempMeas_Server_Coord and OnOff_Server_Coordinator does not handle the listed attributes as the Manufacturer Name, Stack Version ,Model Identifier.., these applications are developed in order to demonstrate the use of ZigBee network and to help designers to build their specific Zigbee applications based on STM32WB series.

Therefore, you have to modify the application according to Tuya Gateway specification so that your device is supported.

To implement these attributes, you can use following APIs : ZbZclBasicServerConfigDefaults and ZbZclBasicWriteDirect.

You can refer to this post which describes the steps to follow.

Kind regards,

Ouadi

[eskomj]

Thank you Ouadi! I got basic cluster working according to the instructions. But connecting to the Tuya network won't work yet. Now it looks like the application won't send TC link key request, which is point 12 in Tuya guide (link above). Such attention also, that instead of setting basic cluster before creating any ZCL endpoints I had to do it after endpoint creation. That is also said in post . When I tried to add ZbZclBasicWriteDirect calls before creating end points, writeDirect call returned STATUS_FAILURE. I moved the basic cluster setting after that 

USER CODE BEGIN CONFIG_ENDPOINT 

in the function APP_ZIGBEE_ConfigEndpoints()

then it worked. Now the problem seems to be that the application won't send TC link key request  I attached latest Wireshark capture. For comparison, Nedis capture can be found in ealier post above. It shoud look like that (from filtered Wireshark capture from Nedis device):

191 157.916257 0xbde5 ZigBee 0x0000 84 Request Key
198 158.226943 0x0000 ZigBee 0xbde5 116 Transport Key
200 158.237543 0xbde5 ZigBee 0x0000 91 Verify Key
201 158.242451 0xbde5 ZigBee 0x0000 91 Verify Key
202 158.247377 0xbde5 ZigBee 0x0000 91 Verify Key

[eskomj]

I looked more closely the Wireshark capture. First difference compared to Tuya specification, is that the application won't send node descriptor request (point 10). 

It is obvious that ZbZdoNodeDescReq() call still missing. If so, where should it be inserted?

[Ouadi]

Hello @eskomj,

Thanks for the update.

You are right, configuration of write attribute need to be done after the creation of endpoint, however, looking at your code, it seems that you are not calling ZbZclBasicServerConfigDefaults function at the end of write basic attribute sequence, so I modified the file you can find an attachment ( Note: I commented some functions (Led init) to be able to compile )

Could you please test and update the status here ?

BR,

Ouadi

[eskomj]

I tested with your version. One difference to previous version is attribute write error which comes now after basic cluster read operation:

[M0] [00000000.982][PLATFORM] ZbZclAttrWrite : Failed to write cl = 0x0000, attr = 0xffde (cannot find attribute)

I understand so, that now it goes further, if attribute write command comes from coordinator. I attached zcl trace log. 

There is something related attribute 0xffde in this post. (tuya0xffde must be defined to be able to use write command). Some Tuya related attribute? Also these post has something:

wiki/en-eng/Technical/Tuya-TS061-eTRV.md at master · zigbeefordomoticz/wiki · GitHub

base cluster adds extra properties - Tuya Developer Forum (tuyaos.com)

[Ouadi]

Hello,

The attribute attr = 0xffde does not exist on the basic cluster according to ZigBee specifications, from the links you mentioned ( Tuya forum), it looks like this attribute is dedicated to Tx power and is to be defined as a custom attribute on your device, I'm not sure this is possible for this specific cluster which is created by default at the startup

Another point, on your logs, I don't see any leave request sent by Tuya gateway, even on the Wireshark logs, so could you please send me an update of Wireshark captures for both Nedis and WB ( with the last version of app_zigbee.c) ? thanks.

Best regards,

Ouadi

[eskomj]

Hello,

I asked that from Tuya support and their answer was:

"Actually,developer do not need to be concerned about Tuya-defined private attributes of basic cluster if your device accessed as a three-party device."

I understand so, the gateway now thinks that end device is not third party device. May be some basic attribute is now wrong? I attached updated Wireshark log and application log. I didn't make any modification into the app_zigbee.c file which you attached. I tested with it.

Esko

[Ouadi]

Hello,

From the logs and Wireshark capture, the device seems to be connected to the coordinator, the association and announcement returned a success status, and the reporting is ok.

So what makes you think that your device is not connected ? 

BR,

Ouadi