TS0601_thermostat (_TZE200_ckud7u2l) Bugs after Update

[geigervibe]

What happened?

Few days ago I updated z2m from version 1.22.1-1 to 1.28.2-1 and today to 1.29.0-1. Since then I've had problems with the thermostat, in particular I noticed that the presets can no longer be selected in Homeassistant and the scheduling (programming_mode) are no longer displayed in Z2M. Two screenshots showing what I mean:

Homeasstant:

Schedule/programming_mode in Z2M:

If I restore the old version, then it behaves normally again immediately. Also, when I changed the batteries yesterday, I was forced to re-join the thermostat (done that with the old version). Previously this had not been necessary. After changing the battery, I could no longer send anything to the thermostat, such as preset, system_mode, programming_mode, force, etc. There was no error message and nothing was visible in the logs either, it just didn't respond to that.

There may be other errors, but this is what I noticed.

The valve_detection option has never worked, neither then nor now. I can click on on/off as I want, nothing happens and the switch icon is not visible either:

What did you expect to happen?

With the old version it was as following:

Homeasstant:

Schedule/programming_mode in Z2M:

How to reproduce it (minimal and precise)

Homeasstant:

Z2M:

Zigbee2MQTT version

1.29.0-1

Adapter firmware version

20210317

Adapter

zStack3x0

Debug log

No response

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[geigervibe]

I have now installed every update up to version 1.30.0-1 hoping that the mentioned issue is resolved. After that wasn't the case, I'm now back to version 1.22.1-1

I also noticed that the thermostat was pretty unreliable. I often had to freeze because the thermostat was not open, although it showed 100%. While I can't say for sure that this behavior was due to recent updates, I'll see if the behavior persists now with the rolled back version 1.22.1-1.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[pakagi]

I often had to freeze because the thermostat was not open, although it showed 100%.

I'm observing the same, during past several weeks - all of my valves sometimes show 100% but are closed, and seems se be not mechanical but sw problem as e.g. pressing Ok/boost make it open correctly. I have also the TS0601_thermostat (_TZE200_ckud7u2l) model.

But I'm not sure if this is related to update of zigbee2mqtt (I'm on 1.30.1) or update of the valve firmware which I've done recently too (I'm using version 87, now checking if there is any possibility to downgrade the firmware, but seems it is not possible ?)

@geigervibe please did the revert of zigbeee2mqtt to 1.22.1 help for you ? And what is your valve firmware version ? (can be seen under zigbee2mqtt device "State" tab)

[geigervibe]

No, it is the same behavior at 1.22.1 too, I had my doubts in this matter anyway. I have also observed the opposite behavior recently, that 0 is displayed even though the valve is open, but that doesn't happen that often. But then it heats up the room without end.

For the first problem I created an automation as a workaround, which recognizes this situation (valve 100, but does not heat), then the automation switches system_mode to 'off' and then to 'heat' and a few minutes later to 'auto'. As soon I have the time, I will also build an automation for the opposite case.

What surprises me is that there were no such problems during the last heating period, at least I didn't notice it and I didn't update the firmware since then either. I don't see the current firmware version in either the state of device or ota, which surprises me too. When I used the device for the first time, I tried an update, but this was not carried out. Unfortunately, I can't remember now whether a version was shown to me at the time, but I think so. Since then I have paid no more attention to the firmware.

Also, I can't see any pattern under which circumstances it regulates. There are cases where it opens the valve in 5% increments even though the target temperature is sometimes 4-5 degrees away. It then takes 100 minutes until the valve is fully open. And in other cases, it will instantly jump to 100 even though the target temp isn't far off. I noticed something similar when closing. ...pretty stupid AI...

All this has very probably nothing to do with z2m. Once the heating season is over I will full reset the device and then I will see.

But the problems I described in the first post are real and reproducible on my side. As soon as I updated z2m to the current version at the time, the problems mentioned recurred. With version 1.22.1 I don't have these display and control problems. How are these things on your side?

[pakagi]

Regarding the problems from 1st post: I also cannot see and update the schedule, and IMO that is related to https://github.com/Koenkk/zigbee2mqtt/issues/16161. Changing preset works ok for me, both from z2m and from HA.

Regarding the valve sometimes closed when telling 100% (and vice versa): I have succeeded in downgrading the valve firmware from 87 to 85 (from 1.1.7 to 1.1.5), for now on one of the valves, and now waiting if it will happen again on it or not.

[geigervibe]

how do you up/downgrade your thermostats? using z2m or other tools?

[pakagi]

how do you up/downgrade your thermostats? using z2m or other tools?

Using z2m. I did it as follows:

added this to configuration.yml

ota:
  zigbee_ota_override_index_location: ota.json

created ota.json, in the same dir as configuration.yml:

[
    {
        "fileVersion": 85,
        "fileSize": 233894,
        "manufacturerCode": 4098,
        "manufacturerName": ["_TZE200_ckud7u2l", "_TZE200_cwnjrr72", "_TZE200_ywdxldoj"],
        "imageType": 5634,
        "sha512": "aefc41c93329f36f87ac955a1b2f15706c8371e9ad275234b6519c84a76c642037fc63f71236829c764ed5898dc7aedc27736797faf1bc1dfeec0e93>
        "url": "1600167449-si32_zg_uart_connect_sleep_ZS5_ty_OTA_1.1.5.bin",
        "force": true
    }
]

