Sonoff TRVZB with thermostat_over_valve

[johnbur1]

I notice that the latest Sonoff firmware (1.1.5) and the latest zigbee2mqtt exposes 'Valve opening degree
Valve open position (percentage) control'
'If the opening degree is set to 100%, the valve is fully open when it is opened. If the opening degree is set to 0%, the valve is fully closed when it is opened, and the default value is 100%'
Does this mean that I should be able to use thermostat_over_valve instead of thermostat_over_climate with this TRV now?
Anyone tried it?

[jmcollin78]

Hello @johnbur1 ,

Yes ! And controling directy the valve is far away the best solution. You will not depend on a regulation algorithm elsewhere.

I suggest to switch to 'over valve' VTherm. Do to that you have to recreate it (you cannot change the type once created).

Thank you for the information, it could be an interesting information for those who want to buy some compatible TRV.

[tbrasser]

I think we don't have actual valve control here. It's just 2 settings to set the percentage in fully open and fully closed positions. (And by default open position is 100% open, and closed position is 100% closed (= 0% open).

(I have 2 of these with firmware 1.1.5 on latest z2m edge)

[johnbur1]

Shame, I was hoping that someone much more clever than me would be able to make this work :-(

[tbrasser]

Maybe if you set one the inverse of the other you force it in that position? (open=75, closed=25, valve forced at 75%?)

[johnbur1]

It works! The 'Valve opening degree' is not enabled by default in HA, but once enabled, you can adjust the valve open % manually and the valve responds immediately.
VT 'over valve' also controls this perfectly.
We do seem to have actual valve control after all!

[jmcollin78]

This is really a great news. I will add that in the README.

[johnbur1]

Update - all working perfectly - have re-done all my trvs.
Even easier than I said - the 'number.trv_name_valve_opening_degree' entity is already enabled in HA, it wasn't on the first one I tested, and you don't need anything in configuration.yaml after all. I factory reset my test one and all ok straight away.

Only thing to remember is to set the internal TRV setpoint to 35deg so it does not ever close the valve itself!

[johnbur1]

@jmcollin78 Loving thermostat over valve with the Sonoffs - many thanks.
One question I have, I am noticing that at low opening % in VT, the danfoss valves I use really don't let any water through, so I am finding that if using central control, the boiler can be triggered with no water flow. Is there any setting I can use that can specify a minimum %age before the boiler fires?
If not, is this something you could consider?

[jmcollin78]

Hello @johnbur1, There is a threshold that starts the boiler only if more than x VTherm are active.
Do you think you can use this threshold to avoid starting the boiler ?

On the other hand, you can define your own min and max for all VTherm. Maybe those threshold will do what you want.
The behavior is the following:

1. VTherm calculate an open percent,
2. if open_percent < min, then set it to min,
3. if open_percent > max, the set it to max.

That is not exactly what you want but there is a chance that it does the trick. Try to put the min let's say to 5% and tell me if it does what you want.

[sleveille4]

hi,
i have serveal TRVZB, and i updated them to FW 1.1.5 to get access to the valves

but there is a problem:

the update actually exposes 2 valves per TRVZB:

• "Valve opening degree" (0% = closed / 100% = opened)
• "Valve closing degree" (0% = open / 100% = closed)

all valve do exposes those 2 entity, BUT for some valves only the "Valve opening degree" works, and for others, only the "Valve closing degree".

despite factory resetting, there is no way to actually change this behaviour.

so the valves responding to the "Valve opening degree" entity works very well with versatile thermostat, but those responding to "Valve closing degree" either:

• do not work if you set versatile thermostat to operate on "Valve opening degree" entity
• works inverted if you set versatile thermostat to operate on "Valve closing degree" entity

despite having 6 of those TRVZB, i found no way to identify wich is wich, short of manually interacting with the 2 valves on each TRVZB to identify wich entity actually controls it

would it be possible to add support for such inverted behaviour, say by adding a "inverted valve" option when selecting the valve, wich would send 100-"computed opening degree" to the device?

for example, if VT is supposed to send "70% opened" to a regular valve, if the inverted flag is active it would send 30% to the valve?

update:

in the mean time, i was able to work around by using automations to send the "100 - Valve opening degree" result to "Valve closing degree" entity every time the value of "Valve opening degree" entity changes.

alias: TRV_CH1_closing_valve
description: ""
trigger:
  - platform: state
    entity_id:
      - number.trv_ch1_valve_opening_degree
condition: []
action:
  - service: number.set_value
    metadata: {}
    data:
      value: "{{100 - states('number.trv_ch1_valve_opening_degree') | float }}"
    target:
      entity_id: number.trv_ch1_valve_closing_degree
mode: single

after some little testing it seems to do the trick, however not sure it's a 100% workaround

so overall all the TRV that do work with "Valve opening degree" still works ( obvious right?)
and all those who did not, i still use the "Valve opening degree" for them in versatile, then after adding the automation for those specific TRVs, now it also works :)

i considered creating 1 automation to manage them all(using trigger ID) BUT, should 2 TRV be updated at once, only one instance of the automation ran so one TRV was properly opened or closed but not the other(s) so i do have 1 automation per "inverted" TRV

[lesotter]

Yes, I have only tested two TRVZB so far - one works with valve opening degree, the other one stays at 100% whatever the VT tries to send it. MQTT also logs it at 100% opening degree whether it wants heat or not

[johnbur1]

Strange. I have fifteen of these valves, and both Valve opening degree and Valve closinhg degree work fine on mine with firmware 1.1.5
Could it be something in zigbee2mqtt settings?

[sleveille4]

well, i started by checking all settings then deleting + factory resetting one of EACH "type" then pairing them back, result remained consistent for each.

i checked in z2mqtt settings, devices settings etc.... but didn't find any setting that seemed relevant to the issue i encounter.

from what you are saying is that, for you, on all TRV you can choose to control the valve either with "opening degree" or "closing degree" and both works?

because on my side i do not have this behaviour, some only works with "opening", the rest only with "closing" and none with both

they are all running 1.1.5, but:

salon1
salon2
bureau
works only with opening degree

ch1
ch2
cuisine
sdb
works only with closing degree

and weirdly cuisine doesn't report fw date for some reason

[ooii]

Actually, opening (resp. closing) degree is how much the valve should be open (resp. closed) when fully opened (resp. closed). Which means that if you set opening degree to 50, the valve will open only to 50% if it receives the order to be fully open. Note that this order is internal and cannot, for now, be controlled externally.

[johnbur1]

I'm just using 'number.trv_name_valve_opening_degree' and using VT to control that in over valve mode.
I don't see why you would touch 'number.trv_name_valve_closing_degree' - just leave it at 100?
Also make sure that the internal target temp of the TRV is set to 35deg. so it is not interfering with the valve.
Test from zigbee2mqtt, as VT may have regulation thresholds set which made testing confusing.

[sleveille4]

Yes all my testing was done without any vt instance on the trvzb, and via z2mqtt interface directly.

Also the trvzb internal thermostat is set to max (35 i think), althought that can't be the explaination as it would block any opening if it had a lower mesured temp than the target, not just one of the 2 kind of valves, randomly from one device to the other. It either would open regardless of the entity i interact with, or wouldn't.

I should have time this week-end to tinker with ha, i'll try deletong z2mqtt and reinstalling it.... Who knows..... Maybe somethong went wrong

[sleveille4]

so after removing then installing Z2MQTT back, it seems to actually properly work. now all the TRVZB respond properly to both entitys, so i disabled my automations and added back the VT instances on all TRVZB and so far, it works.

still unsure what happened, as i removed / factory resetted then added them all again after the FW update, yet ony "resetting" Z2MQTT seems to have solved it.

[Basanites]

If anybody is using VT with a TRVZB, I created a blueprint to use the TRVZB in valve mode and sync the setpoint temperatures between the two. That means you can adjust temperature either via the thermostat directly or via the HA UI.

To properly set it up, go to your TRVZB entity and set the temperature offset to -12.8 (the maximum allowed on firmware 1.2.1, older firmwares have -7 as max).
This way we can actually set the intended temperature while still forcing the internal algorithm of the TRVZB to fully open up (at least I hope so, the testing phase is in progress).
Afterwards create a new automation from my blueprint. Set TRV 1 to your VT and TRV 2 to the actual TRVZB.
Now whenever you change any of the two setpoints, it will automatically be synced to the other, allowing everyone to change temperature to their liking, whether they use the HA app or don't.

[Basanites]

Thanks for the comment @Johnson145, I will look into it later.

My original climate entity seems to accept only temperature steps of .5 degrees. My VT is configured to allow .1 steps though. That was causing another inconsistency before. With my proposed change, another sync will get triggered automatically to reflect the .5 change back to VT.

Iirc there is also a setting in VT which limits temperature step resolution. Probably not a bad idea to keep that the same as the resolution of your TRVs.

The other downside to controlling both the opening and closed % is that in the event of home assistant going down - the TRVZB would be locked in place with no manual user input able to control the heating. (hilburn)

That on the other hand is indeed a quite bad limitation.

If I understand the system correctly, one side is always going to be "locked" if your controller is down. If you are controlling the valve open degree, like we all are, and your room temp was above the setpoint before the controller went down, you won't be able to get the radiator to heat up.

the way i solved it was by changing settings in Z2MQTT, namely the 3 cache option and the Last seen you can find in Z2MQTT settings / Advanced
my T° sensor reported so rarely that it triggered safe mode, since i activated those, no more problems, as it seems it now periodically resend data with a new timestamp if it has not changed

Nice workaround :D I just set my safety timeout to three hours or something ridiculous. That seems to work too. (I am running the Aqara temperature sensors and they also love not updating even though their manual says they should send a message at least every 60mins)

Edit:
The delay is removed from the blueprint. From @Johnson145 and my testing, everything still seems to work fine. If you were not having issues before, I don't really see a reason to upgrade. Should not hurt either though.

[Johnson145]

Iirc there is also a setting in VT which limits temperature step resolution. Probably not a bad idea to keep that the same as the resolution of your TRVs.

Thanks for the hint. I've updated it accordingly by now. I didn't notice the different resolution before explicitly getting pointed to it with the new behavior.

On the other hand, the more I think about it, I can actually imagine that some people prefer to keep those settings independent. So you can probably use the smaller steps for the internal temperature algorithm of VT, even though the thermostat natively supports only larger steps. Anyway, personally I prefer to keep both sides synchronized.

If I understand the system correctly, one side is always going to be "locked" if your controller is down. If you are controlling the valve open degree, like we all are, and your room temp was above the setpoint before the controller went down, you won't be able to get the radiator to heat up.

True, you get limitations when HA is offline either or. With your method, you can at least manually turn off the thermostats at any time. When also using the closing_degree variant, that may not be possible anymore either.

The delay is removed from the blueprint.

Nice :)

