zha-device-handlers
zha-device-handlers copied to clipboard
[BUG / Device Support Request] Smart Air House keeper TS0601 _TZE200_dwcarsat v2
See https://github.com/zigpy/zha-device-handlers/issues/1313 for technical info
The current implementation isn't 100%.
It assumes it's the same as the _TZE200_ryfmq5rl
and _TZE200_yvx5lh6k
devices but it isn't.
The _TZE200_dwcarsat
actually has six sensors.
- Temperature - 0-60 °C
- Humidity - 0-95%
- CO2 - 0-1000 ppm
- Formaldehyde / CHOH (CH2O) - 0-10.00 mg/m3
- PM2.5 - 0-1000 ug/m3
- VOC - 0-99.9 ppm
Most of the above are visible, however, incorrect:
-
VOC Shows a value of 0 constantly measured by
µg/m³
which should be the PM2.5 measurement. -
CO2 Currently shows a value between 0 and 10 measured by
ppm
which doesn't really match any "normal" situation. Not sure what this value should stand for. It might be the VOC -
Formaldehyde / CHOH (CH2O) Currently shows a value of 350-400 measured by
ppm
which would be deadly and definitely not a normal situation. It looks like this might be the value that is meant for CO2. -
PM2.5 Not shown at all.
More info on the MQTT implementation here: https://github.com/Koenkk/zigbee-herdsman-converters/pull/3745/files
Hi Jory, I have the same concerns with this exact same device :)
Can confirm under ZHA I'm seeing similar issues with the TZE200_dwcarsat TS0601 device not showing all the sensors and the data being mismatched.
I actually have this same problem with a device shown as _TZE200_ryfmq5rl
Formaldehyde being at 378ppm right now, CO2 at 2ppm, VOC 1µg/m³. Temperature and humidity look plausible. No PM2.5 sensor on this one, it only has five sensors.
This is on the current dev branch of this repo, commit e3fa034284437595d1997326a8597086d623f413
device signature
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0100",
"in_clusters": [
"0x0000",
"0x0004",
"0x0005",
"0x0402",
"0x0405",
"0x040d",
"0x042b",
"0x042e",
"0xef00"
],
"out_clusters": [
"0x000a",
"0x0019"
]
},
"242": {
"profile_id": 41440,
"device_type": "0x0061",
"in_clusters": [],
"out_clusters": [
"0x0021"
]
}
},
"manufacturer": "_TZE200_ryfmq5rl",
"model": "TS0601",
"class": "zhaquirks.tuya.air.ts0601_air_quality.TuyaCO2SensorGPP"
}
@LittleFox94 Thanks for this, if even the 5 sensor model is showing inaccurate then I assume the whole integration for all smart air models is incorrect.
@MattWestb Do you have more information on how the sensor params are linked to the actual HA params? Besides the values being reported, was it tested that the values we're linked correctly?
I just noticed the values don't even change a lot after having the window open for half an hour
The original values in the comment above were before letting fresh air in after the night (bedroom+home office), only difference is formaldehyde now being at 368ppm - but Hass history suggests the 378ppm in the comment above were a typo (it shows constant 368ppm)
This could be the sensor of course, but might also point at a problem in the integration
(I'm using a USB dongle presenting an UART (EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis
) as coordinator and it's connected directly to that)
Hi @LittleFox94 A Formaldehype value above 100 ppm would be deadly ;). The exposure limit is 8 hours for 0.75 ppm and 15 minutes for 2 ppm (on the workfloor).
Your Formaldehype value probably stands for CO2 which is a normal "daily" value. Hence opening a window won't change it very much.
Yep, I'm aware that formaldehyde value being true would mean I'm dead ^^'
But shouldn't CO2 change when opening the window, by letting CO2 out? I thought it concentrates in rooms from .. breathing it out?
Hi @LittleFox94 If your usual value is around 350 then it means your house is "breathing naturally" so that's a good sign :) Of course this would depend on the isolation of your house and the room size but just from breathing this difference wouldn't be very large and very local in your room.
@JoryHogeveen I think all magic is being made in the INIT https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/air/init.py and i also think the DPs from some one that is having tuya integration and have looking in tuya dev for getting the information what its function liked to the device but its not 110% sure is correct.
@MattWestb Yep looks like it's handled there. Also looks like this is an issue that is also happening at Zigbee2MQTT: https://github.com/Koenkk/zigbee2mqtt/issues/11033
We have founding that many tuya device need some "tuya magic" being casting on them then joining (first was TS004F) but we have not getting it implanted in ZHA but HB and Z2M have getting it working and we need reading and writing attributes very early (or kicking the device so it rejoining) then the device is paring for getting it working. Then we can getting it working in quirks we can fixing nearly 10 bad devices and perhaps i can helping in this case 2 but we cant testing it for the moment.
Bad things is missing endpoints (2 devices), Not reporting attributes and having connecting problems / stooping committing or falling in sleep or cant getting time synced.
just for completeness, my sensor doesn't seem to actually send any updated data - it's not shown as connected in ZigBee visualization and all data is last updated "Yesterday" and right now there is a lot of Isopropanol in the air it should probably pick up as VOC ^^'
Edit: it's now updating regularly after I reconnected it
Can confirm that I'm having the same issues with this device. watching
Maybe related error logs:
Source: /usr/local/lib/python3.9/site-packages/zhaquirks/tuya/__init__.py:1295
First occurred: 6:09:32 PM (2 occurrences)
Last logged: 6:09:36 PM
[0x4093:1:0xef00] No 'handle_set_data_response' tuya handler found for [TuyaCommand(status=0, tsn=1, dp=20, data=TuyaData(dp_type=<TuyaDPType.VALUE: 2>, function=0, raw=b'\x00\x00\x00\x00', *payload=0))]
[0x4093:1:0xef00] No 'handle_set_data_response' tuya handler found for [TuyaCommand(status=0, tsn=3, dp=20, data=TuyaData(dp_type=<TuyaDPType.VALUE: 2>, function=0, raw=b'\x00\x00\x00\x00', *payload=0))]```
I have to add that this device is sending a huge amount of messages everyday. About 15,000-20,000 entries for some sensors and linkquality each day. Is it normal ?
I just bought this device and have the same issues as described above. Is there any unofficial quirk we can download?
Seeing the same issues.. Deadly Formaldehyde Concentration (about 300 ppm) and strange CO2 levels (either around 8 or 40.000)? Temp and Hum seem ok, no PM2.5 and VOC also looks kinda okish.
I also died of Formaldehyde several times over, if the value would be correct and PM2.5 is missing. Fix would be greatly appreciated.
Isn't this a pretty similar unit compared to the _TZE200_yvx5lh6k in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4990 ?
Also to link the topics https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5733
Can confirm under ZHA I'm seeing similar issues with the TZE200_dwcarsat TS0601 device not showing all the sensors and the data being mismatched.
I have the same model and only see one sensor - Voc_level - any idea why I can't even see temperature and humidity?
So, I have this sensor too and also didn't have anything other than VOC right after it is paired.
Other sensors appeared only after HA restart and CO₂/HCHO sensors are swapped. PM2.5 is missing as well.
I have several of these TZE200_dwcarsat TS0601 and can confirm the behavior that several others have reported. Would love to see these supported! For the time being, I have them integrated via Tuya, though even that isn't perfect since the temperature units use a weird ° character that isn't recognized. Here's how that shows up:
Except for the wonky temperature unit, this does correspond with what is shown in the Smart Life app:
Just updated HA Core from 6.6 to 8.0 and the temperature reading shows up correctly in °F now via the Tuya integration.
Just updated HA Core from 6.6 to 8.0 and the temperature reading shows up correctly in °F now via the Tuya integration.
@chaples55 Doing it via the Tuya integration means you need a Tuya hub? Looks like it works in zigbee2mqtt but not ZHA.
@arohl Yeah, I'm still using 5 of these things via a Tuya hub. I have a 6th one connected via ZHA to keep tabs on whether it is fully supported yet, but unfortunately that still is not the case.
I have a second ZigBee dongle coming soon so I can use both z2m and ZHA and ditch the Tuya hub entirely.
@chaples55 My SkyConnect arrived on Friday so I guess I can use my old dongle to run z2m - why didn't I think of that :-)
Having the same exact issues with the same model and ZHA with Skyconnect on homeassistant OS. Mismatched sensors values and missing pm2.5 sensor report. Any update here? any way to fix it? :)
I'm also having this exact same issue
Same issue here...