【TRVZB】Firmware Changelog

[Archarr]

V1.4.4

New Updates:

Added the “Smart Temperature Control” function. Based on the PID algorithm, this feature dynamically adjusts the valve opening according to the difference between actual and target temperatures. In contrast to the traditional full‑on/full‑off logic, it provides more precise and intelligent control, improved comfort, and higher energy efficiency.

Can be enabled with one tap in "Adaptive Mode" in the eWeLink app.

*Note: When “Adaptive Mode” is enabled, “Valve Opening Percentage” and “Temp. Accuracy” features will be disabled.

*Gateway and Platform support timeline

• Already Supported: ZBBridge-P (V3.0.0) / ZBBridge-U (V1.18.0)
• Feb 15: NSPanel Pro (V4.4.0)
• Mar 31: HA (Z2M) / iHost (V2.10.0)
• To be confirmed: HA (ZHA)

*Using Smart Temperature Control with ZHA requires downloading the ZHA script. Click here to download the instructions and files: TRVZB_ZHA_Script

*At present, firmware upgrades are not supported via ZHA. We have already submitted the required review materials and are currently awaiting approval from the Home Assistant team. Once the review is approved, the update will be released. The exact timeline is subject to the approval process. Thank you for your patience and understanding.

V1.4.1

New Updates:

Fixed an issue in v1.4.0 where the temperature control valve might malfunction when the door magnetic sensor triggered a switch in operating mode in an automated scenario.

V1.4.0

New Updates:

1. Schedule
   This feature allows you to define a custom target temperature and an end time.
   The device will operate at the defined temperature until the end time, after which it will revert to its previous operating mode and temperature setting.

2. Temperature Offset
   The feature can be found in the “Device Settings” page.
   It allows temperature calibration in ±0.2 °C increments to correct measurement deviations that may occur when the device is installed near a heat source, ensuring higher temperature accuracy.

3. Boost
   A customizable time period can be set (default: 5 minutes, adjustable from 1 minute to 2 hours 59 minutes) during which the device temperature is temporarily set to the maximum with a single tap.
   When the time expires, the device automatically reverts to its previous operating mode and temperature setting.

4. Display Orientation
   Users can now select the actual installation orientation (horizontal or vertical).
   The device will automatically adjust the screen display accordingly — with the horizontal orientation as the default layout, and the vertical orientation rotating the display content by 180°.

5. eWeLink App UI and interaction optimization
   a. The UI and interaction design on the eWeLink App “Home” page have been optimized.
   Users can now directly switch between Boost, Auto, and Close modes, as well as view detailed device status information.
   

   

b. The UI design and interaction experience of the device details page in the eWeLink App have been optimized, with additional feature entry points added.

V1.3.0

New Updates:

1. Support Adjust Accuracy in eWeLink APP. When the Temp. Accuracy is set to the default of 1°C with a target temperature of 26°C, the SONOFF TRVZB valve closes at 26°C and opens at 25°C. Alternatively, when set to 0.4°C, it closes at 26°C and opens at 25.6°C.
   *A lower accuracy level minimizes temperature fluctuations but comes with increased battery usage.

2. Support automatic switching between daylight saving time and standard time.

3. Refined certain English copy:

In the device user interface:

• off→Standby
• OFF(Frost-protection)→Anti-freeze Mode

In the device settings:

• Frost protection→Anti-freeze Mode

*Currently, only ZBBridge-P gateway is supported, which must be upgraded to V2.4.0. Other Zigbee gateways will be supported in future updates.

*These features require updating the eWeLink app to V5.14.0, expected to be released in early March.

V1.2.1

New Updates:

1. Support setting valve opening percentage when added to ZBBridge-P, NSPanel Pro, iHost, and ZBBridge-U.

2. Support setting external sensor, allowing SNZB-02, SNZB-02D, and SNZB-02P to be used as a reference temperature for the TRVZB.
   *Currently only supported when added to ZBBridge-P.
   *NSPanel Pro, iHost, and ZBBridge-U will be supported in December.

[erich.scheilko]

Thank you for the info.
I have a NSPanel Pro and i have seen the “externalSensor” feature a few days.
But i was not able to save the sensor, because it is not supportet in NSPanel Pro.
Hurry up, in november it could bee cold.

[Daniel_Zhan]

We are working hard on it.

[erich.scheilko]

I think this is the first step to make a good heating control.
The temperature control of the TRVZB is, at best, simple control (OPEN / CLOSE). A proper control system (PI or PID controller) should gradually open or close the valve as the actual temperature approaches the target temperature. Since the number of steps required to open or close the valve is known, I don’t understand why such a controller hasn’t been implemented. I assume it’s not due to a lack of computing power. This feature would increase comfort and reduce heating costs. The point about setting the maximum/minimum valve opening in percentages shows me that you have the capability to achieve this.

