[ZIGBEE] Tuya data point - only one is processed instead of all

[lifaon74]

PROBLEM DESCRIPTION

Using zigbee, Tuya uses a specific cluster 0xef00 and protocol. It has a concept called "DataPoint".

Tasmota manages this protocol as we may see here. However, it doesn't support multiple DataPoints in a single TY_DATA_RESPONSE/TY_DATA_REPORT.

Actually, the payload must be entirely exhausted, as it may contain more than one DataPoint. The current implementation only consumes and report the first one. This results in data lost.

REQUESTED INFORMATION

Console log:

20:55:53.188 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":"0xEF00","srcaddr":"0x629F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":71,"securityuse":0,"seqnumber":213,"fc":"0x09","frametype":1,"direction":1,"disableresp":0,"manuf":"0x0000","transact":117,"cmdid":"0x02","payload":"08CC030200040000002E05020004000000846E0200040000022D"}}
20:55:53.190 ZigbeeZCLSend device: 0x629F, endpoint:1, cluster:0xEF00, cmd:0x0B, send:"0200"
20:55:53.191 ZIG: ZbEZSPSend 3400009F62040100EF01010000000075010510750B0200
20:55:53.193 ZIG: ZbZCLRawReceived: {"0x629F":{"EF00/0203":46,"Endpoint":1,"LinkQuality":71}}

TO REPRODUCE

Buy and link a NAS-STH02B2

I've linked the received payload, and what is "reported" by Tasmota in the SENSOR topic.

EXPECTED BEHAVIOUR

The payload 08CC030200040000002E05020004000000846E0200040000022D should be parsed like this:

NOTE: this is a prototype algorithm, not a real implementation

// https://github.com/arendst/Tasmota/blob/2bf67b96a68fd37ebf82966eff43cfbc3b53a109/tasmota/tasmota_xdrv_driver/xdrv_23_zigbee_6_0_commands.ino#L605
uint16_t  read_index = 0; // position in the buffer
uint16_t seq_number = buf.get16BigEndian(read_index); // seq
read_index += 2;
while (read_index < buf.size) {
  uint8_t dpid = buf.get8(read_index);   // dpid
  read_index++;
  uint8_t attr_type = buf.get8(read_index);   // data type
  read_index++;
  uint16_t len = buf.get16BigEndian(read_index);
  read_index += 2;
  // create a synthetic attribute with id 'dpid'
  Z_attribute & attr = attr_list.addAttribute(cluster, (attr_type << 8) | dpid);
  parseSingleTuyaAttribute(attr, buf, read_index, len, attr_type);
  read_index += len;
}

And should result in something similar to:

{"0x629F":{"EF00/0203":46, "EF00/0205":132,  "EF00/026E":557, "Endpoint":1,"LinkQuality":71}}

---

I'm not a C/CPP developer, but if may help in any manner, don't hesitate to ping me, and I'll be glad to help you.

[s-hadinger]

Oh boy. Tuya is very creative with the Zigbee protocol.

Actually this is the first time I see Tuya device reporting multiple values at once. Indeed the code should be somehow easy to change into this. I'm don't have bandwidth for now to make the change. Any PR is welcome.

[lifaon74]

Yes, Tuya does nothing like others... why follow a spec when you can build your own ? 🤦‍♂️ I've ordered a new Tasmota Zigbee Gateway to play with it and try to fix this issue (I don't want to broke all my installation). However, I'm a web developer, so I'll try my best !

[Jason2866]

To be clear, this is no issue. Tuya changes are not conform to zigbee standard.

[lifaon74]

This is somehow an issue, as there is currently no way to make such a device work with Tasmota: data is lost in the process. I perfectly understand that Tuya does crap, and it's not your/our job to support custom bulls*ts. But there is no options in Tasmota to get the raw zcl frame, so every owner of a Tuya device is currently irremediably stuck. My workaround was to set MqttLog 3 and then inspect the Zigbee packets from the LOGING topic.

In an other hand, Zigbee2MQTT handles properly this case here: https://github.com/Koenkk/zigbee-herdsman/blob/236da5b7b0e007bdbde2d92648bf17bd997bf105/src/zspec/zcl/buffaloZcl.ts#L617 and the fix is pretty simple.

Thus, I'll try to make a PR for this.