[Feature request] Add native support of Sonoff TRVZB valve in VTherm

The SONOFF TRVZB is one of the cheapest and best TRV available in Zigbee for HA. It is cheaper than others, supports the offset_calibration and a kind of direct valve opening control.
This is a great candidate for over_valve VTherm.
But, unfortunately we cannot control the valve openness directly but tow values: opening degree and closing degree.
So there is at least two blueprint created by the community to solve this:

a blueprint proposed by @Basanites here https://my.home-assistant.io/redirect/blueprint_import/?blueprint_url=https%3A%2F%2Fgist.github.com%2FBasanites%2F094e140c29ead05e92de31aaef5312a6
a blueprint proposed by @kumalo here https://my.home-assistant.io/redirect/blueprint_import/?blueprint_url=https%3A%2F%2Fgist.github.com%2FKumalo%2F82b704c5a2d04c113602e0afcaedc8c2

Both seems to have a similar behavior:

change the offset_calibration to the min value to force the TRV to open the valve at 100%,
control the opening degree and closing degree with the result of the regulation algorithm to limit the openness of the valve.
more advanced feature (bi-directionnal synchronization, ...)

There is also a great discussion here on how to deal with SONOFF TRVZB: https://github.com/jmcollin78/versatile_thermostat/discussions/459
Because there is not so much TRV in the market that are directly supported, I propose to integrate it directly into VTherm as an exception to the non-written rule: "VTherm should be generic and should not be specific to a brand or model".
Main features:

control the setpoint of the TRV so that the displayed value on the TRV will reflect the regulated temperature calculated by VTherm. Note that this is not the target temperature set by the user of the preset,
synchronize the temperature set directly on the TRV with the setpoint of VTherm.
manage with offset calibration, opening degree and closing degree entities to force the TRV to regulate with VTherm rules,
optionnaly uses all features of VTherm (presence, motion, ...)

What we need in input:
In input of the new type of VTherm we need:

the underlying SONOFF climate entity. This entity will be used to control the setpoint calculated by the regulation algorithm of the TRV,
3 number entities which can controls the offset calibration, opening degree and closing degree values
the TPI input coefficient for the TPI algorithm

