Tuya / Whitelabel / ZONNSMART TV01-ZG radiator thermostat

[drdownload]

Information about the device + link

Bought from this Link: https://de.aliexpress.com/item/1005002377522262.html?spm=a2g0s.9042311.0.0.4d6f4c4dEXD4cF

Found this Listing with reverse image search: https://expo.tuya.com/product/600974

data/database.db entry of the device

{"id":27,"type":"EndDevice","ieeeAddr":"0x84fd27fffe2dd98b","nwkAddr":18218,"manufId":4098,"manufName":"_TZE200_e9ba97vf","powerSource":"Battery","modelId":"TS0601","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[0,4,5,61184],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"modelId":"TS0601","manufacturerName":"_TZE200_e9ba97vf","powerSource":3,"zclVersion":3,"appVersion":69,"stackVersion":0,"hwVersion":1,"dateCode":""}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":69,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1629911314030}

Things I tried

I tried to add an external converter following the tuya specific guide.

first I tried with the default code from: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_tuya_devices.html

then I copied the converter from the herdsman code that handles radiator thermostats and added the fingerprint.

however it always stays unsupported. I used this fingerprints: default config: fingerprint: [ { // The model ID from: Device with modelID 'TS0601' is not supported // You may need to add \u0000 at the end of the name in some cases modelID: 'TS0601', // The manufacturer name from: Device with modelID 'TS0601' is not supported. manufacturerName: '_TZE200_e9ba97v' }, ], model: 'TV01-ZG', vendor: 'ZONNSMART',

and herdsman converters code; zigbeeModel: ['TS601'], fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_e9ba97v'}], model: 'TS0601_thermostat', vendor: 'TuYa',

[thiscantbeserious]

Oh wow so I have both of these variants (2021/2020) paired via the official Tuya Gateway. Either they are different in hardware or its just a preset. No different firmwares.

Will try the TV02 code later.

I reproduced the bug doing temprature calibration via the Tuya app the other valve would just disconnect - this time at -1,7 before at -0,7 like the first one and you would need to re-pair it to get it to work again - so it seems like a Firmware bug more then anything else.

[geoffreylagaisse]

I found some bugs in Geoffreylagaisse code. You can test the code from my TV02 Zigbee. They seem to be compatible.

Sorry, @Geoffreylagaisse I didn't mean anything bad.

If that works, then I can put the two together.

Hey no worries, It's neither completely my code in the repo ... I kinda merged my external converter code within the code of somebody else, who did a half job. If your code is compatible with our device we could merge them together indeed, also keep in mind I've written the code so it's compatible with the home assistant components.

[vladi1234]

My code is without system_mode and is compatible with Homeassistant.

[thiscantbeserious]

@drdownload @vladi1234 @geoffreylagaisse

I went ahead and checked what the official Tuya Zigbee Gateway paired does with the App getting the current temp - it doesn't light up the screen. Has anyone checked Datapoint 115 == Check01 (label on their IoT Platform) of you?

See my comment here:

https://github.com/Koenkk/zigbee2mqtt/issues/9858#issuecomment-981719178

I didn't come around to try that since I never developed anything for zigbee2mqtt myself yet ... would be interesting to see what happens if you send "off" with the payload I mentioned there. But maybe it needs some sniffing too ?

Edit:

Yep that seems to be the correct one - just tried again - got the local temp, no screen light up:

`

2021-11-29 16:15:06 | Publish | Check01 | off | http publish -- | -- | -- | -- | --

`

I'm using the MOES variant thought.

[geoffreylagaisse]

Yes the 115 is the is_online datapoint we have found. So apparently it behaves differently on the same device ... Maybe they have different firmwares. Strange behavoir to trigger a command while zigbee has reporting endpoints. Thanks for letting us know.

[thiscantbeserious]

Stupid me ... could've checked the table above. Either way it works from the Tuya Gateway itself with the MOES TV01-ZB, I guess I'll have to give a spin in regards to trying all codes myself for this specific variant just to be sure everything works as expected ...

[thiscantbeserious]

Alright - pushed all code here:

https://github.com/thiscantbeserious/zigbee-herdsman-converters/tree/refactor_and_complete_Moes_TV01-ZB_code

And verified it working on my local Hass OS deployment for Moes TV01-ZB (==TV01-ZG) using the code-base from @vladi1234

is_online update works too - without crashing the device, and without turning the screen on.

Only thing I'm not too happy about is the schedule settings ... either the format is different or it's unfinished for now?

The UI could use some work here ...

Will check later today the code from my old TS0601 devices, since they have that part implemented just fine ... so that it's much more accessible and will merge it over (I think their implementation is a little bit different, but still ...).

Also holiday-mode will only activate shortly on the device and then switch back to auto if you manually switch it on - is that supposed to be that way? Pressing the button should in my book set the current date-time so that it stays there, no?

[vladi1234]

https://github.com/Koenkk/zigbee-herdsman-converters/issues/3142#issuecomment-962460788

[geoffreylagaisse]

Just a random thought instead of bloating the repo with redundant and double code, isn't it better to add our device models to the code of @vladi1234 ?

[vladi1234]

That's what I meant, test it first. does it fit 100% to your TVR.

[thiscantbeserious]

So far I found no bugs ... and nothing that didnt work - boost works too, with manual values thats really usefull and awesome.

@vladi1234 @geoffreylagaisse

So I guess adding the signature to the codebase of valdi12345 seems to be the correct way to go forward in regards to support.

Can you do a short PR @vladi1234 or should I do it?

If anything appears to work differently we can fork the codebase but so far it seems - internal by firmware and DPs - they're 100% the same.

Also documentation needs an update in regards to functionality.

[vladi1234]

Hi, I'll do that because I have to make small corrections anyway. Is that TuYa TV01-Zigbee _TZE200_e9ba97vf okay?

[thiscantbeserious]

Hi, I'll do that because I have to make small corrections anyway. Is that TuYa TV01-Zigbee _TZE200_e9ba97vf okay?

These 3 variants:

  fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_e9ba97vf'},
            {modelID: 'TS0601', manufacturerName: '_TZE200_husqqvux'}],
        model: 'TV01-ZB',
        vendor: 'Moes',
        description: 'Thermostat radiator valve',
        ota: ota.zigbeeOTA,
        fromZigbee: [fz.ignore_basic_report, fz.ignore_tuya_set_time, fz.moes_thermostat_tv],
        toZigbee: [tz.moes_thermostat_tv],
        whiteLabel: [{vendor: 'Tesla Smart', model: 'TSL-TRV-TV01ZG'}],

[vladi1234]

Merged #3469 into master.

Please test whether everything is OK.

[olylak]

Hi guys,

Is it possible to use the changes for TV01-ZB you mention here as an external converter?

I have 4 TV01-ZB thermostats and it looks like I'm having the same issues: when they join I see a lot of errors and currrent temperature is not updating.

I'm new to z2m. If there is a separate converter to re-use your fixes would be really nice.

Thanks in advance.

[vladi1234]

Why as an external converter? You can update for z2m, then they are automatically included.

[olylak]

Hi @vladi1234 I'm using version 1.22.1 commit: c2b5229.

What version should I use to get those fixes? Thanks

[vladi1234]

You have to use dev. 1.22.1-dev commit: e5321d3f

[vladi1234]

You have to use dev. 1.22.1-dev commit: e5321d3

It may take a while for them to appear on releases

[olylak]

You have to use dev. 1.22.1-dev commit: e5321d3

Thanks a lot. I have updated to dev branch and now it looks better.

But there is no system mode now and not possible to update setting for "Auto Mode". I can see "Apply" button but no way to enter new values. Device picture is wrong, previous one was correct.

Is is supposed to be that way or something wrong on my environment?

[thiscantbeserious]

Yes - its now identified as a different device because they're internally the same.

I didnt think about that the documentation and picture however - so its currently using the wrong picture and wrong documentation (that being the only issue).

@vladi1234

from a user perspective questions / issues (that are no real issues) will continue to pop up ... so might be better to branch off like I did in my dev-branch. Means duplicate code unless you have a better idea, or maybe Koenk?

@olylak The previous code was bugged and incomplete - for example boost didn't work.

I did test this code before it was merged and verified everything was working properly

and it still does for me on current dev branch. No errors - nothing.

You're likely confused - current_heating_setpoint is what you're really looking for.

If you use Home Assistant for example it still works as before.

[vladi1234]

I'm clarifying with Koenkk.

[geoffreylagaisse]

@vladi1234 Am I correct when I say that the code doesn't trigger any local temperature updates from the device right now?

[drdownload]

@geoffreylagaisse : I'm not aware of any way to periodically send a DP from the converter or any other way to force the updates

[vladi1234]

@geoffreylagaisse Yes, it is correct, the code cannot yet query local_temp regularly. But you can use any home automation program for this, so that queries are triggered with certain time intervals.

Example for TV02-Zigbee: Send local_temperature_calibration 0 every 15 min. I've already described it here. https://github.com/Koenkk/zigbee-herdsman-converters/issues/3142#issuecomment-976885156

As I understood, when local_temperature_calibration 0 is sent for TV01-xx, then display lights up.

Then Example for TV01-xx: Send online ON every 15 min.

[vladi1234]

You have to use dev. 1.22.1-dev commit: e5321d3

Thanks a lot. I have updated to dev branch and now it looks better.

But there is no system mode now and not possible to update setting for "Auto Mode". I can see "Apply" button but no way to enter new values. Device picture is wrong, previous one was correct.

Is is supposed to be that way or something wrong on my environment?

@olylak Yes, there is really no system_mode, because TVR does not have this function, it is self-made by geoffreylagaisse for HA. I think the system_mode is not necessary in this case, it also works well with HA without system_mode.

As for auto-schedule, I'm still working on it, but there is a bigger problem TVR does not accept converter commands. May be that will be impossible to realize. But in our case a schedule is not necessary because we all use home automation programs and only manual mode will be necessary for controlling the TVR, which is logical!

[pvyleta]

@vladi1234 thanks for the investigation!

If for any other newbie like me this ends up to be the first thing they stumble upon when searching for "TRV02/TRV01 not update current temperature", this is the super-simple automation that does the job of updating the temperature on my three devices every 15 minutes:

- id: '1639952459076'
  alias: update_temperature
  description: ''
  trigger:
  - platform: time_pattern
    minutes: '/15'
  condition: []
  action:
  - type: turn_on
    device_id: 0602b7bbf81d4a95acfbf32bc00d7e7d
    entity_id: switch.thermostat_1_online
    domain: switch
  - type: turn_on
    device_id: 7f1ce8a12531f8f1c80332e9ad92301f
    entity_id: switch.thermostat_2_online
    domain: switch
  - type: turn_on
    device_id: 0003637326d5ab27f972c82b2e5a63c3
    entity_id: switch.thermostat_2_online
    domain: switch
  mode: single

It can even be set up from GUI easily by selecting as action-typ 'Device' and as action 'Turn on thermostat_x_online'

[olylak]

@olylak Yes, there is really no system_mode, because TVR does not have this function, it is self-made by geoffreylagaisse for HA. I think the system_mode is not necessary in this case, it also works well with HA without system_mode.

As for auto-schedule, I'm still working on it, but there is a bigger problem TVR does not accept converter commands. May be that will be impossible to realize. But in our case a schedule is not necessary because we all use home automation programs and only manual mode will be necessary for controlling the TVR, which is logical!

Thanks for the explenation. And what about the device modes?

That's what is supported by the device:

And that's how HA shows it:

Why it shows "Cool", "Dry" and "Fan" modes if the device does not support it?

[vladi1234]

@olylak Yes, there is really no system_mode, because TVR does not have this function, it is self-made by geoffreylagaisse for HA. I think the system_mode is not necessary in this case, it also works well with HA without system_mode. As for auto-schedule, I'm still working on it, but there is a bigger problem TVR does not accept converter commands. May be that will be impossible to realize. But in our case a schedule is not necessary because we all use home automation programs and only manual mode will be necessary for controlling the TVR, which is logical!

Thanks for the explenation. And what about the device modes?

That's what is supported by the device:

And that's how HA shows it:

Why it shows "Cool", "Dry" and "Fan" modes if the device does not support it?

Because HA makes a universal mask for every possible termostat. That means you have to delete unusable modes, that's logical!

Here are the instructions with other TRVs on how to do this. But in the last version 2012.12 ... HA removed this function. https://github.com/Koenkk/zigbee-herdsman-converters/issues/2937#issuecomment-991938419

That's why there is a second guide on how to do it.

These are the settings of the TV01-Zigbee: customize.yaml

climate.xxxxxxxxxx:
  hvac_modes:
  - heat
  preset_modes:
  - auto
  - manual
  - holiday
  assumed_state: true
climate.xxxxxxxxxxx:
  hvac_modes:
  - heat
  preset_modes:
  - auto
  - manual
  - holiday
  assumed_state: true

[dvovla]

Hello. I am testing the Tesla Smart TSL-TRV-TV01ZG trv and I need to know if and how it is possible to set a schedule. In the Z2M documentation, this trv is listed under TV02-Zigbee. But it is not clear from the description what the payload should look like. Can anyone advise me? Thanks.

[vladi1234]

Hi, I made PR for holiday_mode yesterday, and now I want to make screenshot with new interface.

[Krzysztonek]

Dear @vladi1234 , I followed this thread from the very beginning. Since I'm not technically skilled enough, I'm totally lost now.. This is why I would beg you for your kindness and support me to resolve the following issue: I have ZONNSMART TV01 thermostats installed at home, being so far controlled by HA and the external converter made by this community. All devices worked for me quite nicely till May/June this year when the summer came and no house heating was required. Now, I'm trying to take the control of my thermostats again, but they simply don't want to work (batteries are fully charged). When changing any of their parameters on the Z2M add-on dashboard I can see the result on a thermostat's display but its corresponding entities remain unknown . This applies to: climate.radiator_bedroom, number.radiator_bedroom_away_preset_temperature, number.radiator_bedroom_boost_time, number.radiator_bedroom_comfort_temperature, number.radiator_bedroom_eco_temperature, number.radiator_bedroom_local_temperature_calibration, switch.radiator_bedroom_frost_protection, switch.radiator_bedroom_heating_stop, switch.radiator_bedroom_is_online, switch.radiator_bedroom_window_detection.

Moreover, the climate.radiator_bedroom entity is NOT accessible from custom: button-card on HA dashboard, where it has been initially located. Taping its icon brings no reaction.

To fix this issue I removed all thermostats from the Z2M add-on and joined them again from scratch. But it changed nothing. Please kindly guide me to the right direction to fix this huge problem. Maybe one of the Home Assistant Updates (several updates appeared since May/June) caused such a problem? Maybe some of the functions working before May/June are no longer available and I need to replace the converter? Where can I find and download the most updated external converter for this device?

I also tried another approach: I simply removed the external converter from Z2M add-on configuration, and my Zonnsmart TV01 thermostat is STILL RECOGNIZABLE and indicated as SUPPORTED, however, it's NOT working correctly (the same issue as mentioned above remains unresolved):

Will you, please very much, help me? I will provide any further details you may need.

[vladi1234]

I have ZONNSMART TV01 thermostats installed at home, being so far controlled by HA and the external converter made by this community. All devices worked for me quite nicely till May/June this year when the summer came and no house heating was required.

Hello @Krzysztonek, I have nothing to do with the external converter you are using. But I have been working on a converter for official zigbee2MQTT support.

If you want everything to work, then you need to update zigbee2MQTT up to the current version 1.27.2.

And remove this external converter.

[Krzysztonek]

Hello again, @vladi1234

Many thanks for your response! :)

