[Device Support Request] Saswell Tuya Thremostat Family Improved Quirk

[PLTorrent]

This quirk supports following devices:
Saswell | SEA801 | _TYST11_KGbxAXL2 | GbxAXL2 | ✅ Sas II | 798
Saswell | SEA802 | _TZE200_c88teujp | TS0601 | ✅ Sas I | 576
Saswell | SEA802 | _TYST11_c88teujp | 88teujp | ✅ Sas II | 576
HiHome | WZB-TRVL | _TZE200_zuhszj9s | TS0601 | ✅ Sas I | 1064
HiHome | WZB-TRVL | _TYST11_zuhszj9s | uhszj9s | ✅ Sas II | 798
Hama | 00176592 | _TZE200_yw7cahqs | TS0601 | ✅ Sas I | 923
Hama | 00176592 | _TYST11_yw7cahqs | w7cahqs | ✅ Sas II | 798
RTX | ZB-RT1 | _TZE200_azqp6ssj | TS0601 | ✅ Sas I | 923
RTX | ZB-RT1 | _TYST11_azqp6ssj | zqp6ssj | ✅ Sas II | 1064
Sanico | - | _TZE200_9gvruqf5 | TS0601 | ✅ Sas I | 1064
Sanico | - | _TYST11_9gvruqf5 | gvruqf5 | ✅ Sas II | 1064
Saswell | SEA802 | TZE200_zr9c0day | TS0601 | ✅ Sas I

This quirk is experimental and supports following functions of the TRV:

• On/Off
• Temperature Setpoint
• Child Lock On/Off (actual child lock has to be activated manually on the device)
• Window Detection On/Off
• Anti-Freeze On/Off
• Limescale Protection On/Off
• Away Mode On/Off
• Schedule Mode On/Off
• Temperature Correction setting
• Battery reporting (Full/Low)

Not implemented:

• Scheduling changing/setting

The quirk:
Saswell.zip

How to activate the quirk: #693 (comment)

Please re-pair the device after new quirk is used.

Since currently we are not able to change names of on_off entities below is the description:

1. Window Detection
2. Child Lock
3. Anti-Freeze
4. Limescale Protection
5. Schedule Mode On/Off
6. Away Mode

Please test and provide feedback. Especially the _TYST11 lineage since my device is _TZE200 based.

Special thanks to @MattWestb @jacekk015

[supersebbo]

This is great! Thank you.

I'm curious though, I still see no mention of the "Valve Position" attribute, or the ability to force the valve position. Zigbee2MQTT has been able to both read and set the valve position on the TS0601 series for quite a long time which makes it a lot more powerful for creating heating control systems in HA. Can you take a look into this?

https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html#controlling-device-specific-features
https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html#position-numeric

https://github.com/Koenkk/zigbee-herdsman-converters/blob/b239676de9f191ba3ee76c1d96a493b4db9d3f3a/converters/fromZigbee.js#L4134

https://github.com/Koenkk/zigbee-herdsman-converters/blob/b239676de9f191ba3ee76c1d96a493b4db9d3f3a/converters/toZigbee.js#L4468

https://github.com/Koenkk/zigbee-herdsman-converters/blob/b239676de9f191ba3ee76c1d96a493b4db9d3f3a/converters/toZigbee.js#L4580

[PLTorrent]

@supersebbo TS0601 is a very wide family of products. AFAIK on Moes likes you have valve position reporting. Saswell and clones do not report valve position in any way. Even in the original tuya app. Also there is no endpoint that reports it as it changes so no way to implement it.

[supersebbo]

@supersebbo TS0601 is a very wide family of products. AFAIK on Moes likes you have valve position reporting. Saswell and clones do not report valve position in any way. Even in the original tuya app. Also there is no endpoint that reports it as it changes so no way to implement it.

Thanks. So the only way to 'control' these clone valves is by manipulating the set-point? Do you by any chance know the internal logic? It seems like they only open the valve if the set-point is >1 degree over the TRV measured temperature, but I don't know if this is true for all cases.

I am trying to work out if it's more efficient in terms of Zigbee traffic to keep changing the set-point in order to meet the heat demand of my room temperature sensors i.e. { TRV_set_point = TRV_measured + (Room_set_point - Room_measured) }, or whether to apply the "temperature correction" based on the room sensor.

[MattWestb]

