zha-device-handlers
zha-device-handlers copied to clipboard
[BUG] Tuya/Saswell TRV (TS601/_TZE200_c88teujp) stuck in schedule mode
Describe the bug Some Tuya TRV's, Sasswell and it clones in particular, like to enable schedule mode in unexpected conditions.
I have 6 TRV's of this type and I have used them with Tuya app ("Smart Life") then with Zigbee2MQTT and now with ZHA. After the migration to ZHA my automations stopped working because my set-points were constantly overridden by values from a schedule that I have previously set in Tuya app. I've tried pairing with Tuya GW again and disabling the schedule but devices seem to enable the schedule by default upon pairing with ZHA and/or possibly after switching from "off" to "heat" mode.
This renders TRV's that have been previously configured with a schedule uncontrollable via ZHA.
I do have a working PoC of a quick-fix for this issue and I'll try to publish a PR with it.
To Reproduce Steps to reproduce the behavior:
- Pair TRV with Tuya GW using Tuya app
- Program any schedule using Tuya app
- Pair TRV with ZHA
- Get frustrated because values programmed in the schedule keep overriding your desired set-points
Expected behavior I expect TRV to keep the requested set-point,
Device signature
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0301",
"in_clusters": [
"0x0000",
"0x0001",
"0x0004",
"0x0005",
"0x0201",
"0xef00"
],
"out_clusters": [
"0x0001",
"0x000a",
"0x0019",
"0x0201",
"0xef00"
]
}
},
"manufacturer": "_TZE200_c88teujp",
"model": "TS0601",
"class": "zhaquirks.tuya.ts0601_trv_sas.Thermostat_TZE200_c88teujp"
}
Additional context
This issue was already noticed and worked-around by Zigbee2MQTT developers, see code highlighted below:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/toZigbee.js#L5877:L5879