Sonoff TRVZB External Temperature Sensor Calibration

Zigbee2MQTT (v2.1.2+) exposes entities to configure the Sonoff TRVZB to use an external temperature sensor instead of the internal sensor. This blueprint synchronises the local temperature of one or more Sonoff TRVZBs with an external temperature sensor.

Use of an external sensor might be desirable when its readings more accurately reflect the room temperature compared with the internal temperature sensor in the TRV, or when you wish to use a single temperature sensor to control multiple radiators in a single room.

The network protocol of the external temperature sensor is irrelevant (it can be Zigbee, WiFi etc.), but the device must broadcast temperature updates at least once within 2 hours to prevent fail-safe mode from activating on the TRV (see below).

Functionality is similar to that of the Sonoff ZBBridge: whenever the external temperature sensor reports the temperature, the TRV is updated with the external temperature.

Before using this blueprint, each TRV must be explicitly configured to use an external temperature sensor (setting available in Zigbee2MQTT v2.1.2+).

Software Requirements

  • Sonoff TRVZB Firmware: 1.2.1+
  • A Zigbee integration that exposes the TRV external temperature input entity (e.g. Zigbee2MQTT v2.1.2+)

Fail-safe Mode
The Sonoff TRVZB has a built-in fail-safe mode whereby if the device has been configured to use an external temperature sensor and the external temperature has not been received by the device for more than 2 hours, the device will revert to using the internal temperature sensor. This behaviour protects against overheating/freezing in scenarios such as when the external temperature sensor is unavailable (e.g. flat battery) or if the automation created by this blueprint is disabled. When the TRV receives the next external temperature update, it switches back to using the external temperature sensor.

Reporting Requirements for Zigbee External Temperatature Sensors

Temperature Accuracy (Min Rep Change)
Most battery powered Zigbee devices conserve power by broadcasting state changes only after a configured threshold in sensor value and/or time has been exceeded. In Zigbee2MQTT, these thresholds are configurable on the device “Reporting” page. If the external temperature sensor has a “Min Rep Change” value of 100, this typically means that updates will only be broadcast if the temperature changes by 1°C. Reducing this value to, say, 50 (0.5°C) will ensure that the external temperature sensor broadcasts updates more frequently, allowing the TRV to more accurately follow the temperature.

Constant Temperatures (Max Rep Interval)
To prevent the TRV from entering fail-safe mode, the external temperature has to be regularly sent to the TRV. This blueprint is triggered by changes made to any of the attributes of the external temperature sensor entity in Home Assistant. The “Max Rep Interval” reporting setting on a device specifies how long a Zigbee device must wait before rebroadcasting its state even if there have been no changes in value. A value of 3600 typically means the Zigbee device will report its state once every hour. It is advised to ensure this value remains under 7200 (2 hours) so that the device is still reporting during long periods of constant temperature.

If using Zigbee2MQTT, further configuration of the external temperature sensor may be required. By default, Zigbee2MQTT does not report back into Home Assistant if an entity’s value has not changed, regardless of its reporting interval. To ensure this happens, the force_update setting on each external temperature sensor needs to be explicitly set. This is done by editing the Zigbee2MQTT devices.yaml file (see example in the blueprint preview).

By doing the above, the blueprint automation will be triggered by each report from the external temperature sensor, ensuring that fail-safe mode will not be activated on the TRV during a 2 hour period of constant temperature.

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