@supersebbo what is the device signature for your device ?
TS0601 is all tuya "DP devices" that is using tuya MCU and some with older zigbee modules.
Some tuya TRV is only supporting setpoint manipulation and other have more function but must knowing your device for knowing what is possible.

By manipulating one TRV by forcing the valve you is braking the regulation algorithm and you cant getting it working well (its takes days for one good TRV getting it self calibrated and working well).

By manipulating the local temperature calibrating in small steps you can still getting the TRV working well but is not easy getting it right and if you is doing it it too large steps its losing the calibrations for its algorithm.

I think the best is getting one good offset for the local temperature and then letting the TRV doing there work and calculating the heat demand from how much the TRV heating from val % reported or if not possible software calculated as being done for the Site TRVs.

[supersebbo]

@MattWestb

"manufacturer": "_TZE200_c88teujp",
"model": "TS0601",

It's not performing badly in the current weather using the set-point manipulation quoted above. But I suspect when the weather changes this will cause some big over-shoots.

[MattWestb]

I have one Siterwell in my kitchen for nearly one year but its little complicated then its in 2 levels and 3 hearings and 2 have normal mechanical ones and the Siterwell is doing the "fin work" and have working very well only one time getting the valve jammed.

The Saswell can also being off / on / auto mode but using on / off its cant using the algorithms for getting good regulation so better using the setpoint changing.

Testing and see how its working but i think if its not have to less heating it shall work OK or its getting problem then need heating and cant getting the heating from the heating system.

[supersebbo]

The ciritcal thing is that the offset from the actual room temperature is not constant. Look the purple line versus the blue line. When the radiator is off the TRV temperature is almost the same as the Room temperature, but when the radiator is on, the TRV temperature is as much as 10 degrees hotter than the room temperature.

The TRV does a good job tracking it's own temperature sensor (light-blue vs purple line) but this is no-where near the actual room temperature.

[PLTorrent]

@supersebbo to be honest I am not very satisfied with how this TRV performs. I can compare it to netatmo and netatmo performs much better so far. I have just started testing it on the radiator, before I was just developing the quirk so it was easier to have it on the table. My general remark is that you should not be forced to manipulate the setpoint, you should just set the temperature and it should work as set and more or less keep the temperature. I mean the non-connected TRVs do it pretty well so why the intelligent one should not be capable of doing it equally well? If you have to set it all the time then for me it means... find another TRV... but that's just me.

[supersebbo]

My impression is that the TRVs are deliberately quite ‘dumb’ and I expect a lot of processing, learning and feedback happens within the Tuya App that you do not get when using them as raw Zigbee devices.

These TRVs are actually quite good at controlling and tracking the TRV measured temperature against the TRV set-point. See graph below, the light-blue and purple lines around 6am each day, the TRV measured temperature tracks the TRV set-point almost exactly, with an approx. 1°C tolerance. This is effectively what a dumb TRV does mechanically. However, the temperature at the TRV is vastly different to room ambient temperature.

The reason for the need to manipulate the set-point is because of the non-linear relationship between the room ambient temperature and the TRV measured temperature. Radiators, by their very nature, radiate heat as a point-source which has a complex interaction with the air and objects in the room, but what is very clear is that as the TRV is so close to the heat source its internal measurement is heavily affected by the heat from the radiator. When the radiator is on, the temperature measured at the TRV can be up to 10°C hotter than the ambient temperature measured in the middle of the room (see 27th Nov 08:00 on graph). Yet when the radiator is cold, the TRV measured temperature is very close to the room ambient temperature (see 27th Nov 12:00 on graph).

For this reason, you cannot simply apply a fixed offset to the TRV to try and compensate for this. Here’s why, let’s say in this scenario you want the room ambient temperature to be 18°C. It would be trivial to conduct a simple experiment to heat the room and see what the TRV temperature was when the ambient sensor hits 18°C. In my plot above, you can see when the room (dark blue) line gets close to 18°C during the 6am heat cycle, the TRV measured temperature is 24°C. This would imply an offset of 6°C. However, move along the graph a little to around the 12:00 time, you see that now because the radiator is at a lower output setting and the room has absorbed a lot of heat, the room ambient temperature and the TRV measured temperature are the same. If you applied the same 6°C offset here, it would cause the TRV to open and start heating the room again, when it’s not needed.

