[Problem]: Moes BRT-100-TRV (TS0601, _TZE200_b6wax7g0) position incorrect

[fhempy]

What happened?

I'm using Moes BRT-100-TRV (TS0601, _TZE200_b6wax7g0) but unfortunately the valve position is somehow incorrect.

What I did: 9:14: set current_heating_setpoint to 21, temperature was 19, valve opened but position remains 0% ...: within that time valve position was reported 0% several times, but the radiator was already heating 9:38: position reports 25%

When using the tuya gateway I get work_state from tuya cloud which immediately changes from closed to opened. See https://developer.tuya.com/en/docs/iot/s?id=K9gf48r3k5ctd#title-1-Support%20reporting%20instructions%20to%20the%20cloud%20only

What did you expect to happen?

Position to be reported immediately after valve opens

How to reproduce it (minimal and precise)

• set desired temperature higher than current temperature
• check changes of position within z2m

The log shows changing desired temperature but position remains at 25%. Could it be that dp 7 reports opened (0) and closed (1)?

Zigbee2MQTT version

1.22.0

Adapter firmware version

20210708

Adapter

Sonoff Zigbee USB Dongle Plus

Debug log

debug_moes_trv.log

[torsetto]

Ciao ragazzi, I have the same problem too. It does not update in real time position with zigbee2mqtt version 1.22.1-1. The Home Assitant Core version is 2021.12.6. Tuya integration in hassio fails to see tubes. I needed to find the position of the valve to turn on the boiler circulator. How can it be done? I am attaching the log file. Grazie log.txt

[mrybas]

i have the same issue

[Lipown]

TV02 here, suggesting it is the same valve. I have them for 10 day and the positioning is strange. The temperature measured by valve updates only if i change the temperature calibration value. A lot of times changing setpoint temperature in manual mode by the valve wheel (or in z2m) to max and then to min does not move the position of the valve at all. I set the temp to 22°C while valve were reporting 19. Came home and on external sensor I had 26. Valve still reported 19. Changed the calibration value to random and back, valve temperature updated to 26,6 and after few seconds the valve finaly closed. I have two of those valves and the behaviour is the same.

[jandot]

Same or similar issue here, I think. Wanting to control the programming using zigbee2mqtt (by setting the BRT100 to "manual" and sending the right target temperatures from my raspberry pi at the right moments). Position does not change when switching between 5 and 20 degrees. After limited testing, what does work are either (1) pressing "-" on the valve itself which then displays "OF", and (2) setting the "preset" to "programming" and then "manual" again using mqtt. In contrast to @Lipown , changing calibration value did not fix it for me.

[fhempy]

Can you please check with debug enabled if you get following message in the log: Received Zigbee message from 'TRV_Kinderzimmer', type 'commandGetData', cluster 'manuSpecificTuya', data '{"data":{"data":[1],"type":"Buffer"},"datatype":4,"dp":7,"fn":0,"status":0,"transid":31}' from endpoint 1 with groupID 0

I thought that this message indicates if the valve is opened or closed.

[jandot]

I don't get that commandGetData message when running mosquitto_sub with debug flag. The position of the valve is however reported in the regular message as below:

{"battery":94,"boost_heating":"OFF","boost_heating_countdown":0,"boost_heating_countdown_time_set":300,"child_lock":"UNLOCK","current_heating_setpoint":5,"eco_mode":"ON","eco_temperature":20,"linkquality":48,"local_temperature":17,"local_temperature_calibration":1,"max_temperature":45,"min_temperature":5,"position":75,"preset":"manual","program_saturday":{"saturday":"7h:30m 20°C,  12h:0m 20°C,   14h:30m 20°C,  17h:30m 5°C "},"program_sunday":{"sunday":"  8h:0m 20°C,  12h:30m 20°C,  14h:30m 20°C,  17h:30m 5°C "},"program_weekday":{"weekday":" 7h:30m 20°C,  9h:0m 20°C,  13h:30m 20°C,  17h:30m 5°C "},"window":"CLOSED","window_detection":"OFF"}

As you can see in the message, target temperature is set to 5 degrees, but valve position remains at 75%.

jan.

[fhempy]

You need to run z2m with debug mode (Frontend - Log - Debug).

[jandot]

Ah, thanks. I got the following message after command {"current_heating_setpoint":5}:

Received Zigbee message from 'MoesRadiatorValve', type 'commandGetData', cluster 'manuSpecificTuya', data '{"data":{"data":[0,0,0,5],"type":"Buffer"},"datatype":2,"dp":2,"fn":0,"status":0,"transid":76}' from endpoint 1 with groupID 0

