[TRVZB / SONOFF] Temp accuracy adjustment not working on some TRVZB

[mortenserv]

What happened?

What did you expect to happen?

I recently bought 8 TRVZB in two batches. So 4 devices from two different sellers. I use them with HA via Z2M and my SMLIGHT SLZB-MR3 Zigbee coordinator. All of them are connected to each their own external Aqara temp sensor. I have used this blueprint to setup the automation and it works as intended by letting the external temp sensor "take over" the temp measurement: https://community.home-assistant.io/t/sonoff-trvzb-external-temperature-sensor-calibration/856444

First, I installed the 4 devices from one of the sellers. They came with firmware 1.2.1 so the first to-do was a firmware upgrade to 1.3.0 for all 4 of them. That went smooth and they work as intended. I think the standard temp accuracy/hysteresis of 1 degree is too much so I lowered it to 0.2 degrees - I'm aware and OK with the extra battery usage. That works fine. When the temp drops around 0.2 degrees HA change them from Idle to Heat.

Then I began installing the other batch of TRVZB. They came with firmware 1.3.0 so no firmware upgrade needed with them. So far I have installed three of them and they all have the same issue: When I adjust the temp accuracy to something else than the standard 1 degree...it's just ignored. They only change from Idle to Heat when the temp difference is 1 degree. See screenshot (where my cursor is placed - ignore the chart before that point as I was experimenting with turning on the heat manually and also did a factory reset).

I have done a factory reset and that haven't changed anything for any of my second batch of devices. Any idea how can this be solved? Just to test I would like to downgrade the firmware to 1.2.1 and then let Z2M upgrade them to 1.3.0 but I can't find any instruction on how to do that or any 1.2.1 image and Sonoff claims a downgrade can't be done.

I have attached a snip from my HA Z2M state.json which shows a difference between my TRVZB with working temperature accuracy and my TRVZB with non-working temperature accuracy. However, I don't really think the difference should matter, but none the less it's a difference which is a bit weird.

state.json.txt

How to reproduce it (minimal and precise)

Debug logs

Details

os: #1 SMP PREEMPT_DYNAMIC Mon Sep 8 17:03:23 UTC 2025 - 6.12.43-haos - x64
node: v22.16.0
zigbee2mqtt: 2.6.2 (unknown)
zigbee-herdsman: 6.1.5
zigbee-herdsman-converters: 25.35.1
adapter: ZStack3x0 {"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20240716,"transportrev":2}

Device

software_build_id: 1.3.0
date_code: 20241224
endpoints:

{"1":{"bindings":[{"cluster":"genPollCtrl","target":{"endpoint":1,"ieee_address":"0x00124b0033c5f452","type":"endpoint"}},{"cluster":"hvacThermostat","target":{"endpoint":1,"ieee_address":"0x00124b0033c5f452","type":"endpoint"}}],"clusters":{"input":["genBasic","genPowerCfg","genIdentify","genOnOff","genPollCtrl","hvacThermostat","manuSpecificAmazonWWAH","customSonoffTrvzb"],"output":["genTime","genOta"]},"configured_reportings":[{"attribute":"localTemp","cluster":"hvacThermostat","maximum_report_interval":3600,"minimum_report_interval":0,"reportable_change":10},{"attribute":"occupiedHeatingSetpoint","cluster":"hvacThermostat","maximum_report_interval":3600,"minimum_report_interval":0,"reportable_change":10},{"attribute":"systemMode","cluster":"hvacThermostat","maximum_report_interval":3600,"minimum_report_interval":10,"reportable_change":null}],"scenes":[]}}

Health

time: Thu Oct 09 2025 11:04:52 GMT+0200 (Central European Summer Time)
process.uptime_sec: 474605

{"leave_count":0,"messages":3669,"messages_per_sec":0.0077,"network_address_changes":0}

[tjay]

Hi,
I have the same setup. Sorry I misread. I use the ZBBridge-P and an accuracy of 0.8 works as expected:

[mortenserv]

Hi,
I have the same setup. Sorry I misread. I use the ZBBridge-P and an accuracy of 0.8 works as expected:

No worries. Also the issue for me is that 0.2 works as intended for 4 of my TRVZB, but for the last 4 they only react when the difference is 1 degree. Puzzling as my two TRVZB batches are from different sellers and came with different firmware. Almost like there is some kind of hardware difference. Would love to be able to downgrade the firmware on the 4 that's not working and let Z2M update it afterwards.

[tjay]

This might mean that the newer TRVZBs don't support the accuracy feature, or that SONOFF doesn't adhere to the ZIGBEE standard if it only works with the ZBBridge-P. Perhaps @lcheng33775823 can tell us more.

[mortenserv]

Hmm Sonoff reached out and asked me to reseat the batteries and see what code I got. On the TRVZB where temp accuracy works I get "34". On the ones where it doesn't work I get "07". Waiting for reply from Sonoff. I have already done factory resets.

[smmhroes]

Did you receive an answer yet?
I have exactly the same issue.
4 brand new devices bought 3 weeks ago that already came with firmware 1.3.0 pre installed.

Seems a little bit like if the firmware is not 1.3.0 but is exposed as 1.3.0...

[mortenserv]

Did you receive an answer yet?
I have exactly the same issue.
4 brand new devices bought 3 weeks ago that already came with firmware 1.3.0 pre installed.

Seems a little bit like if the firmware is not 1.3.0 but is exposed as 1.3.0...

I just got this answer during the night:

"Thanks for your details.
The characters above represent the motor control module version. Due to production batch differences, your device may not have the latest module firmware.
A new firmware version is expected to be released for the device by the end of this month. You can try to update the module firmware and resolve the issue then."

So yeah, this seems to be a firmware issue but bit of a weird one. One can only hope it will get fixed then.

[smmhroes]

Thank you for the update.

Tbh that sounds like what I described since other devices with 1.3.0 seem to be working (updated from previous firmware)...

Since that seems to be a problem with multiple devices (at least your batch and my batch) I hope they are looking into it. End of this month sounds like a hot fix for that problem.

[mortenserv]

Yeah, sounds like they are fixing a bug more than adding features here as it should have worked with 1.3.0. Fingers crossed for the firmware fixing this.

[batman84uk]

Just so you don't feel alone, I also have brand new units with the same issue. They also show up as 1.3.0 firmware out of the box. They also display motor control version 07 on reseating batteries.

Let me know if I can provide any help.

[mortenserv]

Thx it helps :-) Thought I was pretty alone with the issue but now it seems like it's a general issue. And again that makes me think it's probably just a question of time before Sonoff fix it with a firmware update. Which I guess their message to me also indicated.

