search

jmcollin78 / versatile_thermostat

A full featured Thermostat for Home Assistant: presets, window, motion, presence and overpowering management
MIT License
327 stars 34 forks source link

6.3.0: Changing preset will revert to other temperature ("period (0.0) min is < 5 min -> forget the regulation send") #519

Closed maia closed 2 weeks ago

maia commented 1 month ago

Version of the custom_component

6.3.0

Configuration

My VTherm attributes are the following:

hvac_modes:
  - "off"
  - heat
min_temp: 17
max_temp: 25
target_temp_step: 0.5
preset_modes:
  - none
  - eco
  - comfort
  - boost
current_temperature: 22.4
temperature: 23
preset_mode: boost
is_on: true
hvac_action: null
hvac_mode: heat
type: null
is_controlled_by_central_mode: true
last_central_mode: null
frost_temp: 0
eco_temp: 19.5
boost_temp: 23
comfort_temp: 19.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: 11.19341003798929
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: boost
saved_target_temp: 20
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: 120
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-10-02T17:58:03.418930+02:00"
last_ext_temperature_datetime: "2024-10-02T18:05:00.957734+02:00"
security_state: false
minimal_activation_delay_sec: 10
device_power: 1
mean_cycle_power: null
total_energy: 0
last_update_datetime: "2024-10-02T18:05:01.038395+02:00"
timezone: Europe/Vienna
temperature_unit: °C
is_device_active: true
ema_temp: 22.45
is_used_by_central_boiler: false
is_over_climate: true
start_hvac_action_date: null
underlying_climate_0: climate.wohnzimmer_eve_trv_thermostat
underlying_climate_1: null
underlying_climate_2: null
underlying_climate_3: null
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: true
friendly_name: Wohnzimmer Heizung
supported_features: 401

Describe the bug

I'm trying to: Change the preset for a vtherm device, e.g. from comfort to boost.

And I expect: It changes.

But I observe this .... It jumps back to a different temperature and "none" preset after 1-2 seconds. Only the second attempt of chaging the preset works. The first never works.

Debug log

Here are logs for a single climate device, below I'll attach the log for all my devices and a 5 minute period in which I tried to change the presets.

