Moes BRT-100 TRV does not respond to temperature change request

You wouldn’t happen to know what you did to make the automations work do you?

I’m using this automation blueprint:

https://community.home-assistant.io/t/advanced-scheduled-heating-control-with-calibration-and-window-detection/469873?u=james-lee-007

It (somehow) worked before I had the quirk installed, but now the thermostat doesn’t respond to the automation at all. It would be great if I can continue to use the thermostat with the quirk so that I can adjust the calibration, but it would also work with automations.

Is something preventing the thermostat from listening to automations? Like, I don’t know what the binary sensor is for, but in the logs I can see it’s active. Do you maybe know something about that?

Any suggestions would be appreciated. But, thenk again, you’ve already helped me very much with the quirk :grinning_face_with_smiling_eyes:

Or does it have something to do with this “idle” mode?

image

Because if so, is there anyway to turn the idle mode off? I definately cant find it…

In the screenshot above, the thermostat is showing idle because the current temperature (The large number) is higher than the target temperature (the small number).

Now you have the device working, you might want to play with the temperature offset value to account for the fact that TRV’s temperature sensor is right next to the radiator:

image

Mine is set to -3.

However, I dont actually use the TRV’s temp sensor, I use a separate room thermostat and combine the two using Generic Thermostat - Home Assistant

Ahh…and these TRV’s only have 1 hvac mode, which is ‘heat’, so there is no way to turn them off via the hvac mode:

image

As an example, I also have another (different) TRV and its supported modes are:

image

I suspect the blueprint uses hvac mode to turn the TRV on and off, which wont work. See if there is another way using temperature instead.

I dont use a blueprint at all, I use my own automation to simply toggle the temperature to either 5 or 25 for ‘on’ and ‘off’ based on whether the current temperature is above or below the target temp.

And finally… does look like the author of that blueprint is aware of the issue, I see this:

That makes sense now :sweat_smile: Thanks

That’s way better, I would prefer to use my own automations as well, but how do you read the current temperature from the thermostat? The only entities I have from this thermostat are these:

So how can I make an automation based on the current temperature?

Is there a way to split the climate.bathroom_thermostat_becathermostat entity into 3 sensor entities that I can use seperately?

Since when I choose this entity in the history page, I can see 3 sensors:

I must be missing something… again…

Here is a very simple automation that checks if the TRV is below 20 degrees and if so turn on the TRV by setting its target temperature to 25. I added a delay of 2 minutes, but you don’t need to.

description: ""
mode: queued
trigger:
  - platform: device
    device_id: 3db80c338be90671452f65f50baa71b7
    domain: climate
    entity_id: climate.moes_trv_downstairs_bathroom_becathermostat
    type: current_temperature_changed
    below: 20
    for:
      hours: 0
      minutes: 2
      seconds: 0
condition: []
action:
  - service: climate.set_temperature
    data:
      temperature: 25
    target:
      entity_id: climate.moes_trv_ensuite_bathroom_becathermostat

Naturally your device id will be different, this is what it looks like in the automation editor UI:

You can do something similar to in reverse to turn it off, either as a separate automation or combined into this one with trigger ids.

Like James-Lee-007 I bought a Moes BRT-100 TRV and figured it presented me too little entities. I cannot read or set its temperature setpoint. So I followed the same steps, copying Rofo’s quirk to a file on my Pi and adding the reference in my configuration.yaml, exactly the same. I even added the extra two lines cckp suggested. Removed the device, restarted HA and repaired the TRV.

There’s no change in the entities though. What can I do?

The only reference to an error related to Moes I could find is this:

Logger: zhaquirks
Source: /usr/local/lib/python3.11/site-packages/zhaquirks/__init__.py:462
First occurred: 17:57:01 (1 occurrences)
Last logged: 17:57:01

Unexpected exception importing custom quirk 'moes'
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zhaquirks/__init__.py", line 460, in setup
    spec.loader.exec_module(module)
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/config/custom_zha_quirks/moes.py", line 69, in <module>
    class BecaManufCluster(TuyaManufClusterAttributes):
  File "/usr/local/lib/python3.11/site-packages/zigpy/zcl/__init__.py", line 167, in __init_subclass__
    raise TypeError(f"Duplicate definitions exist for {duplicates}")
