VT reverting settings like target temperature all the time

[Ra72xx]

Now that the heating season is starting again, I notice that I'm no longer able to control VT reliably. It worked last year pretty well, I don't know what changed since then.
Most of the time I try to do some settings, e.g. set a new target temperature, VT only seconds later reverts to the previous value. It only works sometimes, after several attempts. This also includes stuff like window open temperature, which in many cases does not work, because the temperature is also reverted again.
I use Aqara thermostats with Zigbee2MQTT. Controlling the thermostats directly with Z2M works.
Anybody else experiencing this?

[jmcollin78]

Since last year, many things have change. The most important feature you have to look is the temperature setting which are now as entities of the VTherm. Maybe you have to look there.
You should also read the evolutions on readme.

I already starts heating on my side and I don't experience your point.
if you cannot solve your issue please post me the attributes of your VTherm (Tools / States)

[Ra72xx]

I attach a debug log: The interesting device is "WZ: Smart Themostat", which combines "WZ: Themostat 1" to "4". It should lower the temperature from 21.5 to 12.0 at the end of the log, because the configured door sensor is opening. That happens for a few seconds, and then the temperature is reverted to 21.5.

home-assistant_versatile_thermostat_2024-09-28T12-28-53.742Z.log

[jmcollin78]

Hello @Ra72xx

When looking at the log you provide in #507, i see man log like:

underlying event is received less than 10 sec after command. Forget it to avoid loop

This is a safety to avoid loop and when you are doing some tests of your device, you should NOT change target temperature to often.
You have to wait at least 10 sec between each test. I guess this is what happens here.

[Ra72xx]

Well, but in fact I don't do anything like testing or so. I just e.g. set the temperature to some preset, or VT itself sets a new temperature value because windows are open. There is no more interaction going on. And, well before 10secs have passed, more like 2 or 3 seconds, in many cases the temperature change is being reverted. I don't really understand why the loop detection is fired at all.

[Ra72xx]

Thermostat config (a thermostat group with four thermostats, but also happens in single thermostat constellations):

hvac_modes:
  - "off"
  - heat
min_temp: 5
max_temp: 30
target_temp_step: 0.5
preset_modes:
  - none
  - frost
  - eco
  - comfort
  - boost
current_temperature: 22.3
temperature: 21.5
preset_mode: comfort
is_on: true
hvac_action: null
hvac_mode: heat
type: null
is_controlled_by_central_mode: true
last_central_mode: Auto
frost_temp: 12
eco_temp: 19
boost_temp: 30
comfort_temp: 21.5
frost_away_temp: 0
eco_away_temp: 0
boost_away_temp: 0
comfort_away_temp: 0
power_temp: 13
target_temperature_step: 0.5
ext_current_temperature: 14.19
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: comfort
saved_target_temp: 19
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.wz_offnungssensoren
window_delay_sec: 3
window_auto_enabled: false
window_auto_open_threshold: 3
window_auto_close_threshold: 0
window_auto_max_duration: 30
window_action: window_frost_temp
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0.1
last_temperature_datetime: "2024-09-30T19:46:22.222038+02:00"
last_ext_temperature_datetime: "2024-09-30T19:31:55.819796+02:00"
security_state: false
minimal_activation_delay_sec: 10
device_power: 0
mean_cycle_power: null
total_energy: 0
last_update_datetime: "2024-09-30T19:46:22.237247+02:00"
timezone: Europe/Berlin
temperature_unit: °C
is_device_active: true
ema_temp: 22.28
is_used_by_central_boiler: false
is_over_climate: true
start_hvac_action_date: null
underlying_climate_0: climate.wz_thermostat_2
underlying_climate_1: climate.wz_thermostat_1
underlying_climate_2: climate.wz_thermostat_4
underlying_climate_3: climate.wz_thermostat_3
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
friendly_name: "WZ: Smart Thermostat"
supported_features: 401

[Ra72xx]

