[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]

👍