This is Z2M add-on version I use:

So, this is the most updated version. I also removed the external converter from the Z2M add-on configuration and restarted this add-on. Now the Z2M add-on configuration is following:

external_converters: [] devices: - devices.yaml groups: - groups.yaml homeassistant: true permit_join: false mqtt: base_topic: zigbee2mqtt user: addons password: Cae9Shahy8phaenaesh8aimeriuche9excvquoi7pheol0peil4moh5SieghuaQu server: mqtt://core-mosquitto:1883 serial: port: /dev/ttyACM0 adapter: deconz advanced: log_level: debug pan_id: 6754 channel: 11 network_key: - 7 - 12 - 13 - 8 - 3 - 10 - 2 - 7 - 5 - 14 - 9 - 4 - 1 - 11 - 15 - 0 availability_blocklist: [] availability_passlist: [] device_options: {} blocklist: [] passlist: [] queue: {} frontend: port: 8099 experimental: {}

The problem is that the thermostat, which I added (first I removed it from Z2M, then I did join it again from scratch) remains UNKNOWN. Please, see the below screen:

Moreover, no entities of this device are changeable. They remain unavailable (see above logbook on the right). So, I'm not able to control the device. What am I supposed to do to have them available?

[vladi1234]

Hello @Krzysztonek , what does z2m show? Have you paired TVR in the z2m?

[Krzysztonek]

Hello @vladi1234 , Yes, I've paired my device with the Z2M. Here is the evidence:

This device exposes the following:

Clicking any of the above switches underlined in yellow doesn't change their state. This is also visible here on the device's entities list below:

All the sensors of the device remain UNKNOWN even if the device has been paired successfully. Therefore, my understanding is that this device is out of my control.

[vladi1234]

I see that you are using an external converter or zha, but not z2m.

Hello @Krzysztonek , what does z2m show?

[Krzysztonek]

Hello, @vladi1234 Here it is: ...and I have to tell you, that all my thermostats started working correctly! :) Since this morning they are fully recognizable, all their entities are changeable. It means that something miraculous happened during this night. This is a kind of mystery for me because I haven't changed anything since yesterday.

Do you see my setting are OK now?

[vladi1234]

I congratulate

[Krzysztonek]

Thank you so much for your kind support, @vladi1234 🍺