The point 1. make this Vtherm a kind of over_climate VTherm and the points 2. and 3. make it more a over_valve VTherm.
How to configure it:
We have here a kind of hybrid VTherm which impose to use the over_climate type with some specificities. So, we will add an option to the over_climate configuration.
This option allows a new Sonoff TRVZ configuration menu.
A specific underlying entitites menu is also needed to collect the 3 numbers entities
This extra underlying entities will prevent this VTherm to be a multi-underlying entities. Only one TRV will be controlled by the VTherm. This is another points of rupture with the current design. This is maybe a future possible enhancement (have a list of climate, and a list of offset calibration, a list of opening degreesand a list of closing degree. Waiting for this enhancement you can always group your VTherm into a super VTherm over_climate with each VTherm configured.
The TPI menu should be accessible to allow TPI regulation (and not the PI algo used for over_climate regulation.
What are the change needed:

add an option to the over_climate VTherm,
create new configuration UI as explained in 'How to configure it',
override the send_regulated_temperature method to send also the offset calibration, opening degree and closing degree as follows:

offset calibration is set with the min value of the number offset entity,
opening degree is set with the 100*on_percent [0..1] value which is the result of the TPI regulation algorithm,
closing degree is set with the 100*(1 - on_percent) value.

Don't hesitate to react to this post if you think something is wrong in my understanding.

Before starting I will need the attributes of each entities:

the SONOFF climate entity,
the 3 number entity offset calibration, opening degree and closing degree

Please send me that (Development Tool / States).

Hello,
Is that what you need ?

climate.radiateur_chambre

hvac_modes:
  - "off"
  - auto
  - heat
min_temp: 4
max_temp: 35
target_temp_step: 0.5
current_temperature: 22
temperature: 21.5
friendly_name: Radiateur Chambre
supported_features: 385
hvac_action: idle

number.radiateur_chambre_local_temperature_calibration

min: -12.8
max: 12.7
step: 0.2
mode: auto
unit_of_measurement: °C
device_class: temperature
icon: mdi:math-compass
friendly_name: Radiateur Chambre Température

number.radiateur_chambre_valve_opening_degree

min: 0
max: 100
step: 1
mode: auto
unit_of_measurement: "%"
friendly_name: Radiateur Chambre Valve opening degree

number.radiateur_chambre_valve_closing_degree

min: 0
max: 100
step: 1
mode: auto
unit_of_measurement: "%"
friendly_name: Radiateur Chambre Valve closing degree

Can we use offset not for "target" but for "current" temp setting? Like BT does? As for me it's more fault safe then setting 35C target if HA or smth fails with fully opened TRV

Can we use offset not for "target" but for "current" temp setting? Like BT does? As for me it's more fault safe then setting 35C target if HA or smth fails with fully opened TRV, and anyway leave chance for TRV maintain with internal logics itself

I don't understand what you propose. offset is an absolute value. It doesn't apply to target or current.

Maybe I explained not directly, but in BT it's named "direct offset"
On Sonoff TRV it changes the Temp.calibration preset via z2m to change "current temp" on TRV itself to make it use it's own logic.

ok. That is what I intend to use. And there is no other choice so all is fine.

I have half-written something along these lines but.. got distracted playing Factorio
I don't think this should be made so specific to the Sonoff TRVZB - it should be possible to set it up relatively generically with:

Climate Entity
Offset Entity - corrects TRV internal temperature to match the room thermostat
Tuple with (Valve Opening Entity, Valve Closing Entity) - either can be None, when you set a valve percentage to X it sets Opening to X, Closing to 100-X

I think this would give the most robust performance of the valve control, while also maintaining the behaviour of the TRV when physically interacted with - the problem with the "set the temperature offset to the minimum" control method is that it means the temperature displayed on the TRV itself will show as artificially low which would be confusing for people operating it.

I have half-written something along these lines but.. got distracted playing Factorio
I don't think this should be made so specific to the Sonoff TRVZB - it should be possible to set it up relatively generically with:

Climate Entity
Offset Entity - corrects TRV internal temperature to match the room thermostat
Tuple with (Valve Opening Entity, Valve Closing Entity) - either can be None, when you set a valve percentage to X it sets Opening to X, Closing to 100-X

I think this would give the most robust performance of the valve control, while also maintaining the behaviour of the TRV when physically interacted with - the problem with the "set the temperature offset to the minimum" control method is that it means the temperature displayed on the TRV itself will show as artificially low which would be confusing for people operating it.

Yeah was thinking along these lines as well, then it can also work with bosch as soon as z2m also creates the pi_heating_demand as number in HA (it's controllable already in z2m)

Yes be patient.

Hello,
Si I have a working VTherm with Sonoff TRVZB on my testing environment.
The PR is here: https://github.com/jmcollin78/versatile_thermostat/pull/651
The pre-release version is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta2
Release note
What's Changed

preview of #645

Please do not install it, if you are not invited to do so.
To use it:

create a VTherm over_climate,
set the Sonoff climate as underlying. You can also add many climate (not tested yet),
check the "Sonoff TRVZB mode" checkbox. This will add a menu 'Sonoff TRVZB configuration',
in this menu, add the 'offset calibration', 'opening_degree' and 'closing_degree' entities. You should add as many entities as underlying climate added in 2.
this will enable the TPI menu. You can check or adjust the TPI parameters or keep the default values first. Tuning will be done later.

Then you can use the VTherm as usual. You have more VTherm attributes (tpi, open_valve_percent, ...) if you want to check and to make some graph.
To be completed: the self-regulation is not used, please ignore the parameters
Note: all unit tests pass. So you should not have an impact on the others VTherm you could have. Despite I don't have any Sonoff TRVB at home, I will install this pre-release to check the non regression.
Full Changelog: https://github.com/jmcollin78/versatile_thermostat/compare/6.7.0...6.8.0.beta2
Please report
You are welcome to give it a try. When you report always add the VTherm attributes, curves if needed, and logs if it is relevant.
Some result in my test env
When target is almost reach:

When the temperature goes low:

Just for interest, why should we use valve close %
Not only open?

Discovering your thermostat, i will test it when you will release it for sure. Home being fully deployed with sonoff trvzb here. Thanks a lot for this support !

Running this now on 1 vtherm with 2 trvzb underlyings. Awesome!

Just for interest, why should we use valve close % Not only open?
As for me I not sure for valve % usage because on water noice ( Multiappartmnent house so well

See https://github.com/jmcollin78/versatile_thermostat/discussions/459

I broke out hvac_action via template to sensor

hvac action is Heating on VTherm when the open_percent is > 0. This is what is send to the opening_degree number entity.
Can you see this ? It is a value between 0 and 100. I don't see it in your screen copy.
This is expected to force the TRV to heat.

What is the "Occupied heating point" ?

The "occupied heating point" is the target temperature.
I will try to test the beta tomorrow

Hello,
Since "local_temperature_calibration","valve_closing_degree", "valve_opening_degree" are normalized would it be possible not to ask them but to determine them automatically thanks to the name of the climate ?
Regards

I broke out hvac_action via template to sensor

hvac action is Heating on VTherm when the open_percent is > 0. This is what is send to the opening_degree number entity.
Can you see this ? It is a value between 0 and 100. I don't see it in your screen copy.
This is expected to force the TRV to heat.

What is the "Occupied heating point" ?

I would assume:

valve open & closing determine actual valve posistion as set by vtherm
offset/calibration applied such that the setpoints are the same for vtherm and trv

btw I did see 'heating' while the valve was closed, but also saw it on the trvzb itself, corrected itself after a small bit.

Hello,
Since "local_temperature_calibration","valve_closing_degree", "valve_opening_degree" are normalized would it be possible not to ask them but to determine them automatically thanks to the name of the climate ?
Regards

maybe later (@hilburn  have some ideas around this). For now we are trying to see if it works.

Will try tonight.
For the offset/calibration we don't need that theorerically to force opening right? Because the 2 valve settings will make sure the valve is always opened/closed in the right position.

Will try tonight.
For the offset/calibration we don't need that theorerically to force opening right? Because the 2 valve settings will make sure the valve is always opened/closed in the right position.

This is not my understanding. But once more, I don't have any Sonoff TRVZB and I rely totally on your feedback.

To me it seems that if opening percent = x, and closing percent is 100-x, the valve will always be opened x percent no matter the local temperature or the setpoint.

Will try tonight.
For the offset/calibration we don't need that theorerically to force opening right? Because the 2 valve settings will make sure the valve is always opened/closed in the right position.

This is not my understanding. But once more, I don't have any Sonoff TRVZB and I rely totally on your feedback.

could it help if i send you one?

This is a max. The max opening percent is ...
So, if you don't change the local temp, it is possible that the TRV don't heat

Yes but they clamp eachother, x=40 means:
max_opening_degrees=40 max_closing_degrees=60
means that there is no other position the valve can go to except 40 percent opened (0 = closed = 60 percent closed, 100 = opened = 40 % opened)
So by setting max_xxx_degrees like this, the internal regulation/sensors/setpoint do not affect the actual valve anymore

Same behavior for me when i did my manuals tests without VTherm.
Whatever the offset value, if opening and closing are inverted, there is only 1 position available. The offset is superfluous.
I will try again this evening.
Potentially this will simply the code and understanding.

Great news !

I would love having your heating regulation curves, if you have this. What is important:

target temp,
current room temp,
open_percent
opening_degree
offset_calibration

All these attributes are available in the VTherm attributes. You can help with the readme to get regulation curves: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#even-better-with-plotly-to-tune-your-thermostat

hello @jmcollin78 ,
I set a TRVZB this morning with one VTherm : I made a graph but i didn't found the calibration attribute in the Vtherm (I put the one of the TRVZB).

I will send you again when I will get more data : Ask me If you need some other data (other attibutes or entities)
hvac_modes: off, auto, heat
min_temp: 12
max_temp: 22
target_temp_step: 0.5
preset_modes: none, frost, eco, comfort, boost
current_temperature: 19.5
temperature: 19.5
hvac_action: idle
preset_mode: comfort
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: false
last_central_mode: null
frost_temp: 12
eco_temp: 18
boost_temp: 21
comfort_temp: 19.5
frost_away_temp: 12
eco_away_temp: 16
boost_away_temp: 19
comfort_away_temp: 18
power_temp: null
target_temperature_step: 0.5
ext_current_temperature: 10.63
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: comfort
saved_target_temp: 19.5
saved_hvac_mode: null
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
overpowering_state: null
presence_sensor_entity_id: null
presence_state: null
window_state: off
window_auto_state: off
window_bypass_state: false
window_sensor_entity_id: null
window_delay_sec: 60
window_auto_enabled: false
window_auto_open_threshold: null
window_auto_close_threshold: null
window_auto_max_duration: null
window_action: window_turn_off
security_delay_min: 120
security_min_on_percent: 0.5
security_default_on_percent: 0
last_temperature_datetime: 2024-11-18T11:38:16.197616+01:00
last_ext_temperature_datetime: 2024-11-18T11:29:43.999382+01:00
security_state: false
minimal_activation_delay_sec: 480
device_power: 1
mean_cycle_power: null
total_energy: 0.42
last_update_datetime: 2024-11-18T11:39:51.241745+01:00
timezone: Europe/Paris
temperature_unit: °C
is_device_active: false
ema_temp: 19.65
is_used_by_central_boiler: true
temperature_slope: -0.29
hvac_off_reason: null
is_over_climate: true
start_hvac_action_date: null
underlying_entities: climate.trv_chambre_parents
auto_fan_mode: auto_fan_high
current_auto_fan_mode: auto_fan_high
auto_activated_fan_mode: null
auto_deactivated_fan_mode: null
auto_regulation_use_device_temp: false
auto_start_stop_enable: false
auto_start_stop_level: auto_start_stop_none
auto_start_stop_dtmin: null
auto_start_stop_accumulated_error: 0
auto_start_stop_accumulated_error_threshold: null
follow_underlying_temp_change: false
is_over_sonoff_trvzb: true
underlying_sonoff_trvzb_entities: number.trv_chambre_parents_valve_opening_degree
on_percent: 0.09
power_percent: 9
on_time_sec: 0
off_time_sec: 1800
cycle_min: 30
function: tpi
tpi_coef_int: 0.6
tpi_coef_ext: 0.01
valve_open_percent: 0
auto_regulation_dpercent: 10
auto_regulation_period_min: 5
last_calculation_timestamp: 2024-11-18T09:46:00.804230+01:00
friendly_name: Thermostat.Chambre.Parents.Radiateur
supported_features: 401

Same behavior for me when i did my manuals tests without VTherm.
Whatever the offset value, if opening and closing are inverted, there is only 1 position available. The offset is superfluous.
I will try again this evening.
Potentially this will simply the code and understanding.

I have just retried it with an other valve and the offset seems unecessary if opening degree = 100- closing degree

Hey !
thanks for the great job !
working globally well. One thing I noticed : when the valve is open to x% for heating, the valve and thermostat are not reporting as « heating » but as « idle », or just as heating for a few secs.

No clue where it might be coming from…
JG

Yeah same here, seems we need to ignore underlying hvac_action and just check valve open % > 0 = heating

Hello @Kumalo

I set a TRVZB this morning with one VTherm

This is really impressive... 🎉  The stability is very good, the current temp is always near the target, no oscillation and it's only heating a few minutes per hour.
I see you have a very long cycle and the standard coefs:
cycle_min: 30
tpi_coef_int: 0.6
tpi_coef_ext: 0.01

Why this so long cycle ? Have you tried with 10 min ?
The only thing we can tune here is the two coefficient here:
auto_regulation_dpercent: 10
auto_regulation_period_min: 5

There are configurable here:

The new value will be send only if open_percent vary from at least 10%. This generate the stairs we can see and prevent the valve_open_percent to be stable. You should try something like 2 or 3. I guess you will have an open_percent much stable. Ideally the open_percent should not vary smoothly. The drawnback is that in non stable condition, the battery of the TRV could be more sollicited.
So I would try this for your case:
cycle_min: 10
tpi_coef_int: 0.6            <--- no change
tpi_coef_ext: 0.01         <--- no change
auto_regulation_dpercent: 2
auto_regulation_period_min: 5      <--- no change. Not usefull when < cycle_min

But this is very promising regulation curves ! Thank you for this.
What about configuration ? Is it easy or painfull ?

i can send you one, that's my way to support your work i just discover !

🙏  so nice ! Please contact me on hacf.fr in MP. My name is: Jean-Marc_Collin

Hello @JGSBP2S ,

the valve and thermostat are not reporting as « heating » but as « idle »,

Ok, thank you for the report. The hvac_action should be heating when the open_percent (in attribute) is > 0. Can you post me the attributes when it is heating, so that I will confirm this is a bug ? How to do that, is described here: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#custom-attributes

I don't think it will be useful since it's too warm in my house at the moment...

Yes there is no need to heat now. Maybe tomorrow. You should add the on_percent value to the curve so that I will control when it is heating or not.

Hi @jmcollin78,
tried something not planned, so not working of course, but since you’re on the sonoff TRV at the moment, might be great if, when turning manually the valve control, it would update target temp OM the VTherm accordingly. No clue if something like this can be included ?
If you would need me to test something, don’t hesitate to let me know.

but since you’re on the sonoff TRV at the moment, might be great if, when turning manually the valve control, it would update target temp OM the VTherm accordingly. No clue if something like this can be included ?

This is already done and should work. If someone can test this and let me know if the target temp change on VTherm and if the preset is removed (manual mode). Thank you.

but since you’re on the sonoff TRV at the moment, might be great if, when turning manually the valve control, it would update target temp OM the VTherm accordingly. No clue if something like this can be included ?

This is already done and should work. If someone can test this and let me know if the target temp change on VTherm and if the preset is removed (manual mode). Thank you.
Warning you should check the 'Follow the underlying temperature change' switch entity in the VTherm device for this to work.

Tried a few mins ago, and doesn’t seem to work on my side.

Tried a few mins ago, and doesn’t seem to work on my side.

Is the attribute 'follow_underlying_temp_change' set the true (Development Tools / State)

Tried a few mins ago, and doesn’t seem to work on my side.

Is the attribute 'follow_underlying_temp_change' set the true (Development Tools / State)

Tested with follow underlying activated, and it’s then indeed working well ! Brilliant, thanks !

Hello @jmcollin78 ,
I will follow your advices and try to reduce cycle time and auto_regulation_dpercent
For the cycle, I have tried to follow th readme for a central boiler (Maybe I was wrong) :

My graph this morning (I turn off my boiler manually between 9:00 PM and 9:30PM for testing) :

🎉  New beta release beta5 🎉
This new beta fixes:

Calculate offset_calibration as room_temp - local_temp and no more as the min value accepted. This should fix the value displayed by the TRV to the room temperature,
Fix hvac_action calculation as reported by @tbrasser.

The pre-release is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta5

I will follow your advices and try to reduce cycle time and auto_regulation_dpercent

This is like the changes have not taken into account. You still have very long cycle and still not have a constant valve_open_percent. Maybe this is the thermometer which don't send the temperature very often. If it is the case, you cannot do better than this. So, this is still very good, and you can keep this values.

Have tried the new release.
it is now reporting as « heating », indeed, but then, once I reduce target temp, it is remaining on « heating ». Furthermore, it has move all the VTherms I’ve set up to « heating » while I tested it on only one.

It seems to work better, but the 'local temperature' (so after offset/calibration is applied) still is not the same as the room temp.
Also I see different calibration (expected because different internal/local temp) and different setpoints (not expected) between my 2 trvzb's (same vtherm):
Vtherm:

room: 18.5
target: 20

trvzb1:

local 23.7 (offset -0.1)
target: 21.5

trvzb2:

local 19.2 (offset -3.6)
target: 23.5

I was expecting:
trvzb's: local 18.5 (offset respectively to reach 18.5) and target 20
the valves themselves (and hvac_action) seem to work perfect

I was expecting:
trvzb's: local 18.5 (offset respectively to reach 18.5) and target 20

Do you have the internal temp of the Sonoff climate ?

Will check,
in addition I see this:

auto stop turned vtherm off
valve is 0%
hvac_action still is heating:

The internal temp is local temp + offset (in other words, the local temp already includes the offset)

The internal temp is local temp + offset (in other words, the local temp already includes the offset)

you mean, internal temp includes the offset. So I cannot use it to calculate the new offset. Right ? I should rather use the local temp to calculate the offset.
offset  = room_temp - local_temp.
I get the local_temp like this: local_temp = self.<sonoff climate>.current_temperature
Is that wrong ?
What value should I use to get a correct offset_calibration ?

I am also confused by cycle, why can't it just stay at 41% power = 41% valve, why cycle at all?

The cycle aims to recalculate periodically the correct open_percent (or I don't understand your point). How can I do without a cycle ?

yes, the local temp always already includes the offset/calibration, so actual measured local temp = what the local temp says and then add the offset.
so in order to calculate new offset you need to take into account the current offset (in other words, the difference between local temperature and room temperature always needs to be added to the existing calibration to get the local temperature to be equal to the room temperature)
in other words again: if you change calibration/offset it is immediately reflected in the local temp.

so in order to calculate new offset you need to take into account the current offset (in other words, the difference between local temperature and room temperature always needs to be added to the existing calibration to get the local temperature to be equal to the room temperature)

Understood. But what a mess. Is that usefull ?

new_offset = room_temp - (local_temp - current_offset)
x = 18.5 - (19 - -1) = -1.5
for example when actual local temp = 20, and current offset/calibration=-1 and vtherm room temp=18.5

On my side, On Percent=Power Percent=Valve Open Percent at a certain time. Is it normal ? Example below right now.
on_percent: 0.11
power_percent: 11
valve_open_percent: 11
And each time valve open percent is changing, the 2 others are changing accordingly.

That makes sense right? Maybe the on and off entities are confusing and can be ignored?

That’s what I thought first, but then, am getting confused because of an article on HACF on how to spare energy… but after careful reading and starting to understand better @jmcollin78, i start to get that one word can be very important in his writing, and I think I overlooked one in the article which might explain :)

On my side, On Percent=Power Percent=Valve Open Percent at a certain time. Is it normal ? Example below right now.
on_percent: 0.11 power_percent: 11 valve_open_percent: 11
And each time valve open percent is changing, the 2 others are changing accordingly.

Yes this is normal, the only point is the wording of on_percent which is not a percent but a value between 0 and 1 which is used to compute the real percentage.

Calculate offset_calibration as room_temp - local_temp and no more as the min value accepted. This should fix the value displayed by the TRV to the room temperature,

The displayed value by the TRV is the target temperature (occupied_heating_setpoint) : are you trying to show the room temperature on the TRV ?
It is maybe a stupid question but what it is the aim of changing the offset calibration right now if the valve is controlled with the opening and closing degree without problems when they are consistent with each other  ?
With  Beta 5 installed tonight, I don't understand the behaviour when i change the temperature on the sonoff TRV
init state:

sonoff TRV : Target temperature (occupied_heating_setpoint)  = 20

VTherm
Target temperature (temperature) = 20
follow_underlying_temp_change = true
auto_regulation_use_device_temp: false

I manually changed the Target temperature on the valve to 18.5
Target temperature (temperature) of the VTherm change to 18.5 -> OK
Target temperature (occupied_heating_setpoint) of the sonoff come back to 20 (occupied_heating_setpoint) -> ???
Logs:
2024-11-19 19:30:41.799 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - _async_climate_changed new_state is <state climate.trv_chambre_parents=heat; hvac_modes=['off', 'auto', 'heat'], min_temp=4.0, max_temp=35.0, target_temp_step=0.5, current_temperature=25.0, temperature=18.5, hvac_action=idle, friendly_name=Trv.Chambre.Parents, supported_features=385 @ 2024-11-19T19:00:08.117994+01:00>
2024-11-19 19:30:41.799 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - Underlying climate climate.trv_chambre_parents have changed. new_hvac_mode is heat (vs heat), new_hvac_action=idle (vs idle), new_target_temp=18.5 (vs 20.0), new_fan_mode=None (vs None)
2024-11-19 19:30:41.800 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - last_change_time=2024-11-19 19:30:31.353411+01:00 old_state_date_changed=2024-11-19 18:00:08.117994+00:00 old_state_date_updated=2024-11-19 18:30:22.464751+00:00 new_state_date_changed=2024-11-19 18:00:08.117994+00:00 new_state_date_updated=2024-11-19 18:30:41.793534+00:00
2024-11-19 19:30:41.800 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_climate] Do temperature check. under.last_sent_temperature is 20.0, new_target_temp is 18.5
2024-11-19 19:30:41.800 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - Target temp in underlying have change to 18.5 (vs 20.0)
2024-11-19 19:30:41.800 INFO (MainThread) [custom_components.versatile_thermostat.base_thermostat] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - Set target temp: 18.5
2024-11-19 19:30:41.800 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - Calling ThermostatClimate._send_regulated_temperature force=True
2024-11-19 19:30:41.800 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - regulation calculation will be done
2024-11-19 19:30:41.801 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - usage regulation_step: 5.00
2024-11-19 19:30:41.801 DEBUG (MainThread) [custom_components.versatile_thermostat.pi_algorithm] PITemperatureRegulator - Error: -1.20 accumulated_error: 0.00 offset: 0.00 offset_ext: 0.00 target_tem: 18.5 regulatedTemp: 18.5
2024-11-19 19:30:41.801 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - Regulated temp have changed to 20.0. Resend it to underlyings
2024-11-19 19:30:41.801 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - The device offset temp for regulation is 0.00 - internal temp is 0.00. New target is 20.00
2024-11-19 19:30:41.803 DEBUG (MainThread) [custom_components.versatile_thermostat.thermostat_sonoff_trvzb] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - recalculate the open percent
2024-11-19 19:30:41.803 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_sonoff_trvzb] VersatileThermostat-Thermostat.Chambre.Parents.Radiateur - do not calculate TPI because regulation_period (2) is not exceeded

Hello,
https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta6
With:

Fix hvac_action (this time it should be good)
Fix offset_calibration=room_temp - (local_temp - current_offset), so that the local temperature is the room temperature

@Kumalo

The displayed value by the TRV is the target temperature (occupied_heating_setpoint) : are you trying to show the room temperature on the TRV ?

No. I think it was possible to display the local temperature but that is not the case. The goal is that the local temperature is the room temperature. This is not useful for this case but will be in the future for TRV that don't have closing_degree.

@Kumalo ,

do not calculate TPI because regulation_period (2) is not exceeded

This is due to the temporal filter. You have configured that VTherm can send a command to the TRV at most every 2 minutes. When you make some test like this, you have to wait at least 2 minutes between two tests. This is to avoid loops (Vtherm change the TRV which change VTherm, which ...) and too much battery consumption if VTherm sends too many commands. This is a core feature (not related to Sonoff TRVZB)

@Kumalo ,

do not calculate TPI because regulation_period (2) is not exceeded

This is due to the temporal filter. You have configured that VTherm can send a command to the TRV at most every 2 minutes. When you make some test like this, you have to wait at least 2 minutes between two tests. This is to avoid loops (Vtherm change the TRV which change VTherm, which ...) and too much battery consumption if VTherm sends too many commands. This is a core feature (not related to Sonoff TRVZB)

I just tried again in waiting and same result. I understand the timer but why a command is sent to the trv to update its target temperature : In the log, we can see " New target is 20.0 ..."
In my test, Target of the trv and the vtherm at the start are 20.
When I change the target manually on the sonoff to 18.5, the target of the vtherm is synchronised to 18.5 but after some seconds the target of the trv become again 20.
The target on the vtherm is keeping 18.5.
The best is waiting if somebody else have a similar problem , it can be my configuration: I will check it again tomorrow.

it can be my configuration: I will check it again tomorrow.

You are certainly right. Do you have self-regulation activated ? If yes please set it to 'None' else it will interfere with the open percent calculation.

I don't think it will be useful since it's too warm in my house at the moment...

Yes there is no need to heat now. Maybe tomorrow. You should add the on_percent value to the curve so that I will control when it is heating or not.

Thanks. I will add the on_percent on the curve. BTW, it would be nice to update the Plotly exemple in the documentation to include the on_percent value.

@Kumalo ,

do not calculate TPI because regulation_period (2) is not exceeded

This is due to the temporal filter. You have configured that VTherm can send a command to the TRV at most every 2 minutes. When you make some test like this, you have to wait at least 2 minutes between two tests. This is to avoid loops (Vtherm change the TRV which change VTherm, which ...) and too much battery consumption if VTherm sends too many commands. This is a core feature (not related to Sonoff TRVZB)

I just tried again in waiting and same result. I understand the timer but why a command is sent to the trv to update its target temperature : In the log, we can see " New target is 20.0 ..."
In my test, Target of the trv and the vtherm at the start are 20.
When I change the target manually on the sonoff to 18.5, the target of the vtherm is synchronised to 18.5 but after some seconds the target of the trv become again 20. The target on the vtherm is keeping 18.5.
The best is waiting if somebody else have a similar problem , it can be my configuration: I will check it again tomorrow.

Regarding synchronization between TRV setpoint and VTherm setpoint :
In my case with beta5, TRV and VTherm was synchronized, but with an offset on the TRV :

VTherm at 20°C at the beginning
Manual change TRV setpoint to 21°C : TRV show 21°C during ~2s, and change to 23°C automatically
VTherm target set to 21°C

With beta6 : synchonization between TRV and Vtherm setpoint no longer works at all
In both cases, follow underlying temperature check, and i recreated from scratch my VTherm after updating to beta6.

it would be nice to update the Plotly exemple in the documentation to include the on_percent value.

Done here: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#even-better-with-plotly-to-tune-your-thermostat

and i recreated from scratch my VTherm after updating to beta6

Sorry, there was a big bug in beta6 which is fixed in beta7.
You should have a hvac_action working fine and the offset_calibration which adapts itself at each refresh so that the local_temperature of the TRV is the room temperature.

it would be nice to update the Plotly exemple in the documentation to include the on_percent value.

Done here: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#even-better-with-plotly-to-tune-your-thermostat

Thanks. I've just migrated to beta 6 (I was on beta 5) : I will provide screenshots this evening.

Thank you so much for your hard work! I've been testing the beta for almost two days now, and I haven’t encountered any issues with heating. On the contrary, it seems to be working even better than before.
Note that I’ve been testing your beta alongside this recent ZHA evolution (I’m not using ZigBee2MQTT): https://github.com/zigpy/zha-device-handlers/pull/3358.
That said, I’ve noticed a persisting bug with heat detection. Even with the beta version released this morning, the thermostats are not reporting as heating, despite the TRVs being open (please refer to the attached screenshots).

Let me know if you need any other information.

I read carefully the comments arount the offset of the TRV (the "local_temperature_calibration" for the TRVZB).
Maybe I don't understand something, but what's the aim of modifying the offset of the TRV ?
Wouldn't this add complexity to a relatively simple system?
As said previously, "local_temperature_calibration" is used by the TRVZB to directly add an offset to the local temp "local_temperature".
The original value is not directly available.
So : "original temp" = "local_temperature" - "local_temperature_calibration".
That's useful, even essential, if we want an approximately correct setpoint when we use the TRVZB out of the box.
Here, we want to use external temp to control the TRV.
And we are sending a % opening value (and his opposite value to force the TRV to the right position) and using an external algorithm to regulated around  the same setpoint (the local setpoint of the TRV, which is also the external setpoint (VTherm)).
So :  "occupied_heating_setpoint"(the setpoint of the TRVZB) = .temperature (or something like this ahah).
After that, maybe we need to think about who is the master of the setpoint.
During my tests :

if I change the setpoint on the TRV in 1 time (from 19 to 21 for exemple), the value change correctly in VTherm to 21
but if I change the setpoint on the TRV in 2 times (from 19 to 21, and quickly after to 20), the value change to 21 in VTherm.

At this point : Which one is the good setpoint ? VTherm or Local ? In my usecase : Local.

From my point of view, I think that it will always be the local setpoint which will be the master.
Because if I change setpoint from the VTherm, VTherm can  record that the setpoint has been modified by VTherm, and in the case who "local TRV set point" =/= "VTherm setpoint", the good setpoint is VTherm, and VTherm can say to the TRV the good setpoint.
The reverse does not seem possible.
So in all others cases when "local TRV set point" =/= "VTherm setpoint" (when "VTherm recently modified setpoint" trigger is not set to 1 for exemple), the good setpoint is the local.
And at the next "local TRV set point" = "VTherm setpoint", the  "VTherm recently modified setpoint" trigger is set to 0.

Hello @quent1-fr
Thank you for your report. It's great.

the thermostats are not reporting as heating, despite the TRVs being open

For the heating symbol to be displayed as heating we need 2 things :

the valve to be open,
the undeerlying Sonoff climate to be heating also.

You can check this in the attributes of the Vtherm (Outils de dev / Etats). Please copy/paste this attributes.

I read carefully the comments around the offset of the TRV (the "local_temperature_calibration" for the TRVZB).
Maybe I don't understand something, but what's the aim of modifying the offset of the TRV ?
Wouldn't this add complexity to a relatively simple system?
As said previously, "local_temperature_calibration" is used by the TRVZB to directly add an offset to the local temp "local_temperature".
The original value is not directly available.
So : "original temp" = "local_temperature" - "local_temperature_calibration".
That's useful, even essential, if we want an approximately correct setpoint when we use the TRVZB out of the box.
Here, we want to use external temp to control the TRV.
And we are sending a % opening value (and his opposite value to force the TRV to the right position) and using an external algorithm to regulated around  the same setpoint (the local setpoint of the TRV, which is also the external setpoint (VTherm)).
So :  "occupied_heating_setpoint"(the setpoint of the TRVZB) = .temperature (or something like this ahah).
After that, maybe we need to think about who is the master of the setpoint.
During my tests :

if I change the setpoint on the TRV in 1 time (from 19 to 21 for exemple), the value change correctly in VTherm to 21
but if I change the setpoint on the TRV in 2 times (from 19 to 21, and quickly after to 20), the value change to 21 in VTherm.

At this point : Which one is the good setpoint ? VTherm or Local ? In my usecase : Local.

From my point of view, I think that it will always be the local setpoint which will be the master.
Because if I change setpoint from the VTherm, VTherm can  record that the setpoint has been modified by VTherm, and in the case who "local TRV set point" =/= "VTherm setpoint", the good setpoint is VTherm, and VTherm can say to the TRV the good setpoint.
The reverse does not seem possible.
So in all others cases when "local TRV set point" =/= "VTherm setpoint" (when "VTherm recently modified setpoint" trigger is not set to 1 for exemple), the good setpoint is the local.
And at the next "local TRV set point" = "VTherm setpoint", the  "VTherm recently modified setpoint" trigger is set to 0.

This way the displayed temp on the trv and the hvac_action will always be correct.

Hello @SuperfrogMe

From my point of view, I think that it will always be the local setpoint which will be the master.
Because if I change setpoint from the VTherm, VTherm can record that the setpoint has been modified by VTherm, and in the case who "local TRV set point" =/= "VTherm setpoint", the good setpoint is VTherm, and VTherm can say to the TRV the good setpoint.

I think I underssood your point because it was also my first naive idea. But this is an issue I had for a long time with the feature "VTherm follow the underlying device setpoint" - which is mostly what you said "the master of the setpoint is the TRV". I will try to explain:

some device are smart enought to change their setpoint internaly (detect open window, have a kind of self-regulation like Vtherm does, goes in sleep mode, ...). If VTherm blindly follow the TRV setpoint, you will loose the user point of view. The user wants "Comfort" but for unknown reasons, the TRV change and then the VTherm goes into manual mode (the user loose the preset) and the setpoint of Vtherm is aligned with the TRV setpoint (which is surely not what the user wants). You just have to see the number of issues like "my VTherm change on its behalf", ... so much issues that I finish to implement the "follow the underlying temperature change" flag. Since this, no more issues.
So this is not so easy and the choice I made is : the VTherm is always the master of the setpoint because it is the user choice and, it the user accepts it (the famous "follow the underlying temperature change" flag, the setpoint of VTherm will reflect the change of the setpoint of the device.

The other thing to have in mind in that when VTherm sends a setpoint to the device, Vtherm will have in return an event that says: "the underlying setpoint have change". But it is not possible to tell if this return is a consequence or not of the initial command. If values are equals, VTherm assume this is a consequence but if not how to deal with ?
That leads to hard case like you explains: the user clicks many times quickly from 19 -> 20, then to 20 -> 21, Vtherm is receving the 20 AFTER the user change to 21. So I have issues like 'My HA is totally down, caused by a loop due to this mecanism'.
So I have to do some compromises: accept device event if it not to near a command from VTherm and other temporal filters like this. Not perfect, and that is the case for all compromises but this is mostly working.
See:
https://github.com/jmcollin78/versatile_thermostat/issues/95
https://github.com/jmcollin78/versatile_thermostat/issues/121
https://github.com/jmcollin78/versatile_thermostat/issues/329
https://github.com/jmcollin78/versatile_thermostat/issues/478
...

I just made a test and it is working fine. The behavior you are described, is when you don't check the "Follow underlying temperature check"

Hello @jmcollin78
Yes , I saw it and it was checked. Anyway, I am installing the beta7 and I will restart from scratch

That leads to hard case like you explains: the user clicks many times quickly from 19 -> 20, then to 20 -> 21, Vtherm is receving the 20 AFTER the user change to 21. So I have issues like 'My HA is totally down, caused by a loop due to this mecanism'

I don't know if it could help but to avoid this problem the most possible in my automation:

I put a delay to let the time for the users to change many times the value (quickly from 19 -> 20, then to 20 -> 21)
The same automation can be launched only once at the same time and is triggered if target value is changing on the TRV or on the VTHERM (I don' know if you can do it in a integration) to avoid loop.

Trigger the automation when target value is changing on the TRV or on the VTHERM.

* if the target value is changing on the TRV
1. Wait 10 seconds  (Time for user to change the value several times : could be more)
2. Read again the target value of the TRV (stored in t_updated)
3. if t_updated == VTherm target value, do nothing and exit
4. Check if t_updated is in the range of the possible target values of the Vtherm
    - if t_updated is greater than the maximum possible target value of the Vtherm
            Set t_updated = maximum possible target value
    - if t_updated is lower than the minimum possible target value of the Vtherm
            Set t_updated = minimum possible target values
5. Set Vtherm target value = t_updated
6. Wait 1 second
7. if t_updated != target value of the TRV (Case when the initial TRV target temperature was out of the vtherm limits)
   - Set target value of the TRV = target value of the TRV
8. Wait 10 seconds (to avoid loop)

* if the target value is changing on the VTHERM
1. Trigger the automation when target value is changing on the Vtherm.
2. Wait 10 seconds (to avoid loop)

End

My main goal is not to manage Vtherm with the TRV but the TRV with the Vtherm but just keeping some consistency in some specific cases:

when a person (a kid :-) ) change the value on the TRV
when a punctual boost is necessary in a room

I let the scheduler put back the VTherm into auto mode at the start of the next period.
I think some case are not working if a change is done on the Vtherm and the TRV in the same time but for the moment I have not got this problem

his way the displayed temp on the trv and the hvac_action will always be correc

Hello @tbrasser
Ok for the hvac_action but the displayed temp is the target temperature and the calibration does not change the value.
I missed something ?

Please find here feedback on 4 VTherm configured at approximately 3pm (with an HA reboot at 3:19pm). Previsously they were configured in over climate with Aqara TRV.
In my son's room

in my daughter's room  (isolation is not as good as in others rooms):

in my room :

on a landing which is about 20m2. There are 2 radiators in the VTherm

@Kumalo,
Very interesting algo to take into account the setpoint of the TRV, and it could certainly inspire the VTherm algo. There is one big difference : in the integration event are received and catched in //. So VTherm can receive a new event from the TRV while waiting and this will not break the wait or both event can me managed in //.
As far as I know, there is no:

automation can be launched only once at the same time

I'm not sure I'm able to do this in a integration, but your proposal is fine (if we forget this // detail).

Hello @jiquem

in over climate with Aqara TRV.

Is Aqara TRV compatible with SONOFF TRVZB ? How do have made the configuration with Aqara TRV ? This is very interesting for me because the next step will be to generalize this solution with others TRV than the SONOFF.

I probably didn’t express myself clearly in my previous message. Actually, I already had VTherm using Aqara in over_climate mode. This afternoon, I simply reconfigured these VTherm to switch them to over_switch mode, and I was pleasantly surprised that it worked.

in my daughter's room

Great curves also but slow to reach the target. You can certainly augment the coef_int. You will not gain so much as you are at 100% during the begining of the heating period but this will start to reduce later and then reach the target earlier. There is a drop to 0 at 15:19 which is strange ? A restart maybe ?

Yes, it's a restart.
I will modify the coef_int and post new graphs in a few days

Hello @quent1-fr ,

current_temperature: 19.4
temperature: 22
hvac_action: idle

Here is the issue why you don't see the VTherm as heating. The Sonoff Climate says it is idle while it should be heating (temperature is >> current_temperature) and the valve is open. I don't understand why the Sonoff don't says 'heating'.
The VTherm has correctly the hvac_action as heating (because valve is open > 0%). But the Sonoff climate says it is not heating. I don't know what to do with that. I can cheat the system and force the heating if the valve is open but this is not the normal behavior.

(it was fine with the latest stable version).

There was no support of Sonoff TRVZB in the previous stable version. Can you tell me more ?

Hello @jiquem

in over climate with Aqara TRV.

Is Aqara TRV compatible with SONOFF TRVZB ? How do have made the configuration with Aqara TRV ? This is very interesting for me because the next step will be to generalize this solution with others TRV than the SONOFF.

I probably didn’t express myself clearly in my previous message. Actually, I already had VTherm using Aqara in over_climate mode. This afternoon, I simply reconfigured these VTherm to switch them to over_switch mode, and I was pleasantly surprised that it worked.

Does your post have a relation with this thread dedicated to Sonoff TRVZB ?

Does your post have a relation with this thread dedicated to Sonoff TRVZB ?

Yes of course. I was using Vtherm configured in over_climate with Aqara until this afternoon. Since this afternoon they are using Sonoff TRVZB

Does your post have a relation with this thread dedicated to Sonoff TRVZB ?

Yes of course. I was using Vtherm configured in over_climate with Aqara until this afternoon. Since this afternoon they are using Sonoff TRVZB

I ask this because you said: "I simply reconfigured these VTherm to switch them to over_switch mode" and Sonoff TRVZB doesn't have any relation with over_switch.
So I suppose you have check the "Mode Sonoff TRVZB" checkbox:

And then my question is (it was my first question), how did you configure the sonoff attributes in this page:

It will be very interesting for the Aqara TRV users if you find a way to configure it.

For me, the custom for the TRVZB is an over_valve, with some additional features :

Major feature :

Send closing degree in the same time of the opening degree

Minor feature :

Send the new target T° manually set on the TRV to the Vtherm like the change would be done on HA (and reciprocally to display the target T° of the Vtherm on the TRV)

Optional feature (but I understand less and less the interest) :

Recalculate the calibration on change of ROOM.temperature as :

new TRV.local_temperature_calibration = ROOM.temperature - TRV.local_temperature +current TRV.local_temperature_calibration

the intelligence should remain on the Vtherm else why not use the native over climate ?

😄  If you read carefully the first post, you will that this is exactly what I does: Sonoff TRV VTherm is over_climate VTherm with over_valve features. Litteraly. (that is why I was so quick to develop it).

@Kumalo I just made a test and it is working fine. The behavior you are described, is when you don't check the "Follow underlying temperature check" :
I guess this your case.

With the beta7, I have no more the problem.
Thank you again @jmcollin78

I ask this because you said: "I simply reconfigured these VTherm to switch them to over_switch mode" and Sonoff TRVZB doesn't have any relation with over_switch.

Oups… sorry, my bad. I was using over_climate with Aqara and still use it with Sonoff.

And then my question is (it was my first question), how did you configure the sonoff attributes in this page:

I use Sonoff TRV so I configured with Sonoff properties.

It will be very interesting for the Aqara TRV users if you find a way to configure it.

I am no more using them and will sell them in a few days.

😄 If you read carefully the first post, you will that this is exactly what I does: Sonoff TRV VTherm is over_climate VTherm with over_valve features. Litteraly. (that is why I was so quick to develop it).

Sorry, my confuse with the previous posts about aqara and to select over_climate when I redo the configuration

There was no support of Sonoff TRVZB in the previous stable version. Can you tell me more ?

Sorry if I wasn't clear earlier. I was using my TRVs with VTherm without any issues before switching to the new experimental SonOff mode. Back then, the heating/idle states seemed to be reported properly by the TRVs into HA.
Do you think it could be useful to add an option like "Consider any valve opening > 0% as active heating"? It might mitigate situations like this.

I had a working setup with the the Sonoff TRVZB with firmware 1.1.X and using a switch as thermostat.
I have upgraded the firmware to 1.2.1 and I'm tying to setup the thermostat using climate + the SONOFF TRVZB mode but nothing really happens anymore in my system.
For example, I don't understand why in this situation the heating is not on

This is my first attempt to setup Versatile Thermostate, so might be missing something trivial

I have upgraded the firmware to 1.2.1

I have created a new issue because it seems not related to this thread. Let's continue the analysis here: https://github.com/jmcollin78/versatile_thermostat/issues/656

Addressing the previous question of whether the offset entity needs to get manipulated: As already pointed out earlier in this thread, the offset is not needed if manipulating the max values for closing and opening.  I think in the original draft of this issue, two different approaches have been mixed.
Either or of the folowing two methods should work:
1: Changing offset to ensure that the TRV is always open (or always closed) along with modifying only the maximum value for opening (or only for closing).

Not changing the offset, but changing maximum opening and maximum closing.

The second approach is what is currently used in the native implementation.
However, as discussed in #459, I think the first approach may be the better one. The advantage is that you can still turn off the heating manually, if HA/VT is down. In the second approach, heating will remain in the last configuration and you can't turn off the devices until HA/VT is up again.
Of course, it's always bad if HA/VT is down. Both approaches don't really allow to change the temperature or similar in that case. Anyway, I think if all heatings in the house are running although they shouldn't and there is no way to stop them, that's the worst case, isn't it?

Here is a screenshot of the temperature in my daugther's room today.
I am surprised by what happened this afternoon : no windows, no door was openned... external temparature was quite stable... really strange.

Hello @jiquem ,
Yes this is strange:

The external temperature drop at the begining of the issue:

the Vtherm that wants 100% but the temperature continue to drop:

the temperature raising at 18h00

Can you check if the valve was open during 12h00-18h00 ? You can maybe add the open_degree value in the graph.
If yes, can you check that your central boiler was active (if you have one).
It seems the valve was open but no hot water was circulating.

Hello @jmcollin78

Can you check if the valve was open during 12h00-18h00 ? You can maybe add the open_degree value in the graph. If yes, can you check that your central boiler was active (if you have one).

The central boiler was switched off...
Regarding the "open_degree", whichi parameters, should I had 👍
hvac_modes:
  - "off"
  - auto
  - heat
min_temp: 7
max_temp: 35
target_temp_step: 0.5
preset_modes:
  - none
  - frost
  - eco
  - comfort
  - boost
current_temperature: 18.6
temperature: 17
hvac_action: "off"
preset_mode: eco
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: false
last_central_mode: null
frost_temp: 7
eco_temp: 17
boost_temp: 21
comfort_temp: 19
frost_away_temp: 0
eco_away_temp: 0
boost_away_temp: 0
comfort_away_temp: 0
power_temp: null
target_temperature_step: 0.5
ext_current_temperature: 3.69
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: eco
saved_target_temp: 17
saved_hvac_mode: null
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
overpowering_state: null
presence_sensor_entity_id: null
presence_state: null
window_state: "off"
window_auto_state: "off"
window_bypass_state: false
window_sensor_entity_id: binary_sensor.aqara_open_naomi_contact
window_delay_sec: 30
window_auto_enabled: false
window_auto_open_threshold: null
window_auto_close_threshold: null
window_auto_max_duration: null
window_action: window_turn_off
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0.1
last_temperature_datetime: "2024-11-22T09:20:26.408592+01:00"
last_ext_temperature_datetime: "2024-11-22T09:14:07.605988+01:00"
security_state: false
minimal_activation_delay_sec: 10
device_power: 1
mean_cycle_power: null
total_energy: 0.39
last_update_datetime: "2024-11-22T09:29:10.770968+01:00"
timezone: Europe/Paris
temperature_unit: °C
is_device_active: false
ema_temp: 18.56
is_used_by_central_boiler: false
temperature_slope: 0
hvac_off_reason: manual
max_on_percent: null
is_over_climate: true
start_hvac_action_date: null
underlying_entities:
  - climate.trv_sonoff_naomi
auto_fan_mode: auto_fan_none
current_auto_fan_mode: auto_fan_none
auto_activated_fan_mode: null
auto_deactivated_fan_mode: null
auto_regulation_use_device_temp: false
auto_start_stop_enable: false
auto_start_stop_level: auto_start_stop_none
auto_start_stop_dtmin: null
auto_start_stop_accumulated_error: 0
auto_start_stop_accumulated_error_threshold: null
follow_underlying_temp_change: false
is_over_sonoff_trvzb: true
underlying_sonoff_trvzb_entities:
 REMOVED
on_percent: 0
power_percent: 0
on_time_sec: 0
off_time_sec: 300
cycle_min: 5
function: tpi
tpi_coef_int: 0.6
tpi_coef_ext: 0.01
valve_open_percent: 0
auto_regulation_dpercent: 0.5
auto_regulation_period_min: 5
last_calculation_timestamp: "2024-11-22T09:24:10.773160+01:00"
friendly_name: VTherm Naomi
supported_features: 401

The central boiler was switched off...

Do you use the central boiler of VTherm ? If yes, because there is a bug in the hvac_action, it may not starts the central boiler.

Regarding the "open_degree", whichi parameters, should I add ?

I have updated the example with the open_percent (named power_percent) here: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#even-better-with-plotly-to-tune-your-thermostat
You can inspire to add the valve_open_percent and change the yaxis from 0 to 100 instead of 0 to 1.

Hello all,
Thank you for your tests.
It seems that the POC is a success. I will generalize this for others TRV. For that I intend to:

replace the checkbox "Sonoff TRV mode" by a new self_regulation lide named "valve regulation". This is mode is not compatible with the others self-regulation which consists in sending a regulated temperature to the underlying,
rename Sonoff with sometthing like "climate with valve regulation",
put the closing_degree and offset_calibration in optional so that TRV with only a opening valve and a calibration will be able to use it (ping @maia @overEngineer @hilburn , this could be interesting for you !) - #595,
put a documentation (maybe I will start to reorganize the documentation),
fix the 2 remaining bugs: hvac_action not always 'on' even if valve is opened, list of valve underlying seems wrong in attributes list (#656),
add unit tests

Once more, thank you so much for all your tests !

Regarding the "open_degree", whichi parameters, should I add ?

I have updated the example with the open_percent (named power_percent) here: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#even-better-with-plotly-to-tune-your-thermostat
You can inspire to add the valve_open_percent and change the yaxis from 0 to 100 instead of 0 to 1.

Hello,
Thanks for the update of the documentation.
in fact on_percent * 100  =  valve_open_percent. I've just tested : the graph are superimposed

Hello @jiquem,

in fact on_percent * 100 = valve_open_percent

If min and max of the valve is 0 - 100 yes. Else the valve_open_percent can be clamped to the min / max. That is the difference

Hello,
I have 4 classical VTherm using Sonoff TRVZB & a Central Configuration.
The 4 VTherm are configured to control the central boiler : I have is_used_by_central_boiler : true in all of them.
Moreover all of them indicate hvac_action: heating
However, sensor.nb_device_active_for_boiler is at 0 and binary_sensor.central_boiler is off. (number.boiler_activation_threshold is configured at 1)
It may not be related to the TRVZB, but since I use the beta version, I post this here.

Hello all,
The final (🎉  ?) beta release is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta8
Please give it a try and follow the instruction after installation.

My first 10 minutes of testing is not promising 😞

Valves not moving
Thermostats are not requesting for heat
boiler is off

Valve movement are clamped by 2 parameters:

Depending of your configuration this parameters can block an update.
Check that the "follow underlying temp change" is checked, check those parameters, and if you are doing many tests, you just have to wait a few between them.

The 6.8.0b8 is working with TRVZB but I am still facing the issue with my boiler.

Does someone have the boiler control which is working fine with the beta ?

Boiler does not seems to be working unfortunately.

Thank you @gbasile !
(And thank you for the beer ! 🍻 Cheers !)

@gbasile , @jiquem ,
Central boiler is working fine at home:

I have a VTherm with 2 fake Sonoff TRVZB attached. When I turn on the VTherm the number of active heater is 2 and the boiler starts.
This is really strange.
Do you have something in the logs ? (an error or a warning ?)
You should find this log:
_LOGGER.info(
                "%s - the underlyings that could controls the central boiler are %s",
                self,
                underlying_entities_id,
            )

with the list of underlying which controls the boiler.
Exmple at home:
2024-11-24 21:56:46.855 INFO (MainThread) [custom_components.versatile_thermostat.sensor] VersatileThermostat-Nb device active for boiler - the underlyings that could controls the central boiler are ['climate.underlying_sonoff_trvzb1', 'climate.underlying_sonoff_trvzb2']
If you don't have this log, it means the configuration is not good: check the central configuration (enable feature:
),
Check parameter of the central boiler:

and check each VTherm have the checkbox checked (in the main attributes page) :

All the configurations are as the one you describe in your comment.
The boiler commands are fine because they are working when I use the climate thermostats (I use the same central configuration for climate + valve)
There are no logs that are relevant, just one when I activate the thermostat that shouldn't matter.
Living Room debugging - Proportional algorithm: calculation is not possible cause target_temp (22.0) or current_temp (None) is null. Heating/cooling will be disabled. This could be normal at startup
Office debugging - Proportional algorithm: calculation is not possible cause target_temp (22.0) or current_temp (None) is null. Heating/cooling will be disabled. This could be normal at startup

Let me know if you want to do a pairing session so that you can check the problem on an environment with real hardware

So I understand you don't have this log: "Nb device active for boiler - the underlyings that could...". It should be just after the startup.

Let me know if you want to do a pairing session so that you can check the problem on an environment with real hardware

This is great idea but before there is another test you can do if possible:

put the listening sensor in debug mode by adding this line on your recorder.yaml:

logger:
    default: warning
    logs:
        custom_components.versatile_thermostat: info
        custom_components.versatile_thermostat.sensor: debug
        custom_components.versatile_thermostat.vtherm_api: debug

restart to take the change into account,
waits Versatile Thermostat have restarted and send me the logs.

If this fails we could try to make a live debug session as you propose.

VTherm.log.zip
Hello,
Please find attached some logs.
When I get the logs, I had 4 VTherm heating, and the boiler was switched off.

I managed to have the system running correctly thanks to the logs.
I have discovered that my VTherm was not able to set the offset calibration temperture correctly. I then realise that I was using an attribute from the thermometer and not from the thermostat.
I made this mistake because the sonoff thermostat has an attribute named: {trv_name}_temperature
while the thermometer has an attribute named {thermometer_name}_temperature_calibration. The latter seems to be the correct settings for the valve configuration.
I initially fixed the configuration by removing the offset calibration from the settings. The system has been running now for 30 minutes correctly 🎉
I'm now testing using the {trv_name}_temperature for the offset calibration

Hi @jmcollin78
Thank you for the amazing work on the Versatile Thermostat!  I have recently purchased some Sonoff TRVZB devices and was looking for way to manually adjust the valve opening percentage and had been doing my own testing on the device, when I found this feature request thread.  I have since tested version 6.8.0.beta7 and 6.8.0.beta8  and wanted to share my findings, particularly regarding boiler integration.
My hypothesis is that the Closing Degree value is causing the hvac_action to be stuck at "idle", therefore the call to turn on the boiler is not working.
In real-world tests using a VTherm with a Sonoff TRVZB, configured in accordance with the Beta release notes, I found that the climate.[TRV]::hvac_action value was not updating correctly.  After the first cycle of "Heat" to "Idle", the TRV refused to go back to "Heat", no matter what desired temperature settings I used.
I have tested this further with a new Sonoff TRVZB, by manually adjusting the valve_opening_degree and valve_closing_degree values.  It appears the Sonoff TRVDB works in such a way that:
IF valve_opening_degree + valve_closing_degree = 100, THEN hvac_action = idle

To reproduce this, using the controls for the TRVZB itself (not the VTherm) you must first set the valve_opening_degree to 0%, then the valve_closing_degree (e.g. 80%) then increase the valve_opening_degree (e.g. 20%).
I propose a change to the code to NOT adjust the valve_closing_degree value.  I think the control of the device will then operate as required, while also ensuring that the hvac_action value is correctly changed to "heat" and the boiler is correctly turned on (and off).
I can provide further test results if required.
Hope this helps!

I managed to have the system running correctly thanks to the logs.
I have discovered that my VTherm was not able to set the offset calibration temperture correctly. I then realise that I was using an attribute from the thermometer and not from the thermostat. I made this mistake because the sonoff thermostat has an attribute named: {trv_name}_temperature while the thermometer has an attribute named {thermometer_name}_temperature_calibration. The latter seems to be the correct settings for the valve configuration.
I initially fixed the configuration by removing the offset calibration from the settings. The system has been running now for 30 minutes correctly 🎉
I'm now testing using the {trv_name}_temperature for the offset calibration

This is interesting, because according to https://www.zigbee2mqtt.io/devices/TRVZB.html the Sonoff TRVZB uses local_temperature_calibration:

local_temperature_calibration: Offset to add/subtract to the local temperature. To control publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"local_temperature_calibration": VALUE}.To read send a message to zigbee2mqtt/FRIENDLY_NAME/get with payload {"local_temperature": ""}.The minimal value is -12.8 and the maximum value is 12.7 with a step size of 0.2.

How are you connecting to it, with Zigbee2MQTT?

How are you connecting to it, with Zigbee2MQTT?
Yes, correct.

I just realised that the naming of the attribute on home assistant is a bit unfortunate:
Zigbee2MQTT calls this attribute: Local Temperature Calibration
Home assistant calls this attribute Temperature

Zigbee2MQTT calls this attribute: Local Temperature Calibration
Home assistant calls this attribute Temperature

Please also report this as separate issue for the z2m integration. I assume it will be fixed quickly.

Does it mean you was able to configure a sensor as a offset calibration (which is a number entity) ? This should not possible.

In the valve configuration, I can use any number entity to configure the offset calibration. See the attached image

Zigbee2MQTT calls this attribute: Local Temperature Calibration
Home assistant calls this attribute Temperature

Please also report this as separate issue for the z2m integration. I assume it will be fixed quickly.

I just realised that the full attribute is indeed correct. It's the friendly name that is just called Temperature
Do you think it's worth to bring to the attention of the team?

Hello @gibsonshine ,

In real-world tests using a VTherm with a Sonoff TRVZB, configured in accordance with the Beta release notes, I found that the climate.[TRV]::hvac_action value was not updating correctly. After the first cycle of "Heat" to "Idle", the TRV refused to go back to "Heat", no matter what desired temperature settings I used.

Yes there is a "bug" in Sonoff TRV or associated climate which prevent it to set correctly the hvac_action. But I have made a workaround in Vtherm so that is now usable. The workaround is to force the hvac_action of the VTherm to "heating" if the open_degree of the valve is > 0. And that's it. In bet8, yo should have this already working.

I propose a change to the code to NOT adjust the valve_closing_degree value

Oooh fine. You just have to remove the closing_degree entity. It is now optional in beta8. So there is nothing to change in the code. I would love a try... But it should not be an issue now with the workaround.

I just realised that the full attribute is indeed correct. It's the friendly name that is just called Temperature Do you think it's worth to bring to the attention of the team?

As the main goal of HA for the next months is to increase usability and understandability for novice users, I do think that anything that causes confusion should be reported, yes.

Yes there is a "bug" in Sonoff TRV or associated climate which prevent it to set correctly the hvac_action. But I have made a workaround in Vtherm so that is now usable. The workaround is to force the hvac_action of the VTherm to "heating" if the open_degree of the valve is > 0. And that's it. In bet8, yo should have this already working.

Thanks, however during testing this did not work for me.  The hvac_action of the Vtherm did not override that of the hvac_action on the TRV, and the nb_device_active_for_boiler = 0.

Oooh fine. You just have to remove the closing_degree entity. It is now optional in beta8. So there is nothing to change in the code. I would love a try... But it should not be an issue now with the workaround.

Yes, thanks, I can confirm this is now working.

Hi @jmcollin78
I tried the last beta8.
When i want to create from scratch a TRV, no climate entity is created.
As you can see : TRV 1 is my try from scratch.
TR2 and TRV3 were only updated from beta6 with "Direct valve control" param.
**

**

Hello @jiquem ,

Please find attached some logs : VTherm.log.zip

Here is some feedback on your log:
the configuration is correct:
VersatileThermostat-Nb device active for boiler - the underlyings that could controls the central boiler are ['climate.trv_sonoff_adam', 'climate.trv_sonoff_naomi', 'climate.trv_sonoff_couloir', 'climate.trv_sonoff_bureau', 'climate.trv_sonoff_beajeanmi']

Later, there are all in 0 so the calculation is done but given 0 active VTherm :
2024-11-25 13:05:23.948 INFO (MainThread) [custom_components.versatile_thermostat.underlyings] VersatileThermostat-VTherm Adam-number.trv_sonoff_adam_valve_opening_degree - Setting valve ouverture percent to 0
2024-11-25 13:05:23.949 INFO (MainThread) [custom_components.versatile_thermostat.underlyings] VersatileThermostat-VTherm Naomi-number.trv_sonoff_naomi_valve_opening_degree - Setting valve ouverture percent to 0
2024-11-25 13:05:23.950 INFO (MainThread) [custom_components.versatile_thermostat.underlyings] VersatileThermostat-VTherm Couloir-number.trv_sonoff_couloir_valve_opening_degree - Setting valve ouverture percent to 0
2024-11-25 13:05:23.950 INFO (MainThread) [custom_components.versatile_thermostat.underlyings] VersatileThermostat-VTherm Couloir-number.trv_sonoff_bureau_valve_opening_degree - Setting valve ouverture percent to 0
2024-11-25 13:05:23.951 INFO (MainThread) [custom_components.versatile_thermostat.underlyings] VersatileThermostat-VTherm BeaJeanmi-number.trv_sonoff_beajeanmi_valve_opening_degree - Setting valve ouverture percent to 0

2024-11-25 13:05:24.859 DEBUG (MainThread) [custom_components.versatile_thermostat.sensor] VersatileThermostat-Nb device active for boiler - calculating the number of active VTherm
2024-11-25 13:05:24.859 DEBUG (MainThread) [custom_components.versatile_thermostat.sensor] Examining the hvac_action of VTherm Adam
2024-11-25 13:05:24.859 DEBUG (MainThread) [custom_components.versatile_thermostat.sensor] Examining the hvac_action of VTherm Naomi
2024-11-25 13:05:24.859 DEBUG (MainThread) [custom_components.versatile_thermostat.sensor] Examining the hvac_action of VTherm Couloir
2024-11-25 13:05:24.859 DEBUG (MainThread) [custom_components.versatile_thermostat.sensor] Examining the hvac_action of VTherm BeaJeanmi

After you have to wait 5 minutes before the next regulation can be sent. This lead to many logs like:
 do not calculate TPI because regulation_period (4) is not exceeded

Then it is begining to be interesting. The Adam vanne opens:
13:10:47.876
Adam-number.trv_sonoff_adam_valve_opening_degree - Setting valve ouverture percent to 100

underlying just switch ON. Set power and energy start date 2024-11-25T13:10:51.437109+01:00

VersatileThermostat-Nb device active for boiler - calculating the number of active VTherm

---- start of central boiler:
13:10:51.439
VersatileThermostat-Central boiler - central boiler have been turned on
VersatileThermostat-Central boiler - Sending event EventType.CENTRAL_BOILER_EVENT with data: {'central_boiler': True}

Unti here it works
Then:
13:10:58.823. --- le Sonoff passa à Idle
VersatileThermostat-VTherm Adam - Underlying climate climate.trv_sonoff_adam have changed. new_hvac_mode is heat (vs heat), new_hvac_action=idle (vs heating)

VersatileThermostat-VTherm Adam - underlying just switch OFF at 2024-11-25T13:10:58.823807+01:00

VersatileThermostat-Nb device active for boiler - calculating the number of active VTherm
VersatileThermostat-Central boiler - central boiler have been turned off

VersatileThermostat-Central boiler - Sending event EventType.CENTRAL_BOILER_EVENT with data: {'central_boiler': False}

Here we are. The change from havc_action to idle coming from the Sonoff TRV turns off the central boiler.
You can try like your colleagues to remove the closing_degree entity and it should work. The explaination is here: https://github.com/jmcollin78/versatile_thermostat/issues/645#issuecomment-2498243410
I will try to bypass this 😠 Sonoff hvac_action.

So I got it. To be counted as active a device should be in a VTherm which hvac_action is "heating" AND the device should be active. The first point have been fixed but the second is cleared when device says idle.
I will do another workaround.

Hello @jmcollin78
Thanks for the analysis and the recommendation : it's working.

Hello @SuperfrogMe ,

When i want to create from scratch a VTherm, no climate entity is created.

When this happens, you should have a log explaining the issue.

Hello @SuperfrogMe ,

When i want to create from scratch a VTherm, no climate entity is created.

When this happens, you should have a log explaining the issue.

Of course, my bad.
During recording logs, I tried to add "calibration offset", and that was the issue.
With valve opening entity and valve closing entity, without "calibration offset" entity, the VTherm climate is not created.
When you add the calibration offset entity, the climate is created.
In the log if necessary : first creation : with calibration. Second creation : without calibration (then added just after the creation to confirm the "issue"). All params are exactly the same in both creations from scratch.
home-assistant_versatile_thermostat_2024-11-25T19-17-52.574Z.log

This pre-release fix #661 - the central boiler is not working with Sonoff TRVZB
https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta9
(don't forget to configure the closing_degree to test the fix).

Thanks @jmcollin78.
I've installed it and it seems to work. I will confirm tomorrow.

I am using 6.8.0b9 with 4 Vtherms, therefore the above mixture is quite strange.

Here it looks good on b9:

With valve opening entity and valve closing entity, without "calibration offset" entity, the VTherm climate is not created.
When you add the calibration offset entity, the climate is created.

this seems not normal as the calibration offset is now optional. You can just leave the field empty and it should work.

I am using 6.8.0b9 with 4 Vtherms, therefore the above mixture is quite strange.

ok I found the issue.

Should be fixed in https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta10
Sorry for all of these pre-release. It is really not comfortable to not being able to test in local. You help a lot guys !
Thank you.
I hope this one will be the good one.

Should be fixed in https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta10
Sorry for all of these pre-release. It is really not comfortable to not being able to test in local. You help a lot guys ! Thank you.
I hope this one will be the good one.

Thanks @jmcollin78.
I've just installed it before going to work. It seems to have fixed the  value calculated for "Nb device active for boiler".
However, even if the Nb device active for boiler is equal to 0, the boiler is not switched off.
Please find here some logs :
VTherm-2024-11-26-1.log.zip

However, even if the Nb device active for boiler is equal to 0, the boiler is not switched off.

You don't have the beta10 installed. I added new logs and you have the old one.
At home I have to choose explicitly the 6.8.0.beta10. It was not selected by default.

I was not awake… I didn’t restart. Will give it a try this evening

Hello @eflye ,

How do we switch to the "Sonoff mode" in order to configure valve opening / closing / calibration in the last beta ? I feel dumb but i'm not able to get the option menu anymore.

Yes ! Things have changed fast and you should carefully read the release notes, specially in beta release. I let you read that and come back if things are not crystal clear.
I help you a few: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta8

I don't see anymore auto_regulation_valve available in the menu selector in beta10.
https://github.com/jmcollin78/versatile_thermostat/blob/6.8.0.beta10/custom_components/versatile_thermostat/translations/fr.json
wheras it's here on beta9
https://github.com/jmcollin78/versatile_thermostat/blob/0a658b7a2a3c6ed329e082b81e363d143dc8cc9d/custom_components/versatile_thermostat/translations/fr.json#L512

I don't see anymore auto_regulation_valve available in the menu selector in beta10.
https://github.com/jmcollin78/versatile_thermostat/blob/0a658b7a2a3c6ed329e082b81e363d143dc8cc9d/custom_components/versatile_thermostat/translations/fr.json#L512
wheras it's here on beta9
https://github.com/jmcollin78/versatile_thermostat/blob/f29097fbc2fc9758ee4b570d7c4e13ba062c2d39/custom_components/versatile_thermostat/translations/fr.json#L504

@eflye forgive me for interjecting but I believe the issue here may be that the version packaged as beta10 is an older version:

For testing beta10 I needed to copy directly from the Development branch.

I don't see anymore auto_regulation_valve available in the menu selector in beta10.
https://github.com/jmcollin78/versatile_thermostat/blob/0a658b7a2a3c6ed329e082b81e363d143dc8cc9d/custom_components/versatile_thermostat/translations/fr.json#L512
wheras it's here on beta9
https://github.com/jmcollin78/versatile_thermostat/blob/f29097fbc2fc9758ee4b570d7c4e13ba062c2d39/custom_components/versatile_thermostat/translations/fr.json#L504

@eflye forgive me for interjecting but I believe the issue here may be that the version packaged as beta10 is an older version:

For testing beta10 I needed to copy directly from the Development branch.

@jmcollin78  is coding a treasure hunt, that's for sure! :D
thanks for the quick tip ! i'll check beta9

Hello @jmcollin78
At 9:20 PM, I restarted Home Assistant. Right after that, I set the temperature of my 4 VTherms to 30°C. The duration of my cycles is 5 minutes. And yet, nothing happens. It doesn’t heat up, and the boiler doesn’t start. Here are the logs :
VTherm-2024-11-26-2.log.zip
Thanks a lot

Hi @jmcollin78,
Thank you again for your great work on these updated beta releases!
I have been testing 6.8.0.beta10 in various scenarios, and I’m pleased to see that the workaround using _percent_open is now effectively switching on the boiler. However, I’ve also encountered some cases where the behavior is not entirely as anticipated. For example, the Nb device active for boiler value does not always return to zero as expected.
Additionally, when _percent_open + closing_degree = 100, the Sonoff TRVZB still forces itself into an Idle state. While this is not a critical issue—since the valves should be open by the correct percentage and heating water should flow as intended—I personally prefer the TRVZB to accurately reflect its Heating status to maintain consistency.
While testing release 6.8.0.beta8, I worked on a proposed fix locally that revises the _percent_open and closing_degree logic to resolve the issue where the TRVZB's hvac_action reverts to Idle. My fix is based on 6.8.0.beta8, so it uses the prior logic for boiler control (before the new behavior introduced in beta9 and beta10).
After further testing this proposed fix today, I can confirm that:

The Sonoff TRV correctly reports hvac_action = heating when expected.
The Nb device active for boiler behaves as anticipated, returning to zero when appropriate.

Would it be okay for me to submit a Pull Request for you to review and consider?
Thank you for your time, and I look forward to hearing your thoughts!
Best regards

@gibsonshine , @eflye ,
the beta10 is the good one but HACS don't propose it by default. You have to select explicitly the right release:

Please go to hacs, select the Versatile and check the version installed. If you want you can re-download it and force the release.

Would it be okay for me to submit a Pull Request for you to review and consider?

Yes of course. I will what you propose. I do not change so many things in beta9 and 10.

are you sure @jmcollin78 ?
look at file from tag 6.8.0.beta10 blob directory
https://github.com/jmcollin78/versatile_thermostat/blob/6.8.0.beta10/custom_components/versatile_thermostat/translations/fr.json

In fact, when I installed the 6.8.0 it installed back a 6.7.0 version

It seems something goes wrong, you are right in the beta10. I try to understand and I will publish a new one.

It seems something goes wrong, you are right in the beta10. I try to understand and I will publish a new one.
It have release the main branch and not the beta branch. So, my bad.... (too fast).
The correct one is this one: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta11
I install it and verify the new code is there. So sorry for that...

Thank you for your responsiveness @jmcollin78 ! I was starting to feel being dumb and too old to work with my home automation 🧓

However I noticed that the number of VTherm heating is not aligned with the number of device active for the boiler. (ie : 2 Vtherm heating while only 1 device appears active for the boiler)

6,4 Mo of logs 😪  I'm just a human.
When do you think there is an issue ?

small bug i discover in the beta11:
if you select in time auto_regulation_valve in the form and would like to select back something else, you will have an inconsistent error about valve_nb_regulation_entities.
https://github.com/user-attachments/assets/ad461187-6db2-4b1a-b636-77ed82788236
I don't know if you can correct it but to let you know :)
Etienne

However I noticed that the number of VTherm heating is not aligned with the number of device active for the boiler. (ie : 2 Vtherm heating while only 1 device appears active for the boiler)

6,4 Mo of logs 😪 I'm just a human.
When do you think there is an issue ?

Oups sorry about that. In the last 15 minutes of the logs. (Before I was not running on 6.8.0beta11)

Home deployed fully with VTherm beta11 :)
boiler with Vtherm thanks to https://github.com/TheGui01/Frisquet-connect-for-home-assistant
14 TRV with Sonoff.
Cycle duration: 30 min
Wait and see :)

Home deployed fully with VTherm beta11 :)
boiler with Vtherm thanks to https://github.com/TheGui01/Frisquet-connect-for-home-assistant 14 TRV with Sonoff. Cycle duration: 30 min
Wait and see :)

