[Device Support Request] Tuya Gas Detector

[timbru31]

I've bought a new Zigbee device: The Tuya (combustible) gas detector (model TS0204) - sadly, it's not yet supported.
See attached Node and Cluster info below:

---

Hardware image:

---

PS: Deconz GUI says it's a CO sensor, it seems the translation of the attribute e16ZoneType (i.e., E_CLD_IASZONE_TYPE_GAS_SENSOR (0x002B)) is wrong, since it can but is not always a CO sensor.

[SwoopX]

Can you also please provide a screenshot with the available clusters? Thanks.

[timbru31]

Sure:

I'll work on a PR, too. Hopefully it's just adjusting the bindings to whitelist the model id.

[SwoopX]

Nope, it isn't ;)

[timbru31]

What should be missing then? Basically it's yet another gas sensor, the clusters aren't very special (as expected)

[ebaauw]

Deconz GUI says it's a CO sensor, it seems the translation of the attribute e16ZoneType (i.e., E_CLD_IASZONE_TYPE_GAS_SENSOR (0x002B)) is wrong, since it can but is not always a CO sensor.

It advertises incorrectly as a CO sensor. Make sure to expose it as ZHAFire instead of ZHACarbonMonoxide, see #2515.

[SwoopX]

Ah, wait. Seems that I mixed it up as it doen't have the IAS WD cluster...

Don't even think any binding is required here. Probably just add them on top of de_web_plugin.cpp as the other devices and the changes mentioned by @ebaauw somewhere around line 3989.

[timbru31]

Deconz GUI says it's a CO sensor, it seems the translation of the attribute e16ZoneType (i.e., E_CLD_IASZONE_TYPE_GAS_SENSOR (0x002B)) is wrong, since it can but is not always a CO sensor.

It advertises incorrectly as a CO sensor. Make sure to expose it as ZHAFire instead of ZHACarbonMonoxide, see #2515.

There are no dumb question: why should I force the sensor to be a fire sensor when the current zone is correct spec wise?

[ebaauw]

What spec? See #2634.

[timbru31]

Ah, wait. Seems that I mixed it up as it doen't have the IAS WD cluster...

Don't even think any binding is required here. Probably just add them on top of de_web_plugin.cpp as the other devices and the changes mentioned by @ebaauw somewhere around line 3989.

Hmm, interestingly this doesn't seem to do the trick:

diff --git a/de_web_plugin.cpp b/de_web_plugin.cpp
index 39b2a58..6836ee4 100644
--- a/de_web_plugin.cpp
+++ b/de_web_plugin.cpp
@@ -274,6 +274,7 @@ static const SupportedDevice supportedDevices[] = {
     { VENDOR_HANGZHOU_IMAGIC, "1117-S", energyMiMacPrefix }, // iris motion sensor v3
     { VENDOR_JENNIC, "113D", jennicMacPrefix }, // iHorn (Huawei) temperature and humidity sensor
     { VENDOR_SERCOMM, "SZ-ESW01", emberMacPrefix }, // Sercomm / Telstra smart plug
+    { VENDOR_NONE, "TS0204", silabs3MacPrefix }, // Tuya gas sensor
     { 0, nullptr, 0 }
 };

@@ -3976,7 +3977,8 @@ void DeRestPluginPrivate::addSensorNode(const deCONZ::Node *node, const deCONZ::
                              modelId.startsWith(QLatin1String("SMSZB-120")) ||        // Develco smoke detector
                              modelId.startsWith(QLatin1String("HESZB-120")) ||        // Develco heat detector
                              modelId.startsWith(QLatin1String("SF2")) ||              // ORVIBO (Heiman) smoke sensor
-                             modelId.startsWith(QLatin1String("lumi.sensor_smoke")))  // Xiaomi Mi smoke sensor
+                             modelId.startsWith(QLatin1String("lumi.sensor_smoke")) || // Xiaomi Mi smoke sensor
+                             modelId.startsWith(QLatin1String("TS0204")))  // Tuya gas sensor
                     {
                         // Gas sensor detects combustable gas, so fire is more appropriate than CO.
                         fpFireSensor.inClusters.push_back(ci->id());

Any ideas? Re-paring the sensor doesn't even yield the green success message in Phoscon. Debug logs show a successful network join of the device though.

[SwoopX]

Try reading the basic cluster while sensor search is active.

[timbru31]

Nice, that did the trick!

[SwoopX]

👍

[SwoopX]

@timbru31 Did the sensot enroll automatically?

[timbru31]

To the IAS Zone? I'm not sure anymore, but I think that I've manually set the value.

[SwoopX]

@timbru31 Thanks for your feedback, that would be my expectation. I'm currently after integrating another mains powered IAS zone device and it does not enroll automatically, simply because the code seems not be able to handle that (yet).

If you maybe got some time over the weekend, I'd appreciate if you could double check that with a sensor reset.

[timbru31]

After a reset it's not enrolled automatically.

[SwoopX]

Thanks a lot. I was hoping not to be alone with this, it might be a rare phenomenon though. I made some tests with corresponding code changes and managed to have it enrolled automatically now.