[mmarci]

Support setting external sensor, allowing SNZB-02, SNZB-02D, and SNZB-02P to be used as a reference temperature for the TRVZB.
*Currently only supported when added to ZBBridge-P.

I understand that it is currently only supported when using a ZBBridge-P, but under the hood does the temperature sensor report the temperature directly to the TRV, or do they communicate through the bridge? I’m asking this because I’m curious about the robustness of this solution. What happens when the bridge is offline for some reason?

[eerke]

If you stick a debug node in Node Red connected to a temperature sensor I’m not sure it updates often enough either. Aswell as the route I’d be keen to know if the temperature sensor update frequency is changed and if it is what the effect on battery life is. Also presumably the TRV has to use energy to connect to any Zigbee Network itself and so I would expect a reduced battery life.

In Zigbee you can directly connect one device to another, so for example a Zigbee light switch can be connected to a Zigbee Light Bulb with a reduced latency. I forget what it is called. Don’t know if the coordinator needs to be alive. I don’t think so but am not sure. There is a tab for that in Zigbee2MQTT. I don’t know if it’s possible for them to be using that. It is possible they are.

[mmarci]

I’m not sure it updates often enough either

Zigbee temperature sensors which follow the ZCL standard report their measurement periodically AND when the value changes by a configured amount. You’ll see if you check out the Reporting tab in Zigbee2MQTT for a temperature sensor.

In Zigbee you can directly connect one device to another

Yes, and it’s called binding.

[eerke]

I know the Zigbee T&H sensor will update more often if temperature changes but I don’t think that setting exists for the iHost. I’m not sure the default amount is often enough to operate a radiator. The fact it exists in Zigbee2MQTT means they could theoretically add the ability though, so maybe it could be suggested to them… If you connect a T&H sensor to the iHost, stick a node Red debug node behind it and watch the output it doesn’t seem often enough, maybe behind the scenes if a T&H system is running the radiator they make it more sensitive already… who knows. I think superficially the idea of using a separate sensor is nice but not convinced the reality is so good. I’ve found big improvements where I’ve turned the cal a horizontal from vertical although in some places I’ve not been able to do this and maybe the new method will be helpful.

[greg.tunney]

I currently use Zigbee2MQTT for my zigbee setup. I have Sonoff TRVZB and their T&H sensors for all rooms that have TRVs.

At the moment I use a blueprint within HA to adjust the calibration offset of the TRV to match the T&H sensor. This of course has a reliant on HA being up and running. Would be great to get this natively built into Z2M or the TRV firmware itself.

Also will v1.2.1 be pushed for Z2M users to do OTA updates? We’re currently still on v1.1.5

[mmarci]

I agree it would be great if the TRVZB could do this standalone!

I saw a PR where 1.2.1 is added to Z2M’s OTA repository, so it will be available in the next Z2M release, or on the dev branch soon after the PR is merged.

Added v1.2.1 ota firmware for SONOFF's TRVZB.

[mm82]

The firmware does not inform via Zigbee when an error occurs. This could be done, for example, with an additional value for the entity “running_state” = “error”.

[riori]

@Archarr , what are the changes in version 1.3.0?

[riori]

@Daniel_Zhan Anybody home?

[Archarr]

Hello, the updated feature introduction for firmware V1.3.0 is now available. These new features will be accessible in the eWeLink APP V5.14.0 released in early March.

[riori]

@Archarr

These new features will be accessible in the eWeLink APP V5.14.0 released in early March.

What should those who use iHost do?

[DJackCZ]

Great news , March starts tomorrow

[Il_Marco]

This update is a complete mess. Zbbridge-p updated to last firmware 2.4.0. EWeLink app updated to latest version V5.13.1. Out of ten TRVZB only two updated regularly and I can see firmware 1.3.0 in device settings. Four TRVZB repeatedly failed to update. Four TRVZB “successfully” updated but in device setting they still report firmware 1. 2.1 and no more “update” notify

[Archarr]

Apologies, these features are currently supported only by the ZBBridge-P which upgraded to V2.4.0. Other Zigbee gateways (iHost, NSPanel Pro and ZBBridge-U) will be supported in future updates.

[Archarr]

Please try the following steps:

1. Log out of your eWeLink account and log in again, then check whether the devices that previously failed to upgrade now show the new firmware version.
2. If the devices still show the old version, move the Zigbee gateway closer to them and attempt the upgrade again.
3. If the issue persists, kindly provide the device ID so we can investigate the specific cause.

[trukke]

I have the same problem with 2 trvzb.
The systems said that the upgrade was “successfully” but i see the old 1.2.1 firmware and no possibility to try to upgrade again.
I tried to logout and access again to my profile but nothing changed.
Device id:
a4800cb2ef
a4800cc0e7