I believe the only way to achieve proper ambient room temperature control is to use a feedback loop that manipulates the TRV set-point based on the ambient measurement. This is what I’ve tried to implement here, the aim is to get the amient room temperature (dark-blue line) to be as stable as possible around the ambient room set-point by manipulating the TRV set-point (light blue) and as you can see, this achieves it quite well for a first attempt.

[jacekk015]

Only PID can probably make it to work properly.

[MattWestb]

CN-Hysen "Moes" HY366, HY 367, HY368 an HY369 is having PID if looking on some data from http://www.xmhysen.com/ProductInfoCategory?categoryId=126920

[jacekk015]

@supersebbo

My impression is that the TRVs are deliberately quite ‘dumb’ and I expect a lot of processing, learning and feedback happens within the Tuya App that you do not get when using them as raw Zigbee devices.

That's actually not true, most of them has PID and need to still work without Tuya gateway.
Tuya app is for temp set and etc. - what's the difference if you set a temp form App or on TRV locally.
Some of TRV has static open valve positions, like 25%, 50%, 75% or 100%
My Maxsmarts now has 29% opened valve and it never go back up/down to same value.

It's nothing new that the TRV is mounted on a heat source. Standard TRVs are also working same.
The thing is that, because of construction, they are slowly reacting devices, so they smooth the reaction to changes.
The same reason is why most of Window Detection functions don't even react.
If the temp doesn't drop rapidly TRV will open and heat more, instead of closing the valve for Window open reason.

[supersebbo]

@supersebbo

My impression is that the TRVs are deliberately quite ‘dumb’ and I expect a lot of processing, learning and feedback happens within the Tuya App that you do not get when using them as raw Zigbee devices.

That's actually not true, most of them has PID and need to still work without Tuya gateway. Tuya app is for temp set and etc. - what's the difference if you set a temp form App or on TRV locally. Some of TRV has static open valve positions, like 25%, 50%, 75% or 100% My Maxsmarts now has 29% opened valve and it never go back up/down to same value.

We are saying the same thing. As I showed above, the PID control on the TRV is quite good, it is able to control the temperature at the TRV accurately and consistently, but it can only do PID with the inputs it knows about, which for a TRV on it's own is just the valve position, the set-point and the temperature measured at the TRV. There is no way the TRV on it's own can know about the temperature in other parts of the room it is heating.

The Tuya app allows you to add additional temperature sensors and assign them to rooms to help the TRV, in this case it must be the Tuya app doing the additional processing, or at the very least forwarding set-points/corrections values to the TRV based on the in-room temperature sensors.

[PLTorrent]

The Tuya app allows you to add additional temperature sensors and assign them to rooms to help the TRV, in this case it must be the Tuya app doing the additional processing, or at the very least forwarding set-points/corrections values to the TRV based on the in-room temperature sensors.

@supersebbo TBH I have sniffed this TRV with ZBOSS on the original tuya gateway with tuya app and seeing how quiet the device is zigbee-wise I am not so sure it does anything more with tuya app. I'm not sure it is able to have any use from external thermometer, even if you assign one to the same "area" in tuya app as the temp correction settings are in the range -6 to +6 degrees with a full degree step. It is also not possible to send data to device on the room temp endpoint and this is what one would expect in case of such "external thermometer" adjustment. It even does not report the valve position.

What you could do with the HA automation is you could read external thermometer, compare with TRV readout and send correction as the difference of the two up to a degree of precision using the temp correction setting BUT... please bear in mind that device reports temperature rather seldom, and constantly sending it zigbee traffic will impact battery life. You could also just forget it has its own thermometer and just based on the room temp send it a full ON setting (30C setpoint) and when hot enough send it an OFF command based solely on the external thermometer. And probably this would work best.

EDIT: It does report when it was heating (valve open) to the tuya app but it does so retrospectively like every hour or so. The history in the tuya app is not immediately available as well. So not usefull for the device adjustments.

[digital-cowboy-91]

Hello guys,

I really appreciate your work here. My _TZE200_yw7cahqs starts working like I would expect it to work, specially with that calibration entity. Anyway is there a way, how to force the quirk to send to TRV decimal numbers? I just tested to set resolution to 0.5deg and set manually the value to like 1.5deg, TRV enregister it. But When trying to do the same using Home Assistant, it sends to TRV just rounded values.

Update: Not supported by device

[supersebbo]

@PLTorrent