The current state after this command:

{
    "battery": 94,
    "boost_heating": "OFF",
    "boost_heating_countdown": 0,
    "boost_heating_countdown_time_set": 300,
    "child_lock": "UNLOCK",
    "current_heating_setpoint": 5,
    "eco_mode": "ON",
    "eco_temperature": 20,
    "linkquality": 51,
    "local_temperature": 18,
    "local_temperature_calibration": -2,
    "max_temperature": 45,
    "min_temperature": 5,
    "position": 50,
    "preset": "manual",
    "program_saturday": {
        "saturday": "7h:30m 20°C,  12h:0m 20°C,   14h:30m 20°C,  17h:30m 5°C "
    },
    "program_sunday": {
        "sunday": "  8h:0m 20°C,  12h:30m 20°C,  14h:30m 20°C,  17h:30m 5°C "
    },
    "program_weekday": {
        "weekday": " 7h:30m 20°C,  9h:0m 20°C,  13h:30m 20°C,  17h:30m 5°C "
    },
    "window": "CLOSED",
    "window_detection": "OFF"
}

Although target is 5 degrees, the position stays at 50 (was 50 before sending the command).

[fhempy]

I think we should check in debug mode if we can find a proper ZigBee message which indicates if the valve is opened or closed. I have used this thermostat with tuya gateway as well and it reports opened/closed correctly. So there must be definitely some info about it.

[jandot]

I only have a zigbee2mqtt running on RPi as a gateway, so no other way of interfacing at the moment. I'll keep on trying things out.

[jandot]

It seems that switching "eco_temperature" (instead of "current_temperature_setpoint") between 5 and 20 does change the valve opening. At least I can hear the little motor turning, but the "position" does not change unfortunately. As we have old cast iron heating it will take a while to cool down, so I'll can check if it actually worked tomorrow.

[fhempy]

Hmm...seems little bit different than mine. In my case set heating temperature always changes the valve position as I can hear the motor. So the function itself works as it should, just the value position isn't updated in z2m.

[c0dr1ver]

I have the same problem.

[jandot]

I have now tested a couple of days and it does seem that the temperature setpoint does do what it is intended to do and that it is indeed just the reporting of the position that is wrong. My apologies for confusing anyone.

Jan.

On Tue, 4 Jan 2022, 00:12 Dominik, @.***> wrote:

Hmm...seems little bit different than mine. In my case set heating temperature always changes the valve position as I can hear the motor. So the function itself works as it should, just the value position isn't updated in z2m.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/10384#issuecomment-1004418286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACOO5PVLGMON2BH24OP6DUUIUMVANCNFSM5K2AZIAA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[KaHeMu]

Hi, I noticed the same issue with a newly bought BRT-100-TRV (using Z2M 1.22.1 commit: c2b5229, zStack3x0). The TRV works correctly but the valve value {"position"} sometimes stops reporting its real position after a while. I have tried out many things like changing between the "preset" modes, or changing eco_temperature or setcurrent_heating_setpoint. Sometimes the valve position comes back being reported correctly but I cannot reproduce exactly the condition how to get it back working.

[vladi1234]

Hi, I've already written somewhere when TRV delivers valve position, you have to search through topics instead of making new topics. Well it doesn't matter now.

BRT-100-TRV only supplies valve position if the touchscreen display is active. Probably the manufacturer Beca has done this on purpose to save battery, less data transport, less consumption. So in standbay mode there is also less data transport.

[fhempy]

Hi Vladimir,

thank you for that info. Nevertheless tuya reports opened and closed via tuya gateway if I use smart life app. It's reported correctly all the time via smart life app. So there must be some info about the state of the valve, at least if it is opened or closed.

[vladi1234]

There is a possibility for the Smart Life app to stay connected while you have the app open and keep TRV active to prevent TRV from going into standby mode.

TRV has five states, showing as a percentage: 0 - 25 - 50 - 75 - 100

[fhempy]

Actually I can also receive the correct state (opened/closed) via Tuya Cloud API (no active Smart life app). So maybe the tuya gateway is sending some signal to prevent standby?

[fhempy]

You can find that documented here in the official API (valve_state): https://developer.tuya.com/en/docs/iot/s?id=K9gf48r3k5ctd#title-1-Support%20reporting%20instructions%20to%20the%20cloud%20only

[vladi1234]

You can't rely on it because that is Beca's own development, not Tuya.

[fhempy]

But how does tuya get the correct state? It works in my case with 7 thermostats and all of them report opened/closed correctly via Tuya cloud.

