dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 502 forks source link

[Device Support Request] Tuya Gas Detector #2633

Closed timbru31 closed 4 years ago

timbru31 commented 4 years ago

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:

tuya2 tuya3 tuya1


Hardware image: TS0204


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 commented 4 years ago

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

timbru31 commented 4 years ago

Sure: tuya4

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

SwoopX commented 4 years ago

Nope, it isn't ;)

timbru31 commented 4 years ago

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

ebaauw commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

What spec? See #2634.

timbru31 commented 4 years ago

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 commented 4 years ago

Try reading the basic cluster while sensor search is active.

timbru31 commented 4 years ago

Nice, that did the trick!

SwoopX commented 4 years ago

👍

SwoopX commented 4 years ago

@timbru31 Did the sensot enroll automatically?

timbru31 commented 4 years ago

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

SwoopX commented 4 years ago

@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 commented 4 years ago

After a reset it's not enrolled automatically.

SwoopX commented 4 years ago

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.