So this is consistent with what I've seen. I started to do the control by calcuting the difference between the room set point and the room measured temperature and adding this difference to the TRV mesured temperature - creating a 'virtual' demand signal at the TRV which takes into account the radiated heat from the radiator.

This resulted in the TRV making very frequent on/off cycles (which are easy to hear because these TRVs are pretty noisy) as often as every 2-3 minutes. This is in line with what you observed as while the TRV is 'quiet' and doesn't send the temperature very often, the TRV does respond immediately to commanded temperature changes. This latency in the feedback loop actually induces the very frequent on/off cycles as the feedback from the TRV is out of cadence with the input.

This fine grained control would be very beneficial if the valve was clever enough to modulate the supply based on the proximity to the target temperature, however it doesn't do this, it's just full off or full on.

So as you suggested, the most 'efficient' way to use these TRVs as part of an integrated heating system is to command them full-on (30 degrees) and full off (5 degrees) purely based on the room heating demand signal from the room thermometer and thermostat, and ignore the TRV measured temperature entirely.

Of course you still need to apply some smoothing to this otherwise it would rapidly on/off as the room entered the hysterisis cycle as it gets close to, then overshoots the target temp, cools down and so on, but this is fairly simple to encode in HA automations.

[jacekk015]

@pticon91 You also have to change resolution of the GUI field
from[line 361]

self._update_attribute(self.attridx["resolution"], 1)

to

self._update_attribute(self.attridx["resolution"], 0.5)

[digital-cowboy-91]

@jacekk015 , yeah, that's done, but thank you for additional info. It will be definitely handy to have this info here, when someone else would like to achieve the same result.

[dieneuser]

Since version HA2022.4 the quirk does not work properly for my Hama _TZE200_yw7cahqs & _TYST11_yw7cahqs devices. I had to adjust line 159 in the Saswell.py file to get ZHA to work at all. (change var name from "manufacturer_attributes" to "attributes")
ZHA detects the device correctly, but the temperature cannot set or get. A repair of the devices did not bring any change.
Without this quirk I have only basic functions - no additional functions like the offset temperature that I need.

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[zillion42]

I have 9 Hama _TZE200_yw7cahqs devices. I have not installed this quirk but judging from what @dieneuser wrote, it's not worth trying at this point. Any chance someone can look into this ? I would really like to get all the modes working. Thanks in advance.

[jacekk015]

@zillion42 That quirk code wasn't modified to apply HA code changes made in April.
Will try too look at it. It needs to be rewritten in some areas.

[zillion42]

@zillion42 That quirk code wasn't modified to apply HA code changes made in April. Will try too look at it. It needs to be rewritten in some areas.

Sounds promising... thx a lot !

[jacekk015]

Someone need to test the quirk.
I didn't touch quirk programming since over a year, so it's possible that a bugs are present.
trv_saswell.py.zip

[dieneuser]

Hello @jacekk015,

Thank you for the effort.
Your quirk works perfectly. All additional functions are available.

[wtom]

For me it also works perfectly.
I own the Hama _TZE200_yw7cahqs thermostat. I just have one question, is it possible to get the "heating" state as a binary sensor, i mean this little flame it shows when the valve is open.
https://www.zigbee2mqtt.io/devices/SEA801-Zigbee_SEA802-Zigbee.html#heating-binary
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices/saswell.js#L46
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/lib/tuya.js#L505

If i compare the attributes:
SASWELL_ANTI_FREEZE_ATTR = 0x010A # [0/1] on/off 266
SASWELL_WINDOW_DETECT_ATTR = 0x0108 # [0/1] on/off 264
saswellWindowDetection: 8,
saswellFrostDetection: 10,
it's matching, so the heating attr should be 0x0103? Does anyone know if this value works in zigbee2mqtt?

[jzielke84]

Keep in mind that the childlock switch will only enable the childlock function on the thermostat (e.g. holding down the button for 3 seconds). It won’t activate the lock itself. Quite a stupid way of controlling but that’s how a Hama technician told me how it works.

[digital-cowboy-91]

Yeah, there's def much more they can improve. Unfortunately Hama itself doesn't know completely how these TRVs work, as they are not a manufacturer. I had some chat with them too. But I like this product more and more since I finally create a sufficient automation / functionality workaround in nodered. Am just disapointed that Hama does not distinguish the versioning when selling this devices. I have 6 of those in (probably) v1 and now I bought 3 others this Christmas and it's v3 and obviously not compatible with existing quirk. Seems like they changed manufacturer, I've asked them to provide us some change log, let's see what they'll reply - however using Tuya gateway and App I do not see any difference.

