Tuya TRV602Z not so well supported
What happened?
This TRV listed as supported in the devices pages is in fact partially supported.
- Auto mode and schedules is not working.
- Temperature settings can only be set to round temps in GUI whereas the device itself allows 0.5° steps.
- Motor thrust is not working.
- Screen orientation shows only two options whereas the device has four different orientations.
Before going into details, as there is a lot of confusion on Tuya's devices identification, here is the exact data I have from Zigbee pairing:
Manufacturer: Tuya
Model: TRV602Z
Zigbee Model: TS0601
Zigbee Manufacturer "_TZE204_ltwbm23f"
Moreover, "TRV602Z" is indeed written on the device itself, and the picture correspond (the new OLED display).
Auto mode and schedules problem:
In "manual" modes, presets are working well. If I set Preset to "Eco" or "Comfort", the target temperature displayed on the valve itself corresponds to the respective temp settings and the mode icon follows the Preset.
The "Auto" mode doesn't work as intended. First, when the valve is set to "Auto" mode, the icon on the valve is OK (the one with a clock), but the target temperature displayed is not the one that is in the schedule (here 20.0 as per the factory default "06:00/20.0 08:00/15.0 12:00/20.0 14:00/15.0 18:00/20.0 22:00/15.0"), but stay on the "Eco" setting.
And, here is the worst problem, as soon as we update a schedule in the GUI, this scrambles the device settings. I did a simple test. Factory default schedule is "06:00/20.0 08:00/15.0 12:00/20.0 14:00/15.0 18:00/20.0 22:00/15.0" for all days. I just changed the schedule for the current day to "06:00/19.0 08:00/17.0 12:00/19.0 14:00/17.0 18:00/19.0 22:00/17.0" (without touching hours, just the target temperatures to be sure that I was not wrong on the time periods syntax).
After applying this new schedule, the TRV displays the antifreeze icon and target temperature is 5°C. For other untouched days, it's OK, it works according to schedules.
While googling for support of this _TZE204_ltwbm23f particular model, I found this discussion where the proposed converter works for the daily schedules (file trv601z_trv602z.txt, renamed into .js): discussions 25269
Motor thrust problem:
This setting seems to just be silently ignored, and always stays to "middle". If I click on "Weak", I can see in the logs that it immediately returns to "Middle". Same on the GUI as soon as it is refreshed.
Display orientation problem:
If I change screen orientation on the device itself using the push button, over the 4 possibilities, the following errors are triggered in the logs for positions right and left:
[2025-02-05 13:53:00] error: z2m: Exception while calling fromZigbee converter: Value '2' is not allowed, expected one of 0,1}
[2025-02-05 13:53:00] debug: z2m: Error: Value '2' is not allowed, expected one of 0,1
at Object.from (/app/node_modules/.pnpm/[email protected]/node_modules/src/lib/tuya.ts:546:27)
at Object.convert (/app/node_modules/.pnpm/[email protected]/node_modules/src/lib/tuya.ts:1880:57)
at Receive.onDeviceMessage (/app/lib/extension/receive.ts:170:51)
at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:23)
at EventEmitter.emit (node:events:530:35)
at EventBus.emitDeviceMessage (/app/lib/eventBus.ts:130:22)
Same with Value '3' for other not supported orientation.
The relevant frames I found in debug mode for this setting are:
[2025-02-05 13:53:00] debug: z2m: Received Zigbee message from '0xa4c1386bc7fed5ff', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,180],"type":"Buffer"},"datatype":2,"dp":5},{"data":{"data":[2],"type":"Buffer"},"datatype":4,"dp":113}],"seq":56320}' from endpoint 1 with groupID 0
[2025-02-05 13:53:00] error: z2m: Exception while calling fromZigbee converter: Value '2' is not allowed, expected one of 0,1}
And
[2025-02-05 13:53:03] debug: z2m: Received Zigbee message from '0xa4c1386bc7fed5ff', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[3],"type":"Buffer"},"datatype":4,"dp":113}],"seq":56832}' from endpoint 1 with groupID 0
[2025-02-05 13:53:03] error: z2m: Exception while calling fromZigbee converter: Value '3' is not allowed, expected one of 0,1}
So, it seems that dp 113 with values 2 and 3 holds left and right orientation.
What did you expect to happen?
No errors and full support of all cases.
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
2.1.0-1
Adapter firmware version
Not relevant
Adapter
Not relevant
Setup
Home Assistant OS
Debug log
No response
Got 10 of these TRVs, investigating how to implement some features. Found that schedule config done via Tuya app values can't be recognized by current converter. Also don't know yet how it handles boost mode (available only in auto mode). No countdowns advertised, no boost switch either. Boost time only shows current setting (if chosen 30 mins it will stay 30 mins until they pass) Also you can configure UP to 6 schedules per day. It can be 1 or 5 or 6.
This is my device btw https://a.aliexpress.com/_EIxem1I
This is how its interface logs like on Tuya app.
I guess I've found how their engineers have done the schedule to support all the features they provide.
@Koenkk I know we are not in the right place (should we probably move to converters repo?), but are there any converters with complex functionality like composite groups?
I've found some semi-complex one for the following device https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/tuya.ts#L4598. However to support full schedule functionality for this device, it will be even more complex
Nobody wanting to capitalize on discussions/25269 work? As said, the converter prototype that can be found here is working with schedules. By the way, @andreypuhovsky, the TRV you mention is not the same model, the picture on AliExpress link doesn't correspond. For information I bought mines here: https://fr.aliexpress.com/item/1005004733341777.html. They are advertised as TRV602Z and this is even written on the valve itself.
Pictures can be different but the inner part is the same. I almost did whole converter, just need more time - I have my full-time job :). Already did the schedules to work the same as in tuya app - you can setup a mode to start at certain time or a manual temperature. Also you can have UP to 6 schedules per day (you can just setup 1 or 5 or full 6 transitions)
The code provided above is not complete for a full set of scheduler features.
fyi @g-chevalier I've finished my work, but this is still considered as beta :) I'm currently testing it on 2 different devices which are being detected as _TZE204_ltwbm23f
- https://www.aliexpress.com/item/1005008383187509.html (model on device TRV702Z)
- https://www.aliexpress.com/item/1005008226702664.html (model on device TRV601Z)
However these are identical without cover and "screen". Both are having your device on some or more pictures in the product description.
I guess I will share the implementation as external converter tomorrow in z2m-converters repo discussions (and mention it here), because it will take a while to get it in a release version. The implementation took 800+ lines of code and a week of investigation and development :) This can't be just transferred as-is to main repo.
Functionality as below
Thank's @andreypuhovsky you for your hard work! I'll test your converter with my device when it will be available. This will add a new model (TRV602Z) to the list.
@g-chevalier here you go https://github.com/Koenkk/zigbee-herdsman-converters/issues/8819
@andreypuhovsky, I just posted some feedback into your request to comments. Thank you again.
i have a issue too, my model _TZE204_ltwbm23f, i can't use scheduler
Hello,
Based on Andrey's version (credits and many thanks!), I created my mod of this converter. You can download it here: https://github.com/sstefanowski/Z2M_converters/blob/main/TRV602Z/andreypuhovsky_sstefanowski_mod--TZE204_ltwbm23f-beta5.js
My version fully replicates the device behaviour in Z2M and HA, while introducing a bit different organization of Modes and Presets. My motivation was adjust mapping to Modes/Preset like in very popular TS601_thermostat https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html. Some explanation: This implementation is a bit "deviated" from the specification of HVAC Modes of Home Assistant, but I feel it reflects functionality of the smart-valve much better:
- HVAC mode OFF is reserved for the state when the Valve is totally closed, so we are sure the Radiator is not heating (the preset does not matter in this mode)
- HVAC mode HEAT is reserved for the state when the Valve if fully opened so we are sure the Radiator is heating at max power (the preset does not matter in this mode)
- HVAC mode AUTO is for all the presets when the Valve opens and closes AUTOmatically, by comparing ambient temperature with the temperature set on the device (by one of the presets, schedules, or even manually by the user). So, it means that all the presets of the valve are valid ONLY in the AUTO mode.
I've tested it briefly, and it successfully synchronizes device Modes with HA Presets when I switch modes in Z2M, but also when I play manually on the device.
This is how Device modes of operation are mapped to Modes/Presets of Z2M/HA in my converter:
| Device Mode as described in Manual | Device display | Z2M/HA Mode/Preset | Device activation and Behaviour |
|---|---|---|---|
| Off | Off (icon) + OF | Off /None | Activated by turning down the knob down, below min temp or by pressing the knob on the device until Off icon appears |
| On | Heat (icon) + ON | Heat / None | Activated on the device by turning knob up, above max temp. This preset fully opens the valve, so it's equivalent to Andrey's "100%" preset. |
| Anti-frost | Snowflake (icon) + 5 | Auto / Sleep | Activated by pressing the knob on the device until Snowflake icon appears or... when you set manually temperature to "Sleep" value (while device not in Programming/Schedule mode) |
| Eco | Moon (icon) + 15 | Auto / Eco | Activated by pressing the knob on the device until Moon icon appears or... when you set manually temperature to "Eco value" (while device not in Programming/Schedule mode) |
| Comfort | Sun (icon) + 20 | Auto / Comfort | Activated by pressing the knob on the device until Sun icon appears or... when you set manually temperature to "Comfort value" (while device not in Programming/Schedule mode) |
| Custom? | no icon + manually preset temperature | Auto / Manual | Activated when you manually change the temperature on the device while it was in Off, On, Sleep, Eco, or Comfort mode. The set temperature will remain for a long time (until the user changes any settings), therefore, this mode is called Manual. If the manually set temperature is equal to one of the preset temperatures (Sleep, Eco, Comfort), then the device switches automatically to the preset indicated by the set temp |
| Programming | Clock (icon) + scheduled temperature | Auto / Schedule | Activated by pressing knob on the device until Clock icon appears. Automatically changes temperature according to schedule |
| Programming (Adjusted) | Clock (icon blinking ) + manually preset temperature | Auto / Complex | Activated when the Device was in Schedule mode (device=Programming) mode and the user manually changes the temperature. The Clock icon on the device starts blinking. The manually adjusted temperature lasts until the next scheduled change comes, then the device switches automatically back to Schedule preset. If the user manually readjusts the temperature to the value that matches the current Scheduled temperature, the device goes back automatically and immediately to Schedule preset. |
| Boost | (no icon) + "bO" | Auto / Boost | The Boost mode can be activated only from the Z2M/HA. It turns temp to MAX last for the number of pre-configured minutes, then the Device goes back to Schedule mode (Programming mode on the device) |
| Vaccation mode | (no icon) + "HO" | Auto / Away | The Away mode can be activated only from the Z2M/HA. It lasts for the number of pre-configured days, then the Device goes back to Sleep mode |
I think my mod works like described above. No matter if you change the setting on the device or in Z2M/HA the states, modes, and presets (including icon on the device) should be fully synchronized.
@andreypuhovsky, @g-chevalier Let me know what you think.
NOTE: This version is dirty and logs a lot of lines directly to the Z2M log (in a dirty way). If you like this version, I'll clean up this later.
Hi @sstefanowski,
Thank you for your dedication and time for this mini-project.
I have to mention one important thing here — it seems that there are a lot of different devices with the same Product Name (TRV602Z), each might have a little bit different firmware.
Im my case, I have a device which doesn't support the "complex" preset. If I change temp manually by turning knob/programmatically via Tuya app, it immediately switches to manual mode and never comes back to auto. As a lot of you (users) of different devices report that you actually have it, I think this is a variation of the product :)
Your division by actual operation modes (auto, when it automatically controls valve, manual when you control valve) seems to be viable, but it seems to me to be different from other devices available in Z2M. We are purchasing such devices to always let them control valve by variables provided by users (us), i.e. always auto mode based on temp and, optionally, time. (p.s. I know some users are automating the valve control f.e. on HA side by manually controlling valve opening %, but this device is not the case – it doesn't allow to)
TLDR; So it might be confusing if someone either replaces devices with this product or using them alongside.
Let's wait a little bit longer for other opinions. Will also be happy to hear some thoughts on this from you.
Thank you, Andrey.
Hi Andrey,
Regarding hardware/firmware. Yeah, it's strange. I have this device
It's often described as TRV601 but... mine has manufacturer id
_TZE204_ltwbm23f and is recognized as... TRV602Z.
REgarding Modes/prsets
I just replicated the functionality using the strategy from very popular (GTZ04, TS0601, HY368). I used TS0601 for a few years and found its mode/preset system is very easy to understand.
https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html
climate.system_mode --> OFF (valve is closed), HEAT (valve is fully opened), AUTO (valve changes its state automatically, based on preset or manually set temperature). As simple as that...
Regarding Manual preset....
It's NOT when the user sets a percentage (I know this cannot be controlled). The Manual preset jumps-in when the user sets current_heating_setpoint (target temperature) manually (by device knob or in the application), and then the valve (device) starts opening and closing "automatically" to keep this temperature. So, in this case, the system_mode=AUTO and preset=Manual
Now... regarding to Complex preset...
-
Complexjumps-in ONLY when previous preset wasSchedule... (in ANY OTHER preset --> using knob changes toManual) - My hardware/firmware has a
Complexstate (even if not explicitly described in docs) - it's represented by the "blinking clock" icon on the device. My device goes back toSchedulewhen the next scheduled time comes (if it was previously inSchedulepreset), but of course, the device sends no other info but current-heating-setpoint. Now... the code of my converter checks if a recently received current-heating-setpoint is equal to the temperature predefined in the currentScheduleand switches back to Schedule ONLY if the new current-heating-setpoint equals the temperature from the current schedule. This is also how my device works ("blinking clock" icon indicatingComplexchanges to "non-blinking clock" ofSchedule)
Question: If I understand correctly, your Valve will stay in Complex preset forever (just like in Manual preset). What icons are displayed on your device, then? What happens when you manually (using knob) change your temperature back to equal temperature from current Schedule (like first the Auto/Schedule sets temp to 20, then you turn knob to 22 and then after a few seconds you turn back to 20)? In my case, the device goes back to Schedule preset (clock icon stops blinking), and my code reflects this logic....
-- BTW... Are you based in Warsaw? If you are we may have a beer... ;) Cheers...
Hi @andreypuhovsky & @sstefanowski ,
First, I apologize for the delay of answer.
Thank you sstefanowski for the time invested in your variant.
Bad news, it seems that the list of different devices having product name TRV602Z and the _TZE204_ltwbm23f signature increased! This starts to be a nightmare for managing the converter… The one I have don't have the so called "Complex" mode (with the clock blinking). By the way, shouldn't it be "Temporary" as it is a temporary override of the current schedule that will go off at the next schedule time slot?
From the paper documentation given in the box, the modes are:
To try to better explain all this diversity on behaviors, I searched again for documentation of the model I have, and did not find any accurate user manual describing exactly it's behavior (except the one from a link given in the paper doc, pointing to https://manual.rti-tek.org/en/TRV602Z-TYC). Also, search on the RTI TEK company doesn't bring valuable information.
Considering the change introduced around HVAC Auto mode by sstefanowski, I'm not comfortable with this approach of dealing with "auto". In this new approach, "auto" means the TRV regulate automatically the temperature following the current target. My opinion is that it is not really interesting as it is the basic job of a TRV. In the HVAC world,
- "auto" is more depicting the fact that the temperature setting points are automatically managed by a schedule for energy savings.
- "Off" meaning heating is off and the valve is closed.
- "On" meaning the TRV is heating constantly (at the current target, except if forced at 100 % / summer, see below) irrespective of any schedule, potentially wasting energy.
Considering the special "summer ON", here is what I found in the paper document: "During summer months when heating is not needed, it is recommended to disable heating and keep the valve open by selecting the ON mode. This practice helps prevent valve seizure and extends its service life." Regarding this preset, the Andrey's converter shows "100%" on HA GUI, which is correct.
Finally, my preference would go to the Andrey's converter, with perhaps those changes:
- Frost icon mapped to "Antifrost" Preset.
- Manual preset implemented and showed in GUI in cases where it is possible.
Thank again to all.
Hello @g-chevalier, @andreypuhovsky,
Okay, I understand your comment about using HEAT mode for any non-scheduled operation and AUTO mode for scheduled operations. I just assumed my proposal was more popular because I've seen it elsewhere (TS0601), but since there are no other voices, we can do whatever we want. Unless any other voices appear, I think we could go with your approach.
--
So, now the only major difference between my version and Andrey's is the Complex (aka Temporary) preset. I guess IF IT EXISTS if must be reflected in the converter. Otherwise, the state of TRV hardware will desynchronize with the state of Z2M.
So, are you sure you do not have Complex/Temporary preset in your devices?
Kindly NOTE:
- My paper doc (attached to my TRV) also DOES NOT say a word about this operation. Even more... the paper it says that after turning a knob the valve switches to "custom" (our
Manualpreset). - But.... I can surely observe how my hardware/firmware works. When I use knob to changed scheduled temperature it will last only until next scheduled time comes (and then TRV jumps/sets back to the next scheduled temeperature).
Obviously, you have different hardware, so (forget about "clock blinking", which is clearly in my device) and...
Could you do the simple hardware test, checking the existence of the Complex/Temporary preset?
I mean "test" is the execution of a scenario like this:
-
Set the schedule of TRV in Z2M (day of the week/time/ temp) to expect:
- The current time/temperature to 10C
- The following/next temperature change to 20C in 5 minutes.
-
Use hardware (knob) to set TRV in manual mode to 7C.
-
Use hardware (knob) to change TRV device to Schedule/Auto mode (in my hardware it's represented by clock icon). Wait until the temperature on the TRV changes to the currently scheduled 10C
-
Use hardware (knob) to change TRV to 15C. (in my hardware clock starts blinking, in you it may not)
-
Wait 5-6 minutes until the next scheduled time comes and... check if your hardware jumped automatically new scheduled temp - 20C
If TRV jumps automatically to 20C (the next scheduled temperature), then it will continue using Schedule - it was in Complex/Temporary mode and now it's in Auto/Schedule mode, and this fact should be reflected in Z2M (which is my implementation doing).
I'll wait for your comments (result of the test above) before applying any changes to create a "universal converter". Thank you.
We definitely are having different firmware configuration built in the devices. Thanks to one of the users of the device, I have the following info that the following features are actually different from device to device:
OLED screen Temporary mode in Auto mode 0: ecogaz panel, 1: Tuya panel clone 0: model 705, 1: model 706 70x series temperature symbol Adaptive thrust calibration Ultra‑low battery antifreeze adjustment Default screen orientation Enhanced child lock Brightness timing adjustment Window function Temperature control logic Power statistics
So we will either have to write universal converter that will support all the features, OR some minimal stuff which is general across all. Third option is to have several converters for different devices
@sstefanowski , I confirm that when I set manually (with the knob), a target temperature while in auto (scheduled) mode:
- The hand icon appears to tell the TRV is in manual mode.
- And the TRV doesn't return to auto mode at the next schedule time.
Could you please share here the value of TRV config variable?
andreypuhovsky--TZE204_ltwbm23f-beta6.txt
You have to restart the device to show it almost instantly. The value is not being reported very frequently.
I have 2 different devices with the same product name (_TZE204_ltwbm23f).
This
And this
First has value 138. It has window function support, temperature control logic (pid) and not ecogaz panel (tuya clone?) from the list above.
Second has value 10. It has window function support, temperature control logic (pid) and ecogaz panel from the list above.
Please share your values so we will understand how many modifications we have here.
Thanks @g-chevalier for your test.
@andreypuhovsky I see your point. I think we do not need to have all the features, but we should focus on syncing modes/presets between the device and Z2M, as this is a critical function - users need to know what mode of heating is on the device while looking just at Z2M. This means that having "Temporary" mode handled is important, as otherwise the state of the device and Z2M gets unsynchronized.
Note: I've just noticed that the @malwikl has already reported the existence of "Temporary" mode here https://github.com/Koenkk/zigbee-herdsman-converters/issues/8819#issuecomment-2664930793 He has it in the documentation of his model, represented by two icons "clock"+"hand". I do not have this in my docs, but I can observe this behaviour, and as I mentioned... in my model, this special state is represented by the icon of a "blinking clock".
After applying "beta6" I can see:
Thanks @sstefanowski Take a look here
Wow... Thank you. So, we could use this map (especially bit0) to control how to change modes/presets, if temperature is adjusted manually while in Auto/Schedule mode. This is great.
BTW. It looks like my model is having most of the features. I can test it for you later if you want.
Yeah, your device is the most feature-rich :) Mine are very poor 🗡
@andreypuhovsky : very impressive findings! Is it pure reverse engineering or did you find dome documentation?
One question: does the "Temperature control logic" correspond to the PID control of temperature? This is one of the features that interested me a lot when buying this TRV (and I confirm that it works like a PID when in this mode).
My TRV reports 154 (1001 1010) in "Trv config". So, features supported and characteristics are:
- Windows function.
- Temperature control logic.
- OLED Screen.
- 70x series temperature symbol = "o".
- Model = 705.
- Tuya panel clone.
Bellow is a picture from the WEB of my model:
I noticed that some very similar TRV do have a non-alignment between the nut and the TRV's body. See next picture:
On my model this is on the same axis.
@g-chevalier we have this thanks to one of our great users (kudos to Stanislav H! thank you, if you reading this ;) ) He contacted one of the manufacturers of this device, and they have shared a documentation on it.
I was not sure about the legal part if I share it here, but it seems it's ok.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Remove stale
Hello @andreypuhovsky , @g-chevalier,
I implemented a new version of this converter here https://github.com/Koenkk/zigbee-herdsman-converters/issues/8819#issuecomment-3289669934 It's ready for testing
Making a long story short, I implemented your suggestions:
- I implemented support for devices with Complex preset (temporary change of Schedule) and devices without this feature - based on
TRV_CONFIG bit1. Obviously, I tested it just with my device, which supports the feature. Please verify that this converter switches correctly to Auto/Manual in your case. - Most of the presets (except Schedule/Complex and Boost) use Heat mode. Only Schedule/Complex and Boost are in Auto mode.
Details of new modes and presets are described in the table in the linked post.
Happy testing....
Hello, I just realized that my _TZE204_ltwbm23f that should be Tuya TRV601 are recognized as TRV602Z and there are several problems:
- the image is wrong, but it doesn't really matter
- the Motor thrust shouldn't be exposed
- the local temperatura calibration is limited to ±10 °C but it should be ±30 °C with 0.1 °C steps
Yes, many different devices share the same "fingerprint." We are working on a new converter here, and testers are welcome.
Currently, we focus on the best support for built-in device presets/modes. Later, we will handle optional/unsupported features (mostly by hiding them).