TypeError: Duplicate definitions exist for ['boost_duration_seconds']

The quirk is old. That error you’ve listed was caused by an HA upgrade ages ago, but it was very easily fixed.

Try this one: (The link will expire in a day)

https://ctxt.io/2/AABQ_YHRFA

Thank you so much @Rofo! I’ll try this one out.

Edit: so much better!


Thanks again.

If I use this quirks file in home assistant I get an log error:

Logger: zhaquirks
Source: /usr/local/lib/python3.11/site-packages/zhaquirks/__init__.py:462
First occurred: 22:12:57 (1 occurrences)
Last logged: 22:12:57

Unexpected exception importing custom quirk 'ts0601_trv_beca'
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zhaquirks/__init__.py", line 460, in setup
    spec.loader.exec_module(module)
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/config/custom_zha_quirks/ts0601_trv_beca.py", line 68, in <module>
    class BecaManufCluster(TuyaManufClusterAttributes):
  File "/usr/local/lib/python3.11/site-packages/zigpy/zcl/__init__.py", line 167, in __init_subclass__
    raise TypeError(f"Duplicate definitions exist for {duplicates}")
TypeError: Duplicate definitions exist for ['boost_duration_seconds']

@Rofo Could you share a link to this new quirks file again? Or could I find this file elsewhere?

Find this line of code in the quirk (should be line 95):-

BECA_BOOST_COUNTDOWN_ATTR: ("boost_duration_seconds", t.uint32_t),

And change it to this:-

BECA_BOOST_COUNTDOWN_ATTR: ("boost_duration_countdown_seconds", t.uint32_t),

Keep the indentation the same as the lines above and below it.

Note there is another line of code on line 92 above it that looks the same, leave that untouched.

Yes, thank you. It looks like it is working now. No error in the log.

For what reason is the description of the on_off buttons in the interface just “Switch”?
Is this a limitation of home assistant (e.g. on_off buttons do not have a “description” property)?
I am asking because I have a similar quirk for another Tuya valve and it has the same issue. I have been trying to add a description, but failed with my limited home assistant knowledge.

Could you please share this working ZHA quirk?

Here it is, I hope pastebin doesn’t ruin the formatting: """Beca TRV devices support."""import loggingfrom typing import Optional, - Pastebin.com
This is totally Rofo’s work, I take no credit.

1 Like

Hi All,
Trying to get the exact same TRV to work with my HA instance via ZHA. I’ve tried using this BECA custom quirk but it still doesn’t seem to allow me to ‘push’ any configuration to the device at all, just reading the ambient temperature and current target temperature.
I’m really surprised (given how common this TRV seems to be) that ZHA don’t fully support it.
Is there any way to easily debug problems?

There is another quirk for the device here,

See also ZHA - ZigPy - Thermostatic valve TS0601 doesn't work - #17 by highsciguy

I compared with the one from the Pastebin above and find that there are only a few differences in the code. The major difference being the addition of an array “server_commands” in the Github version.

I have not tried the above quirk yet, but I can tell that the upstream ZHA implementation does not push any configuration at all and also simple things like battery state info do not work (if you see that, the custom quirk may not be active).

I also have issues with the custom quirk though. Among others, the device, although re-initialized, always returns to a schedule and starts to heat after some time. I do not find means to disable that via ZHA. However, I can at least temporarily set the temperature, toggle the child lock, open window detection and so on. I will test the Pastebin version in the coming days.

FYI, I had a go with that custom quirk and it was still not happy.
I decided to take a punt and spin up Zigbee2MQTT in a docker container and pair it up to that - it worked immediately.
I think I’m probably going to move my whole Zigbee setup over to that instead of using ZHA as it seems to be a more focussed project and can be operated in it’s own right.
It also works really well with HA from what I’ve seen.

Indeed that looks somewhat more organized. The Zigbee2MQTT “converter file” for the device appears to be https://github.com/Koenkk/zigbee-herdsman-converters/blob/89fd37d7fc0715e62fb6e62e83a9fc48cbb31fba/devices/tuya.js
It has much less low level code than the quirk, likely because it reuses generic code shared between tuya devices etc.