[jzielke84]

@pticon91 True, Hama only acts as a reseller. They even don't have any technical documents (which I don't believe since they made the decision to sell this stuff in the first place by probably looking at some datasheets rather than throwing dices). One thermostat is working fine so far but another one I bought from a private seller just stepped out of my zigbee network on random occasions. Hence aside of one Hama thermostat I installed 3 from Aqara (which also still are buggy e.g. no batter status etc.). But at least they do their job and respond much faster to commands than the Hama ones. Too bad you can not flash the firmware of a zigbee device like you can with Tasmota.

[jacekk015]

Probably there's something wrong with manufacturers ID.
Need to do some testing on my own TRV and I will get back with test quirk.

[wtom]

Just for your info, i was also disappointed of how they work so i started to contribute on the "better thermostat" integration. And now I'm pretty happy because i have now like a tolerance of 0.1 to 0.3 for the temperature to target temperature.

https://github.com/KartoffelToby/better_thermostat

[digital-cowboy-91]

Hello gents,

I've managed to make the _TZE200_h4cgnbzg work, for more info please see this comment.

[jacekk015]

Updated quirk below.
_TZE200_h4cgnbzg should work

NO changes in file below needed - all needed changes are embedded in the quirk itself:
usr/local/lib/python3.10/site-packages/zhaquirks/tuya/__init__.py

trv_saswell.py.zip

[jzielke84]

Warning: The latest HA version (2023.2) seems to break this quirk, thus making Zigbee impossible to start:

Error setting up entry Sonoff Zigbee 3.0 USB Dongle Plus - Sonoff Zigbee 3.0 USB Dongle Plus, s/n: 0001 - Silicon Labs for zha
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup
    result = await component.async_setup_entry(hass, self)
  File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 100, in async_setup_entry
    setup_quirks(config)
  File "/usr/local/lib/python3.10/site-packages/zhaquirks/__init__.py", line 409, in setup
    importer.find_module(modname).load_module(modname)
  File "<frozen importlib._bootstrap_external>", line 548, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 1063, in load_module
  File "<frozen importlib._bootstrap_external>", line 888, in load_module
  File "<frozen importlib._bootstrap>", line 290, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 719, in _load
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/config/quirks/trv_saswell.py", line 57, in <module>
    class CustomTuyaOnOff(LocalDataCluster, OnOff):
  File "/config/quirks/trv_saswell.py", line 115, in CustomTuyaOnOff
    command_id: Union[foundation.Command, int, t.uint8_t],
AttributeError: module 'zigpy.zcl.foundation' has no attribute 'Command'

[TheJulianJES]

@jzielke84 See #1061 (comment) on how to fix custom quirks.

[jacekk015]

All quirks will be corrected, later evening.

[jacekk015]

Quirk corrected
trv_saswell.py.zip

[jzielke84]