Very interesing ! I would love a REX when you will have time.
Do you wish to change the temperature on the central boiler itself ?

Home deployed fully with VTherm beta11 :)
boiler with Vtherm thanks to https://github.com/TheGui01/Frisquet-connect-for-home-assistant 14 TRV with Sonoff. Cycle duration: 30 min
Wait and see :)

Very interesing ! I would love a REX when you will have time.

Do you wish to change the temperature on the central boiler itself ?

already configured :)

I'm just concerned by one case:

If i have 3 TRV asking heat so VTh  is asking to my boiler to reach a upper temperature like 20°C versus the probe one in order to force the start which result by having my water circuit reaching 75 °C very quickly.

On the other side i can see that theses 3 TRV are with following log "Setting valve ouverture percent to 1" because current temp is 19.1 and requested temps is 19.0 So it means that i just have a little bit of water volume going through radiator .
I was wondering if it could result to a too high water pressure in the circuit.

any opinion?

"Setting valve ouverture percent to 1" because current temp is 19.1 and requested temps is 19.0 So it means that i just have a little bit of water volume going through radiator

I suppose this is possible also without Vtherm ? How it was manage before ?

To be honest I don't know, I was asking more for feedback from other user being with trv+valve and central boiler.

https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0.beta12
With the two last bug reported. I finish the documentation rework and I will release next week.

