Hello @DriesA ,
This have been designed for TRV with a direct control of the valve through a number entity.
But any “system” in which a valve is controllable may fit.
1 Like
Is it possible to open the valve only in steps of like 20%?
Cause I believe there is not much difference between 3%, 8% and 12% for example, you just cannot achieve such small granularity. Even my original TRV has only 4 levels to set. Also you would reduce the frequency of opening/closing the valve with this…
I’m using Sonoff TRVZB for what it’s worth…
Hi, I starte using Sonoff TRVZB and i found following statement in docs:
Note: for Sonoff TRVZB you should not configure the “closing degree” parameter. This leads to a bug in the TRV and the
hvac_actionis no more working.
Is this still a case? How the bug manifest? I had it running with this for couple of days and didnt spot any issues (latest version of VTherm and trv firmware version 1.1.5
Would anyone be able to share working settings / config for setting up VTherm with the Sonoff TRVZB as I’m having issues?
I have read the docs in full. I’ve set them up as over_climate entities with direct valve control and only specified a valve opening entity as per the note in the docs referenced in the above post.
What I’m seeing is the VTherm hvac state conflict with the underlying state. So the VTherm states it is heating when the underlying is actually not. I suspect this is a common issue with Sonoff TRVZBs as their internal temp sensor isn’t very good, and they also have 1C of hysteresis.
I am using external temp sensors to combat this, specified in VTherm but I still see significant disparities between the current temps of the VTherm climate entity (which look correct) and the underlying entity (which are often too high or low).
If the underlying entity (i.e. he TRVZB) does not have a target above it’s current it appears the it won’t allow the valve to be opened and vice versa. The effect being that sometimes the VTherm initiates heating, but the radiators are still cold as the valves didn’t open so my target would never be reached.
I was using Better Thermostat before and saw similar but slightly different issues. I had hoped that VTherm with direct valve control would ‘just work’ if setup correctly as from reading the docs and this thread it appears many people are successfully using it.
I might try an idea I read elsewhere which is to setup an automation that sets the underlyings target to 30C when VTherm hvac_action is heating and 10C when it is not. However this feels both inelligent and like it may have unintended consequences. Surely if it were truly necessary every Sonoff TRVZB user would be talking about it!
Thanks in advance.
It is possible to do that with the following parameter regulation threshold:
Set it to a percent level like 20 (maybe too much)
Yes this is the case as far I know. The hvac_action which is used to control the central boiler is not working if you use it.
hello @danieljclark
You need the opening degree AND the calibration offset to have the best experience.
You should not use the “use internal temp” of device as explained in the documentation now. This information was missing.
This is not working for me. If I don’t set closing degree entity, then VT is controlling only opening degree entity, so I end up with something like this:
Current temp is 24.7c, set temp is 22.5c. VT changed opening degree to 0 long time ago, but it is not really 0 due to the closing degree entity not changing. I can feel my radiator is hot when I touch it, so heating is on definitely.
When I set closing degree entity as well in VT, then everything works fine as it will set opening degree to 0 and closing degree to 100 for example.
I have SONOFF TRVZB by the way.
1 Like
Thanks for a great integration. Really excellent work and thank you for taking the time to reply.
Yes I have been using opening degree AND had set the calibration offset. I have not using the internal temp of the device (unless by accident setup error or bug), I’m using sensors elsewhere in the room (mixture of Awair, Sonoff and Aqara). These are the ones I have specified under Room Temperature in the “Main” VTherm config page for each. I have never had “use underlying internal temperature of the underlying” ticked for any of my TRVs.
I think there may be a fundamental logic issue the Sonoff TRVZBs firmware which prevents them from responding to certain valve set requests when the underlying hvac_action state conflicts with the command. They have to be in “heating” state to accept an increase in the valve percentage value and not heating state to accept a set request to a decreased percentage value.
It was this post in another thread that made me aware of this ‘feature’ of TRVZBs, and I’ve confirmed that I am seeing the same behaviour with latest firmware:
I have implemented a similar workaround to the above user. I have automations that set the target of the underlying to 30C whenever hvac_action of the VTherm changes to heating. Similarly I have automations that set the target of the underlying to 10C whenever hvac_action of the VTherm changes from heating to anything else.
This way when the VTherm attempts to adjust the valve opening % this actually gets applied and I hear the valve motor change. This seems to work well with sensible fine adjustments made by the VTherm to the opening percentage to hit and maintain the temperature around the set point. As only the VTherm is shown on my dashboard, it doesn’t matter to me what the target temperature of the underlying is set to as it’s not seen anywhere.
However if anyone has Sonoff TRVZB valve control working reliably without requiring a workaround similar to the above I’d appreciate seeing their specific settings. If the underlying internal temp perfectly mirrored the external temp (i.e. instant replication tracked to within 0.1C) this workaround wouldn’t necessary as there’d never be a conflict. I’ve never been able to get this to happen satisfactorily, either with my own automations via Z2m commands, Better Thermostat or Versatile Thermostat.
1 Like
Mine seems to be working and I have only specified opening degree as per the docs.
VT sends 0% open via the opening degree entity and the valve responds accordingly. I hear the change and feel the radiator start to cool down.
If I look at the states of each in Z2M, opening degree is updated correctly and closing degree is always 100. Never updates. I’ve never even tried to change it as I read in the docs not to.
As per my last post, it seems to me like you have to check the hvac action state of the underlying TRVZB at the time the new “valve open” command is sent. If it is “heating” then I don’t think the TRVZB accepts a new position that is less open than it’s present position (or 0 for closed). Hence the workaround to force the state of the underlying.
If you are able to confirm that the issue occurs only when the underlying hvac action state is conflicting with VT hvac action state, then it becomes a case of how best to ensure this doesn’t happen.
I plan to use Versatile with the Wiser solution (its integration within HA seems to work smoothly) for electric heater (thermostat + actuator) Does anyone already implemented that set up? I suppose I should configure a Vtherm over a climate to make it work.
Hi Daniel,
I have been using Versatile Thermostat for a few days now and I am facing similar issues with the Sonoff TRVZBs. One major problem is that the temperature adjustment through the external temperature sensor via the offset parameter is not working properly. In 4 out of 5 cases when I check, the value is either higher or lower than the actual temperature of my external temperature source. This results in either no heating or continuous heating. Additionally, the Sonoff TRVZB apparently randomly switches off (IDLE) within ~0.5 degrees of the target temperature while Versatile Thermostat still shows “heating”. Especially in the living room, where I use three thermostats, it constantly leads to one radiator being off, one being hot, and the other being lukewarm. The fact that the valve control is no longer properly addressed was not on my radar until now, but it is also a consequence.
I would like to test your workaround. So, if I understand correctly, I just need to create an automation that triggers when the hvac_action attribute changes to HEATING or IDLE. As a target, I then set the temperature directly in the thermostat to, for example, 30°C for heating and 7°C for IDLE. Correct?
What does the rest of your TRVZB thermostat configuration in the Versatile Thermostat look like? Standard? Or do I need to consider anything else besides the usual (e.g., not setting closing valves)?
By the way, is there no problem with the automation when Versatile Thermostat makes changes to the target temperature? Versatile Thermostat also writes this directly into the thermostat. For example, when switching from Eco to Comfort or when I manually adjust the temperature?
Edit: I just checked it. The automation seems to work in principle. However, Versatile Thermostat immediately overwrites the target temperature again with the “correct” preset temperature. The same thing happens, of course, when I switch to another mode (eco, comfort) or adjust the temperature. How did you solve this?
I have added the temperature of the Versatile Thermostat as an additional trigger in the automation. I now always increase the “Set Temperature” of the TRVZB directly by +5°C above the original set temperature. This ensures that the thermostat always heats and doesn’t go into IDLE 0.5°C before reaching the target temperature, while the Versatile Thermostat still thinks it’s still heating.
The initial tests are extremely promising. The automation ensures that the TRVZB states are now always consistent with those of the Versatile Thermostat. As a result, the temperature control via the valve now works perfectly. The target temperature is now maintained much more stably (+/- 0.1°C on average) and, more importantly, is actually reached. Also, all 3 TRVZBs in the living room now run “synchronously” and don’t completely diverge (one on, one off, one warm, another cold, another hot).
This must be a problem that every TRVZB user has. Why don’t others notice it? Is there perhaps some way to implement this workaround directly in Versatile Thermostat?
alias: WOHNZIMMER Temperaturanpassung TRV_WZ / VT_WOHNZIMMER
description: Temperaturanpassung für Heizung WOHNZIMMER
triggers:
- entity_id: climate.vt_wohnzimmer
attribute: hvac_action
trigger: state
- entity_id: climate.vt_wohnzimmer
attribute: temperature
trigger: state
actions:
- delay: "00:00:05"
- target:
entity_id:
- climate.trv_wz_1
- climate.trv_wz_2
- climate.trv_wz_3
data:
temperature: >
{% if is_state_attr('climate.vt_wohnzimmer', 'hvac_action', 'heating')
and state_attr('climate.vt_wohnzimmer', 'temperature') != none %}
{{ ((state_attr('climate.vt_wohnzimmer', 'temperature') | float + 5) / 0.5) | round(0) * 0.5 }}
{% else %}
7
{% endif %}
action: climate.set_temperature
mode: single
Hi, I’m still fighting to migrate the logic from KNX to HASS. Perhaps someone can help me …
Current situation: On KNX a cover actor is controlling my 3 valve to mange the floor heating. There is logic that steers the target temperature based on a calculated heating curve.
Achievements so far:
- climate defined in configuration.yaml
- cover address defined in knx.yaml (id: cover.heating)
Is there any chance to modify VT to accept a cover id? I tried also boiler in the settings, but no way.
Thanks,
Hello @danieljclark ,
Thank you for this very interesing post. In the french forum many people seems to not need this workaround, but others have.
Does changing the target temp to a high value have some drawback like display is wrong or somethink like that ?
I think the Sonoff climate on HA will display a “wrong” setpoint then. Does the TRV display also this “wrong” value ?
If it is “heating” then I don’t think the TRVZB accepts a new position that is less open than it’s present position (or 0 for closed).
Hello @Gregwelldone
Yes Wiser solution have been succesfully integrated. It has been done with an over_cliamte VTherm. I think you don’t have the choice.
If you read French I can send you the thread about this.
Hello @b4rRa,
Yes, When a setpoint is changed on VTherm it does two thing:
- send the setpoint to the Sonoff
climate(the underlying device), - send to valve openess percent to the valve through the opening degree
numberentity.
I think point 1 is useless for valve openness and does only display a correct value as setpoint.
Is there perhaps some way to implement this workaround directly in Versatile Thermostat?
This feature is not dedicated to Sonoff TRVZB. This is the point. I consider this hack like awful personaly (but I understand the point).
EDIT : one better hack is to force the calibration offset to something like -12°c to force heating. Can you check this with your hack (or direclty in the calibration entity) and remove the calibration offset from the VTherm conftguration.
Let me know. This could be taken into account into VTherm because it don’t beraks the setpoint.
Merci pour la reponse. Ou puis je trouver la discussion sur le sujet?
Hello if you don’t use closing degree, you should set it to 100
Search Wiser in this french forum or claim for help: Integration schneider Wiser à home assistant - Entraide Home Assistant - Home Assistant Communauté Francophone
Le thread principale de Versatile thermostat est ici : Nouveau thermostat type proportionnel avec gestion des presets / portes et fenêtres / détection de mouvement / gestion de présence et surconsommation - #2720 par Jean-Marc_Collin - Intégration - Home Assistant Communauté Francophone
On y parle de Wiser.