17:57:53 - Set preset_mode: boost force=False
17:57:53 - find preset temp: boost
17:57:53 - Calling ThermostatClimate._send_regulated_temperature force=True
17:57:53 - regulation calculation will be done
17:57:53 - Regulated temp have changed to 23.0. Resend it to underlyings
17:57:53 - Sending event EventType.PRESET_EVENT with data: {'preset': 'boost'}
17:57:53 - Calling ThermostatClimate._send_regulated_temperature force=False
17:57:53 - period (0.0) min is < 5 min -> forget the regulation send
17:57:55 - Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None
17:57:55 - Target temp in underlying have change to 20.0
17:57:55 - Set target temp: 20.0
17:57:55 - Calling ThermostatClimate._send_regulated_temperature force=True
17:57:55 - regulation calculation will be done
17:57:55 - Regulated temp have changed to 20.0. Resend it to underlyings
17:57:55 - Calling ThermostatClimate._send_regulated_temperature force=False
17:57:55 - period (0.0) min is < 5 min -> forget the regulation send
17:57:55 - Calling ThermostatClimate._send_regulated_temperature force=False
17:57:55 - period (0.0) min is < 5 min -> forget the regulation send
17:57:57 - Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None
17:57:57 - underlying event is received less than 10 sec after command. Forget it to avoid loop
17:57:58 - Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None
17:57:58 - underlying event is received less than 10 sec after command. Forget it to avoid loop
17:58:00 - Calling ThermostatClimate._send_regulated_temperature force=False
17:58:00 - period (0.1) min is < 5 min -> forget the regulation send
17:58:03 - Set preset_mode: boost force=False
17:58:03 - find preset temp: boost
17:58:03 - Calling ThermostatClimate._send_regulated_temperature force=True
17:58:03 - regulation calculation will be done
17:58:03 - Regulated temp have changed to 23.0. Resend it to underlyings
17:58:03 - Sending event EventType.PRESET_EVENT with data: {'preset': 'boost'}
17:58:03 - Calling ThermostatClimate._send_regulated_temperature force=False
17:58:03 - period (0.0) min is < 5 min -> forget the regulation send
17:58:04 - Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None
17:58:04 - underlying event is received less than 10 sec after command. Forget it to avoid loop
17:58:35 - Calling ThermostatClimate._send_regulated_temperature force=False
17:58:35 - period (0.5) min is < 5 min -> forget the regulation send
17:59:00 - Calling ThermostatClimate._send_regulated_temperature force=False
17:59:00 - period (0.9) min is < 5 min -> forget the regulation send
18:00:00 - Calling ThermostatClimate._send_regulated_temperature force=False
18:00:00 - period (2.0) min is < 5 min -> forget the regulation send```

home-assistant_2024-10-02T16-00-55.234Z.log

maia commented 1 month ago

I'm starting to wonder if vtherm subtracts the last auto-regulation value (from last winter) from the target temperature sent to the TRV, altough auto-regulation is turned off.

jmcollin78 commented 1 month ago

Hello @maia ,

what happens is that, your TRV change its target alone and VTherm follows this change. Maybe someone change the target directly on the TRV, maybe the TRV itself change this target value (is there a internal regulation mecanism in Eve TRV ?);

17:57:55 - Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None
17:57:55 - Target temp in underlying have change to 20.0
17:57:55 - Set target temp: 20.0
17:

in the log we can see that the underlying have change to 20.0 (Target temp in underlying have change to 20.0 ) and Vtherm have follow this 20.0 (Set target temp: 20.0)

maia commented 1 month ago

Nope, that's not it. I didn't touch the TRV and it does not change its target temperature by itself. The issue seems to appear when turning off self regulation. I just tried again:

  1. Target temperature in HA was 21.5, with vtherm self-regulation ("slow") the TRV was set to 23.5.
  2. I turned off self-regulation in vtherm. The exact moment I saved the TRV went to a new target temperature of 20.0°C, although HA still showed "comfort 21.5°C"
  3. I switched from comfort (21.5°C) to boost (22.5°C) in HA. The TRV lowers its target temperature instantly to 19°C (!). HA shows "preset: manual" with a target temperature of 20.5°C.

This weird behaviour shows up when disabling self-regulation.

Ra72xx commented 1 month ago

Subscribing because of https://github.com/jmcollin78/versatile_thermostat/discussions/507

Ra72xx commented 1 month ago

Because of @maia 's hint, I experimentally switched to enabled self regulation for one TRV group which fixed this issue for me. But afterwards, I was not able to disable self regulation again. At first, only that one VT could no longer be set up because of a "faulty configuration". After a restart of HA, all VTs could no longer be setup. I had to uninstall all configurations and reinstall and reconfigure the VT custom integration to get it working again. Unfortunately I did capture no logs as I wanted to get everything working again as fast as possible. So now I have a completely fresh installed VT which never had self regulation enabled, but the problem is there from the beginnig again.

While wrriting this, I notice that over night almost all VT units have gone offline again. The log looks like this: 

2024-10-04 20:53:08.388 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Central configuration for versatile_thermostat
2024-10-04 20:53:09.571 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry WZ: Smart Thermostat for versatile_thermostat

The log also contains eintries like

2024-10-04 20:53:09.875 WARNING (MainThread) [custom_components.versatile_thermostat.base_thermostat] VersatileThermostat-SZ: Smart Thermostat - Undefined target temperature, falling back to 5.0

which is strange, because all the temperatures have been setup by the integration ui. I don't know what happened at 20:53 so mess up VT.

Moreover I wonder what the log entries like

2024-10-04 20:53:09.906 WARNING (MainThread) [custom_components.versatile_thermostat.pi_algorithm] Temporarily skipping the self-regulation algorithm while the configured sensor for room temperature is unavailable

mean, because the self regulation isn't enabled at all and the temperature sensors seem to be online.

These errors happen for all my configured VTs including the central configuration. Only one VT which has been turned off all the time and another one which has the same configuration like all others but has no "window open" detection still have no configuration error..

I then reconfigured the central configuration and switched "window open detection" from "0" to "-1" (yes, you can set this to negative values with the buttons....) and back to "0", and now all VTs are back online again.

Something strange is definitely going on with the central configuration...

jmcollin78 commented 1 month ago

ok. i will try to reproduce with your explanations. Not sure this have a link with the @maia issue.

Ra72xx commented 1 month ago

There seem to be two problems for me, I don't know if they are related:

Ra72xx commented 1 month ago

I grepped for Versatile in homeassistant.log for the last two days, maybe this contains helpfull information: errors.zip

maia commented 1 month ago

There seem to be two problems for me, I don't know if they are related:

Interestingly as you I am experiencing both those issues, so maybe they are related.

  • About once a day some of the VT units at first go rather silently offline (no sensible entries to be seen in the lovelace card, no more working temperature regulation). Then I change something in the central configuration, which leads to "configuration errors" for most of the VTs. Then I change this central configuration value once again back, and everything is fine again. This happens regardless of the self regulation settings.

I'm seeing this after HA restarts. I've added an automation that will reload the vtherm configuration a few minutes after restarting HA. Can you check if reloading the yaml configuration (in developer tools) get's everything back to okay for you too?

Ra72xx commented 1 month ago

I'm seeing this after HA restarts. I've added an automation that will reload the vtherm configuration a few minutes after restarting HA. Can you check if reloading the yaml configuration (in developer tools) get's everything back to okay for you too?

Just tried it out - you're right, this way I can reproduce both the error and the workaround!

Ra72xx commented 1 month ago

Unfortunately, only an hour later, the VT thermostats are offline again without any action ny myself. I also noticed that suddenly the features "Power management" and "Presence detection" are enabled fot the VTs (I never enabled or used that) and can't be disabled any more...

This time I was able to "heal" it by reloading some of the non-working VTs. This also fixed the issue with the erraneaous enabled festures.

Something is very, very wrong here :-/ ...

EDIT: Problem was not fixed, there was just no more error on the devices page. However, VTs and real TRVs were not really connected to each other. I once again try to re-install and re-create a working setup.

Ra72xx commented 1 month ago

So... I deleted all VTs, re-installed the custom integration. and then recreated the VTs. From the very first moment the log was filled with errors like this: errors.txt.zip Once again this error could be resolved by changing and re-changing some settings of central configuration (probably reloading the yamls would have done the job, too). It is as if VT has problems interpreting/writing its own configuration.

jmcollin78 commented 1 month ago

Hello @Ra72xx ,

I will give a closer look to your logs. Sorry for not being so much available for this issue.

I will try to review all your comment and see with the log what happens.

EDIT: are the logs still relative to the title of this issue ? I wonder if you have change the subject ?

EDIT 2: the log says

temp_cond: bool = delta_temp > self._security_delay_min or (
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '>' not supported between instances of 'float' and 'NoneType'

So it seems that self._security_delay_min is not well initialized. What is the value you expect to see here ? Can you give me the attributes of your VTherm (Debug Tools/State) and for the central configuration also if you use it

EDIT3: because it is correctly set in the @maia first post, I guess this is another issue. I think the best is to open a new issue.

EDIT4 : this attribute self._security_delay_min is mandatory and cannot be None. You have a serious configuration issue. It is initialized at startup:

self._security_delay_min = entry_infos.get(CONF_SECURITY_DELAY_MIN)

and then used in the security (safety) check:

temp_cond: bool = delta_temp > self._security_delay_min or (
            is_outdoor_checked and delta_ext_temp > self._security_delay_min
        )

Nothing have change for years around this.

jmcollin78 commented 1 month ago

I will come back to original post of @maia now.

Nope, that's not it. I didn't touch the TRV and it does not change its target temperature by itself. The issue seems to appear when turning off self regulation. I just tried again:

  1. Target temperature in HA was 21.5, with vtherm self-regulation ("slow") the TRV was set to 23.5.
  2. I turned off self-regulation in vtherm. The exact moment I saved the TRV went to a new target temperature of 20.0°C, although HA still showed "comfort 21.5°C"
  3. I switched from comfort (21.5°C) to boost (22.5°C) in HA. The TRV lowers its target temperature instantly to 19°C (!). HA shows "preset: manual" with a target temperature of 20.5°C.

This weird behaviour shows up when disabling self-regulation.

If I (re) look at your logs what happens is clear:

First you change the preset: Set preset_mode: boost

then, the regulation calculation try to send 23°: Regulated temp have changed to 23.0. Resend it to underlyings

then, because there was already a command send to TRV in the last 5 minutes, this command is discarded: period (0.0) min is < 5 min -> forget the regulation send

then, 2 sec later, without any command from VTherm, your TRV decide itself, alone, on its behalf to change its target temperature: `Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None``

