[BETA] Sonoff TRVZB driver (automatic reporting WORKING! :) )

Currently, the Sonoff TRVZB thermostat does not automatically send the temperature and the heating setpoint, except if it has been paired and configured before in the Sonoff hub or in Home Assistant (Z2M or ZHA).

This is a dedicated driver for Sonoff TRVZB thermostatic Radiator Valve. Note, that the driver name and the GitHub URL has changed! The link is at the bottom of this post.

Sonoff TRVZB can be purchased at a very good price directly from here :

Amazon .co.uk : (link)
Amazon. de : (link)
Amazon .fr : (link)
Amazon .it : (link)
Amazon .es : (link)

Features (TRV) :

  • thermostatMode:
    • heat : 4.0 .. 45.0 degrees C, resolution 0.5 C
    • off - switches the thermostat is 'anti-freeze' mode.
      Note: the 'auto' mode (programming a weekly schedule in the TRV itself for offline operation) is not supported
  • minHeatingSetpoint, maxHeatingSetpoint - limits the heatingSetpoint configuration within a narrower range than 4.0 .. 45.0, as an example - do not allow boosting the temp more than 28 degrees.
  • calibrationTemp - allows manual correction of the internal sensor temperature reading. Correction range: -7.0 ... +7.0 C, step 0.2 deg.
  • termostatRunningState : 'off' when the valve is closed or 'heat' when the valve is open. Can be used to control the hot water source (boiler as an example).
  • childLock - allows locking the TRV manual control
  • windowOpenDetection - automatically turns off the radiator when local temperature drops by more than 1.5°C in 4.5 minutes.
  • frostProtectionTemperature - Minimum temperature at which to automatically turn on the radiator, if system mode is off, to prevent pipes freezing.
  • battery - the battery percentage remaining

Features (driver)

  • healthStatus - fires an offline event when nothing is received from the device for more than 12 hours (TBD)
  • ping() command - pings the device and calculates the RTT (round-trip time)
  • refresh() command - refreshes the temperature, the heating setpoint and the operatingState
  • setPar() command - allows changing of the TRV parameters (preferences) 'on the fly' from RM5 or WebCoRE automations
  • sendCommand() command - for advanced use

The custom driver for Hubitat can be manually installed from this link in GitHub :



Reserved #2

What a coincidence! Discovered a jammed TRV actuator just yesterday (I thought the living room was a bit chilly) and got to researching these tonight. Guess I may be one of your alpha testers! :wink:

1 Like

Thanks to a deal on Amazon I've wound up with two of these. One is in the living room (where something is better than broken) and the other is here in the study where I can keep an eye on it.

Here's my first ten minutes with them!

With the alpha driver installed I found that it was not chosen during pairing and the TRVs appeared with the generic "Device" driver. Here's my pairing info:

After viewing the device page and switching to the driver, I saw this in Current States:

Screenshot 2023-12-04 at 21.18.46

Then I did the usual, hit Configure:

Screenshot 2023-12-04 at 21.19.05

Things happened in the log:

dev:10832023-12-04 21:19:26.812debugStudy TRV received Power source battery (03)
dev:10832023-12-04 21:19:26.808debugStudy TRV received device model TRVZB
dev:10832023-12-04 21:19:26.804debugStudy TRV Tuya check-in message (attribute 0001 reported: 00)
dev:10832023-12-04 21:19:26.801debugStudy TRV Basic cluster: ZCLVersion = 08
dev:10832023-12-04 21:19:26.797debugStudy TRV received device manufacturer SONOFF
dev:10832023-12-04 21:19:26.792debugStudy TRV parse: descMap = [raw:E5B70100004E04004206534F4E4F46460000002008010000200005000042055452565A420700003003FEFF86, dni:E5B7, endpoint:01, cluster:0000, size:4E, attrId:0004, encoding:42, command:01, value:SONOFF, clusterInt:0, attrInt:4, additionalAttrs:[[value:08, encoding:20, attrId:0000, consumedBytes:4, attrInt:0], [value:00, encoding:20, attrId:0001, consumedBytes:4, attrInt:1], [value:TRVZB, encoding:42, attrId:0005, consumedBytes:8, attrInt:5], [value:03, encoding:30, attrId:0007, consumedBytes:4, attrInt:7]]] description=read attr - raw: E5B70100004E04004206534F4E4F46460000002008010000200005000042055452565A420700003003FEFF86, dni: E5B7, endpoint: 01, cluster: 0000, size: 4E, attrId: 0004, encoding: 42, command: 01, value: 06534F4E4F46460000002008010000200005000042055452565A420700003003FEFF86
dev:10832023-12-04 21:19:26.765debugStudy TRV parse: read attr - raw: E5B70100004E04004206534F4E4F46460000002008010000200005000042055452565A420700003003FEFF86, dni: E5B7, endpoint: 01, cluster: 0000, size: 4E, attrId: 0004, encoding: 42, command: 01, value: 06534F4E4F46460000002008010000200005000042055452565A420700003003FEFF86
dev:10832023-12-04 21:19:26.590infoStudy TRV executed 'configure'
dev:10832023-12-04 21:19:26.543infoStudy TRV sent device configuration
dev:10832023-12-04 21:19:26.524debugStudy TRV sendZigbeeCommands(cmd=[he raw 0xE5B7 1 0x01 0x0000 {10 00 00 04 00 00 00 01 00 05 00 07 00 FE FF}, delay 200, delay 299, null])
dev:10832023-12-04 21:19:26.518debugStudy TRV sendZigbeeCommands(cmd=[delay 277])
dev:10832023-12-04 21:19:26.512infoStudy TRV configureDevice...
dev:10832023-12-04 21:19:26.507infoStudy TRV initializeDevice...
dev:10832023-12-04 21:19:26.499debugStudy TRV [txtEnable:true, logEnable:true, traceEnable:false, alwaysOn:false, advancedOptions:false, healthCheckMethod:1, healthCheckInterval:240, voltageToPercent:false, forcedProfile:Sonoff TRVZB, temperaturePollingInterval:600, minReportingTime:10, maxReportingTime:3600]
dev:10832023-12-04 21:19:26.493infoStudy TRV configure...
dev:10832023-12-04 21:19:26.488infoStudy TRV configure(Configure the device only)...

But after Configure the device stays in what appears to be pairing mode:

Looks weirdly bright on that picture, I wonder if the LEDs put out a bit of IR.

Anyway, then I hit Heat and it immediately showed the setpoint instead, which seems to default to 19degC, then the display went to sleep.

Seems we're up and running now, but if I adjust the setpoint on the TRV it doesn't seem to get reflected in HE. Oh, no... I'm becoming curious about tinkering. There's no time in December! :joy:

BTW, the instructions with these basically don't mention how to use the adapters and pins. Here's the guide hidden on their website of which adapter to use with which valve.

1 Like

I am happy to have you as an alpha tester! : )

I have to publish a small bug fix on the previous thermostat driver first, and then will go back to the new driver.

As you have already noticed, I have published the 'lib included' complete version, as I don't feel confident myself in publishing a bundle with the common libraries yet. Probably at some later time, will try the bundles option.

These are the direct links for tinkering with the code :

BTW, I have not tried pairing it to my C-8 yet - all the tests were made on my C-7 dev hub. And yes, pairing is a bit problematic - I needed a few tries.

1 Like

The Sonoff one seems much more affordable than others I've seen, eg Hive (UK), especially when you need lots of them.

I've bought one to try out on my C-8. I wonder if they'll make different colours?

1 Like

The code that generates dynamically the fingerprints was simply missing .. Fixed.
For debugging purposes, you can see all the devices fingerprints by entering the command "printFingerprints" and clicking on the "Send Command" button above. Clicking on the "Send Command" without any parameters (or with a wrong parameter) will show the list of the valid commands in the live logs.
/I am writing all this in detail so that I can later copy and paste it in the driver documentation : ) /

Here the 'healthStatus' is probably set to online state too early. This is especially misleading with these problematic Zigbee 3.0 devices paired to C-8 hib, that will stay connected for just a few seconds before issuing a Zigbee 'leave' command... A possible improvement is to wait for a at least 10 seconds to receive more than 4-5 messages, before deciding that the device is online.