[vladi1234]

Moes BRT-100-TRV Beca BRT-100-TRV has five states, showing as a percentage: 0 - 25 - 50 - 75 - 100

Tuya APP or Tuya cloud only uses two states: 0 = close 100 = open

[fhempy]

Sorry, I wasn't clear enough. Position isn't always correct. Even if you look in smart life you will see sometimes 25% open but "working status" says Heating or Paused. Paused means that the valve is closed even if valve ratio value is not 0%.

Closed and opened (valve_state, not position) are the states shown as Heating/Paused in the smart life app and they are always correct.

[fhempy]

Here is one example, it says Paused and 25%. The real state is closed. Just in case the app says Heating it is opened. So there must be some information about the state at least, not the position.

[vladi1234]

Have you tried in such a state when pause and 25% appears, also activate the display on TRV?

[fhempy]

No, not yet as I'm not using the touch display normally. I can try that this weekend to see if position updates.

But as you can see the working status is correct. So that would help already to know if the valve is opened or closed.

[vladi1234]

BRT-100-TRV only supplies valve position if the touchscreen display is active.

Please test it first.

[KaHeMu]

This is correct. The BRT-100-TRV updates the valve position only as long as the display is active. I tested it. This explains why it sometimes worked and sometimes not. Unfortunately this doesn't help for my Z2M and node-red based automation. The "working status" with "heating" or "paused" mentioned by @dominikkarall would be sufficient for me. How can I get this via zigbee2mqtt? It's not included in the exposed data.

[fhempy]

I'm using those states for heating automation via Tuya Cloud and Tuya Gateway. I wanted to switch the system to z2m but at the moment I can't get that value via z2m. I'm sure that the value must be transmitted but I couldn't identify it yet.

[fhempy]

I can confirm, that the updates are sent immediately after the touch display of the thermostat is activated.

I tested again the behavior of datapoint 7 and I can reproduce following:

• Temperature: 20 degrees
• Set temperature to 15 degrees (received value 1 = valve closed from datapoint 7)
• Set temperature to 25 degrees (received value 0 = valve open from datapoint 7)

I activated DEBUG to see those values. I'm going to test during the night if datapoint 7 is also sending values when the temperature changes.

@vladi1234 can you confirm if you have the same behavior for datapoint 7?

[Rigolman69]

Hello,

I just get one of this items fews days ago and I am currently preforming tests. Following thoses discussions I was wondering what is "datapoint 7" ?

[fhempy]

datapoint 7: Set log to DEBUG and check for messages with datapoint (dp) 7: Received Zigbee message from 'TRV_Kinderzimmer', type 'commandGetData', cluster 'manuSpecificTuya', data '{"data":{"data":[1],"type":"Buffer"},"datatype":4,"dp":7,"fn":0,"status":0,"transid":31}' from endpoint 1 with groupID 0

In my case the thermostat sends this message immediately after I set a heating temperature which needs to change valve position (I can hear the motor).

Unfortunately my test during the night didn't succeed. There were no more dp 7 messages :( But there must be some possibility to detect the state (opened/closed). Here you can see a plot of a thermostat which I use with official tuya gateway. The data is taken from tuya iot cloud via FHEM/fhempy implementation: The red filled bars show the valve state open.

[Rigolman69]

OK. Got it. I do not perform tests like this. I mean by growing up or down setpoint. Because I think this not true life behavior. So may be wrong results. I prefer to take my TRV and witness thermostat and moving them from cool to warm room. Of course my TRV is not physicaly instaled.

[fhempy]

Of course it's easier to move from warm to cold room. Therefore I did the test over the night to see what happens if the temperature drops. Nevertheless, can you please verify if you get the dp 7 if you set the heating temperature?

[fhempy]

I just tested as @Rigolman69 proposed by moving the thermostat from a cold to warm room and back. The dp 7 was correctly reported as opened/closed. So maybe the valve was really open the whole night during my test and therefore dp 7 value never changed.

I'm going to test further with following changes: node_modules/zigbee-herdsman-converters/converters/fromZigbee.js

case tuya.dataPoints.moesSreset:
    return {valve_state: value ? 'CLOSED' : 'OPEN' };  <== ADD THIS LINE and REMOVE break;

node_modules/zigbee-herdsman-converters/devices/moes.js

exposes.binary('window', ea.STATE, 'CLOSED', 'OPEN').withDescription('Window status closed or open '),
exposes.binary('valve_state', ea.STATE, 'CLOSED', 'OPEN').withDescription('Valve state if open or closed '), <== ADD THIS LINE BELOW THE ABOVE