blueprint:
  domain: automation
  name: Sonoff TRVZB External Temperature Sensor Calibration
  description: |
    ## Sonoff TRVZB External Temperature Sensor Calibration (v1.0.1)
    This blueprint synchronises the local temperature of one or more Sonoff TRVZBs with an external temperature sensor. Such behaviour might be required when an external temperature sensor more accurately reflects the room temperature compared with the internal temperature sensor in the TRV(s), or when you wish to use a single temperature sensor to control multiple radiators in a single room.

    The network protocol of the external temperature sensor is irrelevant (it can be Zigbee, WiFi etc.), but the device must broadcast temperature updates at least once within 2 hours to prevent fail-safe mode from activating on the TRV (see below).

    Functionality is similar to that of the Sonoff ZBBridge: whenever the external temperature sensor reports the temperature, the TRV is updated with the external temperature.

    Before using this blueprint, each TRV must be explicitly configured to use an external temperature sensor (setting available in Zigbee2MQTT v2.1.2+).

    ### Software Requirements
    - Sonoff TRVZB Firmware: 1.2.1+
    - A Zigbee integration that exposes the TRV external temperature input entity (e.g. Zigbee2MQTT v2.1.2+)

    ### Required Entities in Home Assistant
    - The external temperature sensor value
    - The external temperature input entity of one or more Sonoff TRVZBs.

    ### Fail-safe Mode
    The Sonoff TRVZB has a built-in fail-safe mode whereby if the device has been configured to use an external temperature sensor and the external temperature has not been received by the device for more than 2 hours, the device will revert to using the internal temperature sensor. This behaviour protects against overheating/freezing in scenarios such as when the external temperature sensor is unavailable (e.g. flat battery) or if the automation created by this blueprint is disabled. When the TRV receives the next external temperature update, it switches back to using the external temperature sensor.

    ### Reporting Requirements for Zigbee External Temperatature Sensors

    #### Temperature Accuracy (Min Rep Change)
    Most battery powered Zigbee devices conserve power by broadcasting state changes only after a configured threshold in sensor value and/or time has been exceeded. In Zigbee2MQTT, these thresholds are configurable on the device "Reporting" page. If the external temperature sensor has a "Min Rep Change" value of 100, this typically means that updates will only be broadcast if the temperature changes by 1°C. Reducing this value to, say, 50 (0.5°C) will ensure that the external temperature sensor broadcasts updates more frequently, allowing the TRV to more accurately follow the temperature.

    #### Constant Temperatures (Max Rep Interval)
    To prevent the TRV from entering fail-safe mode, the external temperature has to be regularly sent to the TRV. This blueprint is triggered by changes made to any of the attributes of the external temperature sensor entity in Home Assistant. The "Max Rep Interval" reporting setting on a device specifies how long a Zigbee device must wait before rebroadcasting its state even if there have been no changes in value. A value of 3600 typically means the Zigbee device will report its state once every hour. It is advised to ensure this value remains under 7200 (2 hours) so that the device is still reporting during long periods of constant temperature.

    If using Zigbee2MQTT, further configuration of the external temperature sensor may be required. By default, Zigbee2MQTT does not report back into Home Assistant if an entity's value has not changed, regardless of its reporting interval. To ensure this happens, the `force_update` setting on each external temperature sensor needs to be explicitly set. This is done by editing the Zigbee2MQTT `devices.yaml` file, as follows:

    ```
    '0xd44867fffe111ce1':
      friendly_name: Kitchen Temperature Sensor
      homeassistant:
        temperature:
          force_update: true
    ```

    By doing the above, the blueprint automation will be triggered by each report from the external temperature sensor, ensuring that fail-safe mode will not be activated on the TRV during a 2 hour period of constant temperature.

  input:
    external_temperature_sensor:
      name: External Temperature Sensor
      description: The entity of the external temperature sensor device that represents the temperature value.
      selector:
        entity:
          filter:
            - domain: sensor
              device_class: temperature

    trv_external_temperature_input:
      name: Sonoff TRVZB(s)
      description: The entity of the Sonoff TRVZB device that represents the external temperature value.
      selector:
        entity:
          multiple: true
          filter:
            - domain: number
              device_class: temperature

triggers:
  - trigger: state
    entity_id: !input external_temperature_sensor
variables:
  external_temperature_sensor: !input external_temperature_sensor
actions:
  - action: number.set_value
    metadata: {}
    data:
      value: "{{ states(external_temperature_sensor) | float }}"
      entity_id: !input trv_external_temperature_input
mode: single
6 Likes

I’m currently using Better Thermostat to do use an external temperature sensor. Is there any benefit to using this or is it just another approach to achieve the same? AFIAK, Better Thermostat simply switches between on / off ( 100-0%) on the valve. Will your approach throttle the valve?