[Atiroocky]

7 degrees is the maximum correction allowed - I haven't really looked into whether this is an issue with the z2m quirk or the device itself

With last firmaware updated (1.2.1), i also have -12.8°C to 12.7°C offset min/max

[hilburn]

It doesn't really matter anyway - the logic is "set offset to offset.min" so whatever it allows works

[hilburn]

Turns out it's a z2mqtt thing - the latest release about 2 weeks ago included that fix!

[Johnson145]

Do I understand correctly that thermostat_over_valve is now the suggested mode for the Sonoff TRVZBs? Are there any downsides for using this mode instead of thermostat_over_climate?

[jmcollin78]

over_valve is the most accurate type if compatible.
over_climate is when you cannot do something else.

[Johnson145]

Awesome, thanks for the quick clarification!

PS: Maybe such a strong statement is worth being added to the Readme? I may have missed it somewhere, but after reading the section about the three types a few times, I was assuming that potentially over_climate is the most powerful one.

[sleveille4]

this was the mode i used last winter as valve control was not possible then

over_climate as some limitations, the most notable being that when the emitter is heating up it will heat up the internal TRVZB sensor really fast (because it is ON the emitter), so VT will need to recompute and adjust the TARGET_TEMP sent to TRVZB very often.
this makes regulation really hard to fine tune leading to overheating or under heating.
coupled with the "on/off" behaviour of the valve in this mode, it also chew throught batteries REALLY fast.