Thanks man! Kind regards, Julian From: Jacek Kończewski ***@***.***> Reply to: zigpy/zha-device-handlers ***@***.***> Date: Monday, 9. January 2023 at 20:59 To: zigpy/zha-device-handlers ***@***.***> Cc: Julian Zielke ***@***.***>, Mention ***@***.***> Subject: Re: [zigpy/zha-device-handlers] [Device Support Request] Saswell Tuya Thremostat Family Improved Quirk (Issue #1189) Quirk corrected trv_saswell.py.zip<https://github.com/zigpy/zha-device-handlers/files/10376449/trv_saswell.py.zip> — Reply to this email directly, view it on GitHub<#1189 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADGTG2Q5YHH7CUTDHKODTCTWRRUYVANCNFSM5I5L7IJQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[0x64746b]

Quirk corrected trv_saswell.py.zip

Thank you for your awesome work!! 🦸‍♂️

[thprim]

I have the trv _TZE200_h4cgnbzg, but the quirk ist not working for setting the temperature. It shows in HA the manual changes at the TRV, but changig the heat from HASS ist still not working despite the several hints and modifications in the published quirk files.

[jacekk015]

@thprim If you have same TRV it cannot work for few users and don't work for you. There's no need to do modification - code is corrected.

Did you:

• removed other quirks for this TRV?
• removed pycache folder?
• restarted HA after quirk upload?

To tell you more you need to enable debug logging and post the FULL HA logs from pairing process +10 minutes.
After few minutes after pairing try to change temp from HA. We will see that in the logs.

configuration.yaml

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    zigpy: debug
    zhaquirks: debug

You need to restart HA after changes above.

[thprim]

@thprim If you have same TRV it cannot work for few users and don't work for you. There's no need to do modification - code is corrected.

Did you:

* removed other quirks for this TRV?   ---> **YES**
* removed pycache folder?   ---> **YES**
* restarted HA after quirk upload?   ---> **YES**

To tell you more you need to enable debug logging and post the FULL HA logs from pairing process +10 minutes. After few minutes after pairing try to change temp from HA. We will see that in the logs.

I tried to change the heat value round the timestamp between 03:00 and 05:00

home-assistant.log

[jacekk015]

What I see:

• you have 2 TRVs _TZE200_h4cgnbzg
• for 99.999% you are NOT using my most recent quirk https://github.com/zigpy/zha-device-handlers/files/10376449/trv_saswell.py.zip

Here you set the temp to 19 degrees

2023-01-13 00:00:01.441 DEBUG (MainThread) [zhaquirks.tuya] [0xf3ef:1:0x0201] Mapping standard occupied_heating_setpoint (0x0012) with value 1900 to custom {615: 190}
2023-01-13 00:00:01.442 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=True, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=False), manufacturer=4417, tsn=136, command_id=0, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2023-01-13 00:00:01.443 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Sending request: set_data(param=Command(status=0, tsn=136, command_id=615, function=0, data=[4, 0, 0, 0, 190]))

Here is response from TRV - with ERROR: UNSUP_MANUF_CLUSTER_COMMAND

2023-01-13 00:00:08.247 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xF3EF), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=None, profile_id=260, cluster_id=61184, data=Serialized[b'\x18\x88\x0b\x00\x83'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=255, rssi=-55)
2023-01-13 00:00:08.248 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Received ZCL frame: b'\x18\x88\x0b\x00\x83'
2023-01-13 00:00:08.248 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=136, command_id=11, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
2023-01-13 00:00:08.249 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Decoded ZCL frame: ManufacturerThermostatCluster:Default_Response(command_id=0, status=<Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>)
2023-01-13 00:00:08.250 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Received command 0x0B (TSN 136): Default_Response(command_id=0, status=<Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>)

That error was repaired in latest quirk - so you cant use newest version.

If you would use it that line below:

2023-01-13 00:00:01.442 DEBUG (MainThread) [zigpy.zcl] [0xF3EF:1:0xef00] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=True, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False, *is_reply=False), manufacturer=4417, tsn=136, command_id=0, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)

would have is_manufacturer_specific=False instead of true.

That line of quirk code is responsible for that:

    server_commands = {
        0x0000: foundation.ZCLCommandDef(
            "set_data",
            {"param": TuyaManufCluster.Command},
            False,
            is_manufacturer_specific=False,
        ),
        0x0010: foundation.ZCLCommandDef(
            "mcu_version_req",
            {"param": t.uint16_t},
            False,
            is_manufacturer_specific=True,
        ),
        0x0024: foundation.ZCLCommandDef(
            "set_time",
            {"param": TuyaTimePayload},
            False,
            is_manufacturer_specific=True,
        ),
    }

Moreover - that lines says you don't use any custom quirk probably:

2023-01-12 23:57:00.002 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for _TZE200_h4cgnbzg TS0601 (a4:c1:38:bc:7a:f6:f1:a2)
2023-01-12 23:57:00.003 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.tuya.ts0601_trv_sas.Thermostat_TZE200_c88teujp'>
2023-01-12 23:57:00.003 DEBUG (MainThread) [zigpy.quirks.registry] Found custom device replacement for a4:c1:38:bc:7a:f6:f1:a2: <class 'zhaquirks.tuya.ts0601_trv_sas.Thermostat_TZE200_c88teujp'>

You are using:
https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_trv_sas.py#L264

So - start using my custom quirk and then you will be good.

[thprim]

What I see:

* you have 2 TRVs _TZE200_h4cgnbzg    --> **YES**
* for 99.999% you are NOT using my most recent quirk https://github.com/zigpy/zha-device-handlers/files/10376449/trv_saswell.py.zip  --> **YES** and **NO**, seems that I had an older version and tried also to use a different quirk file for that trv