@photomoose It looks like this is supported in Zigbee2MQTT from 2.1.2 and later, which includes your Sonoff TRVZB: expose external temperature sensor attributes by photomoose · Pull Request #8873 · Koenkk/zigbee-herdsman-converters · GitHub change.
Thanks!

1 Like

Thanks for the handy blueprint.

1 Like

Yes, you’re correct. I guessed the version number incorrectly, I’ll update the text. I’ll also constrain the device class to temperature entities when selecting the TRV external temperature entity, now that my other PR has been merged.

1 Like

Better Thermostat looks at the value of the external temperature sensor then either makes adjustments to the TRV local temperature calibration setting or increases/decreases the temperature set point of the TRV.

Here’s a simplified example of how BT uses temperature calibration:

TRV reports local temp as 15C
External sensor reports temp as 17C
Better Thermostat detects 2C difference and sets “local temperature calibration” to +2C, so that TRV now thinks the local temp is 17C.

Note that the TRV is still using its internal sensor to calculate the temperature, but applying the calibration offset to the value.

(There are obviously more features in BT which affect this calibration, but that’s the general gist of it).

This blueprint works in a similar way, except that it doesn’t alter the calibration, it just tells the TRV that “this is the real temperature as reported by an external sensor, use this value as the source of truth, do not use the internal sensor”.

There’s no changes to any throttling of the valve, all this does is change the way in which the TRV measures temperature.

1 Like

I am also using BT, but eagerly waited for this feature (and the tolerance adjustment), because BT sometimes has problems updating multiple thermostats in the same room (Local temperature calibration won't be updated on single thermostat (of three) when target temperature is reached · Issue #1410 · KartoffelToby/better_thermostat · GitHub) and the tolerance is not working correctly ("Tolerance" not working · Issue #1136 · KartoffelToby/better_thermostat · GitHub). With this feature and tolerance adjustment I can stop using BT, which means one possible failure point less in the system.

Please help, I can’t find the hysteresis (temperature accuracy) settings anywhere. Or did I misunderstand something about the changes?

They will be (most probably) present in the next release - Added temperature control accuracy attribute for the trvzb by lcheng33775823 · Pull Request #8837 · Koenkk/zigbee-herdsman-converters · GitHub

1 Like

Thanks very much for this @photomoose

I’ve changed my TRVs from using a offset calibration blueprint to now using yours and external temperature. I reset my calibration back to 0 as well as that was still on the last value set by the previous blueprint.

I shall let you know how I get on with your blueprint.

1 Like

i’ve tested the blueprint.
Even without better thermostat in between the sonoff trvzb didn’t open the valve while the temperature was already 0,2°C under the target temperature.

Sonoff-Version was 1.3.0 and Z2M-Version was 2.1.3.

After increasing the target temperature by 0,5°C the valve opened and it went in heating mode even after going back to the previous defined temperature.

So i looks like the problem is more depending on the thermostat in general.


the graphic shows the target-temperature at the TRVZB in green, the current external temperature at the TRVZB in ligh-red and the valve voltage in pink.

At 19.25 the external temperature was 0,2° below target for already more than 1hour. The green line then shows where i manually changed the target temperature at the TRVZB.

I’m now testing both: better thermostat and external temperature calibration in combination.
But the temperatures outside are increasing actually so the valves are not needed so much at the moment :smiley:

Sonoff TRVZB has a hysteresis of 1c meaning the valve won’t open until temp is 1c below target temp.

This hysteresis will be changeable in a future update.

2 Likes

Going to test this with Sonoff SNZB-02P.

My TRVZBs are version 1.3.0.

How might Retain: True affect this?

Sensor:
In my experience the sensor reports only when there is a change in environment (regardless temp or humidity) , and HA updates likewise - hence Force_update: True.

Values may appear stale even when they are not.

Valve:
It published about once every minute, upon inspection without any change, and Retain: True resolved this and my two valves are no longer reporting too often, without any real update.