[PROJECT] Tuya ZigBee Air Sensor Driver

[snell]

Tuya Air Sensor.groovy

Feature(s):

• Receives data from the Tuya ZigBee Air Sensor for temperature, humidity, Carbon Dioxide, VOC, and, Formaldehyde
• Temperature, Humidity, and Carbon Dioxide report using the standard Hubitat capabilities. VOC and Formaldehyde required custom attributes to be created
• Has no user commands that can be triggered, including refresh (since it did not respond to it and pushes data so often anyways)
• Checks my website daily for an updated version of the driver (if any)

Setup:

1. Using driver link above download the driver to past as a user driver or import it into the window
2. Save driver
3. Add Tuya Air Sensor device using standard ZigBee methods
4. Driver should automatically be selected, but if not you can select it from the "Type" dropdown on the device's information page

Note(s):

• This is a VERY chatty device, it sends many data pushes to the Hubitat and I have not yet found any way to alter the rate (it does not appear to react to standard commands to do so), as such I do not recommend leaving Trace logging on unless you are specifically checking something.
• Personal opinion, I cannot really recommend these devices. They say they are ZigBee but Tuya ignores many of the standard ZigBee methods to use their own, even for basic commands...

[cathyychang]

Hi Dr. Snell. I just got in this Tuya Smart Air Box yesterday and was pleasantly surprised to find your driver. It works nicely. Just to throw the data points onto a graph (last 12 hours):

Just to note, temp is reading approx 4 degrees (F) high and the humidity is reading 10% low. I am very pleased with your driver and I'm excited for future updates.

[snell]

Maybe what I can do is build a couple preferences to adjust the temperature and humidity readings.

Mine has seemed fairly accurate to my room but I do not have any really sophisticated measurement in there to compare it with at the moment. I bet there is quite some variability with them.

Not sure why I did not think to do this before but I just opened the case and took a look:

• ZigBee chip is Tuya's ZS3L (Link)
• The temperature & humidity chip is a very generic DHT11 with a +- 2°C rating. That explains the 4°F difference but there may be some consistency in it so a preference might still be useful.
• The other sensor chip (sticking off the side) has no usable markings on it. It appears there might have been some but they were sanded off (leaving bare copper even).
• You can see they have different connections for a WiFi module also, so they must just reuse this model for both types.

Here is a picture of the top side:

[snell]

Updated Version(s):

• Tuya Air Sensor.groovy = 0.1.1

Change(s):

• Corrected the Formaldehyde & VOC reporting. These were swapped in the previous version as I did not have a way to know which was which (there is no documentation of course). However, I ordered a bottle of Formaldehyde and set the sensor over it. What HAD been listed as VOC went up dramatically (and what had been listed as Formaldehyde went up only slightly). Therefore I had them reversed. This is what I corrected.

Known Issue(s):

• Still no known way to set the reporting interval. Despite being "ZigBee 3.0" they use their private cluster for all reporting and that reporting is not using attribute IDs so I cannot use normal commands to request X cluster with Y attribute report at such and such time or amount of change. I read over the Tuya "Zigbee Connection Standard" but it does not list any way to set a report interval (it does have ways to request a report, but this thing already reports a LOT).

[richard1]

Thanks for the driver, it does seem to be working pretty well and, while chatty, it certainly makes it respond pretty quickly.

I am wondering about the CO2 levels, and calibration in general really. I was getting high 600 ppm inside so took the sensor outside, where it still reads this high. I would expect in the rural fringe area where I am that the levels should be lower. The sensor definitely works since breathing on it pushes the reading above 1000 ppm very fast.

I have another, more industrial strength sensor suite on the way which I will likely use to calibrate the output. As I understand, these devices don't actually read CO2 at all but rather do some fancy calculations against the VOC sensor, but I would still expect something a little bit closer.

Anyone else experienced likely incorrect readings and validated them?

[snell]

I have been meaning to add some preferences to "calibrate" the responses (really just offset them). Will try to get that posted tonight.

UPDATE: New driver posted.

Updated Version(s):

• Tuya Air Sensor.groovy = 0.1.2