Hello,

Please find here some logs on 6.0.10 beta 11 regarding the central boiler issue.
At 05:30:00 the central boiler is switched on. At this time 3 VTherm require it.
At 05:32:10 Home assistant history show that it is switched off, (but I don’t know by which trigger)
At 05:32:10 the number of Vtherm requiring the central boiler drop from 3 to 2. Nothing appears in logs indicating that the central boiler will go switched off.
VTherm 2024-11-28.log.zip

At 05:32:10 the number of Vtherm requiring the central boiler drop from 3 to 2. Nothing appears in logs indicating that the central boiler will go switched off.

And how is configured the threshold to turn off the boiler ?

Regarding the "boiler count" point, I have 5 Vtherm.
However the number of device active for the boiler was set at 6 during a few moment this afternoon between 19:39 and 20:05.

Please find here some logs exactly at 19:39 and 20:05
VTherm-20:05.log
VTherm-19:39.log
Please, let me know if you prefer to open another topic.

on my side, an unexpected consequence of valve control: radiator are really more noisy than without valve control.  Noise is noticeable and i'm not sure it will not be too much :/

Regarding the "boiler count" point, I have 5 Vtherm. However the number of device active for the boiler was set at 6 during a few moment this afternoon between 19:39 and 20:05.
Please find here some logs exactly at 19:39 and 20:05 VTherm-20:05.log VTherm-19:39.log
Please, let me know if you prefer to open another topic.