then VTherm follows the new target temp from your TRV which is set to 20°: 17:57:55 - Target temp in underlying have change to 20.0

I guess EVE TRV have internal regulation algorithm than is conflicting with VTherm.

It seems that your EVE TRV is sending its internal state every 2 seconds.

This mecanism prevent VTherm for looping due to the conflict. I will be able to do anything on this. I would like you to confirm what I see. If yes, I will write a disclaimer on EVE TRV in the Read-me. I'm so sad about this bad news.

Ra72xx commented 1 month ago

Thanks for the feedback, however for the time being (as I need a controllable TRV :-/ ) I have converted my setup to more simple and probably more robust templates. Maybe this is even a better solution, as I don't use that self-regulation stuff. I will continue montoring this issue, however.

maia commented 1 month ago

then, 2 sec later, without any command from VTherm, your TRV decide itself, alone, on its behalf to change its target temperature: `Underlying climate climate.wohnzimmer_eve_trv_thermostat changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None`` … I guess EVE TRV have internal regulation algorithm than is conflicting with VTherm.

I have been using these Eve TRV for a few years now and I didn't have any issues last winter with vtherm 4.x, it only appeared a few months ago when the new heating season started, I upgraded vtherm 4.x to 6.x and upgraded the Eve TRV firmware from Homekit to Matter. As you might remember, the development of the auto-regulation feature in vtherm was something I actively supported. Everything was working fine last year. That's the confusing part.

I tried to reproduce the issue right now while filming it, but didn't manage to reproduce it on the TRV I currently have access to. I had the issue with two other TRVs which I can't access tonight. I will re-check these in the next few days.

The Eve Thermo TRV has an internal PID algorithm that regulates the valve opening percentage. But I've never before seen it change the (visible) target temperature itself. I have no explanation why a switch from comfort to boost lowers the target temperature on the TRV and the vtherm device switches to "manual" and displays another temperature – and only with self-regulation turned off.

I will re-attempt to disable self-regulation for all TRVs this weekend, in case it's not too warm for heating, and will get back to you.

jmcollin78 commented 1 month ago

I have been using these Eve TRV for a few years now and I didn't have any issues last winter with vtherm 4.x, it only appeared a few months ago when the new heating season started, I upgraded vtherm 4.x to 6.x and upgraded the Eve TRV firmware from Homekit to Matter. As you might remember, the development of the auto-regulation feature in vtherm was something I actively supported. Everything was working fine last year. That's the confusing part.

Yes. This is really strange. Before 6.3, VTherm always send an interval of temperature with the target. When changing the target temp to 20°, VTherm was sending target temp to 20° and min_temp and max_temp, even if the climate doesn't support a feature name TARGET_RANGE. That is now controled by HA 2024.10 and that is what I fix in 6.3.0. Now, if you climate doesn't support the TARGET_RANGE, VTherm only send the target value (and not min_temp and max_temp). This is what was expected by HA.

I guess this change have now an impact on how the internal regulation of your TRV works.

Your TRV have this feature: supported_features: 401 and 401 means it doesn't support the TARGET_RANGE. Here are the code:

class ClimateEntityFeature(IntFlag):
    """Supported features of the climate entity."""

    TARGET_TEMPERATURE = 1
    TARGET_TEMPERATURE_RANGE = 2
    TARGET_HUMIDITY = 4
    FAN_MODE = 8
    PRESET_MODE = 16
    SWING_MODE = 32
    AUX_HEAT = 64
    TURN_OFF = 128
    TURN_ON = 256

401 = 256 + 128 + 8 + 1

Donc l'appel vers ton climate a maintenant changé. Avant, il y avait les 3 paramètres: target, min, max et maintenant il n'y a que target.

jmcollin78 commented 1 month ago

Maybe related to https://github.com/jmcollin78/versatile_thermostat/518 I not sure because your underlying thermostat don't use the TARGET_TEMPERATURE_RANGE but there is a 'huge' bug since this release on the same part of code.

I have done a fix https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta2 that restore the behavior before 6.3.0 which was working well for you.

Ping @maia , @Ra72xx

KipK commented 1 month ago

This looks somehow related to the other bugs I've posted too.

  • About once a day some of the VT units at first go rather silently offline (no sensible entries to be seen in the lovelace card, no more working temperature regulation). Then I change something in the central configuration, which leads to "configuration errors" for most of the VTs. Then I change this central configuration value once again back, and everything is fine again. This happens regardless of the self regulation settings.
  • The issue described here: Settings/presets can no longer be set reliably and are reset after a few seconds as long as there is no additional self regulation by VT. Once self regulation is enabled, everything works.

I've also noticed those 2 behaviors yesterday.

jmcollin78 commented 1 month ago

This looks somehow related to the other bugs I've posted too.

  • About once a day some of the VT units at first go rather silently offline (no sensible entries to be seen in the lovelace card, no more working temperature regulation). Then I change something in the central configuration, which leads to "configuration errors" for most of the VTs. Then I change this central configuration value once again back, and everything is fine again. This happens regardless of the self regulation settings.
  • The issue described here: Settings/presets can no longer be set reliably and are reset after a few seconds as long as there is no additional self regulation by VT. Once self regulation is enabled, everything works.

I've also noticed those 2 behaviors yesterday.

Have you tried with the last 6.3.4 beta release ? It is fixing a huge bug around this feature: https://github.com/jmcollin78/versatile_thermostat/518

KipK commented 1 month ago

not yet, wasn't aware of it. I will tomorrow

jmcollin78 commented 1 month ago

Hello guys,

I don't know if you have seen this, and I don't have it in mind, but a self-regulated VTherm don't follow its underlying temperature changes: https://github.com/jmcollin78/versatile_thermostat/issues/478 (because target temperature send by VTherm is NOT the desired temperture of the user).

jmcollin78 commented 2 weeks ago

Hello, may I close this issue ? Have you still the issue on your side ?

maia commented 2 weeks ago

@jmcollin78 Thanks for asking. I've not seen the issue with recent versions, I will close it.