[vladi1234]

@dominikkarall I now also tested DP7. Yes, you are right valve_state can be seen as a new function, it is well noted. Thank you! Yes, DP7 was not examined enough by me, I can make a new pull request for valve_state.

[vladi1234]

Pull request is ready, you have to wait now. https://github.com/Koenkk/zigbee-herdsman-converters/pull/3645/files

[vladi1234]

Merged https://github.com/Koenkk/zigbee-herdsman-converters/pull/3645/files into master.

[fhempy]

Thanks @vladi1234!

It could be that position value is always correct when the valve is open and just incorrect when valve is closed. So it might make sense to set position to 0 in z2m when valve is closed so that the position value is always correct. I haven't tested it yet if my assumption is correct.

[Rigolman69]

Hello, sorry @dominikkarall, not tested DP7 ! And now I gess too late as long as you got ahead and found a solution !

[torsetto]

Hello, I have written to Moes assistance several times. Apart from the difficulty of making the problem understood, after the fourth time I write about the problems with Zigbee2Mqtt + Home Assitant, they write to me about Google ... they wrote to me this morning "Sorry, the engineer is communicating with Google's engineers in the past two days. They can't turn it on because real-time feedback on the position of the valve will cause the battery to drain more. But other functions such as turning on or off can be controlled by voice"... Worse than going at night!

[ch4d1]

Merged https://github.com/Koenkk/zigbee-herdsman-converters/pull/3645/files into master.

@vladi1234 Using this value, do you think it might be possible to implement the climate action "off" in home assistant? Or does this only not work for me? Basically, only the "current_heating_setpoint" currently seems to determine whether the "valve_state" is open or closed.

[vladi1234]

Read here: https://github.com/Koenkk/zigbee2mqtt/issues/7941#issuecomment-932937296

[ch4d1]

Read here: #7941 (comment)

Thanks for your quick reply and sorry if I should not ask this in this issue.

As a temporary solution, that's fine. But if you think about it further, you run into problems. For example, I integrate the whole thing into Google Home and Amazon Alexa. But the assistants can't turn off the heating. Of course, you can rename "eco_mode" for the assistants. However, everyone would have to know this in the end and it remains a workaround.

Would it not be possible to set a boolean for "on_off"? With "OFF", "current_heating_setpoint" is then simply overwritten with "5" and with "ON" with "20".

Unfortunately, I don't know exactly where the values are stored. But if this were possible, it would be a better solution, wouldn't it?

[fhempy]

If you just want to implement "off" why don't you configure Home Assistant to send current_heating_setpoint=5? I'm using FHEM with Google Assistant and that works without any issues.

@vladi1234 can you set position to 0 if valve_state is closed is received? I think that would make automation easier as users just need to handle position instead of position and valve_state.

[vladi1234]

I think valve_position is a useless function for any automation as it only works when the touch display is active and there is no point in using valve_position in any way.

[fhempy]

I think valve_position provides the rough position of the valve. Even if the touch display is not activated the TRV sends the position from time to time. I can see that in the smart life app via Tuya Gateway as well.

[vladi1234]

Read here: #7941 (comment)

Thanks for your quick reply and sorry if I should not ask this in this issue.

As a temporary solution, that's fine. But if you think about it further, you run into problems. For example, I integrate the whole thing into Google Home and Amazon Alexa. But the assistants can't turn off the heating. Of course, you can rename "eco_mode" for the assistants. However, everyone would have to know this in the end and it remains a workaround.

Would it not be possible to set a boolean for "on_off"? With "OFF", "current_heating_setpoint" is then simply overwritten with "5" and with "ON" with "20".

Unfortunately, I don't know exactly where the values are stored. But if this were possible, it would be a better solution, wouldn't it?

I am very much against zigbee2mqtt devices being customized for Homeassistant only.

Each device must remain universal to fit any automation system.

You can also turn Homeassistant so that each device works according to the scenario.

[Rigolman69]

https://github.com/Koenkk/zigbee2mqtt/issues/7941#issuecomment-932980624

Hello @vladi1234

Sorry to insist but this is still not very clear for me (I'm French, so may be my comprehension is not that good) !

Basic house heating water network is composed of one boiler several radiators and a circulateur which alow hot water to go through. So when one or several rooms require heat, system need to power on ciculator. Therefore RTV need to send etiher position or room temperature in order to tell circulator to power on.

I don't see in your recomendations how you proceed.

Thank in advance for your forthcoming clarifications.