Change(s):

• Preferences section now has offsets for each of the 5 reported fields. Each one can be individually set and will accept negative numbers and decimals (ex: you can have a -2.5 offset to reduce the displayed value by 2.5). There are no bounds specifically set so you can put absurd numbers in there.
• Preferences section now has a "Show All Preferences" boolean to show or hide them all, because of the offsets. Just to make it a little "simpler" looking once you have it all set up.
• All the reported values have been changed to specifically be type "float" and are rounded to the nearest tenth (0.1). Any further than that and they are completely lost in the noise. As it stands there is already a high degree of variability with this device so whole numbers might be better in the long run.

[richard1]

Sweet! Now all I need is something to calibrate against. I wonder whether the device can actually have calibration factors written into it? I guess without proper documentation it is impossible to know.

Weirdest thing, after extended operation, the CO2 levels have started to settle down a little. I suspect that the sensors are not the most accurate things ever made.

[snell]

Yeah, I doubt the chip for VOC and such is high grade, considering the DHT11. There is PROBABLY a way to calibrate it... But like you said that is unlikely to get implemented without documentation. Just send write commands to the Tuya cluster does not seem like a good idea.

[kkossev]

@snell thank you for the driver!

Can you add also * manufacturer: _TZE200_yvx5lh6k , please?

[snell]

Updated Version(s):

• Tuya Air Sensor.groovy = 0.1.3

Change(s):

• Addition of a fingerprint including manufacturer _TZE200_yvx5lh6k per @kkossev's request.
• Changes to the driver version checking.

[znahum]

There is now a 6 in 1 version of this that includes PM2.5 on Aliexpress.

[kkossev]

I still need one more PM2.5 sensor, but this time I will be very cautious before purchasing... The problem is that we can not identify what is the particular model and manufacturer ID from the information provided by AE sellers.

[damianPL]

some one use 6 in 1?
i bought for test but no exist good driver.

[kkossev]

Please post a screenshot of the 6 in 1 'Data' section from the device web page in HE ( Model, Manufacturer, Application version data values).
Also, a link to the site where this device was purchased will be useful.

Are you observing any extraordinarily intensive Zigbee traffic with this device paired to HE?

[damianPL]

@kkossev

eenshot of t

please,

i bought on aliexpress. i have 15 days to return.
Temperature measurement looks ok but rest i don;t think so like humidity is 9%.
I need more day testing.

[snell]

That has the same model as the device this driver was made for, but the manufacturer is different.

Is this the type of one you bought: Tuya Zigbee 6-in-1 Air Quality Monitor

If so, it will likely need a different driver or an update to this one to try to capture the extra data for the PM2.5 (that appears to be the additional item). However, as this overall thread has mentioned these are pretty "rough" sensors if you are not controlling them specifically with a Tuya hub.

At the very least you could start with this driver, set it to Trace logging, and capture a bunch of the data logs so I can try to look at them and see if there is anything that could be figured out. Tuya is not known for following the ZigBee standards closely (they do some bare minimum but then put things in manufacturer-specific areas even if there already exists defined methods for it).

[damianPL]

yes this is exactly this sensor.
box of this sensor is quite big ;). I would like to use this sensors for automatisation of ventilation accuracy will be not big problem if will be no problem with repetitively, then i can adjust
below you can find logs.

[snell]

That initial logging is not from my driver, since it does have a parse section and no warnings about features not implemented. It DOES look like you have the driver later on, since it got the error (because I do not have a logsOff function, that would have been from the default "Device" Hubitat uses).

Now that you have my driver loaded, set the driver Preference for logging to be "Trace", Save Preferences, then capture some of the logs after it has recorded the values.

[damianPL]

@snell

lemented. It DOES look like you have the driver later on, since it got the error (because I do not

i connect again and below is results

where i can change preferance?

[snell]

On the device's page, you want to select the "Enable Logging" dropdown and set it to Trace. The log you captured above still looks odd though, like it is not from my driver.

If you want to shoot me a Message so we can work it separate, that might be useful. Here is a screenshot of the Preferences also: