zha-device-handlers icon indicating copy to clipboard operation
zha-device-handlers copied to clipboard

[BUG] Tuya/Saswell TRV (TS601/_TZE200_c88teujp) stuck in schedule mode

Open blazewicz opened this issue 2 years ago • 0 comments

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:

  1. Pair TRV with Tuya GW using Tuya app
  2. Program any schedule using Tuya app
  3. Pair TRV with ZHA
  4. 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

blazewicz avatar Oct 09 '22 16:10 blazewicz