[why-grumble]

I am in the same situation, to be continued

[ncolomer]

Same here:

• bought new batch of 4 with 1.3.0 pre-installed
• Z2M setup, directly connected (no ZBBridge-P)
• -0.2°C temperature accuracy setting is just ignored: TRV only wakes up as if it was set to -1°C
• reseating batteries displays motor control version 07

Workaround for me was to increase a bit the temperature setpoint.

Looking forward the new firmware version...

[smmhroes]

In case someone needs it:
As a workaround I created a scriptin HA to change the external temperature as soon as my desired hysteresis is met.

Checks the setpoint and the actual temperature and calculates the difference.
If difference >= desired hysteresis (number helper) it artificially lowers the external temperature to 2 degrees below the setpoint to trigger the TRVZB to heat.
As soon as it changes to heating it returns the temperature to the previous value.
The TRVZB however continues heating until it reaches the setpoint.
There is also a timeout of 1 minute in case the TRVZB does not change to heating.

alias: Bathroom Hysteresis
description: >
  Sets the external temperature sensor of the Sonoff TRVZB in the bathroom based
  on the difference between the setpoint and the actual temperature, controlled
  by a hysteresis.
triggers:
  - value_template: >
      {% set setpoint = state_attr('climate.thermostat_badezimmer', 'temperature') |
      float(0) %} {% set actual =
      states('number.thermostat_badezimmer_external_temperature_input') |
      float(0) %} {% set diff = (setpoint - actual) | round(1) %} {% set hyst =
      states('input_number.hyst_thermometer') | float(0.5) %} {{ diff >= hyst
      and state_attr('climate.thermostat_badezimmer', 'hvac_action') in ['idle']
      }}
    trigger: template
conditions: []
actions:
  - variables:
      setpoint: >-
        {{ state_attr('climate.thermostat_badezimmer', 'temperature') | float(0)
        }}
      actual: >-
        {{ states('number.thermostat_badezimmer_external_temperature_input') |
        float(0) }}
  - target:
      entity_id: number.thermostat_badezimmer_external_temperature_input
    data:
      value: "{{ setpoint - 2 }}"
    action: number.set_value
  - wait_for_trigger:
      - entity_id:
          - climate.thermostat_badezimmer
        trigger: state
        for:
          hours: 0
          minutes: 0
          seconds: 2
        attribute: hvac_action
        to: heating
    timeout:
      hours: 0
      minutes: 1
      seconds: 0
      milliseconds: 0
    continue_on_timeout: true
  - target:
      entity_id: number.thermostat_badezimmer_external_temperature_input
    data:
      value: "{{ actual }}"
    action: number.set_value
mode: single

So far this works pretty good for me.
Only problem I ran into was that I had a timed automation that was updating the external temperature each hour even if no change was detected.
If I simultaneously use a timetable (internal feature of the Sonoff) or an automation to change the setpoint at exactly the same time the values overwrote themselves.

I fixed that by changing the setpoint 5 minutes later (e.g. 05:05 instead of 05:00).

[TheNexter]

Same issue, i just install my Sonoff TRVZB today, latest OTA, latest Z2M

[MissLeavich]

Thanks for this post. Same issue with my trvzbs which lead to boiler getting triggered even when valeves were still closed...eh :( waiting for the FW update. For now aligned "accuracy"/tolerance of trvzbs and better thermostat to 1.