Reading the code, helps me to understand. I have a VTherm with 2 climate in it : it count for 2. In fact here, "device", means "physical device", "not VTherm" as I thought.

Hello, the count is the number of device actives and not the number of VTherm active. If one VTherm have 3 devices, it counts for 3.

Maybe we can take the device power into consideration?
so total demand/nb_devices = sum of per device  power_percentage * device_power

Dear TRVZB users, as I just purchased two devices to test the new features: Is there a way to get the device to recalibrate to the valve without factory resetting it? I just unscrewed and rescrewed it and would like to recalibrate to ensure ideal performance. Thanks!

Normally calibration is done when you physically plug the trv on your radiator and you click on it. Why would you like to recalibrate ?

As mentioned, I unscrewed it after installing it and setting it up in zigbee2mqtt. The firmware update took so long I didn't have time to ensure it works properly before going to sleep, so I reinstalled the old TRV over night. There must be a way to trigger recalibration, isn't there?

Normally calibration is done when you physically plug the trv on your radiator and you click on it. Why would you like to recalibrate ?

As mentioned, I unscrewed it after installing it and setting it up in zigbee2mqtt. The firmware update took so long I didn't have time to ensure it works properly before going to sleep, so I reinstalled the old TRV over night.  Okay, so you now suggest:

remove battery
unscrew
put battery back

…but what's next? You wrote "it will ask to recalibrate itself", how&where do I see that it is asking and how do I say "yes"? Do I need to install the Sonoff app to do so? Thanks for your assistance, the manual unfortunately doesn't say anything about recalibrating.

Sorry I was probably not very clear.

If your trv is currently not anymore on the radiator it should display F5 meaning "no valve detected".
In any case you can follow the method explain on the picture attached. It doesn't reset the trv, you just follow the steps for a standard battery replacement.

Am I correct in understanding that the valve percentage is controlled by setting the opening and closing percentages? I’d like to keep all valves open at ~10% at all times to ensure sufficient water flow (otherwise, my boiler shuts off quickly due to rapid hot water return when too few radiators are open). Would this require re-implementing in vtherm, since it seems vtherm would overwrite the underlying setting (number.device_name_valve_opening_degree)?

so total demand/nb_devices = sum of per device power_percentage * device_power

And what should I do with this calculation ?

nothing, central boiler functionality is good for on/off boilers. For opentherm I found the SAT custom integration. It works ok together with versatile thermostat, allthough better integration might be possible (from SAT side)

Am I correct in understanding that the valve percentage is controlled by setting the opening and closing percentages? I’d like to keep all valves open at ~10% at all times to ensure sufficient water flow (otherwise, my boiler shuts off quickly due to rapid hot water return when too few radiators are open). Would this require re-implementing in vtherm, since it seems vtherm would overwrite the underlying setting (number.device_name_valve_opening_degree)?

