Tuya ts0601_thermostat_3 overrides current_heating_setpoint - schedule?

[ChrisKretschmer]

What happened?

Hi all
I got a couple of Tuya ts0601_thermostat_3 (https://www.amazon.de/dp/B0B5GY1288?) connected via zigbee2mqtt. The communication and integration in to home assistant works fine, but whenever I set a temperature via an automation or a UI control, it gets overridden with either 20° or 22° depending on the daytime.

I believe, this has something to do with some kind of internal schedule or something like that - sadly, there is no way to erase that schedule or to set the device in a mode, where this does not happen.

{ "battery_low": false, "child_lock": "LOCK", "current_heating_setpoint": 20, <-- set to 20 just 2 or 3 minutes after setting it to 13 "error": null, "frost_protection": "OFF", "linkquality": 69, "local_temperature": 20, "local_temperature_calibration": null, "running_state": "idle", "scale_protection": "OFF", "system_mode": "auto" }

I tinkered with all those settings, hoping that the child lock or scale protection setting would change that behaviour, but no success...

I also tried the edge version, but no success :(

Should I return those thermostats, or is this something fixable?

What did you expect to happen?

current_heating_setpoint should stay at the set value

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.30.2-dev commit: aa90765

Adapter firmware version

20210708

Adapter

zStack3x0

Debug log

No response

[UweLm]

I have the same problem since more than one year, see here #16859
And we are not the only ones...
zigpy/zha-device-handlers#1816
zigpy/zha-device-handlers#1815
zigpy/zha-device-handlers#1876
https://forum.iobroker.net/topic/59852/hama-smartes-heizk%C3%B6rper-thermostat/2?_=1668467039158

In ioBroker using the deconz Adapter one can view the properties of the sensor (or thermostatic valve):

It is possible to manually overwrite the "schedule" with an empty object, but shortly it will be overwritten as if by magic ;-) with some values like:
{"W124":[{"heatsetpoint":18,"localtime":"T10:18"},{"heatsetpoint":0,"localtime":"T07:00"}],"W3":[{"heatsetpoint":0,"localtime":"T18:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"},{"heatsetpoint":0,"localtime":"T00:00"}]}
I don't know where these values come from.
Changing "schedule_on" to false doesn't help.

In the Zigbee Adpter on ioBroker these "schedule" and "schedule_on" properties are not visible, but the thermostatic valve acts the same way as it does at deconz.

I'll keep you informed as soon as I've got any info.

KR Uwe

[capsel22]

Following, same issue

[lrljoe]

Swap over to Better Thermostat, it isn't perfect but gets rid of that issue.

[ChrisKretschmer]

I returned my thermostats and bought something different...

[lrljoe]

What'd you go for @ChrisKretschmer and are they markedly better?

[ChrisKretschmer]

I bought some "Brennenstuhl Connect Zigbee Heizkörperthermostat HT CZ 01"
They worked instantly and got no issues so far...

[github-actions]

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