Replying to myself: @jmcollin78 In addition to the reverting settings, I just noticed that I can't change the value window_delay_sec, which is in central configuration for me. I tried to set this value to 0 to avoid possible delayed interactions with other automations (time schedule), as the 3 secs I've set up here are suspiciously close to the time until the settings revert. In fact all the settings in "Central window open management" can't be changed by me, e.g. I have some auto window open settings in there which I don't use and I now cannot get rid of.
Any idea why this is happening?

[jmcollin78]

Maybe you have the same problem as @maia in this issue: #519

Don't know why but sometimes the underlying device is changing itself the target temperature and VTherm follows this change (this is feature and not a bug)

[maia]

I'm seeing you have self-regulation set to off. Has it been on previously? My theory that there's a bug when self-regulation is on and then being turned off.

[Ra72xx]

My TRVs don't have the offset option, but work pretty well when combined with an external temperature sensor, so I'd like to leave it up to them how they operate to reach a target temperature.
For me in many cases the additional self-regulation stuff of VT is more like a nuisance. Right now I use "light" self regulation and it seems that the TRVs are being operated much more often than before, as if VT and the internal algorithms work against each other..

[jmcollin78]

that's why I'm hoping @jmcollin78 will find a way to run the self-regulation by using the offset/calibration-variable some TRVs have

I found no generical way to do that. This offset is not a generical feature but is present only with different name on some TRV. So it is a hard point.

EDIT: maybe another configuration in expert mode (with .yaml configuration) is possible. The bad think, is that I'm not able to test that, I don't have this on my home. Can you show me in Development Tools/States the offset calibration variable you have on your installation ? Ping @maia

[jmcollin78]

as if VT and the internal algorithms work against each other..

I already have this case. I think I wrote something on the Readme about that :
Danfoss POPP valves with temperature feedback. It is impossible to turn off this valve and it self-regulates, causing conflicts with the VTherm,

Maybe you run into this case.

[Ra72xx]

as if VT and the internal algorithms work against each other..

I already have this case. I think I wrote something on the Readme about that : Danfoss POPP valves with temperature feedback. It is impossible to turn off this valve and it self-regulates, causing conflicts with the VTherm,

Maybe you run into this case.

Well, yes, but that's what I want to disable all self regulation done by VT and rely on the internal mechanisms of the TRV. But seemingly this mode of operation (which should be the simplest way of doing things) does not really work well for me and at least @maia.

[maia]

I found no generical way to do that. This offset is not a generical feature but is present only with different name on some TRV. So it is a hard point.

EDIT: maybe another configuration in expert mode (with .yaml configuration) is possible. The bad think, is that I'm not able to test that, I don't have this on my home. Can you show me in Development Tools/States the offset calibration variable you have on your installation ? Ping @maia

The Home Assistant Matter integration currently does not yet expose the calibration offset for Eve Thermo, but @lboue did get it to work and just didn't yet have time to add all necessary tests to commit it to the project. But as this feature is important for me, I am considering the purchase of Sonoff TRVZB or Avatto TRV16/TRV06/TRV16-T/TRV168 (?), as the zigbee2mqtt docs show that they expose this variable, see local_temperature_calibration at https://www.zigbee2mqtt.io/devices/TRVZB.html . I know that if vtherm doesn't support it, I might have to write my own automations to use instead of vtherm.

The self-regulation is just too confusing if the TRV shows e.g. 24°C (self-regulated) target temperature when someone wants to reduce the target temp from 21°C to 20,5°C. Try to explain grandparents why the TRV shows a different temperature than the target temperature for the room. This is why I was trying to turn off the self-regulation (although it's working great) and ran into that vtherm bug.

As the variable name for the calibration offset does not seem to be standardised, I can imagine adding another configuration field to the "underlying" section of the vtherm configuration where one can enter this entity. As long as there is nothing entered there, everything will work the same way it's working now. But when providing an offset entity, vtherm will simply use that for the self-regulation feature.