and placed the file 1600167449-si32_zg_uart_connect_sleep_ZS5_ty_OTA_1.1.5.bin also in the same dir

then from z2m gui I used the OTA and it worked... hope this helps.

But running my valves downgraded too short yet to tell if it helped.

[geigervibe]

thanks.. at this time, I will do not up/downgrade... the thermostat is in use an I have no time to troubleshoot right now. besides, there could be something more wrong on my side, as I can't see the current version of thermostat in z2m... but I will take a look later in few weeks. You may have then some insights...

where did you find the bin-file? is there an archive to download several versions?

[pakagi]

I'm not sure where I have taken the file from, probably here: https://github.com/Koenkk/zigbee-OTA/tree/master/images/Tuya

In my case, I see the current firmware version under z2m GUI, under the device "State" tab, looks like this:

...
"update": {
        "installed_version": 85,
        "latest_version": 85,
        "state": "available"
    },
...

[geigervibe]

I'm almost certain I've seen it there before. but nothing is currently visible there in this regard and under ota it looks like this (and the button does nothing):

[geigervibe]

the rollback to 1.22.1 wasn't without problems either, it's possible that the update info is disturbed because of this. I remember seeing something in the homeasstistant-logs. But it had to be done quickly, so I didn't pursue the matter any further. I'll take care of all that in a few weeks...

[pakagi]

Regarding the problem with thermostatic valve telling 100% while being closed: unfortunately the valve firmware downgrade didn't help, I still observe it randomly on my 4 valves. Really strange, the previous heating season there was no such trouble.

As you wrote above that you use automation as workaround for that problem, please how do you detect that the valve is in this fault state (like telling 100% but actually closed) ?

[geigervibe]

re: firmware downgrade didn't help, I still observe it randomly on my 4 valves.

Did you also reset them completely, if that's even possible?

re: Really strange, the previous heating season there was no such trouble.

Same here, at least I can't remember any such drama. I wasn't sure if I caused the error somehow. But with your statement I can rule that out, which in turn raises more questions. My hope was that the fault would disappear after a full reset (which I did not yet). Downgrading wasn't my big hope as I never upgraded the thermostat.

re: workaround

We have hot water convectors where you can remove the cover at the top. For other reasons, I placed a temperature sensor in each of the important heaters and in the case of the faulty thermostat, I use this also to uncover a contradiction between the thermostat and the actual heating effect.

The automation then looks like this in HA, although I have to make adjustments every now and then. Recently I lowered the central heat and then I had to do it again. Detecting the not really closed valve was more difficult than the reverse case, since it takes longer for the heater to cool down than it heats up. But in 90% of the cases it works.

alias: AM-Winter-Raum-Thermo-Notein
description: 'Detect false 100 state'
trigger:
  - platform: numeric_state
    entity_id: sensor.gate_zb_thermostat_t1_position
    above: '50'
    for:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
condition:
  - condition: numeric_state
    entity_id: sensor.zb_tempsensor_s1_temperature
    below: '30'
action:
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: 'off'
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: heat
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: auto
mode: single

alias: AM-Winter-Raum-Thermo-Notaus
description: 'Detect false 0 state'
trigger:
  - platform: numeric_state
    entity_id: sensor.gate_zb_thermostat_t1_position
    for:
      hours: 0
      minutes: 45
      seconds: 0
      milliseconds: 0
    below: '10'
condition:
  - condition: numeric_state
    entity_id: sensor.zb_tempsensor_s1_temperature
    above: '35'
action:
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: heat
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: 'off'
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - device_id: 6943fab012408252ae83255b80d06439
    domain: climate
    entity_id: climate.zb_thermostat_t1
    type: set_hvac_mode
    hvac_mode: auto
mode: single

[pakagi]

Did you also reset them completely, if that's even possible?

I tried doing the "factory reset" via advanced / A9 / set from 88 to 00 and OK. It looks like it reset the valve (but probably not completely, e.g. it remembers the daily schedule even after the reset). But it didn't help for that 100% when closed problem, it appeared again next morning.

In my case, it seems that I cannot even make the valve working again remotely by forcing to heat / delay / off / delay / auto like your automation is doing, it has no effect. But at the same time I can make it work by doing basically the same using the keys on the valve (long press of the arrows to make it open / close), so still seems like a sw problem...

[geigervibe]

The preset I tested and used the system_mode-switch (heat/auto/off) was in manual and schedule. The force-switch (normal/open/close) should do the same, but never tested force in my automations. I'm remember, that when I updated z2m, some more was faulty than I reported here, maybe system_mode and/or force was one of them. At least I could not switch between the presets, if I remember it correctly.

The delay in my automations is only for the time it takes to transmit and the confirmation (first delay), the second delay to wait for valve to open or close, although one minute should suffice for the second delay, I just used 5 minutes to be really sure.

Is there no way to do a full reset on the thermostat directly?

[pakagi]

Just a update regarding that thermostatic valve telling 100% while being closed (or reverse case) problem: one of my valves had defect, and was replaced with a new one. And it is happening even on the new one, without any intervention (so for sure not related to any firmware update).