I installed now your latest version and it seems now that it works fine for me. Temperature can now be changed which was the main goal for me.
Thanks a lot for your quick help and response, really appreciated !!!

btw: any idea how to get the on/off button functional? But honestly, that's not a showstopper or an urgent issue. It's also not working for the other 4 trv's I have with the standard zha implementation.
Update: On/Off is no still working. Seem's the issue was related with the old quirk I used before. Everything works good now. Sorry for unnecessary trouble.

[jacekk015]

Yes - switch it on/off on the TRV and post the logs.
Make some pause between switching on/off so the TRV could send it to HA.
That's an on/off of heating or what??

[jzielke84]

@thprim From what I know is that they need some time between changing from on to off. Also after being switched on, changing the temperature requires like 5 seconds to be in active 'on' state. I guess that's because they change to 16°C first when being switched on, regardless of the set temperature in HA. I have created a workaround in node red:

The wait node waits for hvac_mode to be 'heating'

You can import those If you like to:

[
    {
        "id": "b42e1d5c6cda0d9a",
        "type": "api-current-state",
        "z": "404303a28a34c76c",
        "name": "check office radiator hvac mode is off",
        "server": "c2541c0c.8532",
        "version": 3,
        "outputs": 2,
        "halt_if": "off",
        "halt_if_type": "re",
        "halt_if_compare": "is",
        "entity_id": "sensor.heizung_arbeitszimmer_hvac_action",
        "state_type": "str",
        "blockInputOverrides": false,
        "outputProperties": [
            {
                "property": "payload",
                "propertyType": "msg",
                "value": "",
                "valueType": "entityState"
            }, {
                "property": "data",
                "propertyType": "msg",
                "value": "",
                "valueType": "entity"
            }
        ],
        "for": "0",
        "forType": "num",
        "forUnits": "minutes",
        "override_topic": false,
        "state_location": "payload",
        "override_payload": "msg",
        "entity_location": "data",
        "override_data": "msg",
        "x": 1090,
        "y": 160,
        "wires": [["630619a7fccb2739"], ["ee6e87880c707f93"]]
    }, {
        "id": "630619a7fccb2739",
        "type": "api-call-service",
        "z": "404303a28a34c76c",
        "name": "set hvac_mode to heat",
        "server": "c2541c0c.8532",
        "version": 5,
        "debugenabled": false,
        "domain": "climate",
        "service": "set_hvac_mode",
        "areaId": [],
        "deviceId": [],
        "entityId": [
            "climate.heizung_arbeitszimmer_thermostat", "climate.heizung_bad_thermostat", "climate.heizung_kueche_thermostat", "climate.heizung_wohnzimmer_thermostat"
        ],
        "data": "{\"hvac_mode\":\"heat\"}",
        "dataType": "json",
        "mergeContext": "",
        "mustacheAltTags": false,
        "outputProperties": [],
        "queue": "none",
        "x": 1460,
        "y": 100,
        "wires": [
            ["9da6a3133c846f19"]
        ]
    }, {
        "id": "9da6a3133c846f19",
        "type": "ha-wait-until",
        "z": "404303a28a34c76c",
        "name": "wait for thermostat office",
        "server": "c2541c0c.8532",
        "version": 2,
        "outputs": 2,
        "entityId": "sensor.heizung_arbeitszimmer_hvac_action",
        "entityIdFilterType": "exact",
        "property": "state",
        "comparator": "is",
        "value": "heating",
        "valueType": "str",
        "timeout": "30",
        "timeoutType": "num",
        "timeoutUnits": "seconds",
        "checkCurrentState": true,
        "blockInputOverrides": true,
        "outputProperties": [],
        "entityLocation": "data",
        "entityLocationType": "none",
        "x": 1730,
        "y": 100,
        "wires": [["80e1a54c16f75faa"], []]
    }, {
        "id": "80e1a54c16f75faa",
        "type": "delay",
        "z": "404303a28a34c76c",
        "name": "wait 5 sec",
        "pauseType": "delay",
        "timeout": "5",
        "timeoutUnits": "seconds",
        "rate": "1",
        "nbRateUnits": "1",
        "rateUnits": "second",
        "randomFirst": "1",
        "randomLast": "5",
        "randomUnits": "seconds",
        "drop": false,
        "allowrate": false,
        "outputs": 1,
        "x": 1980,
        "y": 100,
        "wires": [
            ["ee6e87880c707f93"]
        ]
    }, {
        "id": "ee6e87880c707f93",
        "type": "api-current-state",
        "z": "404303a28a34c76c",
        "name": "get day temperature",
        "server": "c2541c0c.8532",
        "version": 3,
        "outputs": 1,
        "halt_if": "",
        "halt_if_type": "str",
        "halt_if_compare": "is",
        "entity_id": "input_number.tagestemperatur",
        "state_type": "num",
        "blockInputOverrides": false,
        "outputProperties": [
            {
                "property": "payload",
                "propertyType": "msg",
                "value": "",
                "valueType": "entityState"
            }
        ],
        "for": "0",
        "forType": "num",
        "forUnits": "minutes",
        "override_topic": false,
        "state_location": "payload",
        "override_payload": "msg",
        "entity_location": "data",
        "override_data": "msg",
        "x": 1460,
        "y": 180,
        "wires": [
            ["6e8296f80eac1624"]
        ]
    }, {
        "id": "6e8296f80eac1624",
        "type": "api-call-service",
        "z": "404303a28a34c76c",
        "name": "set temperature",
        "server": "c2541c0c.8532",
        "version": 5,
        "debugenabled": false,
        "domain": "climate",
        "service": "set_temperature",
        "areaId": [],
        "deviceId": [],
        "entityId": [
            "climate.heizung_arbeitszimmer_thermostat", "climate.heizung_bad_thermostat", "climate.heizung_kueche_thermostat", "climate.heizung_wohnzimmer_thermostat"
        ],
        "data": "{\"temperature\":\"{{payload}}\"}",
        "dataType": "json",
        "mergeContext": "",
        "mustacheAltTags": false,
        "outputProperties": [],
        "queue": "none",
        "x": 2000,
        "y": 180,
        "wires": [
            []
        ]
    }, {
        "id": "c2541c0c.8532",
        "type": "server",
        "name": "Home Assistant",
        "addon": true,
        "rejectUnauthorizedCerts": true,
        "ha_boolean": "",
        "connectionDelay": false,
        "cacheJson": true,
        "heartbeat": true,
        "heartbeatInterval": "30",
        "areaSelector": "friendlyName",
        "deviceSelector": "friendlyName",
        "entitySelector": "friendlyName",
        "statusSeparator": "",
        "statusYear": "2-digit",
        "statusMonth": "2-digit",
        "statusDay": "2-digit",
        "statusHourCycle": "h23",
        "statusTimeFormat": "h:m:s",
        "enableGlobalContextStore": false
    }
]

