Add support pir motion illuminance sensor _TZE200_3towulqd / TS0601

[MihaiINW]

No description provided.

[MihaiINW]

It seems that there was a recent addition of a driver for this device, but it does not work, however the driver in this PR works properly.
Would you rather have me modify the existing driver? Please let me know how you want to proceed.

[maccyber]

I could not get this to work.

My device interview

Log from pir_motion_illuminance_sensor

The only way I can get this device to work is through the Tuya's Manufacturer Specific Cluster (61184) see comment and code

• Manufacturer Specific Cluster
  In Zigbee, a Manufacturer Specific Cluster is a feature that allows manufacturers to create their own custom functions or features within a Zigbee network. Essentially, it's a way for a company to add unique capabilities or behaviors to their Zigbee-compatible devices that aren't part of the standard Zigbee protocol. This allows manufacturers to differentiate their products and offer specialized functionality.

• Tuya Specific Cluster (61184/0xEF00)
  Tuya is using cluster 61184 for DP commands for TS0601 devices (tunneling MQTT commands to there cloud).
  There are also hybrid devices that is using standard Zigbee clusters for commands and DP for advanced config.

[Boechie]

@maccyber First of all it is weird that your device produces a totally different interview than ours, especially this part:

Ours:
"inputClusters": [
0,
3,
1280,
57346,
61184,
60928,
57344,
1,
1024
],
"outputClusters": []

Yours:
"inputClusters": [
1,
1280,
0
],
"outputClusters": [
25,
10
]

From your interview your device does not support ZCL illuminance cluster (1024 / 0x0400). Ours does. But on the other hand your interview also doesn't show that your device supports cluster 61184. From both interviews I can see that both devices have the same ModelId and ManufacturerName. I don't get that. @MihaiINW @ayhamdabbas do you have any ideas?

Maybe @JohanBendz can shine some bright light on this issue?

[maccyber]

Yes, agreed - seems like two different devices stating to be the same.

When I look at reported device interviews 5 of them are reporting
"inputClusters": [ 1, 1280, 0 ] like mine, 4 of them are like yours.

Wonder if the driver I posted work on your devices - if not; is there a way in homey to filter the driver on anything else than productId and manufacturerName? Like if the appVersion is different or we find something else than inputClusters to differentiate them.

Created a PR if you want to test here: #735

Here is my response from

await zclNode.endpoints[1].clusters.basic.readAttributes('manufacturerName', 'zclVersion', 'appVersion', 'modelId', 'hwVersion', 'dateCode', 'clusterRevision')

{
  "manufacturerName": "_TZE200_3towulqd",
  "zclVersion": 3,
  "appVersion": 72,
  "modelId": "TS0601",
  "hwVersion": 1,
  "dateCode": "",
  "clusterRevision": 2
 }

Link to where I bought it: https://www.aliexpress.com/item/1005004822278385.html

Modelnumber on package: ZG-204Z
I have seen some other devices with ZG-204ZL

It is possible to order without and with illuminance sensor.
My device is with, even though it does not show during device interview.

[Boechie]

@maccyber I bought them from the exact same AliExpress store. The one with lux. This is the box that they are deleivered in:

You can see both ZG-204Z and ZG-204ZL printed on it. My guess would be that the latter (with L) is for the version with lux and without L for the version without lux.

Pairing in the Tuya Zigbee app works on the unique combination of ManufacturerName and ProductID indeed, because it is built on Node Homey Zigbee Driver. That is a problem in itself (but that's a whole different story). Maybe we could merge both drivers into 1 (because of the same ManufacturerName and ProductID) and then in the driver we try the one cluster and if that doesn't work, we try the other.

I will have my colleagues look into it after the weekend. If @JohanBendz has some idea on this, I'd really like to hear his expert's opinion.

Hence, also see PR #735 and issue #715 .

@ayhamdabbas @MihaiINW @ManarINW Can you further investigate this?

[JohanBendz]

@Boechie, not the first device with same Manufacturername and conflicting interviews.. Sadly the brands does not understand the implications. :/
We can solve this in two ways:

1. Two drivers with same Manufacturername and DeviceID, if a user choose the correct one it will work, else it will fail.
2. One driver with a clustercheck, if there is a Tuya cluster or not.. I think this is the better solution.

[maccyber]

@JohanBendz: Agreed, option 2 seems to be the better solution.

Do you have an example of an implementation of a 'clustercheck'?

[JohanBendz]

Something like this?

async onNodeInit() {

try {
  const node = await this.homey.zigbee.getNode(this);
  const hasTuyaCluster = this.checkForTuyaCluster(node);

  if (hasTuyaCluster) {
    this.log('Tuya Cluster found.');
    // Implement logic here for when the Tuya cluster is present
  } else {
    this.log('Tuya Cluster not found.');
    // Implement logic here for when the Tuya cluster is not present
  }
} catch (error) {
  this.error('Error checking for Tuya Cluster:', error);
}

}

checkForTuyaCluster(node) {
for (const endpoint of node.endpoints) {
if (endpoint.clusters[61184]) {
return true; // Tuya cluster found
}
}
return false; // Tuya cluster not found
}

And then add functionality to remove the Illumination capability if it's not to be used.
if (this.hasCapability('measure_luminance')) {
await this.removeCapability('measure_luminance');
}

[maccyber]

Thanks, started a implementation of cluster check and merge the two drivers into one at #740
It works on my 'tuya cluster device', but not sure the cluster check works and if it will work on the 'standard cluster device'.

Maybe you can test it @Boechie?

[Boechie]

@maccyber I will ask my colleagues to look into the solution and test it.
@MihaiINW @ayhamdabbas @ManarINW Can one of you look into this and share your findings?

[JohanBendz]

@Boechie, did you guys ever find out if this works?

[JohanBendz]

#740

[Boechie]

@JohanBendz We indeed figured out how to fix this with a cluster check. We are finishing that up as we speak. That will solve several issues already mentioned and also override a few PRs mentioned. I'd advise not to merge this PR and also not the other. A new one will be coming, but preferrably I'd like to keep this one open for now to keep the history for a little bit longer.

[Wuma68]

@JohanBendz We indeed figured out how to fix this with a cluster check. We are finishing that up as we speak. That will solve several issues already mentioned and also override a few PRs mentioned. I'd advise not to merge this PR and also not the other. A new one will be coming, but preferrably I'd like to keep this one open for now to keep the history for a little bit longer.

Is there a plan when this fix will be released in to a test version?

[JohanBendz]

Waiting for @Boechie to create a new PR. While doing so I made some changes to the current driver hoping the devices that use it will work better.