[Atiroocky]

That new firmware is a game changer.
Have someone manage to expose this new entity in ZHA ? that would be the cherry on the cake...
Thanks

[sleveille4]

not possible for now with ZHA as they won't update, requires a quirck that nobody seems to want to do.
see this thread:
zigpy/zha-device-handlers#2772 (comment)

thread opened for a year and no change.

i decided to switch to Z2MQTT and not only did TRVZB support is fully present but it also let me have better control over most of the other devices, update my zlinky etc....

[ooii]

What would be good is the ability to set the current_temperature from an external sensor, which seems to be possible according to what's written on the box.

[sleveille4]

if you refer to the ability of TRVZB "current_temperature" to be replaced by an external sensor, this is only possible within sonoff ecosystem using some of their controller, as described in the changelog of FW 1.2.1 here:
https://forum.ewelink.cc/t/trvzb-firmware-changelog/74377

for our usage tho, that is exactly what VT is doing by ignoring the internal sensor and replacing the thermostat & logic of the TRVZB (in "over_valve" mode), just using the TRVZB as a valve.

[ooii]

Yes, I'm referring exactly to that. I understand that only their controller can do that for now but that was also the case of the Aqara valve which has been hacked and gives now the ability to set the current_temperature from an external sensor with Z2M.

[hilburn]