Keep in mind you have to change the properties of each node corresponding to your setup and probably ditch get day temperature since that's a input_number I have created in HA.

[digital-cowboy-91]

If they switch ON to 16deg automatically you have probably 'schedule' mode on - clock icon will be shining on the TRV. To turn it off double tap the TRV button. None of my TRV's turn ON automatically to 16deg or resets to 16deg if the schedule mode is off.

[thprim]

Yes - switch it on/off on the TRV and post the logs. Make some pause between switching on/off so the TRV could send it to HA. That's an on/off of heating or what??

See my comment in my reply. Everything is working now with the new quirk.

[zv0n]

Hi @jacekk015, I've edited the quirk file to make it so when TRV is off, it doesn't report as "heating" when temperature goes below target, could you add this patch to your code, please?

--- trv_saswell.py	2023-01-09 20:58:28
+++ trv_saswell_off.py  2023-01-23 01:26:54
@@ -465,6 +465,10 @@

     def hass_climate_state_change(self, attrid, value):
         """Update of the HASS Climate gui state according to temp difference."""
+
+        if self._attr_cache.get(self.attributes_by_name["system_mode"].id) != Thermostat.SystemMode.Heat:
+            self.endpoint.device.thermostat_bus.listener_event("state_change", 0)
+            return
         if attrid == SASWELL_ROOM_TEMP_ATTR:
             temp_current = value * 10
             temp_set = self._attr_cache.get(

I've tested this a bit and seems to work fine.

Btw do you think you could create a Github repository for the quirk file? It would make it easier to track the latest version and we could send pull requests with changes like these :)

[jacekk015]

@zv0n
Your change already included.
https://github.com/jacekk015/zha_quirks

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[zillion42]

github-actions bot closed this as not planned 11 minutes ago

Let's re-open this... Thx jacekk015