How to set retry for zigbee device when applying a scene?

Configuration Zigbee
1

So I have a 5 Tuya TRV TS0601 BRT-100-TRV devices and I have created scenes for applying different temperature configurations (day heating, night heating, etc…)
I also have automations in place which trigger at certain times to apply the scenes.

The problem is that sometimes the TRV devices are not reachable - I am not sure why because the signal is good, I guess they go to sleep mode to preserve battery or something… not sure.
The thing is that they sometimes are out of reach but becomes reachable again after couple of minutes.

If it happens that the automation triggers to apply a scene to an unreachable device - it may not get the new configuration. The automation completes and only half of my devices get their settings applied.

How do I make this more resilient? Is it possible to do some retry? Is there a best practice for situations like this?

2

I’ve noticed this (rarely) on these TRV’s too, and in the end I created a bit of a hack to make sure they are in the state I am expecting.

In my case, they are all connected to a generic thermostat, which toggles an input boolean (because these dont have a switch entity in the device itself). I then have an automation fire when the boolean changes, but every now and then, I noticed that one of the TRV’s that should be on (according to the generic thermostat), is still off.

So all I do is have a time pattern automation that checks the current state of my booleans every 15 minutes against the state of the TRV’s, and if they aren’t in sync, I re-sync them.

3

Woah, I’m impressed :smiley:
This is actually quite smart and I think it might just well work very well!

So just to be sure I understand why it works… Because the generic thermostat and the input boolean are virtual entities that live on hass itself - applying the scene would always work regardless of zigbee coverage, tuya devices reachability, etc etc…
And then we have additional automation to run every XXX minutes to reconcile the generic thermostat state with the Tuya device for resiliency.

Smart, very smart… Thanks a lot for the suggestion, you got yourself a virtual beer from me! :slight_smile:

4

One final question though… Could you please share your thermostat configuration? What do I put for a target sensor? The TRVs don’t seem to expose a sebsor for the current temperature so I’m not sure how to do it

5

I use a separate aqara temperature sensor. The idea is that a separate sensor can be away from the trv in the room and give more accurate temperature readings.

6

I managed to workaround this issue in a neat way thanks to @Rofo’s answer.

Leaving this code for the future generations:

switch:
  - platform: template
    switches:
      master_bedroom_switch_state_revert:
        value_template: "{{ is_state('switch.0x003c84fffef0f185_eco_mode', 'off') }}"
        turn_on:
          service: switch.turn_off
          data:
            entity_id: switch.0x003c84fffef0f185_eco_mode
        turn_off:
          service: switch.turn_on
          data:
            entity_id: switch.0x003c84fffef0f185_eco_mode

climate:
  - platform: generic_thermostat
    name: Master Bedroom Thermostat
    unique_id: master_bedroom_virtual_thermostat
    heater: switch.master_bedroom_switch_state_revert
    target_sensor: sensor.master_bedroom_trv_sensor
    min_temp: 18
    max_temp: 23
    target_temp: 19.0
    cold_tolerance: 0.15
    hot_tolerance: 0
    ac_mode: false
    precision: 0.1
    initial_hvac_mode: "heat"
    keep_alive:
      minutes: 3

template:
  - sensor:
    - name: "Master Bedroom TRV sensor"
      unit_of_measurement: "°C"
      state: "{{ state_attr('climate.0x003c84fffef0f185', 'current_temperature') | float }}"

Explanation:

  • The first entity is a Reverse switch on the eco_mode of the TRV. I use the ‘eco_mode’ function to trigger the TRV on and off - I have specified Eco temperature of 5C and current_heating_setpoint to 28C so that when Eco Mode is ON - the TRV is effectively OFF and when the Eco Mode is OFF - the TRV is effectively ON (since it can’t get to 28C anyway).

The Reverse switch helps here because when Reverse switch is ON → Eco Mode is OFF and vice-versa.
I use this reverse switch as a heater inside my generic thermostat.

  • The next entity is the generic thermostat - the important config here is the keep_alive option which keeps the thermostat state and the heater state in sync. This way I don’t need to create the automation Rofo suggested.

  • The next entity is a virtual sensor based on the current_temperature attribute of the TRV. I use this sensor to feed data to the generic thermostat.

So far it works flawlessly

7

Thats pretty much exactly what I do, except that rather than turning ECO on and off, I simply toggle the temperatures to 5 or 25 based on the generic thermostats switch state and do this via an automation.

I’d really suggest getting a separate temperature sensor as the TRV’s can be wildly out, and setting the temp offset doesn’t fix the problem in all scenarios.

1 Like
8

Update: this has been running for a few days already but unfortunately I still keep hitting into issues.

I don’t have separate temperature sensors and wanted to make those TRV work without one. So far the problem is that the TRV doesn’t report the ‘current_temperature’ attribute of the TRV back to z2m often enough.
I have no idea how to force the TRV to report it more often - the only way I found so far is to physically touch the home button of the TRV so the display lights up - then the current_temperature is reported immediately.

In the end it may turn out I’d need to purchase separate temperature sensors…

9

Even a separate temp sensor and either your approach (custom switch), or mine (via automation) doesn’t fully fix the issue that the TRV sometimes doesn’t ‘accept’ the message sent to it. Thats why I have the 15 minute ‘check’. However, I find it rare that the script actually has to do anything, so perhaps if you’re finding your TRV isn’t set as you expect it could be a weak signal or local interference ?

10

The more I read about generic thermostats, I think it may already be covered with their keep alive option, I’m sure you’ve already looked at

In particular, the keep_alive option that it looks like you are already using should solve the problem.

I do like the way you used a template switch to toggle your eco mode, but if you already have a switch entity, you can feed that straight into the generic thermostat without even needing to make a template switch.

And finally, I’m going to stick with my automation method because it gives me more flexibility, for instance, I have input booleans for things like guest mode/winter mode, so I dont always want the TRV’s turning on (or off) when the generic thermostat tells them to.

11

The signal is great. It’s just that this trashy TRV is not reporting back it’s state very often. In fact, the logbook history shows just a few changes a day.

Check out this video that I made earlier today: Tuya TS0601 Radiator valve with thermostat TRV · Koenkk zigbee2mqtt · Discussion #5748 · GitHub

The TRV reports 20C and is responsive - I changed its state a couple of times before recording and finally sent it command to change hvac mode. Temperature reported was still 20C.
Then, as soon as I woke it up by clicking the Home button - it triggered and reported back 18C

12

I use ZHA and it only exposes 1 HVAC mode, which is heat:

hvac_modes:
  - heat
min_temp: 5
max_temp: 25
preset_modes:
  - none
  - away
  - Schedule
  - eco
  - boost
  - Temporary manual
current_temperature: 23
temperature: 25
hvac_action: heating
preset_mode: none
system_mode: '[4]/heat'
occupancy: 1
occupied_heating_setpoint: 2500
icon: mdi:thermometer
friendly_name: Moes TRV - Downstairs Bathroom Becathermostat
supported_features: 17

is this the same in Z2MQTT ?

If so, the TRV may well be ignoring your command, as its only got one hvac mode, so effectively cant be set to anything else.

Try doing what you do in your template switch and send a preset_mode command instead.

13

As for the frequency of the updates, most battery devices work in the same way… if the change (in this case) for the temperature is rapid, then you get frequent updates. If the temperature is stable or rarely changing, the updates occur much less often, as you can see from this history graph of my TRV

image
image1627×442 23.6 KB