What would this achieve that using the exposed temperature offset entity would not?

The current_temperature attribute exposed by the climate is equal to internal_temperature + offset - if you want to adjust it so the current temperature reads exactly the same as an external one set new_offset = current_offset + external_sensor - climate.current_temperature

[sleveille4]

there are other virtual thermostat that works like that, better thermostat is one of them if memory serves, but it tends to take long to reach target or overheat then oscillate around Target T°, depending on the room / heat emittter etc...

[Johnson145]

Anyone else feels kind of betrayed by Sonoff?

I've just purchased and installed 20 of their TRVZBs around my house and regret not having chosen a different device. I did conduct quite some research before buying them and even explicitly checked the support of the valve control. On there website (and on Amazon etc.) they still explicitly claim that they support this:

Yes, if you know for 100% what you need to look for, the wording may indicate the min-max-only-limitation, but I guess noone will actually understand that without already being in the middle of this rabbit whole...

I even found this GitHub discussion before purchasing the devices, but probably should have been more critical about the "it works now" conclusion.

Long story short: If someone else out there gets here and hasn't decided on which thermostats to buy yet, do not buy the Sonoffs if valve position control is a major objective of yours ;)

[johnbur1]

The discussion here is over complicating a very simple solution.

1. Use VT over_valve to set valve opening degree on the trvzb
2. Set the internal set point to 35deg so it never closes the valve itself
   Nothing 'fairly well' about it. It works perfectly!

[Johnson145]

That's not perfect, because it means that you can't set the temperature without Home Assistant anymore.

[johnbur1]

Ok, you got me, that's a major issue.
Set to temp on the TRV itself in that rare scenario (assuming you have a robust HA setup)?
Or, set in zigbee2mqtt (assuming you are running it separately to HA)?

[hilburn]

If you set the internal temperature calibration to -7C it works fine for both manual and HA control if you sync the TRV climate with the VT climate (easiest way currently is using the "sync temperature blueprint" linked elsewhere in the thread).
I'm looking at integrating this behaviour into VT as well to make it a little more friendly

[sleveille4]

That's not perfect, because it means that you can't set the temperature without Home Assistant anymore.

while you need HA to run in the background, if you use @Basanites script, you CAN actually still control the T° using the TRV dircetly.
i do it in the whole house, including in the living room with 2 TRVs, and changing either will update both TRVs + the associated VT entity.

[jmcollin78]

Hello,

Please read this and tell me if you agree with that: #645

I will start soon to develop this.