Just set max closing degrees to 90% on device and only enter max opening degree in vtherm 👍

Am I correct in understanding that the valve percentage is controlled by setting the opening and closing percentages? I’d like to keep all valves open at ~10% at all times to ensure sufficient water flow (otherwise, my boiler shuts off quickly due to rapid hot water return when too few radiators are open). Would this require re-implementing in vtherm, since it seems vtherm would overwrite the underlying setting (number.device_name_valve_opening_degree)?

Just set max closing degrees to 90% on device and only enter max opening degree in vtherm 👍

Oh that's a smart workaround, thanks. Ideally vtherm will add a configuration setting for the minimum valve percentage.

Valve opening 0 means 10% now because it's relative

https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.8.0
Just released !

Thank you @jmcollin78 for your great work 🥇 and your patience !

Hi @tbrasser @maia I too want to keep valves 10-15% open, both for boiler pressure (i don't think this is a concern for my installation) and also because my radiators make a pinching noise when closing them while central boiler is still flowing water, I don't really know how to solve this
I tested keeping closing_degree to 90 or less on sonoff valve device and VTherm only with opening and temp calibration, but it seems that turning off hvac mode will in fact fully close the valve not taking into account closing/opening degrees
Do you have any suggestions?

@M3te0r, maybe a feature request to add min/max limits to opening/closing?
I have another potential issue to report, and I hope it turns out it's not that major: the TRVs seem to skip steps from time to time. This means that with use, a TRV gradually stops closing the valve to completeness. Currently the only working way of calibration is to pull out a battery, wait a few seconds, then put it back in. If this indeed turns out to be the case, we're going to have to make some noise so that Sonoff addresses this and provides a recalibration routine.

@M3te0r in the meantime, I've worked around this limitation for testing my steps-dropping issue by having a Template Helper in Home Assistant that sets the Valve Closing degree to a {{ 5 + 0.95 * value }} for a 5% offset.

Did anybody get this to work with ZHA, or does this require Zigbee2Mqtt?

@ignisf I'm experiencing the same step dropping. Figured out that opening the valve to100% and then closing it completely does fix the issue but it only works for a while, then you have recalibrate the valve again. I guess the skipped steps ad up over time. Have you found a solution? Does your template helepr solve the issue?

@Riot2891 I am still monitoring without any modifications. For now I am observing that one of my TRVs needs a recal once a week.

@ignisf Thanks for the info. I guess our only hope is that sonoff makes the calibration function availible to zigbee. I will try to reach out to them through the ewelink forum, one of their developers is posting there.


Fix issue where empty dir name in s3 key breaks listdir api.

Tried writing this test case, but moto_service i think ignores these slashes anyway. Maybe somebody else will have a better luck with this test case.
def test_simple_with_empty_folder_name(s3):
    e_base_path = f"{test_bucket_name}//test"
    e = e_base_path + "/" + "e"

    data = b"e" * (10 * 2**20)

    with s3.open(e, "wb") as f:
        f.write(data)

    with s3.open(e, "rb") as f:
        out = f.read(len(data))
        assert len(data) == len(out)
        assert out == data

    dir_list = s3.listdir(f"s3://{test_bucket_name}//test")
    assert len(dir_list) > 0

So s3 has a wiered thing, one of our customers have key s3://bucket_name//test//some_data
With lstrip it removes those '/' but without that we can do a listdir.

Note that .find() should I think still work in these odder cases.

oh okay, I can try and see if that resolves the usecase. Mahor problem is that i am using it with pyarrow and fspec which will do a listdir.

okay I will give it a try, thanks for looking into it.


Add batch transactions to group creation

Description
To avoid timeouts when creating large amounts of groups it would be helpful to process them in batches.
Details
PR : https://github.com/keycloak/keycloak-benchmark/pull/41

@artur-baltabayev / @pedroigor - there has been a PR for this issue, still this issue is open. I wonder if this issue can be closed. Thanks!


Add filters

Implement filters by status, province, municipality and sex.

Frontend part of this ticket is not implemented yet


Never persist placeholder to store

@lazamar any idea why the test I mutated didn't fail? It looks like a lot of tests are never executed.

Seems that is because of this: https://github.com/fourlabsldn/fl-form-builder/blob/placeholder/gulpfile.js#L42-L44
The test src must be the test files, rather than the compiled source.

Actually, no. Forget what I said.

Maybe the reason is that you must first transpile the tests, to then run them.
Try this and see if it will run all tests:
gulp transpile-react:tests && gulp test-headless

Perfect, thanks!

@lazamar Babel has suddenly started joking on JSX. Can you help?

Broken:
yarn install
yarn test

Works:
npm install
npm test

🤷♂


Fix property names in README.MD

These property names are old, and they caused me a surprising amount of trouble :-/
The sample applications in the PCF SSO tile also need these properties updating (or did - I don't know if I had the latest version and if they've already been fixed).

@ipsi These properties are already updated in the branch https://github.com/pivotal-cf/spring-cloud-sso-connector/tree/releases/1.1.0.RELEASE
Develop is to support backwards compatibility with Spring Boot 1.2.x


Changes to create device memory buffers (if needed) and transfer data

@trevor-m @anijain2305

@trevor-m I agree we should just use NDArray functions. It is cleaner.

Thanks @ylc! Can you rebase so we can run the CI?