There was another bug - the thermostat-specific initialization was not called - now fixed.
The debug logs are now enabled by default when the device joins, otherwise it is difficult to understand what happens during the pairing ..

You will need to either pair the device again, or use the 'LOAD ALL DEFAULTS' option :

Try again with the new code version 3.0.4

This is another questionable detail, should the driver set up default/fake values for some attributes (like the measured temperature) on the startup, before receiving the actual values? I remember there was some kind of issues with Google Home or maybe Alexa if not done this way... to be checked later.

I tested pairing again the TRVZB (without deleting it) and the WiFi symbol stopped flashing after several seconds, which means the initialization is OK. Please try pairing it again ( the .... lib_included version link from the top post).

I don't see different color options. Easier for me because my wife was terrified of the choice that I made purchasing a black colored Moes TRV - she doesn't allow me to put it now in the living room! :cry:

1 Like

Most of our rads are white but we've got a few anthracite downstairs to try and be a bit more trendy :rofl:

I think I'd just put the ZigBee TRVs upstairs anyway so the rads aren't on whilst we're downstairs during the day

From the ones I have here, they've not been able to decide which white to use! Looking carefully at them the dial and body is more an off-white / cream, while the shroud is a very "pure" white. Possibly something to do with making it out of a more translucent plastic for the display.

I've chosen not to look at them too hard. :joy:

Sorted, did that with the first two...

I like these, so I now have four!

Paired the two new ones and the same thing - they paired perfectly, first time with my C-8 hub, but they stayed in what appeared to be pairing mode with the wireless indicator flashing. Nothing I did on HE would drop them out of displaying that pairing indication, though they responded to all remote controls just fine. After a little while the screen timed out and my previous assumption that it was hitting the Heat control that did it must have been a coincidence.

I've noticed that configuring the set point works from HE to the TRV, but when varying the setpoint on the TRV the heatingSetpoint value isn't updated in HE. There appears to be a message in the logs, though - but the only value which seems to be extracted from it is the motor voltage. I'm still not entirely sure why this is a useful value, but it must have some purpose! :slight_smile:

1 Like

If you enable the Debug logs and send a Configure command "Configure the device only", do you see successful binding and reporting configuration responses in the live logs?

Yup, certainly do!

All seems OK in the logs, so its rather strange why your TRV does not send immediately the heatingSetpoint when changed locally from the knob ...

I suppose the Refresh command is working and the actual settings are reported correctly?

Yeah, all that works fine. The only thing it appears to send when adjusted manually is the motor voltage, and I guess it only does that when the adjustment goes above or below the set point.

Good news - I was able to replicate the issue!

1 Like

Morning, all. I have some of the same troubles as birdslikewires. Recently installed the Sonoff TRVZB using this driver and for the life of me I cannot get it to report its own temperature, nor will it update my C8 with a manually set temperature. Hitting Refresh does not inspire it to coopoerate. I have something of an ooh-what-does-this-button-do approach and learning from the resulting explosion and usually find my way, but this has me flummoxed.

I grabbed some debug logs after hitting Configure and it warns of problems with a cluster. I don't know what a cluster is but curiously I am now hungry for a snack bar. Oh, and if it might be relevant, I have set up a Thermostat Controller for this (as with my 3x Aqara E1s that work just fine, thanks to your previous driver) so that it will show up on my Google Home setup.

Thoughts? Any help would be appreciated.

Hi @user5911 ,

I think that the problem is that the Sonoff TRVZB requires the automatic internal scheduling to be configured in order to start reporting the temperature and the heating setpoint. This explains why it is working in my setup - I have fist configured it using a Sonoff Zigbee gateway, also in HA using Zigbee2MQTT.

I have edited the top post to warn about this issue.

1 Like

Many thanks for your prompt reply. In the absence of a Sonoff hub I will continue with the press-it-and-see "method" and let you know if it turns up anything useful.

And so you don't worry for my safety, I am single and liable only to mildly bemuse the cat with my tinkering and harrumphing. No wife will be disgruntled in the course of this endeavour :+1:


Ah, thats the reason! I thought it was a bit odd. :slight_smile: